RGZ otvorio registar prostornih jedinica - plan za import

Nisam, još smišljam koji bi plan napada bio. Za sada mi ovako nešto deluje:

  1. Pogledamo tipove jedinica koje RGZ ima i pogledamo kako da ih mapiramo na postojeće admin boundaries-e. Meni je ovo trenutno mutno, moramo prvo to da raspravimo, možda nam treba još jedan admin level. Čim “proučim” RGZ podatke, daću ovde neki predlog
  2. Kad to imamo, dodamo novi tag na postojeće boundaries-e, pošto nam treba ključ za spajanje (što inicijalno, što na dalje). Predlažem da, po ugledu na nemački de:regionalschluessel i de:amtlicher_gemeindeschluessel uvedemo naš “sr:maticni_broj” i nalepimo ga na postojeće boundaries-e (poluautomatizovano)
  3. Kada imamo ove matične brojeve u OSM-u za spajanje, onda možemo da odaberemo metriku kako da uporedimo podatke i odstupanja (razlika površine, udaljenosti centroida…)
  4. Na osnovu dobijenih podataka, možemo da planiramo dalji import (popravke postojećih boundariesa)…

Evo kako je sad:

Level 3 N/A
Level 4 autonomous provinces / аутономне покрајине
Level 5 statistical regions / статистички региони
Level 6 districts / окрузи
Level 7 cities / градови
Level 8 municipalities / општине и градске општине
Level 9 local communities / месне заједнице
Level 10 N/A

Prostorne jedinice koje se vode u Registru su:

  • popisni krugovi,
  • statistički krugovi,
  • naseljena mesta,
  • katastarske opštine,
  • mesne zajednice,
  • opštine/gradske opštine,
  • gradovi,
  • upravni okruzi,
  • autonomne pokrajine

Iz ovoga, jedino naseljena mesta nemamo u kategorizaciji a ona mogu da nam budu zanimljiva. Njih nismo stavili u kategorizaju jer nismo imali pouzdane podatke o tome šta su naseljena mesta i da li to uopšte predstavlja zvaničnu administrativnu jedinicu.

Sad sa ovim podacima iz RGZ to imamo.

Verovatno bi trebalo da se mesne zajednice premeste sa Level 9 a Level 10 a da se na Level 9 stave naseljena mesta.

Da li ima smisla da pored matičnih brojeva upišemo i veze između adminstrativnih nivoa (na primer koje mesne zajenice spadaju u koje opštine, koje opštine spadaju u koje okruge i slično). To bi omogućilo lako izdvajanje podataka po administrativnim nivoima.

Otkud sad mesne zajednice u celoj priči?

Nismo nikad imali MZ u hijerarhiji. Ovo je stanje wiki od 13. marta 2019, pre poslednjih promena: na admin_level=8 su bila naselja. Tad smo imali onu raspravu oko gradova, ja sam se na kraju složio, i naselja su kliznula na nivo 9. So far, so good.

Međutim, nakon toga je Peđa prvo uneo MZ na nivo 10 (ajd dobro), ali je onda Sjevtic ničim izazvan obrisao naselja i uneo MZ na nivo 9. Tako nije dogovoreno, i to nije stanje na terenu: na nivou 9 su nam naselja, i u Vojvodini i u Centralnoj Srbiji. Koliko se sećam, dogovor je bio da nam MZ do daljnjeg ne trebaju sistematski.

Btw, mi imamo unete granice gotovo svih naselja na nivou 9. Ja sam protekle godine pokrio Vojvodinu, a centralna Srbija je bila pokrivena ranije. Koliko su precizne granice ne mogu da garantujem (ja sam ih ručno, ehm, precrtavao sa izvesnog javno dostupnog izvora :D), ali u Vojvodini je posao relativno lak jer su dosta prave. Samo ukucajte

admin_level=9 in Serbia

u overpass-turbo.eu.

Samo treba vratiti izmenu koju je napravio sjevtic.

Meni izgleda da je varijanta pre njegove izmene u skladu sa onim sto koristi RGZ i sto nam je potrebno na mapi.
https://wiki.openstreetmap.org/w/index.php?title=Template:Admin_level_10&oldid=1821227

Mesnih zajednica ima unetih na mapi. Ne mnogo ali ih ima: http://editor.osmsrbija.iz.rs/?dataset=srbija-administrativne-granice-mesna-zajednica&shownamesr=on

Prvo da javim - kome se skida anonimno, a bogami i malo brze i pouzdanije od ovoga sa RGZ sajta, sve 7zip-ovano mozete naci ovde:
https://kokanovic.org/opendata-rgz.7z
Probacu da ga drzim ovde koliko god, ali ne garantujem nista ako neko ovo cita 2021. godine:)

Hm, ajde ovako. Trenutno u OSM-u imamo sledece stanje:


Level   Opis                      Broj
4       аутономне покрајине       2
5       статистички региони       0
6       окрузи                    27
7       градови                   29
8       општине и градске општине 149
9       месне заједнице           4711
10     ?                          77

Evo i sadrzaja iz RGZ-a:


tip                 broj   opis
pokrajina           3      kosovo ne unosimo u OSM, nema maticni broj, ima "sifru pokrajine"
upravni okrug       30     nema maticni broj, ima "sifru okruga", ima vezu ka pokrajini
grad                29     ima maticni broj, ima vezu ka okrugu
opstina             197    ima maticni broj, ima vezu ka okrugu
katastarska opstina 5822   ima maticni broj, ima vezu ka opstini
naselje             4721   ima maticni broj, ima vezu ka opstini
katastarski srez    133    nema poligone, ignorisemo
mesna zajednica     4044   ima maticni broj, ima vezu ka opstini
statisticki krug    13999  ima maticni broj, nema ime, ima vezu i ka naselju i ka opstini
popisni krug        41153  nema ime ni maticni broj, ima vezu ka mesnoj zajednici i statistickom krugu

Mislim da mozemo da otpisemo “katastarski srez” iz daljih razmatranja zato sto nema poligone, kao i “statisticki krug” i “popisni krug” jer nemaju ime.

Od ovoga sto je ostalo, mislim da mozemo da napravimo mapiranje:


OSM level OSM ime                   RGZ tip
4         аутономне покрајине       pokrajina
5         статистички региони       /
6         окрузи                    upravni okrug
7         градови                   grad
8         општине и градске општине opstina
9         насеља?                   naselje
10        месне заједнице           mesna zajednica   

Pitanja za sve:

  • Da li imamo konzensus da naselja budu level 9, a da MZ budu 10? Kako je Pedja predlozio? Mislim da se i Duja (manje-vise:) slaze.
  • Sta da radimo sa “katastarskom opstinom”, trenutno se cini da je level 9 bolje da budu naselja nego katastarske opstine? Jel ima neko da misli suprotno?
  • Da li “pokrajini” i “okruzima” da stavljamo a) “sr:maticni_broj” umesto ove sifre pokrajine, b) smisljamo novi tag, npr. “sr:sifra_pokrajine”/“sr:sifra_okruga”, c) ne unosimo im nikakve sifre ni maticne brojeve. Ja sam najvise za c)
  • [trivijalnost] Da li da brisemo “statisticke regione” sa levela 5? Imamo ih nula, a nismood RGZ-a dobili nista, ne znam ni sta je to, ni cemu sluzi. Bolje da “ispraznimo” level 5 sa wikija?
  • [trivijalnost] Da li da preimenujemo “okruzi” u “upravni okruzi” na wikiju?

Ako se sa ovim slazemo, da zatvaramo prvi deo problema - sinhronizacija levela, pa da otvaramo tezi problem - kako ovo uneti i da li neko zna ovo:) Ukazao mi je “TXBG” da cu imati problema sa menjanjem relacije posto je gomila node-ova prilepljena za nesto, pa nece uopste biti lako uneti ovo (a da se sacuva istorija). Mislim da pitam na nekom drugom forumu da nam neko pomogne sa importom.

Iako deluje primamljivo (valjda zato sto imamo relacioni mozak od programiranja:), ne mislim da im je tu mesto. Mislim da je to “tag for ingestion” (varijacija na temu “tag for renderer”, ako tako nesto postoji). Ovi podaci se jako lako mogu izvaditi, jako su stabilni i dovoljno ih je jednom izvaditi.

Свакако питати и негде другде, нисмо ми први койи то раде.

Мени би било интуитивно да се импорт уради у три корака:

  1. прво унесу тачке које су дефинисане од стране РГЗа,
  2. онда да се у постојећим релацијама постојеће тачке замене са унетим тачкама,
  3. и у трећем кораку да се побришу све тачке на територији Србије које не припадају ниједној релацији, путу или немају дефинисан неки додатни таг.

Чини ми се да би се овако унели “званични” подаци, сачувала историја постојећих релација и база би била релативно чиста.

Vraćena.

Da, ali: samo da se poravnamo. Po prirodi stvari, MZ i naselja nisu ugnežđeni nego paralelni hijerarhijski nivoi. Kao što se vidi i po broju entiteta, MZ i naselja su otprilike 1:1… osim tamo gde nisu. E sad, za većinu upotreba (pre svega adrese) naselja su ono što je bitno za mapu, dok su MZ pretežno upravna stvar sumnjive upotrebne vrednosti. A pošto su i uglavnom 1:1 s naseljima, blesavo je napraviti još 4000 relacija admin_level=10 od kojih je ~95% identično kao one sa admin_level=9. Te bih da izostavimo import ovom prilikom.

Nema. Kao i MZ, i KO je pretežno upravna stvar. Ako nekom treba da gleda katastar i parcele, stvarno treba da ide na Geosrbiju a ne na OSM. Out of scope, ja bih rekao.

I ja sam za c. Ako ćemo ipak da ubacujemo, pravi tag bi bio ref ili nat_ref.

To su neki skupovi okruga za svrhe popisa i sl. Ja sam sklon da se isprazne s wiki da ne bi opet pravili megarelacije sumnjive upotrebne vrednosti.

Naprotiv, ja bih da vratimo “upravni okrug” u “okrug” na OSM, što ću verovatno i da učinim kad me ne bude mrzelo. To niko ne zove “upravni okrug”, jer je rogobatno, te sve to treba prebaciti u official_name, a u običan name ostaviti samo “okrug”.

Koliko sam letimično proverio, problem zalepljenih čvorova nije previše raširen, jer smo i kolega Opaky i ja granice stavljali u poseban “lejer” povezan samo sa samim sobom. Ne sumnjam, međutim, da polepljenih čvorova ima (što nasleđenih odranije, što nepažnjom/neznanjem polepljenih nakon što su granice unete).

+1

Dobih malopre obaveštenje od OSM da je Duja ispravio definicije za administrativne nivoe. Vratio je na stanje pre nego što je to sjevtic izmenio. Interensanto, ne sećam se da sam isto obavštenje dbio kada je sjevtic unosio promenu.

U svakom slučaju ovo kako je sad bi trebalo da je ok.

Moj stav je da treba da tretiramo administrativne granice u skladu sa državnim definicijama i upotrebnoj vrednosti mape.
Stoji da neke definicije u SM nisu baš pogodne, Duja je pomenuo da se neka naselja i mesne zajednice potpuno poklapaju, ali šta je tu je.

Ima smisla imati i jedno i drugo na mapi jer nekme su bitna naselaj a nekome baš mesne zajednice. Ako uzmemo da se ohrabruej da se OSM koristi baš za razne potrebe lokalnih aktivista, ne možemo prenebregnuti da je lokalni aktivizam često vezan baš za administrativne jedinice pa i mesne zajednice.

Evo hipotetičan primer: Užice je jedan do gradova koji u zimskom periodu ima velike probleme sa zagađenjem vazduha. Ima smisla da se napravi mapa zagađenja radi inicijative u lokalnoj samoupravi da se nalaze rešenja za problem, a ta mapa po logici stvari treba da prikazuje zagađenje po mesnim zajednicama jer je to najniži oblik organizvanja bilo kakvih aktivnosti lokalne samouprave.

Možda bi ovaj problem što semz i naselja često potpuno poklapaju neka inicijativa da se uvede tagovanje kojim bi jedna relacija mogla da se označi da predstavlja dva administativnih nivoa. Na primer da se uvede tag alt_admin_level. Ovo bi mislim bilo ok, jer ko obradjuje mapu po tom osnovu, znace da terba da tretira oba taga. Jedino je nezgodno ako bi postojala realna situacija da ista relaciaj predstavlaj tri administrativna nivoa, ali mislim da j eto baš redak slučaj.

Inače isti problem već imamo sa Gradom Beogradom, jer on istovremeno ima status i grada i regiona. I to bi mogli da rešimo sa alt_admin_level

U našoj varijanti mape je KiM ispravno tretirano kao pokrajina tako da tu imaju tri.

Slažem se. Možda to i ne treba tertirati kao administrativne nivoe nego kao sasvim druge atribute.

Recimo možemo za katastarske podatke da uvedemo cadaster_level sa definicijom nivoa analogno admin_level. To čak ima smisla i za globalnu upotrebu. Takođe bi omogućilo da se ti atributi unose paraleno u istoj relaciji pa ne bi trebalo praviti kopiju relacije samo zbog atributa.

Da li treba katastarske relacije imati na OSM. Mislim da treba. Možda mi lično nemamo potebu za takvim podacima ali je meni sasvim očigledno da nekome može trebati. Na primer, lokalne samouprave koje su počele da se oslanjaju na OSM izvesno imaju potrebu da mogu da sa OSM podacima rade na nivou katastarskih površina.

Samo da potvrdim da sam ja za.

Moj predlog je da se uvede tag cadastre_level i da se katastarske relacije označavaju odvojeno do adminsitrativnih. Gore sam dao detaljnije objašnjenje.

Mislim da obavezno treba ubaciti u bazu te kodove jer su oni direktna veza sa spoljnim svetom. Bilo ko kome bude trebalo da poveže OSM sa svojim podacima zasnovanim na administrativnim područjima to može da uradi samo preko ovih šifara (matičnih brojeva).

Evo očigledan primer: za državne granice se u označavanju koristi tag ISO3166-1 koji sadrži kod zemlje. Time je rešen problem pretrage i filtriranje po nazivu koji može biti svakojako zapisan. Kod je uvek isti.

Ja bih predložio da uvedem neki univerzalniji način označavanja koji može biti i globalno upotrebljiv.

Na primer ako imamo tag admin_level da uvedemo tag admin_level_code i da admin_level_ref bude namenjen da se tu upisuje zvaničan identifikator koji je toj konkretnoj administrativnoj granici dodeljen. Tako ne bismo ulazili u problematiku da li je to id, kod, matični broj. šifra ovoga ili onoga nego prosto univezalno, tu se upisuje kod a šta predstavlja taj kod zavisi od dodeljenog administrativnog nivoa.

Slično bi smo mogli uraditi i ako se uvede alt_admin_level, da se uvede i alt_admin_level_ref

Slažem se.

Pošto nema nikavu drugu ulogu osim opisa nije toliko bitno. Što se mene tiče može i jedno i drugo. Možda preteže to što je izraz upravni okrug zvaničan. Mi ćemo u praksi verovatno uvek govoriti o okruzima.

Upotreba naziva upravni okrug ima smisla i sa aspekta pretrage: ako neko traži u vikiju upravni okrug a u definiciji stoji samo okrug, neće ga naći. Ako u definiciji stoji upravni okrug, onda će ga naći bez obzira da li traži upravni okrug ili samo okrug).

Koliko sam pogledao, u bazi i manešto mesnih zajenica koje su već tako obeležene. Bilo je nešto mesnih zajednica koje su bile obeležene kao naselja (admin_level je bio 9 a u nazivu je stajalo MZ) pa sam te doterao.

Međutim imam utisak da ima nekih relacija koje su pogrešno označene kao naselja ili mz ali se to iz naziva ne može sigurno zaključiti osim ako neko ne poznaje lokalne prilike ili ako ti ne primeni opet neku magiu sa povezivanjem sa otvorenim podacima pa detektuješ takve slučajeve. :slight_smile:

Ovo sam predložio iz sopstvenog iskustva. Naime, ume da bude prilično komplikovano izvući iz baze podatke koji spadaju u neku administrativnu granicu. Recimo overpass-api.de baš ima ogrničenja filtriranja ako je osnov za filtriranje relacija.

Zaista bi bilo veliko olakšanje ako bi se mogle niže admnistrativne jedinice izvlačiti iz baze po prostom kriterijumu da spadaju u određenu višu administrativnu granicu, što bi bilo moguće ako bi se te veze unele u bazu. A pošto veze imamo, šteta je ne iskoristiti ih.

Generalno, nije loša ideja o ovom alt_admin_level, mada možda treba razraditi postoji li neki od postojećih tagova koji bi se mogao iskoristiti za tu namenu. Letimičnim pregledom wiki, rekao bih da ne postoji. Kao što rekoh gore (verovatno Peđa nije stigao da pročita), za dodelu kodova je predviđen ref tag sa varijacijama (ref:registar).

I dalje sam stava da katastarski podaci nisu u delokrugu OSM. Informacija o KO ne znači puno sama po sebi, jer je tek deo slike za informaciju o katastarskoj parceli, a ne verujem da želimo parcele ikada u OSM. Plus, to je skup relacija koji je praktično isti kao granice naseljenih mesta a, koliko vidim, ima ih oko 1000 više prvenstveno zato što dataset sadrži granice KO sa Kosova ali ne i granice naselja.

Relacije opština već jesu smeštene u relacije okruga kroz “subarea” ulogu, npr. Mačvanski okrug, ali naselja nisu u opštine na isti način. Nemam ništa protiv da se to importuje.

Jesam, video sam za ref pa sam ispravio u mojoj poruci.

Ja pokušavam nešto da napravim od ovih podataka, ali mi slabo ide. Raspitivao sam se i saznao da ne postoji način da se programski zamene boundaries sa drugim granicama. Tu su državne granice, prirodne granice (reke), zalepljeni drugi node-ovi koji se ne mogu pomerati…odustajem od ovog pristupa. To znači i da odustajem od pristupa da čuvamo istoriju. Ja ovaj import ne znam da izvedem na ovaj način i rade volje prepuštam ceo import onome ko ovo zna.

Ono što su skoro uradili na Kosovu je dokumentovano ovde: https://lists.openstreetmap.org/pipermail/imports/2019-November/006113.html. Inače, taj momak (Guillaume) mi je dosta saveta dao ovde. U tom mailu su opisani alati i način rada (donji deo mail-a vezan za boundaries). Ja sad pokušavam da napravim .osm fajl koji može da se uveze u JOSM i uspeo sam da napravim neku osnovnu, sirovu verziju: https://kokanovic.org/osm/rpj-v1.7z

Molim vas, NIKAKO ne koristite ovo za uvoz u OSM.

Ono što je sigurno je da treba da krenemo “odozdo”, tj. da prvo unesemo/popravimo admin_level=9 (naselja) i da puteve koji grade te relacije upotrebimo i za opštine i na dalje. Pošto opština ima manje od 200, možda to i na dalje može i ručno da se napravi. Ali, ne znam dovoljno JOSM da vidim kako od ovog .osm fajla nastaviti dalje. Generalno, stanje u OSM-u u odnosu na RGZ uopšte nije loše, dosta smo (bar sa admin_level=9) dobri.

Ne znam šta dalje da radimo - ovo što imamo je dovoljno dobro, a ne znam kako da nastavimo ako hoćemo da importujemo ovo iz RGZ-a. Ako želimo da popravljamo geometriju postojećih way-ove, to možda može, da se podelimo po okruzima i treba nam uputstvo kako to izvesti iz JOSM-a tako da bude lako za rad i da ne uništimo i ispomeramo sve okolo. Imamo sad .osm fajl, samo treba da postojeće puteve popravimo. Tu ima JOSM plugin koji može da menja way-ove (https://wiki.openstreetmap.org/wiki/JOSM/Plugins/utilsplugin2#Replace_one_way_with_another_way) a trebaće i “ContourMerge” pomenut u mailu kod Kosova, jer ima dosta mesta u RGZ dataset-u da nisu slepljeni putevi (ima rupa izmedju naselja).

Sa druge strane, ako želimo da izbrišemo postojeće way-ove i zamenimo ih novima - i to može, ali ne znam tačno kako. Morao bih da radim na ovom generatoru .osm-a da može da merge-uje postojeće tagove iz postojećih naselja. Tu ima prevoda na druge jezike, ima wiki tagova i sl. koje želimo da sačuvamo. Ima admin_center node-ova koje isto želimo da sačuvamo. Sve to onda mora da završi u .osm fajlu. Ali čak i da izbrišemo postojeće puteve i zamenimo ih novim i napravimo nova naselja, moramo postojeće way-ove da zamenimo u svim drugim relacijama admin_level < 9 (opštine, gradovi…). Nemam ideju kako bi sve ovo izveli da ne potrošim mnogo dana da ovo isprogramiram, a šteta (gubljenje istorije, gubljenje tagova) bi bila velika. Daljnja iskoristivost ovog programa bi bila ravna nuli. Trenutno nisam za ovaj pristup.

Treba nam neki JOSM guru da pomogne, koji može da uzme ovaj .osm fajl, da nam kaže kako da najbolje uvezemo ovo iz njega i pomerimo postojeće “outer” puteve - ja bih najradije bio za to. Inače, evo šta ja radim - odem u JOSM-u na “Download data…”, kartica “Download from Overpass API” i unesem npr.:


[out:xml];
area["name"="Сремски управни округ"]["admin_level"=6]->.a;
(
  relation(area.a)["boundary"="administrative"]["admin_level"=9];
);
(._;>;);
out;

tako dobijemo layer sa OSM podacima. Onda uvezete naš .osm i… dalje ne znam:)

Бранко,
На основу ових података које си припремио за Срем, да ли уопште има потребе да се увозе подаци? Може се просто, ручно, на пар места, извршити корекција тренутних граница. Битно је само да се геометрија поклапа, а положаји самих тачака које дефинишу геометрију не морају да буду исти (бар по мојим схватањима очекиване прецизности).

Pa to je upravo pitanje koje ja iznosim u prethodnom mailu (možda ne ovako jasno:) ). Da li popravljati postojeće ili uvoziti iznova. Moja teza je da treba popravljati postojeće.

Mooože, ali kako? Zato sam pitao da li neko može da sastavi kratko JOSM tutorijal koji bi mogli da pratimo i da se podelimo na par okruga? Ja trenutno ne vidim kako da lako/brzo/konzistentno obiđem jedan okrug (koji plugin, koji shortcut…), da znam gde sve treba da gledam, da znam na šta sve treba da pazim (možda pomerim reku, možda pomerim neki put usput greškom, a možda to i želim…), da spojim rupe koje postoje u RGZ podacima…I onda na sve to da upload-ujem samo ono što sam menjao. Ako budeš probao ovo što sam ti rekao da popravljaš, ili ćeš shvatiti šta je problem, ili vladaš dovoljno JOSM-om da ne shvataš moje probleme, pa možda onda možeš ti ukratko da opišeš postupak?

I opet, na kraju, ne znam kako da izvučemo metriku preciznosti. Ako neko ima ideju, mogu da napravim program koji izvlači tu metriku sada odmah, i onda nakon popravki. Npr. možda bi bila intersect(“površina naselja u RGZ-u”, “površina naselja u OSM-u”)/“površina naselja u OSM-u”. Da li ovo ima smisla?

Сад сам збуњен - да ли сам пропуштио шта је проблем? Све си сажвакао у прошлом мејлу па не разумем какав додатни туторијал је потребан. Када учиташ податке са ОСМ (са Overpass API), учиташ осм фајл који си генерисао из података РГЗа. Видиш где постоји одсупање, селектујеш тачку коју желиш да помериш на ОСМ слоју и помериш је. Ако желиш да додаш тачку кликнеш на “+” између тачака и поставиш је где желиш. Када завшриш Upload all changes и то је то. Једино на шта треба обратит пажњу је да када се мењају ОСМ подаци треба да тај слој буде активан.

Све ово сигурно и сам знаш па не разумем шта сам превидео :confused:

Чини ми се да поређење површина не би била најбољи показатељ јер су разлике у површинама сувише мале у односу на укупну површину. Ја бих поредио суму најкраћих растојања тачака РГЗ полигона од линија полигона ОСМ. Чини ми се да су границе у ОСМ понегде упрошћење па је боље да се бирају тачке тамо где их је више (а то је РГЗ).

Pa ne, može to tako, ali ko će tako raditi 4000 naselja, jedno po jedno? I da se stvarno tako radi, ni onda nećemo dobiti ono što je u RGZ-u. To me brine. Više sam mislio na to kako možemo ovo pojednostaviti, a dobiti preciznost kao u RGZ-u. Npr. pogledaj https://wiki.openstreetmap.org/wiki/JOSM/Plugins/utilsplugin2#Replace_one_way_with_another_way, pokušavao sam da vidim kako to napraviti, ali nisam našao kako ako su na različitim slojevima… Mislio sam da iskoristimo nešto tog tipa…

Metrika koju su naveo ima više smisla!

Претпоставимо да се једно насеље граничи са два друга насеља. Пошто је један пут део границе два насеља значи да се постоји минимално 4000 путева које је потребно генерисати/кориговати. То опет није занемарљив број. Дакле, како изделити РГЗ полигон на више мањих линија? Једино упоређивањем самих полигона и налажењем преклапања између њих (под условом да се тачке на границама поклапају иначе имамо проблем крајњих тачака). Онда да се направи додатак за ЈОСМ, који би препознате границе између општина приказао на мапи, и тражио да се изабере линија којој би требало заменити тачке. Направити овако нешто није неизводљиво, али да ли се исплати уложени труд?

На основу узорка за Срем, може се закључити да је неко већ користио податке које ми имамо (вероватно је прецртавао преко њих), тако да (по мом мишљењу) “очекивана прецизност” већ постоји.

Možda da se granice naselja/mesnih zajednica uploaduju na OSM u Public GPS traces tako da ljudi to imaju kao podlogu, pa ako je neko raspoložen da doteruje postojeće granice perema njima?

To niee sistematsko rešenje ali ne bi trebalo da smeta a svakako bi značilo nekome kome je u datom momentu potrebno da bar deo neke granice sredi da bude tačan.