[OSM-talk] Naming disputes in Ukraine

[Jo]

2012/7/25 Lester Caine <lester at lsces.co.uk>

> "Petr Morávek [Xificurk]" wrote:
>
>> Actually 'lang' could be populated from a higher level area setting
>>> >initially?
>>>
>> Well, it could be... but I'm not really a fan of this idea, because...
>> You would need to do a spatial query to get the setting from the higher
>> level. And this complicates everything, because...
>> - Things (multipolygons & boundaries especially) get broken pretty
>> frequently, so a single bug in one relation or way could do a lot of
>> damage.
>> - It means that you have to check a whole hierarchy to decide if you
>> need to regenerate the value, which means this would order of magnitude
>> harder to implement in data consumers SW.
>> - Not all data consumers use whole planet data and if they cut out only
>> a small region, they don't have the higher level in their data.
>> - You would need to define how to resolve conflicts, e.g. a way spanning
>> multiple areas with defined lang format.
>>
>
> I'm just talking about an initial setup to get things started.
>
>  >This sidesteps a number of problems in implementation, my only comment
>>> >would be as I indicated. lang="it - de" or "de / it" needs to be a
>>> >single identifiable character. Formatting should be language specific
>>> >when building a 'text=" string, and that could be populated in a
>>> >language specific way for the users preference anyway?
>>>
>> I don't really understand this. To clarify, my suggestion was basically
>> this: let the lang format be arbitrary, just replace any string matching
>> "[a-z_]+" by key:[a-z_]+. E.g.
>>
>>
>> lang="it - de" => name="Bolzano - Bozen"
>> lang="it (de)" => name="Bolzano (Bozen)"
>> lang="it / de" => name="Bolzano / Bozen"
>>
>
> While I can understand why you propose this, it makes 'decoding' the
> languages by tools a little more difficult, and 'hard codes' a format,
> which alternative uses may need to replace? Does hard coding the display
> format here make sense in general terms?
>

Mapnik needs a default that it can work with, so I think hard coding it
does indeed make sense.

Polyglot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20120725/6a19408e/attachment-0001.html>