Pozdrav,
Zanima me kako je kaj z uvozom sloja GJI ceste v OSM? Klasifikacija cest je malce drugačna…
Lp
Grega
Dalo bi se.
En testni primer “prevajanja” vsebine GJI v JOSM je tule: https://qgiscloud.com/coloredstone/qgis_highway_upload_1/mobile
Zaradi omejitve količine so vključene le “glavne” ceste.
Prevajalni šifrant je takle (neverificirano!):
ATR1 ATR1_opis highway
1 Avtocesta motorway
2 Hitra cesta trunk
3 Glavna cesta I.reda primary
4 Glavna cesta II.reda primary
5 Regionalna cesta I.reda primary
6 Regionalna cesta II.reda primary
7 Regionalna cesta III.reda secondary
8 Turisti?na cesta unclasified
9 Lokalna cesta residential
10 Javna pot unclasified
11 Glavna mestna cesta tertiary
12 Zbirna mestna ali krajevna cesta tertiary
13 Mestna ali krajevna cesta residential
14 Daljinska kolesarska pot cycleway
15 Glavna kolesarska pot cycleway
16 Javna pot za kolesarjenje cycleway
17 Gozdna cesta track
18 Nekategorizirana cesta unclasified
…
Pred uvozom pa bi morali še kaj razčistiti, predvsem kako uskladiti že obstoječo vsebino, ker je v OSM že večina cest vrisanih in kakega velikega avtomatizma ne bo dobro izvajati. Morda bi bilo smiselno pripraviti samo en WMS sloj kot ozadje.
Smo se o tem že pogovarjali in je na dnevnem redu: https://lists.openstreetmap.org/pipermail/talk-si/2017-April/000343.html
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.
Trenutno je v teku priprava uvoza hišnih številk v Novi Zelandiji, iz katere se lahko česa naučimo.
Debata na dopisnem seznamu (imports@…): https://lists.openstreetmap.org/pipermail/imports/2017-June/thread.html
Dokumentacija uvoza na wikiju: https://wiki.openstreetmap.org/wiki/LINZ/Address_Import
Zanimivo je, da je bilo v tem primeru potrebno dodatno soglasje poleg CC-BY dovoljenja, ki nedvoumno definira zadovoljiv način navajanja vira, konkretno: https://wiki.openstreetmap.org/wiki/File:OSM_waiver_-_LINZ.pdf
Več o uporabi/uvozu podatkov z licenco CC-BY v OpenStreetMap: https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
Pripravil sem osnutek dokumentacije za uvoz naslovov:
https://wiki.openstreetmap.org/wiki/Slovenia_Address_Import
Pripombe, komentarji, dopolnitve dobrodošle.
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.
Tole tabelo bi bilo dobro uskladiti z wiki stranjo: https://wiki.openstreetmap.org/wiki/Sl:Map_Features
LP, Peter
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.
Primera orodij sta https://wiki.openstreetmap.org/wiki/Osmsync in https://wiki.openstreetmap.org/wiki/OSM_Conflator
Princip pa je lepo opisan na https://github.com/openaddresses/dedupe
Vse v grobem temelji na postopku:
- 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).
LP, Peter
Kot kaže res prihaja do manjšega zamika - StefanB: a se je procedura kaj spremenila?
Ne, ničesar nisem spreminjal.
Je pa zelo možno, da do odstopanj pride zaradi nedavne korekcije podatkov zaradi zamika tektonskih plošč:
https://blog.openstreetmap.org/2017/03/31/osm-plate-tectonics/
Eh, če se je pa to zgodilo … prva misel: “čisto mimo”. Tako se pa ne pristopa. Spremembe objektov brez sledi ?
Čeprav … prvega aprila pa to seveda gre.
Če mi poveste kje je primer tega lahko pogledam.
Me pa zanima predvsem datum (source:date) izreza na robu katerega se pojavljajo neskladja s trenutnimi (2017-05-31) podatki.
Npr. pravokotnik št. 1297 (http://raba.openstreetmap.si/#14/46.1463/14.1756). Do neskladij prihaja tudi med pravokotniki z istim datumom (trenutno 2017-05-31).
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.
Morda kdo ve kako pogosto se osvežujejo ti podatki?
Hišnih številk že skoraj 4 mesece ni bilo dodanih nobenih novih.
http://results.openaddresses.io/sources/si/countrywide
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.