karussell has commented on the following diary entries

Post When Comment
Open Source Routing Engine GraphHopper 0.9 released over 1 year ago


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 …

"Welcome-to-new-mappers" program in the Netherlands comes to an end. over 2 years ago

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

GPS Coordinate shortener: what3words vs Mapcode over 2 years ago

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’:

See here for a good comparison:

Open Source Routing Engine GraphHopper 0.7 released over 2 years ago

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

Open Source Routing Engine GraphHopper 0.7 released over 2 years ago

@Alan: Thanks for the kind words!

@JBacc1: See the discussion about safety etc in this issue:

Mapping private subdivision roads and other gated roads almost 3 years ago

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.

Releasing GraphHopper 0.6 almost 3 years ago

Yes, that is correct. Currently we have only the ‘speed mode’ deployed (this will change). See here for more information about this topic:


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?

Units in OpenStreetMap about 3 years ago

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

Units in OpenStreetMap about 3 years ago

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.

Units in OpenStreetMap about 3 years ago

I meant:

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

Units in OpenStreetMap about 3 years ago

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


Units in OpenStreetMap about 3 years ago

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.

Units in OpenStreetMap about 3 years ago

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.

Units in OpenStreetMap about 3 years ago

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.

Units in OpenStreetMap about 3 years ago

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.

Units in OpenStreetMap about 3 years ago

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.

Doing some highway/routing QA with Mapbox's Distance API over 3 years ago

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.

Postigs question - find out the unnecessary points that exist on the map over 3 years ago

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.

Releasing GraphHopper 0.5 over 3 years ago

See this issue