Hi,

This proposal is well considered and it could work in my view. Even
though it's a compromise (vs. solution) in the sense that it solves a
rendering 'problem', it doesn't compromise the tagging rules/principles
to that end. Of course it's the local mapping community that will have
to make the decision to agree to this or not. I only entered the
discussion when I thought I could help move the discussion forward.

By the way I don't believe the DWG acted irrationally. However their
decision wasn't the best and my goal wasn't to point a finger at them
but to point out a mistake so it could be corrected. On a personal
level I have huge appreciation for them.

And I also like the 7 day time limit.

Lambert Carsten
 
On Fri, 7 Oct 2011 16:40:18 +0100
"Andy Robinson" <ajrli...@gmail.com> wrote:

> 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

Reply via email to