[OSM-talk] Map Features, maxspeed and maplint

Matthias Julius lists at julius-net.net
Sat Oct 11 07:28:16 BST 2008


"Dermot McNally" <dermotm at gmail.com> writes:

> Consider your word-processing package. Most will allow you to set
> margins and positions in a number of units: millimetres, centimetres,
> ems, points, possibly variable concepts like lines and even really
> wacky units like inches. But the representation of any of these units
> (except possibly lines) is just a layer of make-up on whatever
> internal units the program happens to use. It doesn't actually matter
> to us as users how this is done under the hood, as long as we can
> still use the kinds of units we like, and as long as the page we print
> looks the way we want it to. If you suggested to the programmers that
> they should internally store not just the sizes you had chosen, but
> also the units you used to express them, they would probably not be
> very impressed.
>
> And yet that's exactly what you advocate for OSM. You want to turn a
> field whose only documented usage was to store a simple,
> easily-interpreted number into a string that must be parsed to cater
> for what is likely to be an ever-increasing range of possible input
> styles. All so we can achieve a result that can already be achieved
> with the existing key. The missing functionality (the ability to store
> both the information of what the original unit was and the value
> expressed in that unit) can be added using maxspeed:mph. So now we see
> another drawback of anarchy - with no enforcement of good design, you
> rely on the crowd to apply it voluntarily.

HTML for example allows for the specification of units, too.  From the
programmer's point of view I don't think it makes much of a difference
whether the unit is stored in the key or in the value.  Both need to
be parsed and either way one has to deal with an ever-increasing range
of units.

If the unit is included in the value the renderer for example can
decide not to care about it and to render either just the numerical
part hoping that people would not mix units in an area or print the
whole string on the map.

Also from the logical standpoint I think the unit belongs to the
value.  But I guess opinions differ here.

Either way, as it stands with current editors the user needs to spell
out the unit in either the key or value and editor support would be
needed to make that easier for the user and less error prone.

I am all for defining a set of "acceptable" units for different
physical properties (length, speed, weight, ...) in Map Features and
reference that from the different tags that require a unit.

Matthias




More information about the talk mailing list