[OSM-talk] Rendering barangays for the Philippines

[David Earl]

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)
> 
> This lets us keep the richness and sublety of all the tags and values in the 
> database.  As new tags or values are introduced it only requires updates to the 
> equivalence table, not the rendering engine or the editors.
> 
> The only (possible) constraint is the additional processing needed by the lookups, 
> and the additional space required by the tables, but in another 18 months processing 
> power will have doubled and the cost of disk space halved :-)

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.

Furthermore there would be *hundreds* of language variants for every tag.

Even worse (and this is a real problem that I've realised looking at 
even the minimal translations I'll need for the name finder, which is a 
consumer application), there a clashes between languages, so that in one 
language moulin=rouge may mean a windmill and in another a brothel.

Surely it must be better to centralise handling of this so that 
consumers only have to know either about one canonical form, or can get 
the data out in their language (e.g. for editing it) rather than 
necessarily the form in which it was input.

Why force re-invention of the wheel in every application that uses OSM?

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.

David