"Dermot McNally" <[EMAIL PROTECTED]> 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 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk