[OSM-dev] [OSM-talk] Bilingual rendering for Greece

Peter Körner osm-lists at mazdermind.de
Thu Aug 19 08:23:59 BST 2010


Am 18.08.2010 21:30, schrieb Stephan Knauss:
> Peter Körner wrote:
>> Am 18.08.2010 10:31, schrieb Stephan Knauss:
>>> It's complicated because different languages take up different space on
>>> the map. So the placement of icons is not trivial.
>>
>> Ævar had a great Idea for a third approach:
>> Only objects that actually have a translation need to be in the
>> language overlay -- all other objects like most streets can go into
>> the base layer. That way the language overlay would become nearly
>> empty on higher zoom levels.
>
> How should this solve the problem with texts in different languages
> taking up different space on the map?
It does not solve the problem but it kind of avoids it, as most POIs 
have no translation. The biggest number of translated objects are 
place-nodes and they should be rendered above all, anyway.

The only possibility to really solve this is to render the 
PointSymbolizers together with each overlay (PointSymbolizers are the 
only one that can displace TextSymbolizers).

>> You can then create a conditional index like
>> CREATE INDEX bla ON points (osm_id) WHERE NOT "name:" IS NULL;
>
> I did not measure the lookup speed, but having an index sounds nice ;)
> Why do you need an additional column? Do I have a wrong understanding on
> how indexes work?
You need a lookup for "which objects do have a translation". "a 
translation" means one of any name:xx tag, no matter what xx is. It's 
not possible to have an index for a lookup like this using the classic 
osm2pgsql layout nor with the hstore column.

> I did this:
> CREATE INDEX planet_osm_point_names ON planet_osm_point USING
> btree(osm_id) WHERE NOT (tags->'name:en') IS NULL;
That works in the US but no where else on the world. What's about cities 
in russia that eg. have name=.. and name:cz=.. ?

Peter



More information about the dev mailing list