2008/10/10 Ed Loach <[EMAIL PROTECTED]>: > It seems wrong if anyone can just amend Map Features even if their > preferred method is in the minority. That way leads to chaos. I'm > more than tempted to add "or add an mph suffix to the speed" in the > maxspeed= comments field, to document what is already the widely > followed practice (and to my mind makes more sense than allowing two > maxspeed tags on a single way - surely it is as easy to parse any > optional units as it is to read both maxspeed definitions and decide > based on location which is most likely to be the correct one?). But > presumably someone else might just edit out such an amendment.
And here we see the drawback of an anarchy. If anybody can document the truth, the quality of the truth can suffer. This is why discussion is important to restore balance. Consider your word-processing package. Most will allow you to set margins and positions in a number of units: millimetres, centimetres, ems, points, possibly variable concepts like lines and even really wacky units like inches. But the representation of any of these units (except possibly lines) is just a layer of make-up on whatever internal units the program happens to use. It doesn't actually matter to us as users how this is done under the hood, as long as we can still use the kinds of units we like, and as long as the page we print looks the way we want it to. If you suggested to the programmers that they should internally store not just the sizes you had chosen, but also the units you used to express them, they would probably not be very impressed. And yet that's exactly what you advocate for OSM. You want to turn a field whose only documented usage was to store a simple, easily-interpreted number into a string that must be parsed to cater for what is likely to be an ever-increasing range of possible input styles. All so we can achieve a result that can already be achieved with the existing key. The missing functionality (the ability to store both the information of what the original unit was and the value expressed in that unit) can be added using maxspeed:mph. So now we see another drawback of anarchy - with no enforcement of good design, you rely on the crowd to apply it voluntarily. In a world where we will all agree that the tag: maxspeed=six thousand one hundred and eighty furlongs per fortnight ...is utterly daft, where are we going to draw the line? It's possible to parse it in as automated a way as you can maxspeed=30mph. But it's extra work, isn't it? Let's remind ourselves that the project is about the collection of data. By keeping the data as clean as practical, we maximise the uses to which it can be put. > Mappers should be mapping what it is they find. If I find an 11'3" > clearance bridge with a 20mph limit beneath it then that is what I > want to map. Nobody is suggesting you shouldn't do that. I'll certainly express the view that when I drive under that bridge, my km/h speedometer and lack of feet and inches reckoning skills will mean that I'll want that translated into real money, but this is going to be possible wherever you choose to store this information. What I'm saying is that when we have tags that are documented as containing simple numbers interpreted as being in a particular unit, that you should either convert your data into that format or choose another tag where your preferred way of using it doesn't break with the already documented behaviour. > I don't want to have to artificially convert either of > these to metric, or use alternate tags for the same thing. This is an unreasonable position. I can't and won't force you to convert anything, but what you're saying is that you want to store your data under a tag conceived for a different kind of data. And without even any update to the documentation of that tag. How can this be a good thing? > addition of units if they aren't the default should be sufficient. It doesn't help anybody trying to use the data on the terms implied in the docs. Furthermore, you're deciding that your opinion (that the requirement to process units isn't onerous) is more valid that the opinion of the person who first documented maxspeed (that the tag was most valuable as a raw number of implied units). This is a bit like the argument that's going on about whether trunk highways should be implicitly one way, just because mappers in some countries happen to use them only for roads where that is the case. It's just another case of the tail trying to wag the dog. > And for those mappers who aren't reading this discussion, or > watching for un-voted amendments to Map Features, they won't even > know about the minority use tags that were added today. Mappers relying on map features will have a hell of a time coping with that stuff you're adding as maxspeed... Dermot -- -------------------------------------- Iren sind menschlich _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
