I believe that mediation in this particular problem is impossible. Ranking based on population numbers will never be recognized by both parties, as religious inspired politics will never respect a status quo nor a history. Once the Jerusalem problem is solved the dispute will continue on other cities / religions / places in the area.
I think that OSM should develop an official policy towards disputed - areas, - regions, - cities - languages and some effort need to be made to suit the rendering based upon the viewers preferences. As long as there are disputes on a geographic properties of a specific area, OSM should allow for a number of versions doing justice to each recognized political or religious view. So in case of Jerusalem we should be able to present a Israel map with Hebrew names as primary to the Israelis. And at the same time present a different map (possibly with other borders) to the Palestinians. More general, we should be able to present a map in each local language, taking care on all these regional problems (take for example Lille and Rijssel, the same town in Flemish and in French) Our planet is full of disputes, differences like that and we should abandon the idea of one map fits all. As a start we may stop render names when the last change is more recent then say 4 weeks. This will effectively stop rendering based disputes. Later we may switch to localized maps but I believe that is a big effort as the text layer should be presented separately from the map. Even later we should be able to define regions where more than one version of the map exists, any editing user making a selection on what version he will be editing on. So Mohammed will edit the Palestina version of Jerusalem, and Moshe may edit a Jewesh version of Jerusalem, including different names, borders (later) and (even later) landuse. It would make OSM an even better map, able to represent the views of all people of this world. And it would help creating routeplanners for israel for example where some areas are nogo for israeli, but not for tourists or palestinines (and the other way around of course). And we Europeans do not have to learn Hebrew before being able to use the Israel map. Gert Gremmen ----------------------------------------------------- Openstreetmap.nl (alias: cetest) Before printing, think about the environment. -----Oorspronkelijk bericht----- Van: Andy Robinson [mailto:ajrli...@gmail.com] Verzonden: Friday, October 07, 2011 5:40 PM Aan: talk@openstreetmap.org CC: d...@osmfoundation.org Onderwerp: [OSM-talk] Jerusalem name tag - Mediation In addition to the talk list and the DWG this email is being sent to those who have edited the name tag on node 29090735. Those reading the mailing list and forum will know that there is an on-going dispute between Israeli and Palestinian folks as well as unhappiness with the OSMF DWG. All relates to the name=tag for Jerusalem, the default name tag shown by the project mapnik rendering. The facts are clear that a tit for tat dispute of the name tag went on during 2009 and 2010. Also fact is that some discussions were held between mappers in the region to try and reach an agreed position. It was unfortunate that the DWG removed the name tag from the node around the same time, before the views of those discussing the point could communicate back. Regardless of this it is clear that there is no full 100% agreement between the local groups or even within each side. There have been discussions about two nodes, each holding information separately in Hebrew and Arabic, and there have also been suggestions of returning to a single node with Arabic, Hebrew (and English) names on it considering the international interest in the city. Both might work but nether offers a sustainable solution long term, mainly because as new mappers come and go the view of different individuals will change, and so it will be also for those viewing the map. I was asked to help mediate in the dispute. Something that I have found almost impossible as there is no basis on which to force mediation in the first place. I have however looked at the matter and offer the following for consideration and I would hope implementation. It must be recognised that no solution will be perfect. 1. All cities of the world have a varying demographic. Few have only one language or faith. Jerusalem has a population of over 700,000 and by all accounts the religious split of its people (ignoring minority groups) is in the order of 2/3 Jewish, 1/3 Arabic. Therefore a significant number of people will be served by having the name of Jerusalem visible in Hebrew and also in Arabic. English might be useful addition for the international interest in the city but that can be argued for all major cities around the world and therefore I don't see reason to include it in this solution. As with all other languages the language specific name tags are always available anyway. 2. There appear to be three choices for the number of nodes. One node to reflect the whole of the city, two nodes to reflect east and west, or three nodes to reflect both of the above. I'm going to suggest the latter, three nodes as follows: Node 1: With the name in Hebrew and Arabic (in that order to reflect the demographic). Since I believe all of Jerusalem considers it to be the capital, it can have the "capital" tag as well as the place=city tag. This is what most viewing a zoomed out view would see on the default mapnik rendered tiles. No is_in tag would be added to avoid the political connotations, though a note (in English) would be added to reflect why this tag is missing. This node would carry all the international language specific name tags for Jerusalem as well as any other data that is factually correct and applicable for the city as a whole. Nodes 2 and 3: These would be created and maintained by each respective group. They would be placed to the east and west of Node 1. These nodes would not use either the capital nor the city tag but would instead reflect the east and west sector (suburb). The is_in tag would be controlled and decided upon by the respective group. Other tags would be as decided upon by the relevant group but must maintain the on-the-ground approach of factual data. DWG will continue to monitor but only to support the process of maintaining the agreed solution. Finally, I was encouraged that at the start of the discussion process the local mappers met and debated the issues. I would wish and strongly urge this to continue. It will only be through further communication and dialogue that differences will be understood. This needs to keep to one side the politics and beliefs and focus on what the wider community can benefit from in improving OSM for all. I'd argue that we don't create OSM data for ourselves but instead for the benefit of others and those that come after us. I do not consider that the DWG acted irrationally. A problem was posed and in interim solution was implemented. It might have seemed a little harsh but it is clear to me that it was never intended to be a permanent position. I was asked to mediate and I've given my opinion, so perhaps I might better describe what I have done as arbitration. If this oversteps the mark I apologise, but in the circumstances it appears the only thing I can do to move the matter to a speedy conclusion. If there is widespread descent then I will happily reconsider, otherwise I move to implement in 7 days. Cheers Andy (blackadder) _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
