IMO nie.
ja na razie apeluję o OSMMonitor dla granic - dużo z nich po bocie jest dziurawa jak sito 
Dzielę tutaj zdanie Zbigniewa. Rogal, wielke dzieki za dobra robote!
Podepnij ten link jeszcze tak, zeby ktos kto tego szuka poprzez angielskojezyczna stronke: http://wiki.openstreetmap.org/wiki/Admin_level
tez do tej stronki trafil. Przydala by sie tez podwersja po angielsku. Powód: Jesli ktos kiedys bedzie chcial robic nawigacje to jak najbardziej uwzgledni specyfike danego kraju i obowiazujaca w niej strukture administracyjna tylko bedzie to musial najpierw zrozumiec. Tak wiec jest to w naszym interesie.
ok, na razie uaktualniłem na anglojęzycznej stronie tabelkę dla Polski.
Wizualizacja stanu granic administracyjnych:
Większa wersja: http://i.imgur.com/QCI55.png
EDIT: dane są sprzed przejścia bota.
Zastanawiam się tylko co z tymi wioskami, które granic nie mają, a posiadają ulice? Pozostaje tylko dodawanie addr:city= do wszystkich rzeczy należących doń, żeby np. nawigacje dobrze wyszukiwały?
Koledzy z Lodzi siedza dokladnie nad tym tematem - móglbys Zbigu wytlumaczyc ten zgryz z wioskami bez granic Rafalowi Jachowiczowi?
Z tego co sie orientuje to “profesjonalni” daja tu granice na pale dopisujac w comment “estimated” zeby sie nikt nie czepial ze dokladnie nie jest. Nie wiem, moze moglibysmy cos takiego stosowac?..
& Rogal - dzieki serdeczne raz jeszcze!
Co do tego spftu to myslalem, zeby pokazywal jak na tym szkicu
http://wiki.openstreetmap.org/wiki/File:MarekProblematicBoundaryAdministrativeAreas.jpg
obszary typu
1.= nie naleza do zadnego boundary administrative
2.= naleza do dwóch obszarów boundary administrative
soft z jakim ja miałem do czynienia (OSMAnd, mkgmap) jeśli nie znajdzie granic to, o ile pamiętam, szuka najbliższego place=city/town/village i do niego przypisuje.
Ja mam pytanie o edycję granic: czy jak pobiorę sobie wszystko overpassem, otworzę w JOSM i będę edytował (np. usuwał multipolygony) to wystarczy tylko potem wysłać zmiany do OSM, czy jakaś ekstra magia jest potrzebna?
Może jakoś się podzielimy pracą nad tym? Przede wszystkim trzeba posprawdzać ciągłość granic, pousuwać z nich tagi (za wyjątkiem boundary=administrative) i przenieść je do relacji. Dużo granic nie ma relacji, tylko wszystko jest wrzucone jak leci.
Ja biorę na klatę granice wszystkich województw (połowa już za mną) + np. woj. mazowieckie.
Gdy rozpracuję query do overpassa, który wypluwa wszystkie granice to podrzucę.
Ale ja mam jeszcze wątpliwości dotyczące wprowadzania sołectw - w życiu codziennym nie ma wielkiego znaczenia w jakim sołectwie jest dana wioska. Mało tego, bywają wioski podzielone między dwa sołectwa (mieszkam w takiej) i co wtedy?
Skoro nie ma granic wioskowych to może zakończyć sprawę na gminie, a obszar wioski oznaczać przez landuse=residential z nazwą wioski?
A znasz taki przykład? Myślę, że to jest najlepszy sposób by sprawdzić czy schemat zadziała w praktyce na paru gminach/miastach
w życiu codziennym nie - zresztą sołectwo zazwyczaj nazywa się tak samo jak wioska (i obejmuje jedną wioskę), czyli problemu nie ma a mamy poprawną granicę:)
w przypadku wioski podzielonej na 2 sołectwa można ją oznaczyć z levelem miasta (8) i dodatkowo można każde sołectwo osobno z level 10 - takich przypadków jest bardzo mało i otagowanie takiej wsi jako miasta w ramach wyjątku można przyjąć. Nawet taka granica jest lepsza niż żadna.
IMHO nie ma sensu - wyświetlanie nazwy na mapie rozwiązuje place=village, a nikt przy indeksowaniu ulic nie weźmie i tak pod uwagę landuse=residential
Poprawiłem co się dało, ale dalej nie rozumiem dlaczego Nominatim wyświetla w następującej kolejności.
nazwa ulicy,
nazwa osiedla jeżeli jest w obszarze “type=place” ale pomija “type=boundary” dla Wspólnoty mieszkaniowej,
nazwa najbliższej “type=place” “place=sub” a nie “type=boundary” dla dzielnicy,
województwo,
kraj.
Głos obserwatora z UMP.
Obserwuję waszą dyskusje i mam wrażenie że niektórym osobom umyka cel
ćwiczenia “rysowanie granic”.
Z nasz doświadczeń wynika, że praktycznie granice nie mają żadnego znaczenia
o ile działa porządnie WYSZUKIWANIE ADRESÓW.
Przez naszą listę przetoczył się wielokrotnie postulat wykasowania granic
w produktów pochodnych (garmin, www ) bo zaciemniają mapę.
Do tego nie doszło ale taka jest prawda.
Granice gmin/sołectw/wsi potrzebne są do wyszukiwanie po adresie.
Wiem że nie da się zamapować wyszukiwania adresów na granice
bez stworzenia paru wyjątków ale to ćwiczenie powinno być
podporządkowane temu celowi.
Dlatego wydaje mi się że schemat mniej więcej powinien działać tak:
Na podstawie http://wiki.openstreetmap.org/wiki/WikiProject_Poland/Podzia%C5%82_administracyjny#Tworzenie_granic_administracyjnych
Podział administracyjny:
2 – granica państwa
4 – granica województwa
6 - granica powiatu
7 – granica gminy
8 – granica miasta
9 - granica dzielnicy lub lokalnych odpowiedników dzielnic
10 – granica sołectwa
**12** - granica jednostki pomocniczej niższego rzędu (np. osiedla w ramach dzielnicy)
16 – granice działek ewidencyjnych
Podział adresowy
używany jako dodatkowa relacja gdy poprawny nie da się
wydedukować z granic powyżej.
8 – miasta
9 - dzielnica
10 –sołectwa
11- wieś lub inny obszar adresowalny n.p. dzielnica miasta gdzie
dublują się nazwy ulic.
Zasada wyszukiwania adresu powinna być zdefiniowana tak że adres szukamy
w relacjach w kolejności 11->10->9->8.
Zgadzam się w 100%. Pomysł z admin_level=11 jako obszaru adresowalnego jest ciekawy i warty rozważenia (ja jestem za), chociaż sekwencję wyszukiwania bym zmienił:
8 → 11 → 9
w pierwszej kolejności szukamy granicy miasta, potem granicy obszaru adresowalnego, dopiero potem sołectwa (pamiętajmy, że sołectwa mogą być również w ramach miasta - wtedy szukając najpierw sołectwa będziemy mieli błędne przypisanie). Tak samo szukając najpierw dzielnicy a nie miasta będziemy mieli błędne przypisanie.
Jedyną niespójność widzę w przypadku wsi podzielonych na 2 sołectwa - ale taki scenariusz już był opracowany we wcześniejszych wątkach.
Plusem przemawiającym za obszarem adresowalnym jest fakt, iż rozwiązuje to problem przypisania ulicy do miejscowości na podstawie najbliższego punktu typu place=village/town/city - dużo algorytmów szuka wspólnej granicy o jak najmniejszym admin_level. Wtedy można level 11 dać tymczasowo - rysowany na oko - w wielu miejscach gdzie obecnie nie ma poprawnych granic (i zapewne długo nie będzie).
To mi się nadal nie podoba. To jest przede wszystkim granica powiatu. Wyobraź sobie mapę podziału administracyjnego kraju, pokazującą tylko województwa i powiaty (admin_level=2,4,6). Na górnym śląsku zabrakłoby paru granic (miedzy różnymi miastami na prawach powiatu). Jeśli miasta te oznaczymy admin_level=6 (taki jest „poziom” tej granicy!), to będzie ok. Co więcej, dalej będzie ok na mapie administracyjnej województwa, która by pokazywała podział na powiaty i gminy.
Cały czas mówimy o granicach administracyjnych! Adresowanie to rzecz wtórna.
Tam, gdzie nie ma Granicy, jak najbardziej jest sens. Inaczej znikniemy województwa i powiaty całkiem z mapy, a ktoś może właśnie tego (a nie jakiegoś adresu w) szukać.
Gdy granice są… tu mam mieszane uczucia… ja bym zostawił.
place=village samo może być obszarem (nie musi być punktem) i to mi się wydaje najsensowniejszym rozwiązaniem w tym przypadku.
Jak ktoś będzie taką mapę robił to niewielkim nakładem pracy może sobie dane poprawić
albo po dodatkowym tagu w locie sobie je dodać.
A aktualnie bałagan w granicach powoduje, że osm nie nadaję się praktycznie w Polsce
do podstawowego zastosowania: Wyszukiwania po adresie.
Brak wyszukiwania zaś powoduje że nie nadaje się do nawigacji.
Brak sensownej zaś nawigacji powoduje brak restrykcji (zakazy skrętu itp)
oraz liczne błędy w routingu które by szybko wyszły gdyby ludzie używali
je w inny sposób niż oglądając kafeki na www.
Dla mnie argument ze ktoś może chcieć zrobić sobie mapę powiatów jest
absolutnie nieistotny jeśli nie ma wyszukiwania po adresie.
Jesteś pewien, że to nie dlatego, że granic brakuje, tylko dlatego, że miasta na prawach powiatu nie są mapowane jako powiaty? Masz jakikolwiek dowód na potwierdzenie tej tezy (np. przykład z co najmniej dwóch różnych implementacji takiego wyszukiwania)?
Żadna nawigacja, czy system geo-kodowania nie korzysta przecież wprost z Planet.osm, tylko konwertuje to wszystko do swojego wewnętrznego formatu. Jeśli w OSM będą spójnie opisane fakty, to żaden problem wygenerować z tego odpowiedni „indeks” do odpowiedniego zastosowania.
Tu trudno się nie zgodzić.
Ale też nawigacja nie jest jedynym zastosowaniem dla OSM, inaczej moglibyśmy utrzymywać jedynie graf topologii ulic, nie mający wiele wspólnego z mapą 
Ale chyba jednym z podstawowych założeń OSM jest „mapujemy stan faktyczny”. Czyli jeśli mapujemy granice administracyjne – to takie jakie one są, a nie takie, jak jakaś konkretna implementacja nawigacji sobie życzy. To by była taka sama bzdura jak „mapowanie pod renderer”.
Proszę bardzo. Aplikacja OsmAnd. http://forum.openstreetmap.org/viewtopic.php?id=13627
Pokazywała w Warszawie ulice prawie wszędzie tylko nie w Warszawie.
Teraz są dwie granice na poziomie 6 i 8.
Dla mnie to zaklęcie “nie mapujemy pod render” to wyraz dążenia do doskonałości która nigdy nie nastąpi.
Projekt OSM jest projektem światowym. Pewne ustalenia przyjęte w nim są uśrednieniem całego świata.
NIGDY nie powstaną światowe narzędzia które będę uwzględniały w pełni polską specyfikę.
Dlatego albo można do tego światowego uśrednienia się dostosować i uzyskać funkcjonalną mapę
albo wpisywać tagi z których wszystkie narzędzia będą w błędny sposób korzystać przez następne
lata.
Michał
dlatego najlepszym kompromisem było szeroko już dyskutowane tagowanie takich miast 2 relacjami. I wilk syty i owca cała.