[OSM-talk] Mapping canals

[Andy Allan]

On Jan 24, 2008 2:34 PM, Jo <ml at winfix.it> wrote:
> Dermot McNally wrote:
> > My favourite suggestion so far is that a second key be introduced -
> > either for the "original" measurement (my favourite, since it retains
> > the traditional meaning of the existing key) or for the normalised
> > equivalent.
> >
> This is what I was thinking all along. On the one hand you want the info
> as it is indicated in situ. On the other hand you want to be able to
> parse it efficiently. A second field seems like the most obvious
> solution. Maybe name spaced: maxheight:imperial = 3 ft.

I'll make two comments on this whole thing:

1) Processing power should be considered infinite, and contributor
time not so. Make it as easy as possible for the contributor, so long
as we can deterministically post-process it somehow.

2) There are two different things that everyone is talking about, and
keep getting them confused
  * The distance, or speed, that you are recording (i.e. the physical
property). Units are interchangable, can be converted etc to your
heart's content.
  * The manner in which the measurement is displayed in the real world
(i.e. the evidence, signs etc)

So for the first, 30mph and 48 kph are the same thing. For the second,
they are completely different. You can divide everyone who is
discussing this issue by which of those two facets they deem more
important.

Some people only want to record the former (the folks doing routing,
mainly). Some people want the latter stored too. The latter means that
5'6" and 5.5ft are two completely different things, but to someone
dealing with the former will think they are the same (and probably
argue for metric too).

I don't care. I've yet to tag either, nor use either for rendering,
but people should bear these two things in mind when discussing them
and proposing ideas.

Cheers,
Andy