On 22/01/2008, Richard Fairhurst <[EMAIL PROTECTED]> wrote: > Dermot McNally wrote: > > > Up until now, all such units have, by OSM convention, been stored in > > metric units, which obviously suits me just fine. > > That's just not true - there are plenty of maxspeed=something imperial > in the database.
Divergence from the convention doesn't mean there isn't one. I wasn't aware of the fact that there are imperial measures in there, but IMO it's a needless complication and it goes against Mapfeatures. > > TBH I don't see the difficulty in those few clients which need to use > speed/width information adding these three lines of code: > > if ($is_measurement{$key} and $tag{$key}=~/(\d+)\s*(.+)/) { > $tag{$key}=$1*$conversion_factor{$2}; > } Needless complexity. These are physical quantities that can be and should be stored as raw numbers using consistent units, just as we have settled on lat/long and the Gregorian calendar for dates. And your conversion table is going to get nice and complex when it turns out that every imperial fan has a different idea of the right unit notation for each unit. Madness. There's no easier way of making these fields useless to the consumers of the map data. > But then, I'm the author of an editor rather than a routing client, so > I would say that. :) Right enough - I know that my proposed solution to the problem dumps it on you guys, but at least that minimises the pain rather than spreading it widely throughout the database. Dermot _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk