Mezoregiony

Uruchomiłem dziś kwerendę http://overpass-turbo.eu/s/hnM by naprawić w Podkarpackim błędy w relacjach mezoregionów, do których nawiasem mówiąc dawno temu mogłem się po części przyczynić. By granice tych błędnych regionów prawidłowo nanieść wczytałem do JOSM wzorce z GDOŚ http://sdi.gdos.gov.pl/wfs?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=GDOS:Mezoregiony&SRSNAME=EPSG:2180&outputFormat=shape-zip&format_options=charset:windows-1250 i się mocno zdziwiłem gdyż granice regionów w OSM nijak mają się do rzeczywistych http://imgur.com/Tb7xFgq .

Nie uważacie by należało je wszystkie na nowo zaimportować zgodnie z dokładniejszym przebiegiem?

Nie pamiętam już jakich danych używałem. Znalazłem kiedyś przebiegi na public domain i to w formie rastrowej. Kiedyś liczyłem na to, że uda się zrobić to w taki sposób aby wyszukując np. szczyt górski pojawiała się informacja właśnie z mezoregionu. Nigdy jednak tak się nie stało.

No wiadome jest, że korzysta się z danych i podkładów jakie się ma. Zawsze też byłem zwolennikiem dodawania danych (przebiegów w tym przypadku) nawet nie do końca dokładnych jeśli lepszych nie ma, ale skoro są to warto by się nad tym pochylić. Mogę to zrobić, ale zabawy będzie z tym multum, gdyż o ile rozumiem to trzeba będzie nowe przebiegi przepisać pod obecne już w OSM polygony.
Zastanawia mnie też co zrobić z tymi przechodzącymi przez granice kraju gdyż podkład z GDOŚ dotyczy się jedynie naszego kraju i pisze wyraźnie, że jest to część Polska. Jak dla mnie trzeba będzie te obecne w OSM podzielić i wykreślić osobne obszary dla tych zagranicznych i nazwać je tak samo tylko że przypisać odpowiednio kraj przy czym będą mieć dokładną granicę przy granicy z Polską i tą którą dotychczas na pozostałym obszarze

EDIT: By nie uciekło nim ktoś je wszystkie usunie.

Obecne tagi dla regionów to
name=*
region_category=physiographic
region_type=mezoregion

Oraz:


Beskid Niski
name:de=Niedere Beskiden

Wzgórza Sokólskie
name:be=Гродзенскае ўзвышша
name:lt=Sokulkos aukštuma
name:uk=Гродненська височина
wikipedia=pl:Wzgórza_Sokólskie

Tatry Wschodnie - Východné Tatry
alt_name:de=Oestliche Tatra
name:cs=Východní Tatry
name:de=Osttatra
name:en=Eastern Tatras
name:pl=Tatry Wschodnie
name:sk=Východné Tatry

Tatry Zachodnie - Západné Tatry
name:cs=Západní Tatry
name:de=Westtatra
name:en=Western Tatras
name:pl=Tatry Zachodnie
name:sk=Západné Tatry

Płaskowyż Głubczycki
name:cs=Opavská pahorkatina
name:de=Leobschützer Lößhügelland

Pogórze Wałbrzyskie
name:de=Waldenburger Bergland

Pojezierze Drawskie
name:de=Dramburger Seenplatte

Pojezierze Szczecineckie
name:de=Neustettiner Seenplatte

Dolina Dolnej Odry
name:de=Unteres Odertal
name:en=Lower Oder Valley
wikipedia=pl:Dolina Dolnej Odry

PS Wedle jakich obyczajów zaczyna się usuwanie czegoś co nie było przedyskutowane i poinformowane na forum?

znalazłem sposób na uzupełnianie/przerysowanie mezoregionów i powoli idę z nimi do przodu, choć prace potrwają pewnie jeszcze co najmniej kilka dni, gdyż jest to dość skomplikowany proces i dość czasochłonny proces. W międzyczasie zastanawia mnie czy czasem nie powinno się dodać tagów granic. Co by nie powiedzieć to jednak są jakieś formy terytorialne.

http://wiki.openstreetmap.org/wiki/Key:boundary
http://wiki.openstreetmap.org/wiki/Key:border_type

boundary=yes
border_type=territorial

What say you?

Ich terytorialność jest bardziej umowna niż usystematyzowana dlatego nie powinny posiadać tagów granic.

To jest ta słynna relacja source=JerzyK ?
http://www.noclegturysty.pl/img/mezoregiony.jpg

No nie wiem czy tak do końca umowna. Istnieją na jego temat oficjalne opracowania np. https://www.nfosigw.gov.pl/download/gfx/nfosigw/pl/nfoekspertyzy/858/189/1/2013-837.pdf A po za tym co to za różnica czy granica jest umowna czy nie. Co najwyżej powinno to w OSM oznaczać kolejnego tagu np. umowna=tak oczywiście z angielska.

Dokładnie tak to wygląda. Biorąc się za to nie spodziewałem się, że mapa zawiera w sobie również relacje nadrzędne łącząc obszary w większe rejony. Komplikuje to całą sprawę, ale da się zrobić pod warunkiem nie utonięcia w tych wszystkich kreskach a jest tego sporo :wink:

https://upload.wikimedia.org/wikipedia/commons/7/7c/Physico-Geographical_Regionalization_of_Poland.png

Widzę, że są pierwsze importy mezoregionów:)
Jest tam problem z polem description, jest ono ograniczone do 255 znaków i teksty są obcięte. Można by resztę umieszczać np. w description:2

Zrobię i to w swoim czasie. Najpierw muszę ogarnąć same granice a ilość zepsutych relacji jest jest przeogromna. Tak się zastanawiam ile czasu zajmie innym by je ponownie zepsuć gdyż raczej nowi użytkownicy nie będą się zbyt mocno zastanawiać co to jest region_category czy region_type zwłaszcza jak się to nie pokazuje na żadnej skali czy wersji mapy :frowning:

Co do słowa import to w tym konkretnym przypadku zastąpił bym go raczej drobnym eufemizmem “ostrożnie dobrane przebiegi celem poprawienia istniejących relacji” :wink: Import implikowało by, że należy pytać panów od importów czy z danych tych można korzystać, a tym czasem lekko naciągając można uznać, że po pierwsze skoro już dane o regionach w bazie były to znaczy, że są w niej pożądane, a skoro są z tego samego źródła co i dane o użytkach i udostępnione na tej samej licencji co do której nie było wówczas żadnych zastrzeżeń to i po co im wszystkim zawracać głowę :stuck_out_tongue:

Prywatnie korzystam w celach edukacyjnych z tej klasyfikacji Jerzego Kondrackiego i byłoby wielce pomocne, gdyby całość dało się nanieść na OSM.
Na Mapy.cz jest to dość dobrze widoczne. Jak swego czasu mapowałem najbardziej wysunięty obszar Sudetów w Polsce a mianowicie Góry Opawskie to natknąłem się na granice JerzyK. I są one dość dobrze odwzorowane.

Przebiegi mezoregionów ponaprawiane :slight_smile: http://overpass-turbo.eu/s/i3J
Teraz pozostaje walka z detalami i tak:

  1. Regiony udostępnione przez GDOŚ nieco różnią się w szczegółach od tych dostępnych dotychczas i nie zawierają mikroregionów jakimi są http://www.openstreetmap.org/relation/1757864 oraz http://www.openstreetmap.org/relation/1757794 które stanowią część wschodnią i zachodnią Równiny Wrocławskiej. Pozostawiłem ich przebiegi w tych miejscach gdzie dzielą one równinę, więc jak ktoś wie jak je tam dokładnie poprowadzić mile widziane ich odpowiednie poprowadzenie i złączenie z pozostałymi granicami.

  2. Regiony wykraczające poza granice kraju dostępne wcześniej w OSM podzieliłem na dwie części. Dokładną będącą w kraju i tą dotychczasową zagraniczną. Przyszłościowo zapewne jak będą te zagraniczne rejony poprawione to stosownym będzie je połączyć ze sobą

  3. Oryginalne oznaczanie przebiegów jak zauważyłem posiadało również boundary=yes. Uważam, że tu również będzie należało ten tag dodać, gdyż stosowne oznaczenie będzie mniej kusiło by z te dane usuwać/zmieniać. By bardziej ich znaczenie uwypuklić uważam za stosowne dodać kolejny tag by użytkownicy wiedzieli z jakim rodzajem granicy mają styczność np border_type=territorial/geobotanical/physiographic

  4. Ponieważ niezmiernie ciężko pracowało się na obecnych danych, których ~15% węzłów sklejonych było z wszystkim co tylko było możliwe co powodowało całą gamę konfliktów przy ich usuwaniu mile widziane było by dodanie do JOSM i iD opcji, które wychwytują połączenie takich granic z niestosownymi obiektami jak budynki, drogi, linie energetyczne etc i wyrzucanie błędu. Bez tego ciężko będzie to naprawiać po ewentualnym wandalizmie mniej lub bardziej zamierzonym.

  5. Z pewnością kilka dni zajmie mnie również dodawanie relacji wyższych poziomów dla prowincji/subprowincji/makroregionów, ale z czasem i one się pojawią

Dla szerzej zainteresowanych odnalazłem oczywiście z wykorzystaniem innej wyszukiwarki niż forumowa następujące wątki również traktujące o mezoregionach
http://forum.openstreetmap.org/viewtopic.php?id=13844
http://forum.openstreetmap.org/viewtopic.php?id=25479
https://lists.openstreetmap.org/pipermail/tagging/2013-August/014369.html

Konflikty się pojawiały, gdyż okolice tych linii, a dokładniej te węzły z innymi obiektami, nie były załadowane do JOSMa.

Nie no bez przesady. To akurat wiem. Problem w tym, że IMHO nie powinienem musieć ładować okolic tych punktów gdyż nie powinny one z niczym być połączone to po pierwsze. Po drugie jeśli bym załadował choć jedną okolicę węzła to reszta mapy kraju pokryła by się gęstą siatką ukazującą niepobrane rejony utrudniającą pracę i dane z overpass stały by się absolutnie nieczytelne już nie mówiąc jak by ich czytelność była przesłoniona przez punkty znajdujące się w pobliżu. Nawet zastosowanie filtrów w JOSM do ich ukrycia powodowało by że dalej były by te dodatkowe widoczne jako szare mocno utrudniając pracę. Innymi słowy musiałem bawić się w konflikty by mieć nieco przejrzystości w tej poszatkowanej dwoma różnymi zestawami przebiegów regionów mapie.

Przyznam, że nie chwytam. Pisałeś, że konflikty miałeś przy usuwaniu linii. Po co ci do tego dobra widoczność w JOSM? Pobierasz okolice i usuwasz, bez konfliktów. A jak chcesz modyfikować i mieć widoczność do tego, to pracujesz na nowych danych z overpassa.

tak jak powiedziałem ponieważ lubię czytelną mapę i wolę jak JOSM wygląda tak https://postimg.org/image/d0jx4ikln/ a nie tak https://postimg.org/image/csu7swfq3/ Przy okazji wszystkie te kolorowe punkty to obiekty jakie JOSM pobrał przy kolizjach. Gdybym pobierał rejony przy punktach to pobrał by nie tylko punkty ale i obiekty sąsiadujące jeszcze bardziej psując czytelność.

Do tego przy tej ilości danych łatwo o pomyłkę w tagowaniu, więc jeśli zapomnę dodać odpowiedni tag po którym wyszukuje overpass to może się zdarzyć, że będę ponownie dodawał ten sam obszar który już raz dodałem tylko zapomniałem jednego prostego oznaczenia.

To można kontrolować , opcja “Draw boundaries of downloaded data” w Display Settings.

Otrzymałem właśnie wiadomość od użytkownika “hkm” tej treści.
"I want to discus your relations 6533487 and many others. You has twice include all ways in that relations. First time as regular “outer” way and second time as part of “outer” relation. Such inclusion is completely erroneous in many reasons:

Tools, which do not support relations as multipolygon member, has diffculties in interpretation such "strange outer member" (emit warning-error messages)

Tools, which support multipolygon recursion has two same polygons at same place and produce double or even empty polygons

So, I offer to you to preserve only one type of “outer” members, and other type remove from relation members (ways) or mark by some “non geometrical” role such as “subarea” (relations).

Awaiting your decision. Sorry for my english. My native is russian."

Faktem jest, że poprzednio dodane regiony część obiektów w relacji miało oznaczone jako subarea, ale ponieważ JOSM po dodaniu ich w ten sposób krzyczał o nierozpoznanym czy też nieprawidłoym obiekcie oraz wiki pisze http://wiki.openstreetmap.org/wiki/Relation:boundary , że subarea jest “Optional, disputed and redundant” użyłem ponownie roli outer. Jakoś te podrzędne/nadrzędne ralacje przecież trzeba było oznaczyć. Co panowie sądzicie?

wspomniany w wiadomości przykład - http://www.openstreetmap.org/relation/6533487

subarea jest dla relacji boundary, a tu jest multipolygon, stąd JOSM się buntował. Musiałbyś więc zmienić typ relacji, by z tego skorzystać.

Przy multipolygonie faktycznie jest duplikacja linii. Ja bym wyrzucił linie w roli outer i zostawił same relacje w tej roli, bo to jest najwygodniejsze rozwiązanie.
A jeśli jakieś narzędzia nie obługują relacji jako składowych multipolygonu, to jest to problem tych narzędzi.

Co zrobić żeby usunąć to ostrzeżenie przy weryfikacji błędów? Opisy są przecież.
Tagi wielokątów złożonych - może brakować tagu opisującego obszar (1)