Andy Allan wrote: > On Jan 24, 2008 2:34 PM, Jo <[EMAIL PROTECTED]> 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 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
