On Jan 22, 2008 2:17 PM, Dermot McNally <[EMAIL PROTECTED]> wrote: > On 22/01/2008, Richard Fairhurst <[EMAIL PROTECTED]> wrote: > > > maxspeed=110 <-- assumed km/h > > maxspeed=70mph <-- unit stated > > maxwidth=2.14 <-- assumed metres > > maxwidht=7ft <-- unit stated > > I'm uneasy about this - up till now, these fields were assumed to > contain pure numbers, with the ease of processing that this implies. I > know that in an imperial world, it's not so convenient to use a figure > like 2.14 when you're trying to represent what could be a round > number. But to introduce the possibility of there being units in these > fields (and the requirement to arbitrate those units when processing) > smacks to me of dirty data. >
This is really not difficult to handle. You check for a unit, if you don't understand the unit you pretend the tag didn't exist. If there was no unit you assume metre, and then you convert to whatever unit you happen to be using. It's not dirty, it's just correct. > Is there not a nicer middle ground here? I'm thinking of some kind of > editor support that would treat units like 'mph', 'ft' or whatever as > macros that instantly transform any submitted value into the database > internal SI equivalent before submission? > And what is the exact SI equivalent of 30mph? I can give you an approximation: 48.28032km/h. What happens though if everyone sticks in 48 instead.. close enough isn't it? Does the difference matter? Probably not for a lot of data uses, but if you're trying to avoid dirty data then you should avoid this kind of forced approximation. Dave
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
