TobiPeterG
commented
4 days ago Wow, thank you for the great write up :)
Have you had a look at the prototype server already? I have an example data source that provides json and the server converts it to GEOjson currently, but this is really just the first draft to have a starting point.
I would like to have the output format of the API something apps can understand and work with as soon as possible, so we can focus on adding data sources and ways to report data instead of rewriting this part. It seems like adopting TraFF and their format would be useful. :) Do you have a link to it?
Any help on that front would be appreciated. :)
mvglasow
From README:
The solution I built (TraFF, various sources, Navit for navigation) addresses that.
Referencing is primarily done through reference points. The TraFF format, which I developed for this purpose, allows only WGS84 coordinates (aka GPS coordinates) for reference.
from,to; indicated by GPS coordinates) are sufficient for a navigation app to make sense of the location. Typically we also need to express which direction is affected (only from the first point to the second, or both directions).atpoint (for zero-length locations) would work if no directionality is needed, i.e. the message refers to both directions and, if two or more roads intersect at this point, to all roads affected. Matching this to the map would be difficult, though – see below.atfromaux_fromor when leavingattowardsaux_to).viapoints, which must be passed in that exact order.Other attributes, such as
highwaytype,ref,nameetc., are optional and added mostly to make the locations human-readable (“S61 between Wysokie and Raczki” is easier to read than a set of coordinates). They can also be used as auxiliary data to match locations to the map when the point data is ambiguous.Mapping a location pair to a set of OSM ways (or parts of ways) is done using essentially the same routing algorithm the navigation app already has, with a few tweaks:
A4,A-4andA 4are all considered a match of each other. Similar logic might be implemented for street names (so thatDoe St==Doe Streetetc.).trunk/trunkis a perfect match (no penalty),trunk/motorwayandtrunk/primary(next higher or lower category) are a near-match (low penalty), andtrunk/anything else (e.g.trunk/residential) is a miss (highest penalty).A4biscould be a near-match forA4(S61would be a miss).Doe Stis a perfect match forDoe Street,John Doe Streetis a near-match), but this can get very complex quickly.viapoints: the cost of each way segment gets penalized by its distance from the nearestviapoint. (Maybe we can also considertoandfromfor that penalty, and possibly revisit the cost of the off-road links connecting the end points to the road network.)For our sources, we would have to convert everything into WGS84 coordinates:
ref, sometimes with differences in spelling) and kilometric points. For some countries, kilometric points are quite well mapped in OSM (Poland being a good example); other countries make their kilometric points with coordinates available as open data (e.g. Latvia). Usually we just get one location every 100–1000 meters, and would have to infer the rest from OSM data. Should be doable with access to map data. Care must be taken, however, when dealing with duplicate kilometric points (e.g. rerouted sections of road).The beauty of using coordinates (possibly along with auxiliary identifiers) is that the “producing” and the “consuming” end may use different maps – whether that is maps generated from OSM data at different dates, or even maps from completely different sources.