Trochę zmian w granicach administracyjnych które dziś weszły w życie:
http://ksng.gugik.gov.pl/mapa_adm.php
I pytanie laika: dlaczego nie importujemy wszystkich granic z GUGiK, tylko je skrzętnie i ręcznie stamtąd przerysowujemy?
Przecież i tak nie ma lepszego źródła, a to dane
ważne, często ulegają przypadkowemu psuciu i co roku coś się w nich zmienia. …
Bo w uwolnionych danych nie ma granic poniżej poziomu gminy?
To nie tłumaczy dlaczego granice gmin da wyrysowane niedokladnie.
Co masz na myśli v mówiąc “uwolnione dane”?
Jak to nie tłumaczy? Zanim GUGiK łaskawie uwolnił dane PRG (a zrobił to całkiem niedawno) mieliśmy już komplet granic gminnych pozyskany z innych źródeł. To tłumaczy dlaczego granice często bywają niedokładne - po prostu na tamten moment nie było lepszych danych.
z tym poniżej gminy bym się nie zgodził - bawiłem się trochę PRG i z tego co widzę to pomiędzy różnymi dziwnymi granicami ewidencyjnymi jest poukrywanych bardzo dużo granic wsi - wystarczy je przefiltrować bodajże po subkodzie nr 5 (granica obszaru wiejskiego w ramach gminy).
No niby patrzyłem w te dane PRG od GUGIKu i nie znalazłem tam granic miejscowości. Może po prostu źle trafiłem, a może to są granice np. sołectw, a nie miejscowości?
Przed chwilą spojrzałem do tych shape’ów:
jednostki_ewidencyjne - masz granice obszarów miejskich, można je poznać po tym że ID w kolumnie jpt_kod_je zawiera w kodzie wartość _4 (podkreślenie 4). Każda nazwa ma przyrostek “-miasto”, więc tutaj nie ma mowy o pomyłce. Te same informacje sa powielone w pliku obręby_ewidencyjne
obręby ewidencyjne - kody z wartością _4 opisują granice miast w gminach wiejsko-miejskich. Kody z wartością _5 opisują granice obszarów wiejskich (jak rozumiem, są to granice wsi).
Tutaj masz wizualizację:
Na niebiesko są miasta, na pomarańczowo granice wsi. Na fioletowo też są granice wsi, ale nie wiedzieć dlaczego mają kod _2 (wg. teryt/terc kod 2 oznacza gminę wiejską, ale te obszary nie są oczywiście gminami). Białe dziury to gminy miejskie. IMHO warto to zaimportować do OSM - na pewno ogromnie poprawi wyszukiwanie adresów - moglibyśmy wrzucić same granice z admin_level i urzedową nazwą w jakimś osobnym tagu a później porównywać z tagami place=* w danym obszarze, żeby wyłapywać błędy.
Można by zaimportować, pod warunkiem, że sensownie - czyli z użyciem relacji.
Boję się, że ktoś wpadnie na pomysł, by to wrzucić po prostej konwersji jak leci, czyli z ponakładanymi liniami itp.
Wracając do tematu wątku - opierając się na tym dokumencie: http://ksng.gugik.gov.pl/pliki/zmiany_w_podziale_administracyjnym_polski_2015.pdf poprawiłem Stopnicę i Chocz na place=town; dammat poprawił Władysławowo. Co do reszty to chyba trzeba poczekać, aż się nowe przebiegi granic pojawią w EMUiA/wherever, bo nie bardzo wiem jak to poprawiać.
Idąc za ciosem i odnosząc się do słów Wiktora na temat słabo wyrysowanych gmin, poniżej screenshot gminy Baruchowo zaimportowanej z konta WiktorN-import (to nie jest żadna wycieczka osobista, po prostu pierwsza z brzegu gmina, która była rozjechana). Na czerwono granica w OSM, na czarno granica w PRG.
Jak mniemam import był również z PRG, więc albo gdzieś po drodze wystąpił błąd albo po prostu w ostatnim czasie poprawiono przebiegi i stąd różnice - IMHO raz na jakiś czas można by granicę gmin odświeżać - dopasowując po terycie i kopiując stare tagi nie powinien to być problem.
O jakim Ty imporcie mówisz? Granica gminy Baruchowo została utworzona w grudniu 2012 roku: http://osm.mapki.com/history/relation.php?id=2635735
Nie chce mi się analizować poszczególnych linii, ale na Pomorzu dużo granic wyrysował Przemas75 opierając się na mapkach z BIP-u, przykład: http://osm.mapki.com/history/way.php?id=196065470
Jak już pisałem:
Poza tym, myślę że ten przykład nie jest wyznacznikiem jakości granic w całej PL. W Polsce południowej granice są o wiele bardziej dokładnie wyrysowane, głównie dzięki tytanicznej pracy Władka.
rzeczywiście, mój błąd - Wiktor importował tagi population. Oczywiście takich przykładów jak na screenshocie jest relatywnie niedużo (max. kilkadziesiąt na ponad 2500 gmin), walczę z QGIS-em żeby wygenerować jakąś warstwę z najbardziej rozjechanymi liniami do poprawy.
Trzymam kciuki, bo potrzeba takowej 
Ale skoro mamy jedno źródło prawdy, to co stoi na przeszkodzie by wyrzucić cała obecną geometrię z relacji i wrzucić tam tą z PRG. nie trzeba chyba się martwić edycjami mapowiczów.
A yo by zrobić to z mimialną liczbą obiektów i za pomocą relacji to jest problem kodu importera.
Taki import można by robic nawet raz na miesiąc (jakby nie gemerował pustych zmian), to by nam poprawiło przypadkowo zepsute granice…
Brzmi to co nieco arogancko.
na dobrą sprawę nie jestem sobie w stanie wyobrazić po co ktoś miałby zmieniać przebiegi granic gmin (pomijam naprawę tych źle zmapowanych na chwilę obecną).
Zastanawiam się nad zrobieniem walidatora, który by cylicznie sprawdzał różne granice (gminy, miasta, wsie, itp, obecność admin_centre, itp) - bo rzeczywiście przypadkiem można coś zepsuć. I teraz pytanie, czy w GIS jest jakiś algorytm, który by był w stanie porównać przebieg 2 wielokątów oraz różnicę między nimi? Na chwilę obecną mam pomysł na taki bieda mechanizm, który by porównywał powierzchnię obszaru z OSM i PRG oraz krzyczał, gdy różnica wynosi więcej niż X procent.
@rogal - jeżeli korzystasz z Pythona, to polecam pakiet shapely. Wystarczy że dla każdego obiektu zrobisz MultiPolygona, i zrobisz coś takiego:
score = (area1.union (area2) - area1.intersect (area2)).area
I masz pole obszaru który się nie pokrywa. Nie wiem czy GISowcy jakoś lepiej to liczą…
@Zibi:
Wiem ze to aroganckie i doceniam pracę wykonaną wczesniej, gdy nie było lepszych źródeł, ale może skoro mamu już dostępne dobre źródła to nie ma co być sentymentalnym?
@rogal:
u mnie na githubie znajdziesz w pliku osmdb.py funkcję, która zamienia dane z OSM na obiekty shapely. Może Ci się przyda.
Importy w OSM mają niższy priorytet niż praca pojedynczych maperów. Inaczej mówiąc, praca mapowiczów nie powinna być zastępowana importami. Nie mówię, że jestem przeciwny, ale trzeba to przedyskutować i zrobić dobrze.
Najlepiej, żeby to było poprawienie geometrii poszczególnych linii na tej samej zasadzie, jak w JOSM działa narzędzie “zastąp geometrię”, a nie wywalenie wszystkiego co jest i wgranie nowych wersji.
Przyglądałem się jakiś czas temu zestawowi danych udostępnionych przez gugik i niestety (czego można się było spodziewać po analizie innych danych, które robiłem wcześniej) tym danym również daleko od doskonałości… Byłbym nawet skłonny powiedzieć że jeśli chodzi o poprawność topologiczną to dane osm, dzięki stosowaniu relacji, są dużo lepsze niż te z gugiku - tematu dokładności nie ruszam. Jeśli np. od obszaru granicy kraju odejmiemy wszystkie granice gmin dostajemy około 1500 obiektów (znaczy że w tylu miejscach granice się nie stykają - mają dziury), podobną ilość obiektów uzyskamy wyciągając wszystkie obszary w których granice na siebie zachodzą (obszar jest w 2 gminach jednocześnie). Próby przyciągania do grida niewiele pomogły, próby konwersji do topologii (postgis_topology) też się nie powiodły bo albo tolerancja była za mała i nie dociągał (tworzył za dużo obszarów) albo tolerancja była na tyle duża, że zgłaszał non nodded intersection, koniec końców, żeby te dane były użyteczne musiałem nad nimi przeprowadzić kilkugodzinne modły po czym i tak część musiałem ręcznie poprawiać (dociągać o metr-dwa). Oczywiście granice powiatów != sumie połączonych gmin więc o imporcie warstwami można zapomnieć - jedyna rozsądna metoda to zaimportowanie gmin, naprawa ich po czym utworzenie z nich granic powiatów i województw przez łączenie… Już nie wspominam o innych ‘bratkach’ które tam wynalazłem znaczy podstawowe niespójności przestrzenno-opisowe (wszystkie dane gugik-u mają tą bolączkę) znaczy że z danych przestrzennych wynika, że działka (na przykład) jest w gminie A, a w danych opisowych ma identyfikatory z gminy B…
Słowem może te dane to jest jedyna słuszna prawda ale techniczne ich wykonanie pozostawia wiele do życzenia. Wygląda jakby ktoś kto to rysował nie wiedział że istnieją funkcje przyciągania do węzłów i nie znał elementarnych zasad tworzenia danych gis…
Moim zdaniem idealnie byłoby gdyby ktoś do tego wynalazł podobny mechanizm co do śladów ze STRAVA - jeden klik i istniejący obiekt ‘dociąga’ do referencyjnego… w ten sposób otrzymalibyśmy bazę poprawną topologicznie (jak w osm) i dość dokładną (jak w gugik).
Trzeba mieć też na uwadze, że elementy wchodzące w skład granicy Polski wchodzą również w skład granic ościennych państw i granic ich mniejszych jednostek administracyjnych… słowem zaoranie tego co jest i pełen import nie jest takie proste…
Grass robi poprawną topologię przy ustawieniu threshold na 1m.
Tylko do Grassa to trzeba mieć zdrowe nerwy.