Vsekakor ni smiselno uvažati kar celega sloja GJI - ni tako dobro topološko urejen kot so OSM ceste, posamezne linije se v križiščih ne stikajo tako perfektno kot OSM. To je ena od velikih prednosti OSM higways pred uradno evidenco GJI.
Mogoče bi za začetek lahko GJI uporabljali zgolj kot rastrsko podlago, odstopanja obstoječih cest v OSM po mojih izkušnjah niso velika.
Predvsem je potrebno premisliti kako izvesti operacijo “data preparation”/“identifying duplicates”/“pre-import cleanup” kot so to imenovali v uvozih, ki so navedeni kot referenca.
Kot kaže večinoma želijo ob uvozu tudi poenotiti podatke na način, da so naslovi striktno vezani na samostojne točke in ne na druge elemente (stavbe, …). To je kar precej dela. Verjetno bi se dalo kako tudi avtomatsko analizirati, kateri podatki o naslovih že obstajajo in jih nekako procesirati.
…
Pa še “vprašanje”: zakaj sploh naslovi v OSM, če pa so že v OpenAddresses ? A ne gre malce za podvajanje, pa še osveževanje v OpenAddresses je precej enostavnejše. A je kak znan protokol, kako bi to dvoje postalo eno.
Ja, ampak ker to ni prvi tak uvoz s potencialnimi konflikti in je konflikte dokaj enostavno razreševati (točke z nekaj tagi) obstaja že nekaj orodij ki počno točno to, jih je pa potrebno pregledati, preizkusiti in po potrebo ustrezno doplniti.
Poišči obstoječe naslove v OSM (npr prek overpass turbo APIja)
Poišči duplikate med kandidati za uvoz v radiju x (npr 10) metrov okoli obstoječih naslovov (pri tem je verjetno potrebno prilagoditi logiko za fuzzy match slovenskih ulic, cest)
Zavrzi duplikate ali pa obstoječim točkam dopolni (“Slovenska” → ”Slovenska cesta") ali dodaj manjkajoče tage (npr dvojezično ime ulice ali hs_mid za lažja uparjanja v prihodnosti)
uvozi nove točke
Na ta način:
Dobimo vse naslove v OSM
OSM uredniki imamo možnost korigirati mikrolokacijo točk (npr če v GURSovem viru pozicija ni točna, ali pa se je naslov (tablica s hišno številko, “on the ground”) prestavil npr na sosednjo hišo (novogradnja/nadomestna gradnja, lastnik pa ni šel v boj z birokracijo za prestavitev)
v primeru večjih neskladij (npr 50 metrov razlike) bi v OSM imeli obe “resnici”
Zato, ker bi s tem dopolnili manjkajoče podatke v OSM, hkrati pa dali možnost OSM urednikom, da jih izboljšamo. Konec koncev zakaj bi uvažali rabo tal, hiše in risali ceste, če so na voljo vsaka od the v neki tretji bazi.
Opazil sem, da je treba pri uvozu pravokotnikov spojiti prav vse točke, ki se stikajo s sosednjimi pravokotniki (ne samo vogale), saj se še vedno ne ujemajo povsem (točko je treba kar precej povečati).
Zanimivo, pri meni do tega problema ne prihaja. Kot ponavadi sem:
Naložil (k sebi) omenjeni izrez 1297,
sprožil validacijo v JOSM-u,
v seznamu validacijskih opozoril poiskal razne duplicate nodes (landuse duplicate nodes, other duplicate nodes…) - tu verjetno uporablja neko toleranco, ker osm v OSM bazi shrani le do 7 decimalk za pozicijo (https://wiki.openstreetmap.org/wiki/Node#Structure )
kliknil na gumb “fix” pod seznamom napak (to zmerga vozlišča, da ne dodaja po nepotrebnem novih)
preveril vozlišča s severnim in zahodnim izrezom in povsod je bilo le eno vozlišče (namesto zoom-a sem izbral regijo okoli vozlišča in na seznamu izbranih elementov je bilo vselej le eno vozlišče)
Koliko pa so bila narazen ta vozlišča, ker praviš da si moral “točko precej povečati” da se stvar opazi?
Ko izberem območje okoli vozlišča, se ne seznamu pojavita dve vozlišči s povsem enakimi koordinatami. To je morda zato, ker pravokotnik uvoza združim z glavno plastjo (z ukazom ‘Merge’), da lažje urejam okolico pravokotnika. Bom poskusil še z ločenimi plastmi, in sporočim rezultate.
Se opravičujem, ker sem temo začel v napačni niti.
Ja, zgleda, da ta validator pomaga. Jaz sem prej zagnal to orodje šele tik pred pošljanjem na strežnik. Pri zagonu orodja takoj po uvozu pa je težava izginila.
Morali bi se dnevno. V zadnji verziji, ki sem jo pravkar potegnil dol, so novi podatki (en dan nazaj). Poglej pod D_OD ali DV_OD.
Število zapisov pa je 555185.
Hvala, za preverbo!
Sem se s pomočjo tega podatka dokopal do hrošča in ga tudi že odpravil.
V dnevnih obdelavah je v fazi reprojekcije z gk-shp vedno ostal star shapefile direktorij, namesto da bi ga izbrisal https://github.com/openaddresses/openaddresses/pull/3470
Na nemškem WMS strežniku http://wms.openstreetmap.de/ sem se pomočjo GeoCoordinateConverter-ja pripravil rasterska sloja tlorisov hiš (temno modre) in osi cest (svetlo modre), oboje trenutno na dnu seznama.
Za lažjo primerjavo podatkov z obstoječimi OSM podatki pa sem oba sloja vključil v pregledovalnik na http://raba.openstreetmap.si/ (morate ju obkljukati v seznamu slojev desno zgoraj)
Tlorisi hiš pogosto zajemajo tudi podzemne dele, ki segajo izven nadzemnega tlorisa, kar za OSM (as “ON the ground”) niso najbolj zanimivi - npr novejši blokovski kompleksi, ki so v celoti podkleteni z garažami so predstavljeni kot en velik poligon - v teh primerih je potrebno dopolniti in vrisati posamezne bloke kompleksa.
ceste so vrisane zelo grobo, ponekod neskladne z RABA-KGZ datasetom, precej manjših cest v naseljih ni vrisanih v GURS-ovem datasetu
Precej hiš bi lahko uvozili brez konfliktov če se omejimo na področja npr 5m (cca širina ceste) od hiš, ki že obstajajo v OSM, v naslednjih fazah pa bi morali primerjati razlike med GURS in OSM datasetom in jih zmanjševati