Towards a more readable Openstreetmap based world map for westerners
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Geggus, Sven
The standard rendering style used in Openstreetmap today produces hardly readable maps in countries where the usage of latin script is not the norm, at least from an average westerners point of view. Our map style uses a renderer independent approach to solve this. We use localization (l10n) functions that create readable names. They are implemented as stored procedures in the PostgresSQL database which contains the Openstreetmap data. The targeted latin langage (german, english, …) can be easily selected. The talk will show how these functions currently work and will give an outlook on potential future extensions. In contrast to almost all legacy geographic data Openstreetmap does already contain a lot of localized data acquired by mappers from all around the world, which should be used whenever possible (Example: japan instead of 日本). Automatic transliteration can then be used as an alternative if no latin names are available in the database. Especially when using transliteration there are many pifalls which have to be addressed depending on language and country. Some of them have already been dealt with by the current implementation and are presented in the talk. Others, which appear difficult or impossible to solve are also shown. Another challenge which exists in localization of maps are political problems. I will briefly describe some of these issues at the end of my talk. Sven Geggus
 Okay. Hello and welcome to the third and last talk of this session block. We now have Sven Geckos who's working on improvements for label placement, especially for Westerners. Hello. I'm Sven Geckos and I'm working actually at the Fraunhofer Research Institute, IOSB in Karlsruhe, which is one of about 60 all around Germany and they are publicly funded. And I'm a Swiss admin and GIS server, Linux admin, all things Linux guy there. And I'm doing the German metnik style as a hobby. And fortunately, I was able to do some work for this project as part of my day job. And so part of this, what I'm presenting here is, I have been able to do as part of my day job. So what I'm talking about, the motivation for doing this is, if you look at the OpenStreetMap or IGMAP and go to countries where Latin script is not the norm, you will usually understand, you won't understand anything. So the reason for this rule is that the project usually uses local languages for acquiring names and for objects, geographical objects in the map. And so we can't just render names like OpenStreetMap or IGMAP standard style does it, if we want to understand this from a Westerners perspective. So, but fortunately, in contrast to conventional geodata, OpenStreetMap does contain at least some localized data. So we should use this when rendering maps to get a more understandable one. So how do localize objects in OpenStreetMap data look like? I have two examples for country borders, country objects. On the left hand side, you can see the object for Germany. On the right hand side, you can see the object for Israel. So what we want to use is actually something Roman, so not the name tag. And we have this colon separated name tags in this OpenStreetMap key value system where you can use arbitrary keys. And I think what we want to use here, if our target language is German, we want to use the name colon DE tag. Probably we want to have the original name in parentases. So that is our target. So let's have a quick look at writing systems of the world. As you can see, they are mostly dominated by Latin with two exceptions, the Russian three exceptions, probably the Arabian world, the Russian foundation, and all around Asia. So the objective is use all localization for all these countries. There's one in India as an exception because India has English as an official language. So in India, we will always have Latin script alternatives. So here's like our OpenStreetMap Carto style looks like the rural area of Moscow for an example. And here's what it looks like if we add localization. So here's our main objective, making the map readable for Westerners by using Latin script. Use the localized data from OpenStreetMap itself. Whenever this is possible, this is not possible on any object and will never be because many objects just don't have and Latin name. So use other localization methods in OpenStreetMap does not contain the data we want. So use transcription or transliteration. So how will we do this? My approach has been to use PostgreSQL stored procedures, which is an advantage, but it can also be a disadvantage. It is an advantage because it is rendering independent. It doesn't matter if you're using MapNIC, MapServer, GeoServer, whatever for rendering, because all you have to change is your SQL. The disadvantage is, well, if your data source is not PostgreSQL, for example, you're using raw OpenStreetMap files or shape files or something, you can't use this. So here's what the implementation looked like. I have three PostgreSQL functions which can be used. They are placed in their own extension. And this is actually usable for any language, any Western language using Latin script or any language using script, Latin script doesn't need to be a Western language. It is done for German language, but with other Roman languages in mind. So a convenient way to do this is to add database views which look like the original table. So in the best case, you don't even need to change anything in your style. Okay. One thing I need to say, why I have a separate function for a get place name and get street name. The reason is if you add a name in parent cases, you have the local name and localized name and this will get very long. So what I also do is abbreviation of street like ST in English or STR for Straße in Germany. And this is actually a place where I would like to get more native speakers of other language to get these abbreviation code for as many languages as possible. So here is what my state machine like to do the decision which name to use. I have a look at the target language in my example, it's name.colonde. And if we have this, just use it. Now if we don't have it, have a look at name. If name is written in Latin script, well, we are in a country which uses Latin script. So just use this. If name is not Latin script, have a look if int name which is an international name does exist. I am expecting this to be Latin, so just use it. And if this is not the case, have a look if there is an English name, if there is not, well, there's a last resort we have to use transcription. As a short in slide, difference between transcription and transliteration. Transliteration means something which is revertible. Transliterate something, transliterate it back, you will get your original script. This is not the case for transcription. Transcription is more done with a vessel reader in mind reading this, trying to get the pronunciation as close as possible to the original pronunciation. So transcription is what we need because we don't need the reversible factor. And another thing you need to know if you think about stuff like this is there are actually three, probably four, if you consider hybrid forms, classes of writing systems. First, there are alphabets, well-known Latin, Greek, Arabic transcription is usually easy using them. This is also true for syllabaries. The Japanese kana is one example. So it's relatively easy transcription. And then you have a lot of log traffic writing systems like Chinese. Chinese is actually the only log traffic writing system which is still in use. There have been historical ones in the history of humankind. But Chinese is the only one left. And the problem with log traffic writing system is that transcription is only possible by language. And if you do a transcription in Chinese and do a transcription in Japanese for the same characters, you will get something completely different. So this has to be resolved in some way. And last but not least, there are hybrid forms like Thai language or Korean language. Those are all mostly easy to transcript. So a few known problems of transcription I have been encountered. There may be more. I would be glad to hear from more and best would be I would hear how to resolve them. So first of all, the logic logic graphic alphabet transcription of Chinese characters has to be based on the place of the geographical objects. Okay, we are doing maps here. We are having a geographic way our database. So this is not a problem. We can just determine what country we are in and decide based on the country we are in, which transcription to use. Current implementation does this with Japanese. And this will probably need to get extended to some other scripts. Another thing is Thailand uses a royal Thai general system of transcription which you get on local road signs and stuff. Unfortunately, the ICU library, which is publicly available as free software uses ICO 11940, which is something completely different and not widely used. I'm not aware of a free and open source library implementing RGTS. If there would be it would be it could be easily added. Another thing is Arabic and Hebrew, for example, do not add all vocals to the written words. Instead, the readers add them by while reading. So they are they are actually not in the word. So an automatism can't be added without word lists or something. So transliteration will therefore be often incomplete. As an example, I have Tehran using ICO ICU. It gives you trend, which is not what you are likely to expect. Fortunately, in place names, this isn't that problematic because they are they usually have open street map text. So you don't need to go for transliteration. A few words to the current implementation. I am using the ICO international components for Unicode library as a default if there are better ones better ones can be used. A postgresquales.procedure has been implemented, which is actually just the thin layer for calling the any to Latin transliteration form function of this library and is then available as a stored procedure. And we have a place dependent use of transcription libraries for currently doing this Chinese characters, which Japanese called kanji. And this is performed by the Kakasi library, which is also free software. And this is only done if the object is located in Japan and is not used otherwise. This scheme is extendable to other writing system and countries. And we can also add something like usage of different transcription libraries by writing system and not by place, which can also be easily added. Two other problems I encountered by using internationalization. There's no single font available, which contains all Unicode characters. So you have to use different ones and compromise in the current code is to render local names only if they use Latin Greek or Cyrillic. This should be extended. Possible resolution would be, I learned yesterday that map server seven does actually implement this. So I have to have a look. The renderer can use different font spend based on the character set and map server seven does this. I'm not exactly sure about what map Nick currently does. It might also be possible to produce a best of font from various sources. I didn't try this yet. One last slide. Political problems in localization. Political problems are usually unable to solve them by technology. Many regions of the world have been part of other countries in the past. And for example, the German settlement areas in Eastern Europe, if you have even the smallest villages in Poland, Alsace or Lorraine have still German names. Nobody knows if they are still in widespread use or not. In the worst case scenario, the usage will offend people. So the only thing we can do is trust the mappers. The mappers will only acquire with names which are still used. They use old name otherwise. Hopefully they do. What we do as a compromise is always render the current local name in parentases. So prospect and enhancements, technical solution of the problem to render glyphs of different writing systems in a single label. As I already said, this will probably already work in MAP Server 7. Addition of more and better suited libraries. If somebody knows in the audience of a library which might be suitable, I will be happy to know and integrate it. More fine-grained distinction of the transcription algorithms by place. It might be needed to do this more fine-grained. And add street abbreviation code for all common languages. Actually add street abbreviation code for all languages where streets are actually abbreviated. And suggestions from the audience. I will do a two-minute live demo and then I will take questions. Okay. So I will call PostgresQL line. Okay. First I need to create my extension. And then I will show you how to transliterate it. Probably somebody knows these characters. Those are the characters for Tokyo. And you get Dong Qing. Well, this is not very good. So we need to use something else. Okay. I get Tokyo better, I would say much better than Dong Qing. Still not perfect, but well, MAP has already acquired Tokyo in the proper script for us. But if we would use transcription, we should go for the second one. And last, there is the GO-Aware transliteration function. So I will, I just added a point here. And 137.35 is somewhere in Japan. If I add somewhere in Germany, like 949, I will still get Dong Qing. So this is aware of the location and how, whenever the object is located in Japan, it will use the Japanese transliteration. So and if you will, it's easy to also drop the, again, the extension. Okay. One more demo. I take the Karlsgasse in Brak, which is called Kalloba in Czech. And Brak has German names all over the place because of its history. And, but in the real world, you see all, you all, you can only see the Czech street signs. So we add the, we should add the German in parentases. So this is what it looks like. And this is actually what we are using for the map. And as you can see, if you use the get street name function, the Gase will be abbreviated to G dot. And currently I have this abbreviations for Russian, German, English, and Ukrainian. I would be glad to get this for other languages. Okay. So if I don't use street name, but place name, the stuff will not get abbreviated. Yeah. So, okay. So far, questions. Thank you very much, Sven. Yeah, how is it with this to be turned around? Because obviously, like a lot of tourists, like from Japan or Asia come to like Europe and they want to see like the Japanese name for German streets or for German places. This can be likely done, but you need to change the code. But because the code is mostly done with Latin script in mind, there are a few corner cases where it won't work. And first of all, you have to implement something else than you have to extend the ICU repo functions, which currently is hard coded any to let in. This should be any to whatever Thai Japanese. And I think it's not a problem for Japanese because they use Latin script and all that in script. It's probably more for Chinese people. And I'm actually not aware if there even is a transliteration function in the art into the other direction. So it might be possible to do this. You can configure the code to do it, but it will probably not do what you are expecting that it is. So it can be extended to this way, I would say. Hi, great talk. Thanks. Just to answer your question about MAPNIC during the talk, as far as I know, MAPNIC has a fallback mechanism. So if it isn't able to render a place name with the font, then it has then you can provide it with Unifont, for example, and it will use another font set to render the place name. Do you know if this is also the case inside one label because I have Japanese characters and European characters inside one label? That's the problem here. Okay, I'm not quite sure about that. But I think so it is because we are using for our styles, we are using both names as well, if possible, so the local name and the English name. And this is the same label and it should work. I mean, the only problem I discovered was that the Unifont seems to be a little bit smaller. So if you apply a text size of 10, for example, then it works fine for your default font. But the Unifont would be really like almost unreadable. Yeah, so this is something which has to be addressed because I would like to have the parentases all over the world. Do you check intname tag for Latin characters or do you use it right from the database? Probably I'm using it verbatim. It might be needed to add a isLatin function. The code actually contains a isLatin function. So this would be probably just a two line spatcher. So yeah, you know, the first rule of OpenStreetMap is you don't trust OpenStreetMap data. And for example, in Northern Africa, you will get a lot of Arabic names because for some reason, they think that Arabic is pretty international. Any other questions? Okay, one short question for me. All your code changes are online on OpenStreetMap DE or they are in use on OpenStreetMap DE or? Maybe in OpenStreetMap DE there is an older version of the code. The current version will get online on OpenStreetMap DE in a couple of weeks, I would expect. Okay, no more questions. Then thanks again, Sven.
 Okay. Hello and welcome to the third and last talk of this session block. We now have Sven  Geckos who's working on improvements for label placement, especially for Westerners.  Hello. I'm Sven Geckos and I'm working actually at the Fraunhofer Research Institute, IOSB  in Karlsruhe, which is one of about 60 all around Germany and they are publicly funded.  And I'm a Swiss admin and GIS server, Linux admin, all things Linux guy there. And I'm  doing the German metnik style as a hobby. And fortunately, I was able to do some work  for this project as part of my day job. And so part of this, what I'm presenting here  is, I have been able to do as part of my day job. So what I'm talking about, the motivation  for doing this is, if you look at the OpenStreetMap or IGMAP and go to countries where Latin  script is not the norm, you will usually understand, you won't understand anything.  So the reason for this rule is that the project usually uses local languages for acquiring  names and for objects, geographical objects in the map. And so we can't just render names  like OpenStreetMap or IGMAP standard style does it, if we want to understand this from  a Westerners perspective. So, but fortunately, in contrast to conventional geodata, OpenStreetMap  does contain at least some localized data. So we should use this when rendering maps to  get a more understandable one. So how do localize objects in OpenStreetMap  data look like? I have two examples for country borders, country objects. On the left hand  side, you can see the object for Germany. On the right hand side, you can see the object  for Israel. So what we want to use is actually something Roman, so not the name tag. And  we have this colon separated name tags in this OpenStreetMap key value system where  you can use arbitrary keys. And I think what we want to use here, if our target language  is German, we want to use the name colon DE tag. Probably we want to have the original  name in parentases. So that is our target. So let's have a quick look at writing systems  of the world. As you can see, they are mostly dominated by Latin with two exceptions, the  Russian three exceptions, probably the Arabian world, the Russian foundation, and all around  Asia. So the objective is use all localization for all these countries. There's one in India  as an exception because India has English as an official language. So in India, we will  always have Latin script alternatives. So here's like our OpenStreetMap Carto style  looks like the rural area of Moscow for an example. And here's what it looks like if  we add localization. So here's our main objective, making the map readable for Westerners by  using Latin script. Use the localized data from OpenStreetMap itself. Whenever this is  possible, this is not possible on any object and will never be because many objects just  don't have and Latin name. So use other localization methods in OpenStreetMap does not contain the  data we want. So use transcription or transliteration. So how will we do this? My approach has been  to use PostgreSQL stored procedures, which is an advantage, but it can also be a disadvantage.  It is an advantage because it is rendering independent. It doesn't matter if you're using  MapNIC, MapServer, GeoServer, whatever for rendering, because all you have to change is  your SQL. The disadvantage is, well, if your data source is not PostgreSQL, for example,  you're using raw OpenStreetMap files or shape files or something, you can't use this. So  here's what the implementation looked like. I have three PostgreSQL functions which can  be used. They are placed in their own extension. And this is actually usable for any language,  any Western language using Latin script or any language using script, Latin script doesn't  need to be a Western language. It is done for German language, but with other Roman languages  in mind. So a convenient way to do this is to add database views which look like the  original table. So in the best case, you don't even need to change anything in your style.  Okay. One thing I need to say, why I have a separate function for a get place name and  get street name. The reason is if you add a name in parent cases, you have the local  name and localized name and this will get very long. So what I also do is abbreviation  of street like ST in English or STR for Straße in Germany. And this is actually a place where  I would like to get more native speakers of other language to get these abbreviation code  for as many languages as possible. So here is what my state machine like to do the decision  which name to use. I have a look at the target language in my example, it's name.colonde.  And if we have this, just use it. Now if we don't have it, have a look at name. If name  is written in Latin script, well, we are in a country which uses Latin script. So just  use this. If name is not Latin script, have a look if int name which is an international  name does exist. I am expecting this to be Latin, so just use it. And if this is not  the case, have a look if there is an English name, if there is not, well, there's a last  resort we have to use transcription. As a short in slide, difference between transcription  and transliteration. Transliteration means something which is revertible. Transliterate  something, transliterate it back, you will get your original script. This is not the  case for transcription. Transcription is more done with a vessel reader in mind reading  this, trying to get the pronunciation as close as possible to the original pronunciation.  So transcription is what we need because we don't need the reversible factor. And another  thing you need to know if you think about stuff like this is there are actually three,  probably four, if you consider hybrid forms, classes of writing systems. First, there are  alphabets, well-known Latin, Greek, Arabic transcription is usually easy using them.  This is also true for syllabaries. The Japanese kana is one example. So it's relatively easy  transcription. And then you have a lot of log traffic writing systems like Chinese. Chinese  is actually the only log traffic writing system which is still in use. There have been historical  ones in the history of humankind. But Chinese is the only one left. And the problem with  log traffic writing system is that transcription is only possible by language. And if you do  a transcription in Chinese and do a transcription in Japanese for the same characters, you will  get something completely different. So this has to be resolved in some way. And last but  not least, there are hybrid forms like Thai language or Korean language. Those are all  mostly easy to transcript. So a few known problems of transcription I have been encountered.  There may be more. I would be glad to hear from more and best would be I would hear how  to resolve them. So first of all, the logic logic graphic alphabet transcription of Chinese  characters has to be based on the place of the geographical objects. Okay, we are doing  maps here. We are having a geographic way our database. So this is not a problem. We  can just determine what country we are in and decide based on the country we are in,  which transcription to use. Current implementation does this with Japanese. And this will probably  need to get extended to some other scripts. Another thing is Thailand uses a royal Thai  general system of transcription which you get on local road signs and stuff. Unfortunately,  the ICU library, which is publicly available as free software uses ICO 11940, which is  something completely different and not widely used. I'm not aware of a free and open source  library implementing RGTS. If there would be it would be it could be easily added.  Another thing is Arabic and Hebrew, for example, do not add all vocals to the written words.  Instead, the readers add them by while reading. So they are they are actually not in the word.  So an automatism can't be added without word lists or something. So transliteration will  therefore be often incomplete. As an example, I have Tehran using ICO ICU. It gives you  trend, which is not what you are likely to expect. Fortunately, in place names, this  isn't that problematic because they are they usually have open street map text. So you don't  need to go for transliteration. A few words to the current implementation. I am using  the ICO international components for Unicode library as a default if there are better ones  better ones can be used. A postgresquales.procedure has been implemented, which is actually just  the thin layer for calling the any to Latin transliteration form function of this library  and is then available as a stored procedure. And we have a place dependent use of transcription  libraries for currently doing this Chinese characters, which Japanese called kanji. And  this is performed by the Kakasi library, which is also free software. And this is only done  if the object is located in Japan and is not used otherwise. This scheme is extendable  to other writing system and countries. And we can also add something like usage of different  transcription libraries by writing system and not by place, which can also be easily  added. Two other problems I encountered by using internationalization. There's no single  font available, which contains all Unicode characters. So you have to use different ones  and compromise in the current code is to render local names only if they use Latin Greek or  Cyrillic. This should be extended. Possible resolution would be, I learned yesterday that  map server seven does actually implement this. So I have to have a look. The renderer can  use different font spend based on the character set and map server seven does this. I'm not  exactly sure about what map Nick currently does. It might also be possible to produce  a best of font from various sources. I didn't try this yet. One last slide. Political problems  in localization. Political problems are usually unable to solve them by technology. Many regions  of the world have been part of other countries in the past. And for example, the German settlement  areas in Eastern Europe, if you have even the smallest villages in Poland, Alsace or Lorraine  have still German names. Nobody knows if they are still in widespread use or not. In the  worst case scenario, the usage will offend people. So the only thing we can do is trust  the mappers. The mappers will only acquire with names which are still used. They use  old name otherwise. Hopefully they do. What we do as a compromise is always render the  current local name in parentases. So prospect and enhancements, technical solution of the  problem to render glyphs of different writing systems in a single label. As I already said,  this will probably already work in MAP Server 7. Addition of more and better suited libraries.  If somebody knows in the audience of a library which might be suitable, I will be happy to  know and integrate it. More fine-grained distinction of the transcription algorithms  by place. It might be needed to do this more fine-grained. And add street abbreviation  code for all common languages. Actually add street abbreviation code for all languages  where streets are actually abbreviated. And suggestions from the audience. I will do a  two-minute live demo and then I will take questions. Okay. So I will call PostgresQL  line. Okay. First I need to create my extension. And then I will show you how to transliterate  it. Probably somebody knows these characters. Those are the characters for Tokyo. And you  get Dong Qing. Well, this is not very good. So we need to use something else. Okay. I  get Tokyo better, I would say much better than Dong Qing. Still not perfect, but well,  MAP has already acquired Tokyo in the proper script for us. But if we would use transcription,  we should go for the second one. And last, there is the GO-Aware transliteration  function. So I will, I just added a point here. And 137.35 is somewhere in Japan. If  I add somewhere in Germany, like 949, I will still get Dong Qing. So this is aware of the  location and how, whenever the object is located in Japan, it will use the Japanese transliteration.  So and if you will, it's easy to also drop the, again, the extension.  Okay. One more demo. I take the Karlsgasse in Brak, which is called Kalloba in Czech.  And Brak has German names all over the place because of its history. And, but in the real  world, you see all, you all, you can only see the Czech street signs. So we add the,  we should add the German in parentases. So this is what it looks like. And this is actually  what we are using for the map. And as you can see, if you use the get street name function,  the Gase will be abbreviated to G dot. And currently I have this abbreviations for Russian,  German, English, and Ukrainian. I would be glad to get this for other languages. Okay.  So if I don't use street name, but place name, the stuff will not get abbreviated. Yeah.  So, okay. So far, questions. Thank you very much, Sven.  Yeah, how is it with this to be turned around? Because obviously, like a lot of tourists,  like from Japan or Asia come to like Europe and they want to see like the Japanese name  for German streets or for German places. This can be likely done, but you need to change  the code. But because the code is mostly done with Latin script in mind, there are a few  corner cases where it won't work. And first of all, you have to implement something else  than you have to extend the ICU repo functions, which currently is hard coded any to let in.  This should be any to whatever Thai Japanese. And I think it's not a problem for Japanese  because they use Latin script and all that in script. It's probably more for Chinese  people. And I'm actually not aware if there even is a transliteration function in the  art into the other direction. So it might be possible to do this. You can configure  the code to do it, but it will probably not do what you are expecting that it is. So it  can be extended to this way, I would say. Hi, great talk. Thanks. Just to answer your  question about MAPNIC during the talk, as far as I know, MAPNIC has a fallback mechanism.  So if it isn't able to render a place name with the font, then it has then you can provide  it with Unifont, for example, and it will use another font set to render the place name.  Do you know if this is also the case inside one label because I have Japanese characters  and European characters inside one label? That's the problem here.  Okay, I'm not quite sure about that. But I think so it is because we are using for our  styles, we are using both names as well, if possible, so the local name and the English  name. And this is the same label and it should work. I mean, the only problem I discovered  was that the Unifont seems to be a little bit smaller. So if you apply a text size of  10, for example, then it works fine for your default font. But the Unifont would be really  like almost unreadable. Yeah, so this is something which has to be addressed because I would  like to have the parentases all over the world.  Do you check intname tag for Latin characters or do you use it right from the database?  Probably I'm using it verbatim. It might be needed to add a isLatin function. The code  actually contains a isLatin function. So this would be probably just a two line spatcher.  So yeah, you know, the first rule of OpenStreetMap is you don't trust OpenStreetMap data. And  for example, in Northern Africa, you will get a lot of Arabic names because for some  reason, they think that Arabic is pretty international.  Any other questions? Okay, one short question for me. All your code changes are online on  OpenStreetMap DE or they are in use on OpenStreetMap DE or?  Maybe in OpenStreetMap DE there is an older version of the code. The current version will  get online on OpenStreetMap DE in a couple of weeks, I would expect.  Okay, no more questions. Then thanks again, Sven.
foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_0_8459.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_8460_20939.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_20940_35411.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_35412_35735.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_35736_36299.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_36300_36467.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_36468_36527.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_36528_36935.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_36936_37391.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_37392_37559.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_37560_37607.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_37608_38327.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_38328_38411.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_38412_38459.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_38460_38531.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_38532_38579.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_38580_39419.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_39420_39479.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_39480_39659.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_39660_39707.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_39708_40235.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_40236_40307.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_40308_40475.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_40476_40763.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_40764_41699.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_41700_41747.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_41748_41927.png foss4g-2016-1049-towards_a_more_readable_openstreetmap_based_world_map_for_westerners-hd_41928_42118.png