The 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.
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
Thanks for bringing this up to hackernews! The challenge for OrganicMaps is to make it privacy preserving and offline usable, which means on device routing and getting as much information on the device as possible.
The referred document concerns the existing static part, it's a rather cumbersome to build it yourself at the moment. There is some routing logic in the app - I think from the Maps.me time - but currently disabled.
The idea is to redesign this - in the mentioned ticket - and divide it in static (e.g. stops, routes) and 'live' data (e.g. schedule changes). It requires an efficient infrastructure. It's all volunteer driven. If you want to help, feel free to contribute!
It seems like the serverside resource requirements to help with the privacy preserving aspect (and also to avoid DDoSing the data providers) would be non-trivial for a FOSS project like this.
I was wondering if a torrent-based architecture, where clients share updates with each other would help reduce the load. Any idea if it's been considered or would it just overcomplicate it for the number of clients involved and/or the latency for updates be too much to be of use?
Cartes.app is quite like an Organic Maps for the Web. So I don't have any of the offline limitations that you have, but feel free to explore the code if anything looks interesting. The development is in french but the code is mostly in english.
I mean yeah, it is quite good already! But sometimes lines break on stations (see e.g. the green and brown lines on Clark/Lake) and there are some unnecessary intersections (e.g. pink and purple on Washington/Wells – can be avoided by swapping them in in the line “bundle”).
Solving these problems would make the map not just prettier, but also easier to read and understand. Of course, doing this by hand isn't really feasible on Organic’s / OSM’s scale, but the blog post you linked is pretty much a how-to guide that can be implemented in code. I’d love to work on something like that, but don’t really know where to start.
While I don't use Organic Maps as my daily driver because there is no traffic data, it has been invaluable to have on my phone. It is one of the best offline and trail maps I've used.
That's a much requested feature. With imho two main challenges:
1. Much traffic data is private / requires licensing, however some countries have reasonable public data.
For example the TraffXML (https://gitlab.com/traffxml) project has some.
2. The project is free to use, but also volunteer driven. It requires setting up a privacy preserving "live data" infrastructure.
If you think this is a nice challenge and you can help, feel free to reach out!
I like the idea of Organic Maps in general, but using it in Hong Kong is awkward; not only because in many cases it uses Pinyin Mandarin place labels (which locals never use) but also because requires me to download 200+ MB of “China Guangdong”—a large but, critically, distinct in every de jure and de facto sense place beyond a border restriction with no free travel (considering in the case of, say, Kaliningrad, with the same situation and even smaller/sparser place, I would get a separate download). For me it raises questions about who exactly is behind the app and why should I trust its privacy promises.
Can't you just write an Github issue and suggest splitting of these areas? I remember them splitting some areas in the past (because map data are getting bigger and bigger)
There used to also be the interesting prospect of OpenTraffic: https://github.com/opentraffic . Unfortunately the main website appears to be down and the GitHub hasn't seen recent contributions, so I'm guessing the project is dead in the water :(
Agreed. I can’t believe how it’s better than any other hiking app (particularly free ones but I tried some non free ones too), but it is.
For me the winning feature is the UX around dropping a pin and routing to it via trails just works and is very easy, and includes elevation gain etc. Too many hiking apps require you to navigate along fixed trails in their hike database.
I just tried it, and I feel like OsmAnd has a more detailed preview of the hiking route: https://www.youtube.com/watch?v=roMNNJPHDvc , unless I'm missing something in Organic Maps..
Related, 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.
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.
Many crossings in th US actually do not have any warning lights or gates, the only warning of an approaching train is the horn from the locomotive. Low-traffic (either in terms of cars or trains) crossings are often unsignaled.
Does 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.
Cool projects! I actually had a look at you gtfs-server, to use Rust for processing GTFS files. Processing GTFS (basically large zipped text files) is quite resource intensive indeed, especially if you want to do it for the whole planet. What would you do differently now?
It is definitely resource intensive, but not as much as you would expect. Especially considering the fact that the route only gets calculated once and most modern phones are pretty fast, it won’t really drain your battery.
Does anybody know if there's an Organic Maps equivalent for cycling?
OSM has a lot of data that's only available in everything-maps like OsmAnd, such as location of bicycle parking spaces or quality of cycle lanes. It would be nice to have it in a nicer interface than that app.
I'm currently building a bike + public transit directions engine (bringing your bike on the train). I'm surprised that this doesn't exist yet; it's my favourite way to get around!
Organic Maps does include bicycle parking POIs. Also some local transit apps do have bike+train routing options for bike carriage and bike sharing: https://anachb.vor.at/
I agree though that something like this is missing in the offline-first maps space.
> I'm currently building a bike + public transit directions engine (bringing your bike on the train). I'm surprised that this doesn't exist yet; it's my favourite way to get around!
Care to share a link ? What does it provide compared to Motis's multimodal capabilities ?
Having only subway options (and not all of them) in the cities I've been traveling is was a good start, but just adding buses would be a tremendous increase in quality of life... no more going through all the buggy and slow local transit websites.
(Why do local transit authorities think it makes sense to front-load several MB of media files on the homepage of their route-finding website, and load the "itinerary" component last? This is beyond me)
Off-topic to the public transit news, but: I've enjoyed Organic Maps for years, but it seems they made a change within the past year (maybe 3-4 months ago) that slowed everything down. Anyone know what happened? It used to be very responsive, but now one a new area, it can take second or two to update.
I've noticed this as well. I often have to zoom in or out or move the view around to get the map to actually "draw", otherwise there are giant empty regions of the map (sometimes the entire visible map).
From my experience working with GTFS it's difficult because the operators usually don't include all the information but the fact of having GTFS support it's a great step
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.