Free, open and collaborative routing service
maps.openrouteservice.org
maps.openrouteservice.org
http://maps.openrouteservice.org/reach?n1=8.992583&n2=-79.60...
[0] http://maps.openrouteservice.org/reach?n1=38.757564&n2=-9.19...
Seems to be working when you create it for cars.
Either way it's probably a data issue and can be fixed if needed.
Anyway, glad to hear that the routing takes those road usage restrictions into consideration :)
What I would really like to see though is a pedestrian + public transit mode... But I realize that this is hard ;)
Loving the wheelchair option :-) that's not something I've seen before, but now I've seen it - It's a blindlingly obvious accessibility feature...
They appear to use a forked version of Graphhopper [1] [2] for route calculation.
[1] https://www.graphhopper.com/ [2] https://graphhopper.com/maps
The only thing that it misses is info on traffic load—which might be tricky to gather for a FOSS service while critically depending on the quantity of collected data.
As a German citizen, I enjoy that the basis data (only OSM?) is really good. This seems to be a project based on the University at Heidelberg. That's a pretty hilly area, maybe that's why they focus so much on height elevation :-)
But, I love that this is open.
But this is neat, too.
For instance, when going to a certain large hardware store, OsmAnd basically told me to pull over off the Interstate and hoof it up to the store, instead of actually routing me off the highway and into the parking lot.
This site seems to do it correctly, which is nice!
I have back/forward buttons on my mouse and I use those. Why would I move the mouse to click an in-app navigation button instead?
I this what the original meant is that this implementation here is flawed. Once you are on the website, the back button won't bring you back to Hacker News ... ever. Even spamming the back button, you'll get stuck on the redirection to /directions which is annoying and definitely broken. This kind of redirection loops should be forbidden.
On phones, the native ‘back’ button is vastly more easy to tap than searching for where the designer placed their button this time and then likely reaching for the farthest corner of the screen, opposite of where my thumbs are. So much so that I get surprised and annoyed when a page that has fullscreen-y dialogs doesn't close them on ‘back’ but returns me to another page instead.
On desktop, personally for me at least one of the hands is usually on the keyboard in the proximity of ‘backspace’, which is again a no-brainer to mash. So the same consideration applies.
I've been trying iOS for the last couple of months, and especially initially that back button was one of my most missed features; it still annoys me, I've just stopped expecting it.
- pushState is only used for overriding the default behavior, mostly to keep the url bar in sync with changing client state
- pushState pollutes the browsers history
- users have a mental model of how many steps/clicks they performed on a site and expect that an equal number of clicks on the back button brings them back to the beginning
- users are upset if that expectation is not matched
The site should not have control over the users history in the first place but for SPA it's necessary to achieve the expected behavior. But the browser should make sure that it's not misused. In the same way that pop-ups are blocked outside of whitelisted event listeners to prevent a website from polluting your screen, pushState should be blocked to prevent history pollution.
Reminder from the HackerNews guidelines
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
/rant
1.) you're mixing a routing service with a tile service (just view the map). A routing service needs always a tile service to display its result.
2.) the difference between openmaptiles and a traditional apache mod_tile is, that you don't need a ~600GB postgress to serve the entire planet. It's pre-rendered in vector tiles and the entire planet fits into a ~50GB mbtiles (sqlite3) file.
3.) Generating your own mbtiles file is documentated here: https://openmaptiles.org/docs/generate/generate-openmaptiles... and here is the belonging github repository https://github.com/openmaptiles/openmaptiles
But take care, rendering the entire planet took a lot of ressources. e.b. i7 sandy bridge with raid 0 ssd will take ~1 year for planet zoom level 0 to 14. And aws c5d.12xlarge will take 7 days only for zoom level 14.
That 600GB must surely include the full history? The xml dump of just the current openstreetmap data is only ~90GB, and generally XML dumps get smaller when you put them into a real database. That isn't a good comparison.
I could have sworn the last time I checked this the docker image had dependencies that simply were not available, either in docker or on git but I guess I'm mis-remembering.
See the wiki: https://wiki.openstreetmap.org/wiki/Planet.osm/full
Nope! IME a regular `osm2pgsql` database for displaying maps which can be updated with changes needs about ~1TB of diskspace. There are many indexes needed.
nope