[OSM-dev] Different styles for each country/region

Patrick Kilian osm at petschge.de
Thu Feb 24 10:43:14 GMT 2011


Hi,

(sorry, resent to list with correct from)

> thanks for your answer. It was already quite enlightening, because I had
no idea of the technical problems. But, I'm not yet 100% satisfied :)
I'll see that I can do about the remaining issues.


>> People desperately trying to change their countries look and feel to
>> what they are used to from the only road atlas they ever owned might be
>> tempted to "fix" the style without the necessary skills and might very
>> well create ugly styles ruining the nice user experience we have now.
> Well, but the system could set up some barrier, so that not everyone
> could just change the style:
> - only people with a certain amount of edits would have the right to
>   change the style
> - votes are necessary to change the style
> - or something like that
Unfortunatly beeing an avid mapper doesn't mean that you know about
renderers, stylesheets or have any sense of style and design whatsoever.
And the completly broken tag proposal and voting process shows that
openstreetmap is not a democracy.


> Also, creating this style of map would only be necessary once or twice. I
> think, most west european countries are already at some point where the
> important stuff is already inclued in OSM - it would then not be a
> problem to design a nice template for their country. Of course, people
> may tend to copy the style of their printed road atlasses or of Google
> Maps or whatever; still, some styles are not specific to one publisher.
> Think of the Autobahn signs in Germany, for example.
Copying the style of printed road atlases, Google Maps or other
copyrighted works might very well leave openstreetmap open to legal
liabilities. This is certainly not a problem for blue Autobahn signs,
might get tricky if you want to use the logos of subway operators and it
gets outright illegal if you want to copy the look and feel of Google
Maps.


>> 1.) 200 copies of the style with small tweaks to render the correct
>> language of the name tags and the correct highway colors eats more RAM
>> then any reasonable box has to spare on that (IIRC the amount is in the
>> two digit gigabyte range.)
> I don't know about the interna of the rendering, but is this really such
> a big issue? I always thought that the rendering process is idle most of
> the time and only comes to work when somebody made a change. Well, but I
> don't know about that :)
Yes it is. The main tile server is pushing 50 Megabytes per Second of
tiles, most of them freshly rendered. The tiles at home project prerenderes
every change and need about two hours till a change makes it to the
rendered tiles and needs about 6 weeks to rerender the world. The world is
_large_ and the rate of change in openstreetmap is substantial.


>> 3.) Some people (say Germans) will expect all of the world rendered in
>> the style they are used to (lets call it the german style), other
>> Germans would expect Germany in the german style and France in the
>> french rendering style. How do you resolve that? How do you deal with
>> the fact that some tiles are half french and half german?
Well? How do you?


>> 4.) How do you allow people to select map style? On of the earliest
>> problems of the toolserver map display was that a dropdown list with 200
>> language layers in Openlayers is bulky at best and breaks old browsers
>> at worst.
> But that can't really be a problem, right? The choice can be narrowed
> down really nicely:
Oh, it is a very real problem.


> 1. Check the browsers language
> 2. Check, which area is currently viewed.
>
> If then a German user (= German browser) looks at a place in Germany, it
> would just display one option: German (native). If one looked at Austria,
> it would change the list and display: "German style" and "Austrian style".
> If a British user looks at Germany, it would show: "British style with
> English names", "British style with German names", "German native style".
> Imho, this would reasonably satisfy all needs.
> German user looking at a Chinese city: "German style with German names",
> "German style with Chinese names", "Chinese native style", "Chinese
> native style + reading" (the last one would only be
> necessary in areas such as China, Japan or Taiwan, where it is
> impossible/difficult for people having a slight knowledge of the
> language to be able to read _every_ geographical name.)
>
>
> I guess, it is not necessary to offer a German user the option to display
> a Chinese city with Arabian names.
Perhaps not that. But what if I zoom out until I see three european
countries with five languages? What if I want to show that map to a
Japanese collegue? What if I want to show a map of Austria to a British
collegue. Do I want German style, Austrian style or British style? With
German or English names?
All of that are _solvable_ problem. But very real problem and we the lack
the man power to solve them at the moment.


> If the system changed the dropdown list according to the viewed region,
> it would significantly narrow the options. And, if the user then wants to
> have China displayed with Arabian names, he could fine tune it in his
> user profile (similar to wikipedia, where you can change the css file).
Sure that solved that particular UI problem. But suddenly I have one more
weekend of coding work.


>> So bottom line is: If you want this feature this year set up an own
>> rendering stack and render the map in the style you are used to. If you
>> feel like spending a lot of evenings and weekends, contact the people
>> who did the multilanguage maps on the wikimedia toolserver and start
>> hacking at the technical problems. Maintining the stylesheets is a
>> sizeable task but small and simple in comparison and discussions about
>> who edits which stylesheet are simple a year or two too early.
> Well, the usual problem arises: I am no programmer, and thus my ability
> to actually help are a little bit limited (of course, I can do simpler
> things, maybe playing with rendering options would still be ok).
That is exactly the problem. Way too many people want things but don't
want to do them themselves and the few developers we have are already
busy. So how about learning to program? I wasn't born with the innate
ability to programm in a dozen languages.


> I am currently just looking at Openstreetmap from a users perspective and
> am just seeing many practical problems with the current (lack of)
> internationalization, which will be, in my opinion, a severe obstacle for
> worldwide adoption of OSM, outside of Europe. Of course, I can understand
> everybody creating OSM (Internationalization usually does not seem like a
> important job), but I really think that there are some huge problems.
> What I have also observed is, that, because of OSM's current ... sub
> optimal internalization, some areas in the world seem to adopt quite some
> dirty hacks, to cope with it (e.g. "name=東京
> (Tokyo)").
Yes I agree that this is a dirty name. Having name:jp=東京 and
name:en=Tokyo as additional tags will help a lot in the future.


> This may cause some unnecessary work in the future if OSM will then
> (hopefully) be more internationalized. Right now, most of the countries
> outside of Europe do not really seem to be well covered, so it may not be
> too late to provide OSM with a clean interface for it.
Actually the countries outside of Europe are in general quite well mapped
in OSM in comparison to other mapping services.


> I really guess that if OSM will not overcome this current "bugs", it will
> not gain the popularity worldwide as Wikipedia has gained (Just think
> about having each city name or whatever in your home country be bilingual
> on maps, maybe even with a script you cannot even read).
World domination would be nice. But for now we lack the resources.


> If I can help, of course I would really like to do so. My problems are
> just that I am a layman in almost every aspect: programming, cartography
> and whatever.
If you want to improve the situation really badly you can start by setting
up a rendering stack, import data for one country and try to work on the
problems listed above. Expect to spend all your weekends and free
evenings. If you only want to contribute an hour here an hours there
(which is totally fine too), then go through the tickets for the mapnik
component every once in a while and see if they lack informations you can
supply. E.g. for feature request that ask for a new tag to be rendered
check if a link to a example is present. Optimally one in a low density
region and one in a high density region. Is an icon available? Is it in
the correct file format? And so one. You might spend an hour on a ticket
but if you really collect all the necessary information the developers can
tackle it much faster.


Patrick "Petschge" Kilian




More information about the dev mailing list