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
