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