This is going rapidly off-topic, but I think that this is an important precedent we are at risk of setting here. One that shouldn't be made in private by those of us who care about canals.
I think that the matter of unit encoding and presentation is a little like that of language. We've already had to come to terms with the fact that the same city can be called München, Munich, Monaco etc. OSM precedent allows us to ensure that our dataset will allow rendering of whichever version or versions we choose, though the default renderer currently only uses one of them. This is a clean treatment of data that works for everyone. So now let's consider items like distances, depths, heights and other items that can be rendered in either metric or imperial (and for all I know, maybe other) units. I happen to be a user of metric measures, so I want to see mountain heights in metres, speeds in km/h and canal lock rises in metres (regardless what country they're in) because those are the units that make sense to me. Up until now, all such units have, by OSM convention, been stored in metric units, which obviously suits me just fine. This doesn't alter the fact that a bunch of OSM users (and I'm thinking particularly of those wacky Americans among us :) ) would prefer to use other units. This option is open to them by taking repeatable transformations of the data already stored, and we must assume that there will at some stage be parallel rendering projects to give these users what they want to see. IMHO, feet, inches and miles belong no more in OSM data than UK National Grid references. They can readily be extracted from the standard units stored, but there should _be_ a standard, and established OSM practice (as well as common sense) says that the units to use are metric. Trying to have renderers and other processors grok unit suffixes which will be mis-spelt half the time (standard notation not being a strong point of the old units) is just daft. Forcing mappers to work in non-round figures is also, I admit, not ideal, but this is something that can readily be fixed at editor level. On 22/01/2008, Gervase Markham <[EMAIL PROTECTED]> wrote: > We seem to have a choice between: > > 1) Making renderers which need to understand the units they want to > render on the map, and are capable of converting values in a single > standard unit into that rendered unit and rounding appropriately: > 48.28 -> 29.999mph -> "30mph" This is inevitable - as long as there are people who'd like to see the height of the Zugspitze in feet or of Ben Nevis in metres. So even in a world where we store all data internally in metric units (today's world, which I'm advocating we not tamper with) there is both the need and the possibility to render alternative units from the base data. > 2) Making renderers which need to understand all possible units anyone > might use, and how to convert them into the units they want to render on > the map (which may or may not be the units encoded). > 50kph -> 31.07mph -> "30mph" > 45mph -> 45mph -> "45mph" > 73000furlongsperfortnight -> 27.16kph -> "28kph" > > I opt for 1). I think it's reasonable to ask renderers to know about > units they want to render. I don't think it's reasonable to ask them all > to know about all possible units anyone might want to stick in the database. I agree. Let's fix this at the data output, not the input. Dermot _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
