Granice administracyjne - zmiany 2015

Communities Polska (Poland)
21

jeżeli dobrze rozumiem - jeżeli albo granice gmin pomiędzy sobą mają dziury, albo na siebie nachodzą, to tak naprawdę nie dowiemy się jaki jest rzeczywisty ich przebieg? Naprawiając dziurę albo jedna gmina albo druga dostanie większy obszar niż powinna.

Na dniach wrzucę raport z gminami w OSM, które mają największy rozjazd względem PRG (dzięki @WiktorN za rady!)

22

Idealnie byloby to podzielic na dwa kroki: wygenerowanie poprawnych danych, i dostosowanie do nich geometrii OSM (import). Ale nie mamy chyba dobrego miejsca gdzie moznaby grupowo pracowac nad jakims zestawem danych bez importu. Wyobrazam wiec sobie taki workflow:

  • tam gdzie automat nie ma watpliwosci wygenerowanie geometrii granic gmin z danych gugik
  • tam gdzie sa jakies watpliwosci dot. granicy miedzy gmina X i Y wygenerowanie kilku mozliwosci
  • sprytny importer, ktory podczas importu wybierze opcje najblizsza aktualnej w OSM. A tam, gdzie max. odleglosc miedzy linia z gugigku a linia OSM jest przykladowo mniejsza niz 10m, moze jej wcale nie dotykac.
  • proprawienie relacji powiatow czy wojewodztw ktore w efekcie sie popsuly – to najprostsze.

Dostosowanie granic automatem, tak zeby zachowal w miare mozliwosci historie obiektow (przesunal istniejace drogi i wezly) powinno byc wykonalne. Mam taki kod dla budynkow, niestety brzydki i obslugujacy tylko podzbior przypadkow – bez relacji, odklajania scian od landuse czy drog, itp.

23

Patrząc na uwagi odnośnie wyników mam jeszcze dwa pomysły:

  1. Zamiast liczyć różnicę w powierzchni, to może liczyć sumę odległości punktów od danego kształtu od drugiego i vice versa. Może nam tak bardzo nie przeszkadza jak linia ciągnie się kilometrami równolegle, a bardziej duże odstępstwa w punktach.
  2. Może też warto zamienić układ odniesienia WGS84 na jakiś w którym jednostka x i y ma taką samą długość w rzeczywistości. Tu może Ci pomóc pyproj i jeśli się nie mylę - klasa Proj.
24

Już w poprzednim wątku opisałem, gdzie leżał błąd :slight_smile: . Nie wiem, czy odległości punktów zdadzą egzamin - obiekty musiały by mieć chyba zbliżoną gęstość punktów, bo inaczej nawet w identycznych polygonach wychodziłyby kosmiczne różnice. Ew. dla każdego punktu w polygonie OSM zinterpolować najbliższy w polygonie PRG i zmierzyć odległość - ale to chyba trochę strzelanie z armaty do wróbla :). Sprawdźmy najpierw jak się spiszą poprawione raporty oparte o różnice powierzchni.

Co do układu odniesienia, to czemu nie - tutaj niech się wypowie ktoś zaznajomiony z tematem, bo jeżeli chodzi o niuanse i niedokładności w różnych SRID to ja jestem laik :). Skrypt mam oparty o PostGIS, więc zmiana układu odniesienia to banał.

25

No właśnie nie jest potrzebna podobna gęstość punktów, bo algorytm wygląda tak:

dist = 0
for punkt in polygon1:
	dist += punkt.distance(polygon2)

for punkt in polygon2:
	dist += punkt.distance(polygon1)

Ponieważ odległość punkty od wielokąta powinna uwzględniać również jego krawędzie, a nie tylko punkty, które go definują. Oczywiście, trzeba wziąć tylko jego krawędź.

Jeżeli działasz na PostGIS to pewnie obliczenia powierzchni już masz w metrach albo innej podobnej jednostce, więc nie ma potrzeby już kombinować. Takie byłoby moje oczekiwanie, PostGIS-em jeszcze się nie bawiłem.

26

Raczej musialbys wynik podzielic przez liczbe punktow (usrednic), inaczej bedzie rosl proporcjonalnie do liczby punktow. Albo wziac maksimum - nie ma do tego funkcji postgisowej.