[OSM-talk] Rendering barangays for the Philippines

Bob Jonkman bjonkman at sobac.com
Wed Nov 26 22:04:46 GMT 2008


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.


>
>David
>






More information about the talk mailing list