We have public transport included: https://github.com/graphhopper/graphhopper#public-transit

We currently don’t include this in our hosted solution due to various reasons but this might change in the future.

We won’t satisfy every user but you can already achieve this with a custom model. Click the gear icon to modify this or try e.g. this link as a start, which avoids asphalt as an example and reduces the speed to only 10% for cobblestone (just an example as we already decrease the speed by default significantly for this surface)

Do you mean this one? https://github.com/bryceco/GoMap There seems to be a related issue: https://github.com/bryceco/GoMap/issues/206

Another solution is adoptopenjdk

I also recommend this over other solutions: https://adoptopenjdk.net/

You can easily download stable releases and early adopter versions. If you need a JDK for server-side you can also use this in your CI via install-jdk.sh: https://github.com/sormuras/bach

Heather Leson: Lastly, I try very hard to not take offense to your innuendos that I am disrespectful

Thank you. I sometimes miss this attitude of “taking no offense” :) and I think this is one reason where a “community guide” can help.

imagico: The idea that the participants of this project are in need to be managed, … or otherwise ‘handled’ by professionals is in my eyes an affront to these fundamental goals of the project.

Why?

For example I agree with Heather in this matter. I “guide” a small but global community myself and when people from different countries and backgrounds come together there will be different assumptions and languages that can (sometimes) make a friendly communication harder. There needs to be someone that can interfere a discussion to ask for certain changes in communication or ask for clarification and if this is not done then he/she can even mute certain participants in extreme cases after e.g. 2 warnings or so. btw: this happened just once after several years, so this is rare and “freedom of opinion” is still guaranteed.

imagico: beneficial for the goals of the project you need to do more than just campaigning for it, you need to present facts

What do you mean here? “community management is not beneficial” or “the community will manage itself” or something else?

imagico: The idea that they need somehow to be managed and that doing so is not only beneficial but apparently more important than the core ideas

She said “key to our future”. It does not mean “more important than the core ideas”.

derFred: Gebetsmühlenartig wird die Behauptung “toxischer” Mailinglisten wiederholt.

When I started with OSM I was also really pissed off from the friendliness on one mailing list. And I was not even involved in the discussion and removed myself after a few days and never subscribed again to it. So the huge problem is: if you “piss off” somebody at this stage then she/he might leave OSM forever and you cannot easily find out why because of the diverse communication channels.

btw: I don’t think that this diversity of communication channels is good for the OSM community (forum, mailing list, diary comments, github issue trackers, IRC, wiki …) and a community guide would help the community to streamline this but he/she would not guide the decision.

Thanks!

Because that feature of turn restrictions seems to be still missing on normal usage

Currently ‘just’ an UI thing we have to fix or append “&ch.disable=true” to the URL …

Thanks Marc for still doing it in the first place :) !!

Using a web service for this kind of algorithmic work makes no sense to me and I’m also in favour of open location code or ireland its ‘open post code’: http://www.openpostcode.org/

See here for a good comparison: https://github.com/google/open-location-code/blob/master/docs/comparison.adoc

At least we need a warning for those if enabled. Maybe you contribute a pull request?

@Alan: Thanks for the kind words!

@JBacc1: See the discussion about safety etc in this issue: https://github.com/graphhopper/graphhopper/issues/236

Author of a routing engine here: yes, please avoid mapping for the router. Customization of a routing engine which tags are allowed and which not should be easy. Also if there is a gate with a private tag then a “proper routing engine” would still avoid going through it.

Yes, that is correct. Currently we have only the ‘speed mode’ deployed (this will change). See here for more information about this topic: https://github.com/graphhopper/graphhopper/#technical-overview

Thanks for writing about this. Do you know how well these people are equipped with smartphones/computer and/or with internet? Are there internet cafes?

Or is this part of the project to make this also available to them?

BTW: Thanks Nakaner & the others for the toughts too :)

Thanks Wynndale&Sanderd17 for the thoughts :)

I think when we store the unit e.g. in note:maxweight we won’t have this problem

Maybe the biggest problem I have is the uncertainty of 3 different units in the U.S. ..

So in a typical case of being lazy, the easiest method should be implemented.

I don’t agree. This was probably okay in the last 10 years but will become a big headache in the future…

It would allow complex things, s.a. having defaults per country. … But this doesn’t belong in the main database.

Why does it not belong in the main DB??

Does Graphhopper support maxspeed=RO:urban? My tool does.

Again, this discussion has nothing to do with GraphHopper, except that I’m the author and uncovered this problem through working with GH ;) In Java I can do pretty anything I like and I do for maxspeed, it was okayish and not really error-prone. But for weight units it is not the case due to the ambiguity of ‘tons’.

And all can be solved if one defines one unit per tag and per country. Or my preferred solution would be to have just one unit and solve the conversion via editors. Of course we have many editors but we have thousands of consuming software which then need to do the error-prone job.

I meant:

surely this will come ‘officially’ and you can already do this with all JVM scripting languages like jython, javascript, …

who selects the values & transforms

IMO: the editor software should enforce this :)

E.g. I’ve seen many places where the autocomplete of ‘maxw’ used maxweight instead of the intended maxwidth

but often turn into really complex data modelling issues

That is exactly the reason why I would like to see a start with this with the tiny unit conversion problem

BTW: I would love to be able to tweak Graphhopper without having to code Java in exactly the sort of ways RIchardF describes

surely this will come ‘officially’ and you can already do with some JVM scripting language…

I also appreciate that GH may have the same issues with respect to number of developers as OSM editors

:)

I don’t understand what this has to do with GraphHopper itself :)

which explains that there is no scripting language support yet.

There is no support yet, but you can do this easily in Java.

Yes, I guess you could put it in your core Java app, but that seems a very heavyweight solution

You can easily extend the core app with own custom profiles (currently only in Java). Even the algorithm itself or other parts can be replaced and customized and more flexible than what OSRM allows you to do.

I think you’re overestimating how many editor developers we have!

You mean, I underestimate this :) ? Yes, probably :)

I think, if OSM does not want to slow down due to increased complexity it has to make this move towards a cleaner database AND at the same time make mapping easier or at least not more complex. Which means editors have to solve this, yes. And pushing such a feature to the only a few editors JOSM and iD at the beginning would certainly help.

Assume you build an application from scratch, than you put clean, computer readable values in the database and convert to arbitrary other values in the view layer. I know that OSM has a history and one cannot revert this, but I’m arguing for some partial steps towards a more concise DB.

Maybe it’s time for Graphhopper to catch up?

Richard, I do not understand why you comment in this harsh tone? I’m pretty sure you didn’t read the blog post. Because it has nothing to do that one cannot parse a string value in Java.

The main point is, that OpenStreetMap is database, and mappers are currently used to see the raw data, but I think it is time to add a convenience layer for certain purposes like the weight, and yes, maybe also for the speed and length values.

Also the suggestion by SK53 where one tags the original value additionally is interesting, maybe even store a link to the real world sign somehow. But again: we should not put this burden on the mappers shoulder and instead make our editors clever and easy to use so that e.g. people just need to click on a sign and it will then store the link to this sign (maybe just a number) and the associated, converted speed value.