New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible extensions in the Brouter with news tags #486
Comments
I'm sorry for the delay. It's not that I haven't heard the wishes. So all I can say is: yes, I'm interested, I find it useful, it might start for me after 1.6.4 |
Thank for your reply and interest! |
Hello, I think, my prototype using the new tag "estimated_noise" is now running!
|
What did you do for that? I had some time in longer train runs. So I started investigation on this issue as well. |
Hello, Enclosed a short description of my first tasks (add "estimated_noise_class") I had only to create this new script to add the new tag in OSM (perhaps you can reuse the programm used by Arndt for "estimated_traffic_class" OsmTrafficMap.java?? , but it was for me simpler to use a new script) Further tags (river, forest..) are also prepared... |
estimated_traffic_class is injected in the "WayLinker" step, the very last step of preprocessing, but the first step where the ways and their geometry are together. But at this step, the way-id is no longer present. There's another step where I inject pseudo-tags (the relation-pseudo-tags): RelationMerger.java At this step there is no geometry, but there is the way-id. So if you have a preprocessor that generates pseudo-tags connected to the osm-way-id, then that' proabably the best location to inject them. estimated_traffic_class is not a succes story. I had a hard time integrating it into the preprocesor without adding too much latency, I has problems with a "noisy" behaviour blowing up the rd5-delta files. And I never achieved world-coverage, but only europe. |
sorry if you have your data ready the best location i of course the very first step of preprocessing ( see OsmCutter.generatePseudoTags ) Relation merging must be done in a later step because when reading the PBF-File, the relations appear after the ways. |
@EssBee59 I started an other way - the BRouter classic way. At the moment I thinking about the relation problem @abrensch annouced. The repo follows. |
hello, I could generate RD5 files for Germany containing the new tags (noise, river and forest) |
@ abrensch: Thank for the help! (with a new “OsmCutter.generateSpecialTags” and using a JDBC connection to postgresql to get the new tags) Example for Germany map, into 17.831.000 “highway” objects 10.405.000 new tags are added |
new documentation for the tag-calculation: |
Thanks for update and for the report, sounds good. I'm still fixed on the Dreieich test data. |
I'm now prepared to use database export/import. Used this 'green' filter for import - should be discussed:
I ended up in the same problems with timing. No profile with extra data for now. I only control on output. Please see my repository @EssBee59 |
Hello! Yes, the green filter for import is a good idea, as it will reduce the size of the planet_osm_table. my tasks / test in the last weeks: A- I could install a “test” instance with 3 new tags on the BRouter server Restriction: currently only the rd5 from Germany are installed My prefered test cases: B- I also tried to generate the new tags for “Europe” I think 2 problems occur there: Test database parameter: To minimize the memory need I tried to work without “parallel seq scan” (by ==> adding max_parallel_workers_per_gather = 0), but same result as whis parallel scan. I will try another way: split the big pbf file (Europe or planet), as example with squares of max 10 degres, calculate the new tags for each square and concatenate the results in a single table. Could this be a way to proceed? (I made some changes in the sql´s and in OsmCutter.java: do you need the last versions to test?) |
Yes, I think so. A bounding box for the database generation is needed. I already have a database function for the BRouter tile index logic (see OsmCutter.getNameForTile) to split BRouter incoming extra data files.
Would be nice, please let me know. |
Here the sql and java!
noise.sql.txt |
About splitting... |
Thanks for the files. You didn't use an extra index is that correct? My focus at the moment is to reduce database size (brouter.style imports only used columns) and make some index to decrease the import speed. But it's still a lame duck in my eyes. Please see scripts in misc folder |
Hello afischerdev, As I was not satisfied with the behaviour of the database qith big tables ( select's hang often) I redesigned my database and the sql´s. A question: Do you see a need for this tag? |
Nice idea. I enabled population in my scripts (brouter.style and brouter_start.sql). |
Hello, strange, in the table planet_osm_polygon only few cities are stored using the "default" import:
we have possibly to make changes in the import of osm2pgsql? |
I promised my new SQL version! (interesting if you want to generate europe in one step with few RAM) Note/ prerequisites to generate europe: |
Frankfurt: I think we could make an update on the polygon data. Something like this
But this is also covered with questions: |
A note on relations: From the 'Dreieich' data I focused on relation 6831654 and way 148463112. The relation contains four ways and two of them have no tags. In the past I have tried to generate these. Now on database use I see the database import already give a path to the relation. I like that feature. It doesn't require a second pass and is ready to use. But another 'little problem' arises. If a relation has a tagged way, the same constellation appears twice.
Other remark on 'green factor' A way inside a forest like 1082304710 this is the best we can reach.
|
One more remark on Darmstadt. I collected all greens inside the Darmstadt polygon and wrote it to an extra table:
And then the difference from the original Darmstadt polygon gives this geojson file - view at https://geojson.tools/ file import. |
Hello, thank for the update! curently I get for Germany the following cities order by population: |
@EssBee59 |
Hello, I had a look at trekking.brf: I would also change the order of the "options" in the profile, as I think consider_elevation, consider_traffic, etc.. should be on the top of the list |
@EssBee59 |
This is currently my best attempt at customizing my profile to use the new tags: https://paste.rs/xyLAx @EssBee59, the following trick seems to reduce the negative impact of town tag problematic to a reasonable level:
|
Hello Norbert, I could create a prototype based on your first concept above! Perhaps can some expert solve the two problems / limitations remaining: EssBee |
@EssBee59, I already found an issue (openstreetmap.org/#map=15/49.83/8.61): But the solution is probably not trivial, because the cause seems to be that some of the ways are short (like this one: w23638256) and do not come close to the forest boundary, and some of the ways are long (like this one: w23638257) and do come close to the forest boundary. So we either have to split the ways (which seems impractical) or we have to generate more info than just a single class number per way id, which is not much better. |
Hello qualnix! The problem is now fixed, retest is possible . |
@EssBee59, ok, try this: 148.251.191.149/brouter-web/#map=16/49.8310/8.6126/...
|
Fix is only applied to the visualisation!
RD5 will be updated later
quaelnix ***@***.***> schrieb am Mo., 12. Juni 2023, 14:16:
… @EssBee59 <https://github.com/EssBee59>, ok, try this:
148.251.191.149/brouter-web/#map=16/49.8310/8.6126/...
<http://148.251.191.149/brouter-web/#map=16/49.8310/8.6127/standard&lonlats=8.613551,49.830104;8.612154,49.831068&profile=quaelnix-gravel>
1. Segment: estimated_forest_class=4
2. Segment: estimated_forest_class=5
—
Reply to this email directly, view it on GitHub
<#486 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AL75PSH6G7CRJ3VS5K6YWBTXK4CDNANCNFSM6AAAAAASFGIZMY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hello, Tests are possible on the old server (using forceSecondaryData=true) or on the new server http://148.251.191.149/brouter-web/ Some problems were solved for visualization, the known restrictions are now displayed. http://148.251.191.149/brouter-web/PseudoTags.html EssBee |
Great! But the problem of "long ways that protrude the forest border" is still unsolved:
To solve this reasonably well, we would at least need to calculate separate estimated class values for all way segments between each two consecutive nodes of the ways. |
I never consired changes in the granularity of the OSM highways: The calculation of the tags with the current state is allready complex and computing-intensive. Sorry, I can not help if you absolutly need higher granularity |
Yeah, no worries, the new tags are already pretty amazing. I can't wait to play around with the new toolchain. Ok, one more suggestion about the forest tag: would it be possible to reserve the higher |
Hello, Yes, the solution choosen ("green character") is not the perfect" solution for EVERY body; We had a discussion about "nature_reserve": not considering it should lead to loose in Germany the "Kühkopf" and really green domains. The effort to create a tag for each geen-type would be high ...cost processing and space in the RD5. Note: the restrictions in the visualization-page could be removed! |
Hello! But these changes are very limited / have low impact, and a delay of 2 days or more occurs before the tags are available in the RD5. This is not perfect, but the enhancements become only visible on the brouter-server (where also the "visualization" of the tags is supported) As soon a stable / better version is available, it will be saved in github (my contact is affischerdev for that) |
There was no change for the town tags in the last weeks. If you find some thing wrong please explain the point Regards |
Two weeks ago the following logic was used: brouter/misc/scripts/mapcreation/brouter.sql Lines 612 to 615 in e66468b
Pfungstadt (population: 24885) | Eberstädter Straße:
... but it's not an error according to the new logic you just posted.
It would be great if you would share the thought process that goes into the development of brouter.sql with us. |
Quaelnix! About he "tought process": many documents are allready available, see at the begin of this thread, and the comments in the all.sql file. I have no plan to write more documentation: With the visualization tool every one can check the tag values, and every one with basic OSM and SQL knowledge can follow the "thought process" step by step... |
Sorry, but the latest update to brouter.sql (e66468b) does not contain the code you posted above. So somewhere in the last 6 months the code that @afischerdev uploads to this repository and the code you develop must have diverged.
Yes, that's all fine, but I find it a bit unfortunate that the development of the brouter.sql takes place outside of this repository - invisible to all other developers. This leads to a lot of duplicate work, because we don't know what has already been tried or why some choices where made over others. |
I posted above the logical result of the 2 SQL#s, not the current code that was NOT changed |
What I do understand is that it makes no sense that this segment: is is
You are right, the 50k logic is present in the current code: brouter/misc/scripts/mapcreation/brouter.sql Lines 620 to 622 in e66468b
|
In this way, rivers and parks are automatically favored because their presence inevitably reduces the building density.
And we would no longer be affected by the rampant problem of "tagging for the renderer". |
Hello,
I would like to discuss extensions in the brouter!
Many enhancement-requests are already posted, here some examples:
Noise #476
Green area #258
Round trip #460
In the following I will consider (as example) these 3 enhancements:
-consider the noise / pollution on the route
-consider a river or see on the side of the route
-consider the "green" aspect of the route (within a forest or park…)
The basic idea is to introduce new calculated (or estimated) tags in the RD5 files.
(in a similar way as the existing tag „estimated_traffic_class»)
Of course, the routing engine have also to be extended in order to support these tags, and the profiles have to use them according to the preferred route.
1- The first challenge is to calculate / estimate the tag values for the concerned highways:
I started some tests and this seems possible(see documentation in pdf file):
documentation was updated
2- Extension of the RD5 files with the new tags
3- Extension of the routing engine to support the new tags (+ lookups.dat)
4- Extension of profiles
Next steps:
A first look at the results of the spatial-SQL´s (GIS) is very promising: the calculated values for the new tags seems good and usable.
-a decision, which tags exactly should be implemented, can be made later
-a further challenge is the calculation of the tag value for the planet, as it will take a lot of time!
So I suggest next to test the impact of the tags « noise » and « river » on the routing within a regional osm-map (as example 30 km * 30 km).
The tags values are available, but implementing Extension(2) and (3) is prerequisite to start “real” tests.
Is anybody ready to work on this extension / to create a prototype for testing(Extensions 2 and 3)?
The text was updated successfully, but these errors were encountered: