Organic maps: Experimental feed based public transport mapping
1–10 of 36 posts
Re: Organic maps: Experimental feed based public transport mapping
#2Does this mean that the routing will happen on the app? This might be a bit resource intensive, but great feature (especially since it will work offline!)
Re: Organic maps: Experimental feed based public transport mapping
#3The document doesn't say which routing engine is used.
I'm currently integrating Motis on a similar initiative (a french open source Web map, https://cartes.app). More is needed to provide a full transit map experience, but Motis does the essential part.
We're not far from transit calculation as an open source commodity in countries that publish their transit data as GTFS. E.g. in France there is a whole team called transport.data.gouv.fr that deploys a website + API and do the necessary to convince and help local transport agencies to respect the law.
Ingesting this whole dataset is not trivial, lots of bugs arise (e.g. Flixbus's agency id : 0 or conflicting calendar_dates.txt ids between different datasets) but a barebone version goes live in 4 seconds (per big agency) of parsing by Motis's Nigiri module.
The developer of Motis is quite involved, and came to Organic Maps's discussion here https://github.com/organicmaps/organicmaps/issues/5331#issue...
Then comes the hardest part IMHO : the UI. Motis provides intermodal routing with the choice of walk / reduced mobility / bicycle / car / car + parking before and after the bus, and all this needs to be integrated in a UI that can rival Google / Apple Maps / Transitapp.com / etc
Organic Maps have very beautiful transit lines representation in the style of Transit app's great work. https://blog.transitapp.com/how-we-built-the-worlds-pretties...
Would be cool if some demo of the extended transit lines could be provided by Organic Maps following this readme file.
Re: Organic maps: Experimental feed based public transport mapping
#4Does this mean that the routing will happen on the app? This might be a bit resource intensive, but great feature (especially since it will work offline!)
I believe the answer should be on this big issue https://github.com/organicmaps/organicmaps/issues/5331
Re: Organic maps: Experimental feed based public transport mapping
#5Does this mean that the routing will happen on the app? This might be a bit resource intensive, but great feature (especially since it will work offline!)
I don't think routing is that resource intensive, especially in transit setting where there are set number of stops (nodes) and the graph is fairly static - we can do tons of preprocessing and then routing queries would have minimal computational overhead.
Re: Organic maps: Experimental feed based public transport mapping
#6Does this mean that the routing will happen on the app? This might be a bit resource intensive, but great feature (especially since it will work offline!)
I don't think routing is that resource intensive, especially in transit setting where there are set number of stops (nodes) and the graph is fairly static - we can do tons of preprocessing and then routing queries would have minimal computational overhead.
It is. Especially to do multimodal routing offline.
Re: Organic maps: Experimental feed based public transport mapping
#7Related, shouldn't it be possible to get data from rail signalling radios, and infer when a train is blocking a level crossing, and mark a temporary closure on that road so traffic is routed around it?
In the US at least, trains sometimes block crossings for upwards of 10 minutes, and it can be very worthwhile to drive around. Doubly so if you could know en-route and seamlessly reroute, rather than having to approach the crossing to discover the closure.
Re: Organic maps: Experimental feed based public transport mapping
#8Earlier quoted context omitted.
I don't think routing is that resource intensive, especially in transit setting where there are set number of stops (nodes) and the graph is fairly static - we can do tons of preprocessing and then routing queries would have minimal computational overhead.
It is. Especially to do multimodal routing offline. https://github.com/motis-project/motis/issues/423
Thanks for sharing the link! Multimodal routing definitely changes the game, Imma go through the issue.
Re: Organic maps: Experimental feed based public transport mapping
#9Related, shouldn't it be possible to get data from rail signalling radios, and infer when a train is blocking a level crossing, and mark a temporary closure on that road so traffic is routed around it? In the US at least, trains sometimes block crossings for upwards of 10 minutes, and it can be very worthwhile to drive around. Doubly so if you could know en-route and seamlessly reroute, rather than having to approach…
Nearly all level crossings are required to, at the very least, trigger a signal with audible sounds and possibly gates, so you just need that same switch to update some online status.
Re: Organic maps: Experimental feed based public transport mapping
#10Does this mean that the routing will happen on the app? This might be a bit resource intensive, but great feature (especially since it will work offline!)
I don't think routing is that resource intensive, especially in transit setting where there are set number of stops (nodes) and the graph is fairly static - we can do tons of preprocessing and then routing queries would have minimal computational overhead.
I did implement an A* routing "offline" routing algorithm based on GTFS data + walking paths (OptiTravel) and built a GTFS server (to easily serve the data, do geospatial queries, ...) a few years ago. Granted that this was a university project, for some cities the calculation was rather intensive (e.g: London). I might be wrong though.