Some of these tools appear to be oriented for specific things like POIs, etc., so rather than going through every tool I’m hoping someone might be able to save me that trouble.
I am interested in any and all road conflation whether it’s just importing a new housing development into JOSM, or a python/C++ program to compare/analyze and suggest possible changes for a whole county.
I have a separate test server of OSM running, so I won’t be publishing my tests to production.
Probably good to start not with the process, conflation, but what you want to accomplish with it in the end as that is way more import before choosing the tool.
If for instance is your goal to give the community a tool based on opensource government data, this might be the way to do it:
My objectives are:
-adding missing roads
-updating road polylines for ways that aren’t accurate.
-adding meta data like speed limits
Sometimes the road way in OSM is 100-200 feet off of the road, and the county has a shapefile that is dead center. There are many county governments that have roads with excellent data, but OSM has not been updated since the original tiger import. I would update the way to have the exact path of the road.
I am capable of building conflation tools, and I already built some simple stuff. I don’t want to rebuild the wheel if someone else already has excellent tools though. I’m going to start testing tools regardless, but I would appreciate anyone who has done it to point me in the right direction.
That is exactly where the “scheve wegen” layer provides that I linked in my reply above, the good thing is that that layer is also shared so other can help. I know @PeeWee32 is using QGis for that, you might contact him.
The analysis I made was all done in Postgis. I download OSM data (pbf file) from geofabrik and import in postgis using osm2pgsql. I also have a (monthly refreshed) postgis database with public and (mostly) accurate NL data of many objects including highway polygons (called BGT). In a postgis sql script I compare these datasets en publish the results in Qgiscloud so that others can help using the webmap, WMS (e.g. for use in JOSM/Qgis) or WFS. The kind help I got for this was:
Old question, but adding a link to a tool used in Norway and Sweden: GitHub: highway_merge
The -new argument produces files with all highways not in OSM.
The -tagref and -taglocal argument produces files where highways tags in OSM are updated (for example modified speed limits or new bicycle lanes).
Missing highways are tracked on this wiki page on a monthly basis.
Also, each month the source data from the public road administration is checked with another script to discover new highway segments which were not present in that dataset last month. This is the main source of adding highways in Norway after new constructions or upgrades have been completed.
All updates we do involves as a last step manual verification + connecting new ways to the existing highway network in OSM, as automatic conflation of ways can be a tricky.
At a quick glance, the highway_merge github looks very promising. It’s seems to be what I was looking for. I’ll check it out more, and hopefully it works good. I’m surprised I couldn’t find it before, but that’s why I’m here
Before a bike trip, I plan a route with BRouter and notice that on many parts of it, the road surface is not known in OSM
During the bike trip, I take note of all the road surfaces I encounter (which is relatively easy, most of it is asphalt so I just need to make markings at the beginning and end of non-asphalt sections)
After the trip, I would like to add this data to OSM. I would like to conflate my GPX track to the OSM road network, so that I can then easily add the surface where it is missing.
So for me, a JOSM plugin for road conflation would be ideal. Of course one needs to be careful when bike paths or sidewalks are mapped separately because they’d be quite close to the main road and their surfaces often differ, but if I supply the exact same GPX file as the one I downloaded from BRouter, the track should match OSM’s geometry pretty much exactly.
If brouter routes the roads, they must already exist in OSM. Your gpx-track does not add information, it only duplicates what is already there. I would think just adding the right surface tags to the existing ways in OSM, is the way to go.
If the gpx contains waypoints where the surface changes, it may help to open it with JOSM as a reminder of the exact location where the surface changes.
I track my hikes and take pictures of mappable objects and attributes, simply with my mobile. Afterwards I load the track in JOSM, Download from OSM along the track, then display the photos on a second screen, and process what the photos tell me.
Indeed, by conflating I did not mean that the geometry of my GPX track would replace the geometry in OSM. It would only be used to select the corresponding OSM ways so that I can add tags to them.
I do use waypoints to mark start and ends of noteworthy sections. Maybe it’s worth sharing the typical data I would have:
a GPX track of about 150km
three sections of it where I would need to add something else than surface=asphalt, representing 5km in total, marked by 6 waypoints (start and end of each section)
all the rest (where I don’t add any explicit waypoints) needs to be surface=asphalt
In this situation, it is quite tiresome to manually select all the OSM ways to be tagged with surface=asphalt. So that is where I would like conflation to help: ease the selection of those ways. Again, without replacing any geometry (in this case).
Another use case: my local transportation agency shares a GeoJSON containing the geometry of a new bus route. I would like to add this bus route to OSM as a relation, containing all the road segments it covers and the bus stops. If I could conflate the GeoJSON with the OSM road network, that would go a long way, because manually selecting each road segment can be quite some work.
