OK, Thank you.<div><br><div>Well this looks like the type of stuff we are dealing with recently.</div><div><br></div><div>We mentioned it to data with not any response at all, I guess they are very busy with other things.</div>
<div><br></div><div>there is a small group of serbs who are working on renaming everything back to pre 1989.</div><div><br></div><div>I guess we will have to deal with this on a daily basis. It is not the first time we had this problem. </div>
<div><br></div><div>mike<br><br><div class="gmail_quote">2012/4/1 Paul Norman <span dir="ltr"><<a href="mailto:penorman@mac.com">penorman@mac.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> From: Lester Caine [mailto:<a href="mailto:lester@lsces.co.uk">lester@lsces.co.uk</a>]<br>
> Subject: Re: [OSM-talk] Komuna e Malishevės, Serbia ?<br>
<div class="im">><br>
> Mike Dupont wrote:<br>
> > 2012/4/1 Lester Caine <<a href="mailto:lester@lsces.co.uk">lester@lsces.co.uk</a> <mailto:<a href="mailto:lester@lsces.co.uk">lester@lsces.co.uk</a>>><br>
> ><br>
> > Altin Ukshini wrote:<br>
> ><br>
> > Does anyone care about these reports ?<br>
> > I said it before and I'm saying it again, we can't<br>
> monitor/administer<br>
> > the map<br>
> > everyday and you know this, we don't even have enough people<br>
> > contributing in OSM<br>
> > here in Kosovo and Serbians are using this opportunity to<br>
> change<br>
> > whatever they<br>
> > want in the map.<br>
> ><br>
> > I don't think that you might want to loose contributors from<br>
> Kosovo !?<br>
> > You have to report these violations... how much will this last<br>
> until someone<br>
> > makes a decision ?<br>
> > We have already reported so many violations till now.<br>
<br>
</div>If you have reports of vandalism that the local community can't deal with,<br>
send them to <a href="mailto:data@osmfoundation.org">data@osmfoundation.org</a>. Include lists of objects and<br>
changesets. Without those you can't tell who changed what.<br>
<div><div class="h5"><br>
> > 'Location' is somewhat hit or miss everywhere. My own diary<br>
> postings give<br>
> > some strange textual descriptions of where they were supposed to<br>
> be located.<br>
> > The problem here is simply that there is no clear mechanism for<br>
> identifying<br>
> > 'where' a location is, so until all of the relevant boundaries are<br>
> mapped<br>
> > and tested in the same way as the intensive effort on getting the<br>
> coastline<br>
> > complete it is going to be difficult to fix some of these<br>
> irritations.<br>
> ><br>
> > I've given up asking for a proper check on hierarchy place and<br>
> is_in which<br>
> > would at least get towns in the right country ... rather than<br>
> relying on the<br>
> > mapped boundaries ...<br>
> ><br>
> ><br>
> > this has changed, it used to be kosovo.<br>
> > it needs to be fixed, please.<br>
><br>
> My point is ... does anybody actually know where it is broken?<br>
> It is not the 'is_in' tag ... that isn't used to determine location ...<br>
> last time I tried looking at this problem in the UK nobody seemed to<br>
> know how the location was ACTUALLY generated :( It looks to the<br>
> 'administrative boundaries'<br>
> areas and so presumably someone has been playing with them? It's a pain<br>
> trying to find what has been 'modified' ...<br>
><br>
> ( No bloody politics here RB !!! )<br>
<br>
</div></div>The best way I've found to debug the location information is to look up the<br>
location on <a href="http://nominatim.openstreetmap.org" target="_blank">http://nominatim.openstreetmap.org</a><br>
<br>
For the example diary entry linked, this gives you<br>
<a href="http://nominatim.openstreetmap.org/details.php?place_id=4568477" target="_blank">http://nominatim.openstreetmap.org/details.php?place_id=4568477</a><br>
<br>
This tells you that the place is a place=hamlet node in the<br>
boundary=administrative relation "Komuna e Malishevės"<br>
(<a href="http://nominatim.openstreetmap.org/details.php?place_id=128946600" target="_blank">http://nominatim.openstreetmap.org/details.php?place_id=128946600</a>)<br>
<br>
Now it gets complicated. The node is within three admin_level=2 or<br>
admin_level=3 boundaries.<br>
These are:<br>
<a href="http://www.openstreetmap.org/browse/relation/2088990" target="_blank">http://www.openstreetmap.org/browse/relation/2088990</a> with name:en="Kosovo<br>
and Metohija" admin_level=2 created March 18th<br>
<br>
<a href="http://www.openstreetmap.org/browse/relation/53295" target="_blank">http://www.openstreetmap.org/browse/relation/53295</a> with name:en="Kosovo and<br>
Metohija" admin_level=2 created 2008. The admin_level started off as 3, was<br>
changed to 2 in July 2010 and back to admin_level=3 Feb 2012. The name was<br>
also changed from Kosovo to Kosovo and Metohija at the same time (in all<br>
languages).<br>
<br>
<a href="http://www.openstreetmap.org/browse/relation/1741311" target="_blank">http://www.openstreetmap.org/browse/relation/1741311</a> with name:en="Serbia"<br>
admin_level=2 created in 2011.<br>
<br>
Because regenerating all of the address data inside a country would be too<br>
much of a performance drain, they are cached for large boundary objects.<br>
<br>
My guess is what happened is at some point in the past the 53295 relation<br>
was broken and Nominatim cached it.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk" target="_blank">http://lists.openstreetmap.org/listinfo/talk</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>James Michael DuPont<br>Member of Free Libre Open Source Software Kosova <a href="http://flossk.org" target="_blank">http://flossk.org</a><br>
</div></div>