Błedy w obszarach administracyjnych Polska (województwa, powiaty, itd)

Przetwarzam sobie dane dotyczące obszarów administracyjnych w Polsce.
Dane niestety zawierają sporo błędów i są trudne do użycia.

Jest dużo przypadków gdy relacje mają pomyloną kolejność elementów
Być może ten typ elementów powinien mieć jakąś numeracje
Bardzo często way jest odwrócona (to akurat nie jest dla mnie wielki problem) , być może powinno być to jakoś oznakowane

Taki problem (pomylona kolejność member type way) jest np w województwie
mazowieckim
zachodnio pomorskim
podkarpackim

a także w wielu powiatach, przejrzałem około 100 powiatów, 30 trzeba było ręcznie poprawiać

Cześć,

Myślę, że czynisz zbyt ścisłe założenia co do tego jak powinny wyglądać relacje.

Wg https://wiki.openstreetmap.org/wiki/Relation:multipolygon/Algorithm kolejność nie ma znaczenia.

Najlepiej - znajdź kod przetwarzający relacje (np. w osm2pgsql - albo inny projekt w Twoim preferowanym języku programowania) i zobacz jak on działa.

Masz rację. I tak używam jakiegoś algorytmu który to wszystko kontroluje, wiec trzeba będzie go rozbudować o funkcje porządkujące dane, jeżeli coś jest poprzestawiane. Nie ma sensu poprawiać tego ręcznie.
Dziękuje za sugestie.
Myślałem, że te dane są bardziej sformalizowane.
Zasugerowałem się tym, że większość jest prawidłowa.

Specem od granic jest użytkownik wambacher, możesz do niego napisać po angielsku lub niemiecku.
https://forum.openstreetmap.org/viewtopic.php?id=65676

Libosmium ma klasę do składania multipolygonów, tu jest przykład. https://github.com/osmcode/libosmium/blob/master/examples/osmium_area_test.cpp

Nie sprawdzałem tego kodu, ale możesz go przejrzeć: https://github.com/OSGeo/gdal/tree/master/gdal/ogr/ogrsf_frmts/osm

Dziękuje za poświęcony czas.
Najlepsze dla mnie rozwiązanie w poście #2.
Prosto, tekstowo opisany algorytm działania.
Jutro go zastosuje.

Szczerze mówiąc, to wspomniane tam jest o backtrackingu - i myślę, że to może być najcięższa część.
Backtracking wykorzystuje się na przykład przy rozwiązywaniu sudoku :wink:
https://en.wikipedia.org/wiki/Backtracking

Już algorytm gotowy. Jak do tej pory poległ tylko na powiecie:
będzieńskim id 2251894
rybnicki id 2416791
pleszewski 2614807
Musze go ręcznie przeanalizować.

Z powiatem będzińskim jest ciekawostka, bo wygląda na to że są to 2 rozdzielne obszary.
Ciekawe jak sobie poradzić w takiej sytuacji. Skąd wiadomo które elementy tworzą który obszar.

Powiat krakowski 2 obszary
Powiat rybnicki to 3 obszary.
Wydaje mi się, że ktoś kto to projektował nie przewidział takiej sytuacji.
Trzeba by stworzyć jakieś dodatkowe relacje innego poziomu.

Są też błędy powiat zduńskowolski id 2777495, element way o id 206630343 jest zamkniętym kształtem.
powiat zamojski id 2664538, element way o id 198402558, jest zamkniętym kształtem wewnątrz, tutaj pewnie jest problem taki, że miasto miało by być odjęte od powiatu zamojskiego ale to wymaga wiedzy człowieka

Wydaje mi się, że trzeba dodać jakiś element subarea opisujący wyłaczenie obszaru wewnętrznego.
Chociaż - po namyśle być może po prostu w tym wypadku błąd tkwi tylko w tym, ze dodano te obszary zamknięte, bo miasta są i tak na innym poziomie.

Jednak i tak trzeba mieć jakiś sposób na opis obszarów administracyjnych które składają się z kilku odrębnych obszarów.
Dodatkowo powinna być informacja że jakiś obszar jest wyłaczony z tego o obszaru. Dotyczy to powiatów z wewnętrznym powiatem miejskim. W rybnickim są 3 obszary a można by to załatwić jednym obszarem powiatu rybnickiego z wyłaczeniem wenętrznego powiatu miejskiego rybnik.

No już widzę jak to powinno być zrobione, brakuje granic definicji enklaw poprzez
<member type=“way” id=“AC” role=“inner” />
tylko trzeba by przyjąć że enklawa jest narysowana jedną ścieżką bo inaczej znowu będą problemy do której enklawy należy konkretna ścieżka. Chyba, że można użyć type = “relation” role = “inner” inner ale to tworzy kolejny poziom przetwarzania przy parsowaniu danych.

Ciekawe. Sam miałem się za to zabrać. Bo powoli przegryzam się przez dane administracyjne. Wczoraj nawet rozmawiałem o tym z Rico. Wygląda, że trzeba by się temu przyjrzeć. Może jakiś projekt w ramach Stowarzyszenia? Co wy na to? Porównanie danych z granicami oficjalnymi z PRG? I do tego porządek w tagach?

Do tej pory przejrzałem województwa i powiaty. Dostrzegam następujące problemy.

  1. Są powiaty które składają się z > 1 odrębnych obszarów, parsując plik nie da się tego ustalić - być może dało by się to rozwiązać w niektórych przypadkach poprzez definiowanie enklawy (powiat rybnicki, dla będzińskiego już raczej nie)
    powiat będziński
    powiat rybnicki
    powiat włocławski
    powiat krakowski
  2. Są powiaty miejskie które są naniesione wewnątrz na obszarach innych powiatów bez wprowadzenia enklaw. Z tego powodu dostaniemy informacje o 2 różnych powiatach z tego samego poziomu dla jednej współrzędnej geograficznej. Jedna z nich będzie błędna.

Nie za bardzo rozumiem punkt 1. To ile jest odrębnych obszarów algorytm z Wiki sam wyznacza. Da się to ustalić.

Faktycznie, można to ustalić jak zamkniesz pierścień i coś ci zostanie. I z tego co ci zostanie zbudujesz kolejny.
i Tak aż do skutku. Jeżeli nie będzie nic błędnie zdefiniowane to powinno zadziałać.
To też powinno załatwić problem jednej ściezki w

Powiesz jaki język programownia wykorzystujesz? Może wyważasz otwarte drzwi i są gotowce, których można użyć.

To jest trochę https://en.wikipedia.org/wiki/XY_problem :wink: Widzę że tak naprawdę chcesz zrobić jakiś geokoder.

Geokoder to mam już zrobiony kilka lat temu, także system nawigacyjny co liczy nawet nr zjazdu z ronda, zakazy zawracania itp.
Kiedyś z nudów zrobiłem, liczy trasę przez całą Polskę w 0,5s.
To takie prywatne gogle map.
Chce sobie rozbudować system o podział administracyjny, możliwie głęboko w dół.
A pracuje po prostu skryptami SQL, język nie ma znaczenia.
Wszystko jest załadowane do MS SQL

Tak zupełnie na marginesie, k’woli informacji dla edytująćych relacje JOSMem - w JOSMie jest przycisk sortowania dróg (w tym przypadku granic) składających się na relację…

Pozdrawiam,
Grzesiek

Mam plan powoli wrzucać do OSM granice jednostek podziału miasta Bydgoszczy na… w sumie nie wiadomo co to… Wsie, osiedla, podosiedla…
Na mapie jest już podział oficjalny miasta na “osiedla” (odpowiednik dzielnic z innych miast). Osiedla mają swoje Rady osiedli.
No i teraz zostało coś podrzędnego (czyli właśnie nie wiadomo co).

https://www.openstreetmap.org/way/993506919#map=16/53.1758/18.1742

No i pytanie: jak to powinno być opisane. To będą granice na podstawie różnych danych (z Miejskiej Pracowni Urbanistycznej, może spółdzielni). Oficjalnie takiego podziału nie ma wg miasta, ale jest używany przez mieszkańców, deweloperów, rady osiedli, dziennikarzy itp. Chodzi o ujednolicenie. Ma ktoś pomysł/podpowiedź?

Druga sprawa: gdzie to będę mógł zobaczyć - jest jakaś wizualizacja?

Warto, żeby to jednak były dane z jednego lub też zbieżnych źródeł. Powstanie spore zamieszanie jest jakiś obszar wg Miejskiej Pracowni Urbanistycznej będzie miał inny przebieg niż wg spółdzielni a będziesz to chciał opisać jako równorzędne obiekty.
Jeśli to miały by być obszary z Miejskiej Pracowni Urbanistycznej (oczywiście kwestia licencji tych danych!) to jak domniemuję byłoby to coś w stylu obszarów Systemu Informacji Miejskiej, tutaj przykłady z Poznania i Warszawy.
No i kwestia zasadnicza – takie obiekty opisujemy relacjami a nie na liniach (te są elementem składowym relacji w roli outer).

Z tego co wiem, funkcjonuje dedykowana stronka do przeglądania granic.
No i zawsze pozostaje też kwerenda w overpass-turbo.

Jeśli to coś podrzędnego nie ma wyznaczonych administracyjnie granic, to powinieneś IMHO poprzestać na punktach place=neighbourhood i podobnych. Już te warszawskie obszary MSI, o których mówi Szydzio, są kontrowersyjne, ale przynajmniej poparte uchwałą samorządu i weryfikowalne w terenie dzięki obecności na tablicach adresowych. Łączenie według własnego uznania różnych źródeł danych, by uzyskać taki podział, wydaje się już nadużyciem, a jeśli miałbyś oprzeć się na jakimś jednym konkretnie źródle, to trzeba by ocenić to źródło. Niektóre jednostki miejskie mogą mieć tego typu robocze podziały, ale granice w nich wyznaczone mogą być podyktowane specyficznymi względami, które nie wiążą się z codziennym uzusem wśród mieszkańców. W końcu, trzeba powiedzieć, że użycie przez mieszkańców nazw części miast jest w ogóle przeważnie nieostre, więc o ile badanie tego uzusu i wyznaczanie takich granic to ciekawy problem teoretyczny, o tyle niekoniecznie jest na to miejsce na OSM, gdzie dane muszą być weryfikowalne.