Re: [Tagging] RFC: Names localization
On Thu, 02 Aug 2012 07:31:40 John Sturdy wrote: snip i.e. London may be London to an English person and Londres to a French person, but Stourport-on-Severn is Stourport-on-Severn to both of them (just picking a smallish town randomly; no potential slur intended). And a lot of names in OSM are street names; as far as I know, it's rare for people from another country to have different names for a country's streets. Absolutely, but the point is whatever mechanism we implement for name=* (and name:xx=*) must work for anything that can be tagged with name=*. If it's not needed for something, then it is simply not used. And actually... in Korea we do have different names for streets, one in Korean (in Hangul) and one in English. Best wishes, Andrew ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Peter Wendorff wrote: There are two big differences between CSS and the proposed relation stuff. 1) The inventors of CSS provided a working implementation for core CSS features 2) For a considerably long time css was used only very sparse and most of the time with a html4 styling fallback. Nobody arguments about the proposed use of relations per se, but it's far from enough to propose something. 1) Proposing one option is not the same as deprecating another, and that's what some want to do here. 2) Support in editor software does not rely on fixed rules only to use relations, so that could be added even before switching, and both variants may co-exist for some time. The arguments mainly are: relations are the better data model therefore let's deprecate ref tags on ways. instead of: relations are the better data model let's make editors great enough that relations are on top of that easier to use for mappers let's make the API better by fixing the performance issues that occur regularly when dealing with big relations (or very long ways) Let's then encourage by arguments instead of rules to use relations - as there's no good counter argument any more: At this stage they are as easy to use, better to maintain and the cleaner data model. This is a big difference. The first approach is what's tried here, and get's bad critics from some others, because usually these attempts end up with new proposals and questions to the old developers why don't you support that? it's the 'only' way to do it right - or something like that. I could agree with a lot here, but there are several points, where I think you're wrong. 1) Deprecating something does _not_ mean deleting this stuff, or completely throwing out a support for it. 2) I don't think anyone is actually proposing to completely deprecate the concept of adding the ref tags directly to ways (or even purge the data). The question was raised about, what's the point of keeping refs on ways, if the same information is already (more easily) maintained in the relation. I've tried to explain, why I personally think that duplicating data allows you to do cross-checks for conflicts is simply a bad reason. On the other hand, the backwards compatibility with tools used by data producers, as well as consumers, _is_ a good reason, but... 3) ...that's why we're having this discussion, isn't it? I don't think that attitude like Go away and don't come back until you've coded editors support, API changes, osm2pgsql patches, ... If you shouldn't come here with an (incomplete) idea and cooperate with others on improving/completing and realizing it, OR after a short discussion admit that it would need actually more work than you thought and it's not worth it... then, what's the point of this mailing list? I thought this is how the community should work - not everybody knows perfectly everything, but together... Best regards, Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Johan Jönsson wrote: Sorry if I am getting to theoretical on the subject of how to write tags. I was wondering about the reason for this tag, *is it to explain the languages in the tag name: (if, like in your bruxelles-brussel example, is two names I guess that the order is important) Yes, this was the primary motivation for the proposal. *or is it aimed at noting information from wikipedia on the official languages of this place (probably ordered after number of speakers but with administrative language first or something). AFAIK, official languages are usually decided on the level of countries... even if you know the official language of the country, you can still come across a small region, where * most people don't even speak it official language properly * the road signs are written in the official language, supplemented by the language of local minority *It could also be meant to explain something that might not exist on wikipedia, in what languages and scripts the road signs usually are on the place. In the greece capital Athens there are usually the name in greek letters first and then in roman letters (gr and gr_rom maybe). This is actually a related problem - the question, what should we generally put in name tag? IMHO in case of a dispute, a reasonable solution is on-the-ground rule. But if everybody in Greece agrees that in name tag they will put only names in Greek alphabet (even though you say the signs contain latin transcription as well), it's their call. Best regards, Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Am 02.08.2012 11:42, schrieb Petr Morávek [Xificurk]: Peter Wendorff wrote: There are two big differences between CSS and the proposed relation stuff. 1) The inventors of CSS provided a working implementation for core CSS features 2) For a considerably long time css was used only very sparse and most of the time with a html4 styling fallback. Nobody arguments about the proposed use of relations per se, but it's far from enough to propose something. 1) Proposing one option is not the same as deprecating another, and that's what some want to do here. 2) Support in editor software does not rely on fixed rules only to use relations, so that could be added even before switching, and both variants may co-exist for some time. The arguments mainly are: relations are the better data model therefore let's deprecate ref tags on ways. instead of: relations are the better data model let's make editors great enough that relations are on top of that easier to use for mappers let's make the API better by fixing the performance issues that occur regularly when dealing with big relations (or very long ways) Let's then encourage by arguments instead of rules to use relations - as there's no good counter argument any more: At this stage they are as easy to use, better to maintain and the cleaner data model. This is a big difference. The first approach is what's tried here, and get's bad critics from some others, because usually these attempts end up with new proposals and questions to the old developers why don't you support that? it's the 'only' way to do it right - or something like that. I could agree with a lot here, but there are several points, where I think you're wrong. 1) Deprecating something does _not_ mean deleting this stuff, or completely throwing out a support for it. +1 2) I don't think anyone is actually proposing to completely deprecate the concept of adding the ref tags directly to ways (or even purge the data). The question was raised about, what's the point of keeping refs on ways,... The point is to keep the correct, even if deprecated work of local mappers intact. A mapper that has no idea about relations and added the ref tag to his streets instead, but then sees, that some stupid people from somewhere else deleted that stuff, probably not even recognizing now that it's because of duplicates, for him it's they deleted my work. ...if the same information is already (more easily) maintained in the relation. And again we are at your claim again, that's unproven. Yes, that may be more easily to maintain - as soon as the support is good enough in every not niche editor software around. I wouldn't go that far to say, every program out there has to be enhanced to support that, but at least the majority of mappers should use an editor that support it, before deprecating should be started IMHO. You claim, it's more easily maintained in the relation - but for many mappers it isn't, because they don't know about the relations or at least they don't know how to maintain these relations. I've tried to explain, why I personally think that duplicating data allows you to do cross-checks for conflicts is simply a bad reason. well - maybe you're right here, but I'm not sure, so let's omit that for now; I would like to neither agree nor disagree here. On the other hand, the backwards compatibility with tools used by data producers, as well as consumers, _is_ a good reason, but... 3) ...that's why we're having this discussion, isn't it? I don't think that attitude like Go away and don't come back until you've coded editors support, API changes, osm2pgsql patches, ... If you shouldn't come here with an (incomplete) idea and cooperate with others on improving/completing and realizing it, OR after a short discussion admit that it would need actually more work than you thought and it's not worth it... then, what's the point of this mailing list? I thought this is how the community should work - not everybody knows perfectly everything, but together... Well... There was an idea proposed on the mailing list. Some people rised arguments against it, one of it is the editor support question. Nobody opposed to add that support, but the question is one of the order: It's opposed to deprecate a tagging scheme before adding support to ANY editor. It's agreed to deprecate a tagging scheme once it's supported in editors (not necessarily all) and shown to be more or at least equally useful than before. If you - or anyone who approve that proposal would have come with a plugin for josm demonstrating how easy it is to use it instead of claiming stuff, that nobody can proove, I'm sure there would be less arguments about it. But all you do is rising theoretical claims, unproven and - and that's your problem: unbelieved by others. Show how it's better and more easy to use. Show how it can be supported in one major editor - e.g. by writing a plugin. Probably provide ideas for a UI mockup that fit's
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Hi, On 08/01/12 19:41, Petr Morávek [Xificurk] wrote: Frederik Ramm wrote: Tools must serve mappers. Everything in OSM must be geared towards making contribution easy for mappers. Anything else is secondary; consumers are totally unimportant. I think, this is the point on which we fundamentally disagree. Consumers and data usability is important as well. It's not always easy to walk the thin line between the needs and preferences of contributors and consumers, but we should try to. I mean, what's the point of producing the data, if they are unusable or really hard to use? The current usability of OSM for consumers is already sufficient, as proven by millions of consumers. The data *is* usable, and claiming that if we don't change our data model then our data would be comparable to what monkeys with typewriters produce is ridiculous. You have omitted my sentence that followed the totally unimportant. My point is that data consumers are unimportant *for us* because given the high value that OSM represents to them they will invest their own time to make OSM usable for their purpose (rather than us investing our time to make things easier for them). There are certainly ways to improve OSM and some issues are more pressing than others - for example, if we continue to use relations like we do now, then OSM will likely become *less* usable with time - and these issues will have to be solved. The main focus in all we do must be the mappers however - anything that makes OSM more attractive for consumers but more complicated for mappers (or coders who are also a scarce resource) is not acceptable. Therefore, if anyone proposes any improvement to OSM, I expect the argument to say clearly where the advantages for the mappers are - in how far is the suggested change beneficial to the mapper's work, will things become easier for them, will they be able to produce better results in less time, will even less educated mappers be able to contribute. Even if you want mappers to change their behaviour and invest more work to map something the way you want it, that's still ok as long as it's the free decision of those mappers. For example, when Nop set up his hiking map he introduced a new schema for symbols for hiking routes. More work for mappers to record - but many happily did it because they liked the resulting map. Nop did not show up on the tagging list and say: I think we should really make it a policy to add symbols to hiking routes because that makes the map so much more usable or so. That's the spirit that works in OSM. If you want mappers to do something then * give them the tools to do it and * make it attractive for them to do it. The thing that doesn't work is lobby for whatever you want to be made official policy so that mappers are then forced to do it. In initial posting of this thread, Paweł explained how he had written a tool that checks way ref tags against relation ref tags and suggested: Of course there is no hard rules in OSM concerning tagging but http://wiki.openstreetmap.org/wiki/Key:ref does not say too much about the problem above. I think it should describe why relations should be used instead of ref tag on ways if possible. But that is exactly the opposite of how things work round here. Paweł *thinks* that ref tags on relations would be better, and instead of (a) giving mappers the tools to do it and (b) making it attractive to do that (i.e. appealing to the free will of the mappers), Paweł wants to go the (perceived) authoritarian route by changing the rules, by saying that relations SHOULD be used There is no authority in OSM that could tell mappers what they should do - OSMF can't, this list can't, the Wiki can't. The proper approach is to make something that people want to use and where people then see: Oh, if we tag this differently then it works better. If you cannot make such a thing that demonstrates to mappers how your ideas work better, then, obviously, the issue isn't that big after all. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Johan Jönsson johan.j@... writes: *It could also be meant to explain something that might not exist on wikipedia, in what languages and scripts the road signs usually are on the place. In the greece capital Athens there are usually the name in greek letters first and then in roman letters (gr and gr_rom maybe). I would really like the OSM to stop the practice of inventing arbitrary language tags like this and previous ones (ko_ro - Korean as spoken in Romania, really?). Let's please start improving the OSM i18n situation by at least following BCP 47: http://en.wikipedia.org/wiki/IETF_language_tag Thanks, M ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Petr Morávek [Xificurk] xificurk@... writes: Johan Jönsson wrote: *It could also be meant to explain something that might not exist on wikipedia, in what languages and scripts the road signs usually are on the place. In the greece capital Athens there are usually the name in greek letters first and then in roman letters (gr and gr_rom maybe). This is actually a related problem - the question, what should we generally put in name tag? IMHO in case of a dispute, a reasonable solution is on-the-ground rule. But if everybody in Greece agrees that in name tag they will put only names in Greek alphabet (even though you say the signs contain latin transcription as well), it's their call. Exactly, and fits perfectly with the proposed model: in theory there is no difference between multilingual and multi-script content. These should be viewed as just as separate _locales_ (set of parameters that are needed to describe _written_ information). So you could have name:el=Αθήνα lang=el;el-Latn and have the renderer (or whichever client) automatically transliterate the requested 'el-Latn' content from the available 'el' one to populate 'name=Αθήνα (Athína)'. If you only had name=Αθήνα the client wouldn't have a clue that the content is in Greek and wouldn't know how to process it further. name=* without any context of what language is recorded in it is one of the biggest fallacies of OSM i18n and needs to be addressed. The proposed scheme is one way, the other is mandating that name=* is actually name:en=* on the _whole planet_. Having whatever default in it just doesn't work any more. M ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
On 02.08.2012 12:56, MilošKomarčević wrote: name=* without any context of what language is recorded in it is one of the biggest fallacies of OSM i18n and needs to be addressed. You need to realize, though, that mappers in areas where only one language is commonly used will not want to put more effort into mapping names than they do today. And rightly so, imo - from their perspective, it's just more work for little or no gain. Thus, there is a fundamental requirement for any future tagging scheme for names: In areas with a single main language, _one_ tag needs to be enough for a name in that language. Preferably, the key for this case should remain name. Setting some additional tags at the boundary of that area for clarity what name means there is fine, but there must not be any additional effort for setting names on the individual objects. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Tobias Knerr wrote: On 02.08.2012 12:56, MilošKomarčević wrote: name=* without any context of what language is recorded in it is one of the biggest fallacies of OSM i18n and needs to be addressed. You need to realize, though, that mappers in areas where only one language is commonly used will not want to put more effort into mapping names than they do today. And rightly so, imo - from their perspective, it's just more work for little or no gain. Yes, I agree. This is very strong argument for Option 1 and I'm starting to lean towards this solution. I won't touch to page for week or so, but unless someone comes with a strong counter-arguments (or completely different better proposal), I think we should refine the option 1 and build on top of this basic idea. Best regards, Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Tobias Knerr osm@... writes: On 02.08.2012 12:56, MilošKomarčević wrote: name=* without any context of what language is recorded in it is one of the biggest fallacies of OSM i18n and needs to be addressed. You need to realize, though, that mappers in areas where only one language is commonly used will not want to put more effort into mapping names than they do today. And rightly so, imo - from their perspective, it's just more work for little or no gain. Sure. Was just stating the root of the problem, probably brought on by architects with little i18n experience who probably assumed only one language/script is used in an area (or what they though of as most areas). It might have made sense 'from their perspective', but they created a bit of mess for a lot of upcoming and very large and populous multicultural areas (take India for example), not to mention smaller ones all over the world. Saying it was for no gain is a bit short-sighted and selfish, no? Thus, there is a fundamental requirement for any future tagging scheme for names: In areas with a single main language, _one_ tag needs to be enough for a name in that language. Agreed. Preferably, the key for this case should remain name. I don't see a problem of mandating name:xx even when only one language is used for added clarity, and have a bot fix up existing ones. Does break backwards compatibility though, so too late to fix at this point. Setting some additional tags at the boundary of that area for clarity what name means there is fine, but there must not be any additional effort for setting names on the individual objects. Totally agree, and is probably the best way that gives us both the fix of the problem and keeps backward compatibility and least impact to mappers. M ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Petr Morávek [Xificurk] wrote: Tobias Knerr wrote: You need to realize, though, that mappers in areas where only one language is commonly used will not want to put more effort into mapping names than they do today. And rightly so, imo - from their perspective, it's just more work for little or no gain. Yes, I agree. This is very strong argument for Option 1 and I'm starting to lean towards this solution. Have you considered combining the options? For example you could use option 2 with a single additional rule: If lang contains only one language code, treat name as name:lang_value. So if there is only one main language, lang will contain the code for that language, and name will contain the name in that language. But in multilingual areas, lang contains the codes for all these languages as per option 2, and once mappers in those areas trust data consumers to construct the labels from several name:xx reliably, they can begin omitting the bare name tag. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
On Thu, 2012-08-02 at 11:42 +, MilošKomarčević wrote: Tobias Knerr osm@... writes: On 02.08.2012 12:56, MilošKomarčević wrote: name=* without any context of what language is recorded in it is one of the biggest fallacies of OSM i18n and needs to be addressed. You need to realize, though, that mappers in areas where only one language is commonly used will not want to put more effort into mapping names than they do today. And rightly so, imo - from their perspective, it's just more work for little or no gain. Sure. Was just stating the root of the problem, probably brought on by architects with little i18n experience who probably assumed only one language/script is used in an area (or what they though of as most areas). It might have made sense 'from their perspective', but they created a bit of mess for a lot of upcoming and very large and populous multicultural areas (take India for example), not to mention smaller ones all over the world. Saying it was for no gain is a bit short-sighted and selfish, no? Thus, there is a fundamental requirement for any future tagging scheme for names: In areas with a single main language, _one_ tag needs to be enough for a name in that language. Agreed. Preferably, the key for this case should remain name. I don't see a problem of mandating name:xx even when only one language is used for added clarity, and have a bot fix up existing ones. Does break backwards compatibility though, so too late to fix at this point. IMO where there is only one name on a sign, then the name should remain a valid tag. Please no bots on this, as a cross-border mapper I can only see this ending in tears. In Wales, some roads are named in Welsh, some English. I see no problem in that, if there is one name then that should remain the name. A bot really can't be applied here, it first of all has to decide which language a name is in, and then get the tag right. how would it deal with mixed names? Such as Llangollen Road. Welsh place names also drift over the border into Shropshire, where should the border be drawn? Where multiple names exist on signs, larger towns and cities, mappers have already tagged both names, as in name:en name:cy. If there is only one name on the sign, then there should only be one name on the map. This should then be tagged as name, as language cannot be assumed. Even place names in England are not always English, there is a mix of Anglo Saxon, Dane and Norman in there too. Phil ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Hello Peter, you have raised interesting question, so I'll try to address at least some of the questions regarding editor support and describe it from my point of view (as user of Merkaartor). Peter Wendorff wrote: The point is to keep the correct, even if deprecated work of local mappers intact. A mapper that has no idea about relations and added the ref tag to his streets instead, but then sees, that some stupid people from somewhere else deleted that stuff, probably not even recognizing now that it's because of duplicates, for him it's they deleted my work. I presume the workflow, could be something like this (I'll again write in first person): I download the area I've previously edited. Click on the road I've created and see that my ref tag is gone, but wait... what's this dashed square that got highlighted? Let's click it and see. Oh, here is the ref tag and a bunch of others and wait... It highlighted other ways as well, why is that? Aha, it's the whole primary road number 42. Note, you don't need to be a brainiac or have detailed knowledge about the underlying data structure to figure this all out. And if I'm curious about any of this, I can go online and consult the wiki, ask the directly the user that created/modified the relation, or send a question to a mailing list, forum, ... I always thought this cooperative incremental improvement is a key feature in OSM community. If somebody comes and redeos and adds his own bits to the stuff I've created, I don't get offended. You claim, it's more easily maintained in the relation - but for many mappers it isn't, because they don't know about the relations or at least they don't know how to maintain these relations. Once I know, what I described above, I can go ahead and do more stuff like: If I know that from point A to point B there is a road ref=123 and want to make sure it's in OSM. I download the area, click arbitrary part of the road, oh and here we go again with the highlighted box, click it. Great, it highlighted a bunch of ways and: * wait, it says ref=123$, hm... that seems like typo, let's fix it. * somebody forgot to add this piece, let's add it. etc. Compare this with the alternative. The easiest way to go about this is probably find all ways by given criteria. But if there is some kind of mistake, I want to fix, I have to go and correct it on every single way, instead of simply selecting them and adding/removing from relation, or correcting the typo in one place. I admit this is my personal view and is significantly influenced by the editor I use. But I think I've demonstrated that the problem with editors is not that bad as some people say, or at least it doesn't have to be. If you think that the tasks above are hard to do with your favorite tool, then maybe we should talk about how to improve them. -- I have some questions as well (I've already mentioned it before, but it was missed): How should I correctly tag the situation when a part of road has more refs? I don't mean the cycle/hiking routes now, because they have pretty well-established tagging via relations. I'm not sure what the situation is in other countries, but in Czech Republic every bridge has its own reference number. If we abandon the idea of relations for ref numbers, what should I put on that part of the way? * Reference of the bridge only? I don't think that's right - if I go over the bridge I'm still on the road nr. XY. * Both references concatenate by semicolon? Won't this break the algorithms that join the ways with same refs? It will definitely break the find tools in editors. * Or should I simply give up and don't try to add this information? And how about a roundabout intersection of two roads, what ref should be on it? I don't know how to correctly solve these conflicts within the tagging scheme of refs on ways. Best regards, Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Let's not forget that this debate was started by naming disputes in Ukraine. I would vote for option 2 myself, but if that would be found impossible, I could agree with Tobias. LM 2012/8/2 Tobias Knerr o...@tobias-knerr.de: Petr Morávek [Xificurk] wrote: Tobias Knerr wrote: You need to realize, though, that mappers in areas where only one language is commonly used will not want to put more effort into mapping names than they do today. And rightly so, imo - from their perspective, it's just more work for little or no gain. Yes, I agree. This is very strong argument for Option 1 and I'm starting to lean towards this solution. Have you considered combining the options? For example you could use option 2 with a single additional rule: If lang contains only one language code, treat name as name:lang_value. So if there is only one main language, lang will contain the code for that language, and name will contain the name in that language. But in multilingual areas, lang contains the codes for all these languages as per option 2, and once mappers in those areas trust data consumers to construct the labels from several name:xx reliably, they can begin omitting the bare name tag. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
On Thu, Aug 2, 2012 at 1:23 PM, Philip Barnes p...@trigpoint.me.uk wrote: In Wales, some roads are named in Welsh, some English. I see no problem in that, if there is one name then that should remain the name. A bot really can't be applied here, it first of all has to decide which language a name is in, and then get the tag right. how would it deal with mixed names? Such as Llangollen Road. Perfectly illustrates the false assumption name=* was conceived on. Now there's no way to know which is which and how to clean up and separate the data. Not saying you need to in this case, but someone might want to in the future, or in a different area where e.g. the two languages in question are written in different scripts for example. M ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Am 02.08.2012 13:42, schrieb MilošKomarčević: Tobias Knerr osm@... writes: On 02.08.2012 12:56, MilošKomarčević wrote: name=* without any context of what language is recorded in it is one of the biggest fallacies of OSM i18n and needs to be addressed. You need to realize, though, that mappers in areas where only one language is commonly used will not want to put more effort into mapping names than they do today. And rightly so, imo - from their perspective, it's just more work for little or no gain. Sure. Was just stating the root of the problem, probably brought on by architects with little i18n experience who probably assumed only one language/script is used in an area (or what they though of as most areas). It might have made sense 'from their perspective', but they created a bit of mess for a lot of upcoming and very large and populous multicultural areas (take India for example), not to mention smaller ones all over the world. Saying it was for no gain is a bit short-sighted and selfish, no? Thus, there is a fundamental requirement for any future tagging scheme for names: In areas with a single main language, _one_ tag needs to be enough for a name in that language. Agreed. Preferably, the key for this case should remain name. I don't see a problem of mandating name:xx even when only one language is used for added clarity, and have a bot fix up existing ones. Does break backwards compatibility though, so too late to fix at this point. I don't think a bot would help, but a hint in editors etc. might. If editing software encourages the user to specify at least one lang:* additional to name, e.g. by giving a select box to select the language, many would do that, especially in multilanguage areas or near language borders. On the other hand what would you want to do if there's only one name tag, and no localized version of it? use no name instead? Usually you would go for name as there's no better option. Same if there's name and some strange name:*, but not the one you prefer - then tage name as a fallback; and if there's a name:* that equals name, then perfect: use that in your software. A bot cannot fix anything like that: adding name:* works most often, but not always, and future mappers aren't encouraged/hinted by tools (QA tools or Editors) that there's a missing name:*, that could be added to specify the names language. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
On Thu, Aug 2, 2012 at 2:00 PM, Peter Wendorff wendo...@uni-paderborn.de wrote: I don't think a bot would help, but a hint in editors etc. might. If editing software encourages the user to specify at least one lang:* additional to name, e.g. by giving a select box to select the language, many would do that, especially in multilanguage areas or near language borders. On the other hand what would you want to do if there's only one name tag, and no localized version of it? use no name instead? Usually you would go for name as there's no better option. Same if there's name and some strange name:*, but not the one you prefer - then tage name as a fallback; and if there's a name:* that equals name, then perfect: use that in your software. A bot cannot fix anything like that: adding name:* works most often, but not always, and future mappers aren't encouraged/hinted by tools (QA tools or Editors) that there's a missing name:*, that could be added to specify the names language. Sure, there are many ways to improve and fix this. Was just trying to highlight the fundamental problem: we have tons of entered data in the database for which we (at the moment) can't tell what language/script they have been entered in. M ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Option 1 best because of compatibility but also this. It's very difficult to have the renderer synthesize some names. In Belgium, the law states that the name *must* be displayed in all the official languages of the place. For Brussels' streets, if there are two spellings, the names are displayed as (rue and straat mean street) rue du Trône Troonstraat But if there is only one, as (laan means avenue) avenue Marnix laan And there can be many other specifics, like shortening a name to fit the straat length. Furthermore, it makes a harder job for a tracing program to verify that a name was given. So, it's best to write it as it must display. In any case, as for any tag, lang=* should be defined precisely. Is it the languages that are commonly spoken, that is which dictionary to pack in your luggage, or is it just the way the name is displayed, in which case it'd better be called name-lang or something? Indeed, in Russia for example, the only spoken (dictionary) language is Russian but they may like to add the English spelling to some of their places for foreigners' convenience. Again, option 1 make it easier. Another option for Brussels would have been to make two nodes for it, one for each language. But it's a very limited workaround, you just cannot do that for every street. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Shark tagging
I took this photo of a building across the street. How do you propose I tag it? http://www.emacsen.net/shark-bldg.jpg :) - Serge ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shark tagging
Serge Wroclawski wrote: How do you propose I tag it? Like this one? http://www.openstreetmap.org/browse/node/31374891 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shark tagging
2012/8/2 Serge Wroclawski emac...@gmail.com: I took this photo of a building across the street. How do you propose I tag it? http://www.emacsen.net/shark-bldg.jpg I would suggest shark=great_white or simply shark=yes if you are not sure about the exact species. Please also add layer=1 (or higher) and preferable some indication about the height. Martin P.S. ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shark tagging
2012/8/2 Martin Vonwald imagic@gmail.com 2012/8/2 Serge Wroclawski emac...@gmail.com: I took this photo of a building across the street. How do you propose I tag it? http://www.emacsen.net/shark-bldg.jpg I would suggest shark=great_white or simply shark=yes if you are not sure about the exact species. Please also add layer=1 (or higher) and preferable some indication about the height. I fear this will lead to namespace pollution. What if everyone starts to map various protunding elements with their names each? What if there was an actual need to tag the fact that the building has a shark facility, for example? I suggest something along the lines of building:part:protunding=yes, building:part:protunding:shape=shark. I agree with additional tags about height. It may also be useful to indicate whether the shark provides shade for the pedestrians on the streets. Regards, Simone Martin P.S. ;-) ;-) of course ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Hi, just a general note on this: I don't see a problem of mandating name:xx even when only one language is used for added clarity, and have a bot fix up existing ones. Does break backwards compatibility though, so too late to fix at this point. I don't think a bot would help, but a hint in editors etc. might. There is a third way to handle such backward-incompatible changes if we should ever want to make them: We can change in OSM but provide a backward compatibility interface, i.e. modified planet files or even a modified API (so if you get the same way through /api/0.6/way/1234 you get a different result than if you do /api/0.7/way/1234). I'm not saying that we should (or should not) do this for name localization, just pointing out that we don't necessarily have to stick to somethig old just because there are clients who cannot work with the new. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
On Thu, Aug 2, 2012 at 7:25 AM, Andrew Errington erringt...@gmail.comwrote: In Korea we use ko_rm (not ko_ro), which is intended to mean Romanised Korean, i.e. Korean spelled phonetically using Roman characters. If there is an ISO (or similar) code for this, what is it? en_kr? Also, what is the code for Hanja, which is essentially Chinese characters used in Korea? I couldn't find one, so I used zh (which is *actual* Chinese, which might be subtly different). zh_kr? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
On Thu, Aug 2, 2012 at 3:25 PM, Andrew Errington erringt...@gmail.com wrote: On Thu, 02 Aug 2012 19:35:31 MilošKomarčević wrote: Johan Jönsson johan.j@... writes: *It could also be meant to explain something that might not exist on wikipedia, in what languages and scripts the road signs usually are on the place. In the greece capital Athens there are usually the name in greek letters first and then in roman letters (gr and gr_rom maybe). I would really like the OSM to stop the practice of inventing arbitrary language tags like this and previous ones (ko_ro - Korean as spoken in Romania, really?). Let's please start improving the OSM i18n situation by at least following BCP 47: http://en.wikipedia.org/wiki/IETF_language_tag In Korea we use ko_rm (not ko_ro), which is intended to mean Romanised Korean, i.e. Korean spelled phonetically using Roman characters. Sorry, for some reason thought I came across ko_ro somewhere... If there is an ISO (or similar) code for this, what is it? Anyhow, according to BCP 47, this should be 'ko-Latn' (Korean language written in Latin script). Also, what is the code for Hanja, which is essentially Chinese characters used in Korea? I couldn't find one, so I used zh (which is *actual* Chinese, which might be subtly different). This would be 'ko-Hani' (ISO 15 code for Hanja). BCP 47 is pretty self-explanatory and all subtags are given in the links on the wikipedia page. HTH, M ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
On Thu, Aug 2, 2012 at 3:39 PM, Miloš Komarčević kmi...@gmail.com wrote: Also, what is the code for Hanja, which is essentially Chinese characters used in Korea? I couldn't find one, so I used zh (which is *actual* Chinese, which might be subtly different). This would be 'ko-Hani' (ISO 15 code for Hanja). Or, 'ko-Kore', as registered with IANA: Type: language Subtag: ko Description: Korean Added: 2005-10-16 Suppress-Script: Kore From ISO 15924: HaniHan (Hanzi, Kanji, Hanja) KoreKorean (alias for Hangul + Han) I'm not going to pretend I understand the difference. ;) But since it's registered as 'Suppress-Script', it means that if you just tag something as 'kr', you really meant 'ko-Kore'. HTH, M ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Bridge ref highway ref: bridge ref should have a specific tag, such as bridge:ref=whatever Two roads meet at roundabouts: roundabout has higher-ranking (ie lower) number, unless the higher-ranking road has a flyover or underpass. Or don't have a ref. None of the issues raised justify changing a very well established scheme. Richard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
On Thu, Aug 2, 2012 at 3:39 PM, Miloš Komarčević kmi...@gmail.com wrote: On Thu, Aug 2, 2012 at 3:25 PM, Andrew Errington erringt...@gmail.com wrote: In Korea we use ko_rm (not ko_ro), which is intended to mean Romanised Korean, i.e. Korean spelled phonetically using Roman characters. And, just for completeness, ko_rm can be understood as 'Korean as spoken in some road vehicles on Madagascar'. ;) M ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Even though the bridges were not the best example, I would not dismiss their importance. Maybe a better example is when two roads (numbers) run on the same asphalt. It is not uncommon in my country and probably possible elsewhere. There is support for this - that is JOSM + RelationToolbox plugin. Potlatch recently gained the ability to highlight all relations, which is great. I will try using it for a while and suggest concrete improvements on this matter. There were concerns if it is more gain for mappers or for data consumers. I am the former and use the later. As a mapper I prefer one thing being present on one and only one place. I prefer one real object being represented by one osm object be it point a way or a relation. As a mapper I hate repetitive work and relations let me get rid of it for some part. I like to know that I have made no mistakes - relations are easier to check than 50 way segments. If the whole street gets a different surface or gets wider, relation at least gives me an easy way to select all members. I like relations when mapping. As a user of osm applications I want them to be as feature rich as possible. Frederick is right that consumers would not go away because data model is not perfect. But they might omit a feature or ten. I started contributing because osm maps were more detailed and precise than any other. Therefore I believe that the better map comes with osm watermark the more contributors the project gains. Lukáš Matějka (LM_1) 2012/8/2 Richard Mann richard.mann.westoxf...@gmail.com: Bridge ref highway ref: bridge ref should have a specific tag, such as bridge:ref=whatever Two roads meet at roundabouts: roundabout has higher-ranking (ie lower) number, unless the higher-ranking road has a flyover or underpass. Or don't have a ref. None of the issues raised justify changing a very well established scheme. Richard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shark tagging
2012/8/2 Serge Wroclawski emac...@gmail.com: I took this photo of a building across the street. How do you propose I tag it? http://www.emacsen.net/shark-bldg.jpg Tagging, tagging? Like this, maybe? ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Shark tagging
Certainly this is not the first shark in a house. The shark of the shark house at *2 New High Street, Headington, Oxford OX3 7AQ, UK *is some 25 years old and present on OSM as node 31374891. https://en.wikipedia.org/wiki/The_Headington_Shark :-) Volker On 2 August 2012 22:48, André Pirard a_pir...@hotmail.com wrote: ** 2012/8/2 Serge Wroclawski emac...@gmail.com emac...@gmail.com: I took this photo of a building across the street. How do you propose I tag it? http://www.emacsen.net/shark-bldg.jpg Tagging, tagging? Like this, maybehttp://www.papou.byethost9.com/tmp/shark-bldg-Google.png ? ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
