[OSM-talk] Mapping canals

[Jo]

Andy Allan wrote:
> 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
>   
I agree that the mappers can enter whatever they want. Then post 
processing can locate non-SI units and create the separate field with 
this entry and a calculated field with the unit converted to the SI 
unit. In a real DB like PostgreSQL this could be done on the fly in a 
stored procedure triggered upon insertion or update.

Polyglot