[OSM-talk] Rendering barangays for the Philippines

[David Earl]

On 26/11/2008 22:04, Bob Jonkman wrote:
> On 26 Nov 2008 at 21:03, David Earl wrote:
> 
>> On 26/11/2008 20:47, Bob Jonkman wrote:
>>> This can be solved with an equivalence table at the renderer, eg:
>>>
>>> {place,plaats,ilagay}={village,barangay,dorpje} : render(brown)
>>> {natural,pat}={snow,patuquaujuq,patuqun,patpat} : render(white)
>>> [...]
>> Yes, but *every* renderer - nay, *every* consumer everywhere -
>> editors, renderers, search engines, route finders, each of which must
>> all know about all the tag variants everyone uses.
> 
> [...]
> 
>> Surely it must be better to centralise handling of this
> 
> Absolutely.  The equivalence table is stored whereever the mapping database is 
> stored. As the database (or a portion) is downloaded, so is the relevant portion of 
> the equivalence table. 
> 
> The beauty is that the existing tags and values continue to exist as they are now, 
> so existing applications continue to work as they always have.  New applications 
> that incorporate the equivalence table lookups can make use of the extra information 
> as they see fit.
 >
>> so that consumers only have to know either about one canonical form,
> 
> But there isn't one canonical form.  That's the problem.
> 
>> or can get the data out in their language (e.g. for editing it) rather
>> than necessarily the form in which it was input. 
> 
> You can only get the data out in your own language if there is a translation 
> mechanism somewhere.  Equivalence tables could provide the "i18n" portion (another 
> use I hadn't anticipated); the renderer, search engine, route finder &c. can provide 
> the "l10n" part.
> 
>> Why force re-invention of the wheel in every application that uses
>> OSM?
> 
> Because the needs of OSM users isn't being met by current data and applications.  
> The issue is important enough to have sparked a 20+ message discussion over two 
> days.
> 
>> One way to centralise it might be to provide a central table consumers
>> can work from. But so much better to have it happen transparently.
> 
> Agreed on both points, which aren't mutually exclusive.

OK, so you are happy to have the translation table centrally, but not 
the algorithm which applies it. I still don't really see why you want to 
make each application implement its own version of the algorithm when it 
could so simply be done as the data passes into and out of the database.

Applications need change hardly at all this way, whereas your way all 
renderers have to understand (via a table and a homegrown algorithm) 
what each of the equivalent tags mean, otherwise the maps don't render 
correctly.

Here's an example of how I'm seeing it working: User T is Thai so sets 
JOSM to work in Thai (I'm not considering UIs here, just the data). JOSM 
tells the API that's what the language is when it uploads or downloads. 
So T's download automatically sees what I know as a village as 
thai-for-village. N, the Norwegian visitor to Bangkok entered that 
village the previous day in norwegian-for-village having told Potlatch 
she was working in Norwegian. T decides it is really a town, so changes 
it to town-in-thai and uploads it. N downloads it the following day and 
sees town-in-norwegian. Mapnik also sees it and renders town-as-a-symbol.

All that happens with the only change to the API being an indication of 
what language you want to communicate in. You don't care how it is 
stored (it could store the source data and language codes or translate 
it on the fly - but that's all abstracted away, you don't care it is 
hidden behind the API).

(Of course the API would need to include a protocol for changing the table.)

This reduces the impact across all the software, doesn't mean you have 
to download every combination of every tag with each download, and can 
be implemented more efficiently as the API only has to consider the one 
language requested by the user, not all combinations.

I just don't understand why you want to distribute this common code (or 
more likely subtly different code!) and data around all the applications 
when it can be done just once. The effect is identical in the end - when 
all applications implement the table handling in your case - whereas 
doing it centrally all applications continue to work and if they make a 
tiny change to allow users to specify which language automatically get 
localised tags.

David