On 22 February 2013 15:25, Peter Wendorff <wendo...@uni-paderborn.de> wrote: > If you enforce - by an editing bot or by raising error messages -
For the record, I'm not suggesting using a bot. I just know that it's technically not too hard and that if any editing can be automated, somebody will try to at some stage. I certainly won't be encouraging it however. I'm also shying away from the term "enforce" which is too strong. The JOSM validator has multiple severity levels; I think that the check we are talking about should be a notice. Perhaps a warning but certainly not an error. > at least > one localized name to be equal to the name attribute, mappers will either be > offended and leave the project or they will find a solution, imagine > name:communityagreement="Bruxelles - Brussel" - just to make sure the name > the community want's to see in the name tag and rendered on the most > prominent maps. Clearly we don't want that. But I was suggesting to improve the heuristic to deal with this usecase. Show a warning if : * There is a name:XX but no name or * There is at least one name:XX and a name and - The name doesn't match any name:XX and - The name looks like it can be split (with a dash, a slash, a paren, etc) and one of the subname doesn't match any name:XX Hopefully that heuristic would work with all naming conventions that we have in the db. Is there another naming convention that I'm unaware of and that wouldn't work with this algorythm ? I assume that if a weird naming convention is widespread, the algorythm will be fixed quickly. If the algorythm can be relatively free of false-positives, I think it should be implemented. It's just a handy hint to help mappers remember an agreed-uppon convention. It's not "enforcing" a tagging scheme, as that would be a silly thing to attempt in OSM. Concerning the "agreed-uppon" in my previous sentence, I still think the alternate proposal of defining a default language per region is (on top of not being implemented by any current renderer AFAIK) not a workable solution. Nice to have a a fallback from a renderer's point of view, but not something that mappers should depend on. No disagreement here, I hope ? _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
