Frederik Ramm wrote: > Hi, > > Eugene Alvin Villar wrote: > >> What's so hard about standardizing on the boolean values given >> appropriate changes to editor presets, good wiki documentation, and a >> deprecation period for other boolean values? >> > > It's a kind of slippery slope situation. There is fear that once it has > been proven that standardisation works for true/false values, there will > be demands to standardise everything else as well. > Not *everything* just the things that people feel need changing
Fear is not a good reason for the status quo. > This would be positive for the users of our data in the short term > because it means they would not have to interpret the data; however it > would remove dynamism from the project and require mappers who want to > invent something new to apply to the standardisation committee first, > and we feel that this would be a severe detriment to further > participation on the mapper side. OSM flourishes partly because mappers > feel that they can help shape the project, and contribute what they > think is important, rather than just being mechanical turks (without the > payment). > People would still think they would be contributing even with certain restraining guidelines. > In the long term, standardisation would kill the project, and thus not > be desirable even for our users. - Coming from the outside and not > having the knowledge about OSM that we have I find it very disappointing you feel there is a them & us situation. > , users can be forgiven to demand Whoa, there. Who's demanding? Please, don't make things up. > things that would ultimately destroy OSM, > > but it is our duty to > educate them and to explain to them that they can either take OSM as it > is, with some interpretation required, or they can demand that OSM > change but that would, in the long run, probably mean no OSM at all. > This is starting to sound like quasi religious mumbo-jumbo: 'if you do this, the sky will fall on your head' > I run a small company that, among other things, sells standardised > derivates of OSM data. I spend a lot of time trying to stay ahead of the > game, analyse what tags people use and for what, and try and convert > these into consistent and reliable values. If there were certain restrictions you'd have to spend less time. > If OSM changes from > "landuse=forest" to "russ_nelson_sees=trees" because that's what mappers > what to use, then I can adapt and my customers don't have to, and > neither does the OSM community have to twist and turn just because some > users want consistent tagging. > > In my eyes, this is the way to deal with standardisation - do not force > it upon the mappers, but instead create a "filter layer". In my case > this is a commercial operation, but I have been suggesting for ages that > instead of writing bots to streamline OSM data, why don't people write > generic filters/standardising engines that take the "chaotic" OSM data > as of today and produce well-ordered standardised output for people "out > there" who cannot be bothered to keep up with OSM's tagging anarchy? It > would not be too hard. > Isn't that just putting an artificial middle man into the equation? Wouldn't it be better to have an organised, original data? > And I'm not saying this because of my business (until now, keeping up > with changes and doing the standardisation takes more work than I get > paid for it so I would benefit from OSM itself being standardised); I > truly believe that the way things work in OSM, with "standards" being > un-enforceable and people constantly deviating from them (even if there > is a certain base consensus on many things) is the only way it *can* > work without degrading into some kind of Google Map Maker that does not > look for project members, but for worker ants. > > Bye > Frederik > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > > _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk