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.

Each conversion has errors

That is something that should be easy to solve

And I would be okay with one unit per country. But as stated in the post, it is not that simple and makes automated and human consuming too complex IMO.

Is mapping really the process down to the database? I doubt that. Mapping means modeling the real situation with the tools we have. The tools will evolve and so should the mapping process making the database more concise and the mapping process less complex.

but is an OSM maxwight or others like road-width ever used in calculations?

Yes, sure. E.g. if you want to know if a truck of width X fits through it or not.

The best way would be to change the earth use of units to SI ;-)

It is important to keep local things as they are and make the mapping as convenient for the mapper as possible. But again: why would the database need this complexity if we can handle it in the editor?

The OSM project grows, tools get better and so we should make it possible to freeze certain definitions of tags and check them in the most popular editors as it is currently already done.

Interesting! So you check only the connectivity or also the distance changes over time like @flohoff is doing? If the first, then you should be able to easily do this with (a local) GraphHopper, it is called subnetwork calculation and will be much faster and precise with regards to the precise node set. Or just use normal route calculation.

@flohoff let me know if you need support when testing this with graphhopper :)

BTW: GraphHopper is deterministic, even if it does stuff in parallel while import.

For routing we do the same in GraphHopper import as we only need the junctions and end points. But I doubt this makes or will reduce much of the data as the ways are not always this straight in real world. And even if you want to reduce this which difference via douglas-peucker is acceptable 1m, 0.1m or 0.0000m? Reducing the data if it is not 0.00000m difference will reduce the quality in certain cases.

See this issue https://github.com/graphhopper/graphhopper/issues/236

This is just a displaying setting and a dynamic elevation visualization has other problems.

Das war kein Schnellschuss. Das hat ewig gedauert: https://github.com/openstreetmap/openstreetmap-website/pull/716

Aber warum? Weil fast nur Richard wirklich Zeit investierte (ich hatte auch keine). Wahrscheinlich wäre ersteinmal eine Lösung ala http://openstreetmap.de/karte.html besser gewesen.

Ich prangere das an.

Das bringt nicht so wirklich viel. Mitdiskutieren und implementieren schon.

Wir hoffen auch auf Leute die die Router wie: https://graphhopper.com/maps/

und natürlich die Daten für diese verbessern:

Es gibt von esri oder mapbox satellitendaten, von osm natürlich nicht ;)

Klickst Du hier ‘esri’ oben links: https://graphhopper.com/maps/ da gibts auch (outdoor) layer die höhendaten eingebunden haben.

This is what I’ve found from HOTOSM http://www.missingmaps.org/ where there is e.g. this. So the infrastructure is already there and even nice&useful :)

Yeah, also a nice idea! Someone should make a company out of these all so that I can use it ;)

I would have no problems to limit the work to local mappers. Also I would like to see that those local mappers involved somehow. Be it via financial support and direct involvement or as a protection wall for those paid contributions.

Yeah, but I have already too many side projects where I’ll be billionaire afterwards ;)