Units in OpenStreetMap

First of all, this is not a rant nor am I a (regular) mapper but I have some years of experience to read aka ‘interpret’ OSM data. I invite mappers to read, understand and comment on this post (in this order ;)).

Learning and understanding a specific tag

When I learn about a new tag for GraphHopper e.g. maxweight the first thing I do is that I go to taginfo and see some common use cases and implement them. Then I increase the parsing area to country-wide and I add more parsing code here and there to ignore or include commonly used values that make sense or not. Then I go worldwide doing the same. Then what is left, see this gist, are some very infrequent used values, some make sense like ‘15 US ton‘ and some don’t, like ‘agriculture‘. Now I need to decide to fix them, ignore them or include parsing code. In the case of the weight values I did see a reason to include reading values like ‘13000 lbs’ or the most frequent ones like ‘8000 (t(on)s)’ but not e.g. ‘13000 lb’ (10 times world wide) which I just fixed and converted them to SI unit – maybe I should have just added the ‘s’?

OpenStreetMap is a database

In OpenStreetMaps the tagging schema is not always clear and depends from local community to local community. And this is a good thing that OSM is flexible. The question now is, if this difference should be reflected in the data itself or if a more concise database should be preferred and the local difference could be moved into the ‘view’ like the editors. I think:

OSM should prefer more concise data if possible and this gets more important as it grows.

Now back to my example of weight values.

SomeoneElse commented today on my none automatic change where I converted ’15 US tons’ to 13.607 “SI” tons with a world wide occurrence of 5 (!) that we should not make it more complex via SI units. But if you look at the US unit system with ‘US tons’ and ‘short’ and ‘long tons’, ‘pounds’, ‘lbs’ etc, plus the various ‘weight’-possibilities like listed in this good proposal you can guess that this is already not that easy. So such an edit would be probably better done via an assisting editor which converts between weight units.

Popular OSM editors should make it possible to use local units but convert them into some SI-based when stored.

On my OSM diary someone correctly says: But “we map as it is” includes units in a way to. A limiting sign at a bridge does have a written or implied unit.
I answered: Is mapping really the process down to the database? I doubt that. Mapping means modelling 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.

3 thoughts on “Units in OpenStreetMap

  1. SI units are not used in the US and the locals kind of feel strongly about that. Probably that’s what triggered the discussion. I would recommend a per region default unit. In the US, this should be whatever unit is used on the actual road that is commonly adverised, i.e. tons. Similarly, you wouldn’t necessarily want to convert M/H speed limits to KM/H and deal with the weird rounding errors etc. Another thing to consider is that the locally used units are what people have available when they enter the data.

    I agree the UI could support data entry for this a bit better and I fully agree with the argument that a database should have precise, non ambiguous data. The free for all tagging in OSM often ends up being a problematic frequently due to the inconsistent use tags and the lack of automatic validation when data is entered. This leads to complex and convoluted code in pretty much anything that needs to do anything that involves interpreting the data. Becaus of this some tags amount to little more than wishful thinking since the actual values used for the tags are pretty much a crap shoot.

    It would be helpful if OSM would lock down valid uses of commonly used tags and starts rejecting or at least flagging content that does not pass validation for those tags. In this case a number followed by whitespace and a non ambiguous unit from a list of supported units seems like a perfectly reasonable thing to expect here. Even simply flagging invalid content in the database with another tag could be a step forward since volunteers can then step in and improve the data.

  2. Thanks Jilles for your comment!

    One unit per country would be helpful. And the speed is not really a problem as there is just mph, knots, kph and kmh😉

    But I originally didn’t want to discuss how mappers map their local stuff, I would just like to introduce a layer where the DB is a bit more separate from the view. I know that this process will be a hard process but it will be necessary for the future of OSM, now or in 10 years🙂

    And so maybe people could do this at least for the units and iterate from there to tags, and later even to more complex relation-alike structures.

  3. Pingback: weekly 276 | weekly – semanario – hebdo – săptămânal – haftalık – 週刊 – týdeník – edisi

Comments are closed.