Uvoz GURSovih naslovov / Slovenia address import

Communities Slovenija (Slovenia)
1

Za pokušino sem uvozil nekaj GURSovih hišnih številk v različnih naseljih na 5 različnih področjih:

Natančneje: http://overpass-turbo.eu/s/I8q

Vse changesete sem označil s tagom “#GURS-HS”, zato jih je možno videti tudi na: http://resultmaps.neis-one.org/osm-changesets?comment=GURS-HS

Ostali podatki za pregled in uvoz so pripravljeni po naseljih na https://addr.openstreetmap.si/ (pazite, tabela je responsive, tako da na manjših ekranih pokaže le naj pomembnejše stolpce, na širših pa več podrobnosti in povezav do orodij).
Podatki se tu samodejno osvežijo vsako soboto zjutraj, lahko pa po potrebi povečamo frekvenco.

Prosim, preglejte te spremembe in pripravljene podatke na področjih, ki jih poznate in sporočite svoje mnenje.

Vsa izvorna koda je objavljena na https://github.com/openstreetmap-si/GursAddressesForOSM

Jaz nisem več tako zelo prepričan, da je pametna uporaba addr:place namesto addr:street v krajih brez uličnega sistema, ker:

  • V razpotegnjenih / razpršenih vaseh je itak smiselno poimenovati cesto (čeprav ta v uradnih GURSovih evidencah dejansko nima imena), ker je tako na zemljevidu bolj pregledno tudi ob večjih povečavah
  • naredimo manj sprememb v obstoječih naslovih, ki so smo jih ročno vnesli mapperji
  • Zaenkrat orodja bolj podpirajo street kot place (iD editor bi lahko dopolnili tu)
  • OSM inspector naslove, ki so bolj oddaljeni od točke kraja označi kot place_not_found. Verjetno se podobno zgodi z oddaljenimi ulicami, ampak v tem primeru lahko urednik ustrezno poimenuje bližnjo cesto.
2

Sem preizkusil en testni uvoz: Changeset #69462348 (#GURS-HS import: Rovte).
Sama procedura dela odlično.

Če je območje večje, ostale vsebine v JOSM ni mogoče uvoziti - ali bi potem ročno “odrezali” del uvoza ?

Navaditi se je treba pregledati pozicijo - običajno hišna številka “sede” v stavbo, se pa zgodi, da tudi ne - v tem primeru bi bilo smiselno popraviti pozicijo stavb (največkrat), ali pa spremeniti pozicijo hišne številke. Priporočljivo bi bilo ob tem tudi dodati manjkajoče stavbe, verjetno pa nam to v praksi ne bo šlo.

Glede dileme addr:place namesto addr:street v krajih brez uličnega sistema - mislim, da v tem primeru ne bi bilo prav uporabljati ime ulice, ker v bistvu to ni. Morda pa dobimo kako sugestijo tudi iz OSM import talk foruma.

3

Za pregledovanje takšnih changesetov se mi zelo uporaben zdi http://overpass-api.de/achavi/?changeset=69462348
Za preverjanje pa je zelo koristen OSM inspector, edina slaba stran tega je, da je na analizo potrebno počakati kak dan.

Kaj misliš s tem, da “ni mogoče uvoziti” ? Jaz sem recimo samo naložil podatke v JOSM in jih uploadal v OSM. En uvoz sem za pokušino naredil tudi preko spletnega urejevalnika level0 - http://level0.osmz.ru/
Obstoječij OSM podatkov na področju uvoza nisem nalagal v JOSM, samo rastrsko podlago sem vklopil, da sem še enkrat preveril da je stvar res na približno pravem mestu.

Ročno usklajevanje hišnih številk bi jaz raje ločil od uvoza samega v naknadne korekture, ki bodo itak potrebne zaradi:

  • uskladitve imen krajev (velike/male črke, dvojezičnost)
  • dodajanje manjkajočih imen ulic in krajev
  • zamik hiš,
  • združevanje morebitnih podvojenih naslovov
    …

Toleranco za match z obstoječimi hišnimi številkami sem z nekaj poskušanja nastavil na 30m (max_distance = 30), lahko pa jo korigiramo. Največ odmika so zahtevale večje hiše, kjer včasih tudi če naslov pade v hišo z naslovom je bil vseeno več kot 20m od centra hiše in je ustvarilo novo točko z enakim naslovom kot ga že ima hiša.

Ja, addr:place je bolj pravilen, a vsa orodja ga še ne podpirajo tako kot addr:street. Verjetno bi bilo smiselno pogledati katera orodja imajo težave s tem in najti neko rešitev.

Sem se pogovarjal na #imports kanalu na Slacku (registracija) in pravijo, da bi morali imeti naselja kot poligone+točko v centru vasi, ne le točk, kar pa bi bil spet zajeten projekt. In GURSovi poligoni naselij se raztezajo tudi daleč v neposeljene gozdove, da se za vsako smreko vé k kateremu naselju spada.

Danes sem dopolnil še program, da razširi okrajšave, npr “Moravci v Slov. goricah”, “Pristava pri Polh. Gradcu”… vse preslikave so na voljo za pregled in dopolnitve v mapi:
https://github.com/openstreetmap-si/GursAddressesForOSM/tree/master/overrides
Vrstilnih števnikov (rimskih in arabskih) ne spreminjamo, kakor tudi ne “Sv.” in “Dr.” in inicialk (če GURS piše “A.M. Slomška” to zaenkrat pustimo kot je)
Rezultat te obdelave bo viden jutri.

4

Pri pregledovanju prvega uvoza na področju Črnomlja sem opazil, da se GURSovi naslovi na ulici “Nova loka” ne skladajo z obstoječim (v OSM) imenom ulice “Nova Loka”:

(vir: http://tools.geofabrik.de/osmi/?view=addresses&lon=15.18617&lat=45.56713&zoom=18&overlays=buildings,buildings_with_addresses,postal_code,entrances_deprecated,entrances,no_addr_street,street_not_found,place_not_found,misformatted_housenumber_lenient,nodes_with_addresses_defined,nodes_with_addresses_interpolated,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads,nearest_areas,addrx_on_nonclosed_way))

Ker se mi intuitivno zdi bolj pravilno “Loka” sem preveril in v Uradnem Listu našel ODLOK o kategorizaciji občinskih cest v Občini Črnomelj ki omenja ime “Nova Loka”:

Popravek GURSovih podatkov sem vpisal v UL_UIME.csv in ponovno pognal obdelavo tega naselja.

Na https://addr.openstreetmap.si/Črnomelj/ je pripravilo je novo .osm datoteko za celotni Črnomelj, ki je dejansko vseboval le spremembe naslovov v tej ulici in sem jo uvozil:

Skratka: uvoze je potrebno preverjati in GURSovih podatkov ne jemati kot absolutno resnico. Tudi tam so zmotljivi. Imamo pa lep mehanizem da jih popravljamo in istih napak ne prenašamo še v OSM.

Spremembe imen lahko v .csv datoteke dodajate na github-u (neposredno, če ste član openstreetmap-si organizacije ali preko pull requestov), ali pa predloge sporočite tu in jih bomo vnesli, da se bodo upoštevali ob nadaljnih obdelavah.

5

Opazil sem še en problem:
Za addr:city uporabljamo ime pošte, kar priporoča OSM wiki (vsaj tako si jaz razlagam “The name of the city as given in postal addresses of the building/area.”).

Težava pa nastane v Občini Lendava, kjer “Glavna ulica” obstaja v naseljih:

V OSM trenutni naslovi na tem področju v polju addr:city vsebujejo imena naselij.

S spremembo, ki jo trenutno predlaga naša priprava podatkov, pa bi se vsi addr:city spremenili v “Lendava - Lendva”, kar bi lahko pripeljalo do še večje zmešnjave.

Iskanje “Glavna ulica 4, Lendava” že daje nepredvidljive rezultate (naslov najbližji trenutnemu pogledu uporabnika?).

https://addr.openstreetmap.si/Lendava/

Lahko bi namesto naziva pošte uporabili imena naselij, vendar Priročnik za pravilno naslavljanje poštnih številk izrecno zahteva: poštna številka in naziv naslovne pošte.

Imate kak predlog, kako to zagato rešiti čim bolje, za velika in mala naselja, z ulicami in brez?

6

Za take primere moramo v tage uvesti še podatek o naselju. V tejle app se ti naslovi prikažejo pravilno: https://prostor3.gov.si/javni/login.jsp?jezik=sl
(iščeš Glavna ulica 4) in dobiš več rezultatov, ki so v različnih naseljih, vsi pa v občini Lendava.

7

Ja, ime naselja bi lahko vpisali bodisi v addr:place (sem sedaj že vpisujemo ime krajev kjer ni sistema ulic) ali addr:city (kamor sedaj vpisujemo naziv pošte).

Ne vem pa zakaj bi stvar naredili selektivno, le tam kjer je to res potrebno, ker bi v tem primeru bila zmešnjava zaradi nedoslednosti še večja.

Najbolj logično bi se mi zdelo:

  • addr:street ime ulice, tam kjer obstajajo
  • addr:place ime naselja
  • addr:city naziv pošte

V tem primeru bi v mnogih primerih imeli redundantne tage. Mogoče bi se tej redundanci izognili tako, da ne bi dodajali tagov addr:place, če se isto ime kraja že pojavlja v nazivu pošte (addr:city).

Ali

  • addr:street ime ulice, tam kjer obstajajo, sicer ime naselja v addr:place
  • addr:city ime naselja
    Argumentacija za tem bi bila, da je pošta že točno definirana v addr:postcode in uporaba naziva ne doda nobene vrednosti. Različnih imen naselij je več kot nazivov pošt. Ni pa v tem primeru garancije, da ne bi do zmešnjave prišlo zaradi podvojenih imen naselij IN ulic, kar bi bilo pogosto tam, kjer ni sistema ulic.
    https://sl.wikipedia.org/wiki/Naselje_v_Sloveniji#Najpogostej%C5%A1a_imena

Btw, z današnjo obdelavo ima GURS točno okroglih 560000 naslovov :wink:
https://addr.openstreetmap.si/

8

Vsi naslovi Glavna ulica 4 v Sloveniji kot so trenutno v OSM imajo različne addr:city tage, ker imajo tam vpisano ime naselja in ne naziva pošte:

vir: http://overpass-turbo.eu/s/IjN

Me prav zanima kako tam poštarji dostavljajo pravilno naslovljene pošiljke (brez imena naselja v naslovu, zgolj enak naziv pošte) :slight_smile: Poznajo vse prebivalce po imenih?

9

Odlično delo , Štefan in ostali!

Uporaba vasi Bela mogoče ni odličen primer, ker je grozen odmik satelitske slike, ker je vas v Rovtah in sam hudournik je težko določit na kateri strani ceste je na kakšnem delu. Nekdo je vrisal cesto kjer je hudournik, sem popraviil, da za bolj natančno moram na teren, že dolgo nisem bil tam. :slight_smile: V takih primerih bodo hišne številke hitro “ven iz stavbe”.

Kot je že v enem postu podobno omenjeno, je v vasi Slap, iz kjer prihajam, primer novogradnje, ki je katastersko v vasi Slap, a je geografsko bližje vasi Planina. Slap 100, na SZ delu: http://geojson.io/#map=15/45.8424/13.9257
Slap seveda nima ulic.

Pogosto imam občutek, da GURSovim obrisom hiš ne gre popolnoma zaupati, bolj zanesljiva mi deluje kombinacija GPS sledi in na to sled poravnana satelitska slika. GURSove ceste pa še toliko manj.

Če je ime kraja enak imenu pošte, se bo to ime podvojilo. Menim, da je prav tako.
Vprašanje je le uporabe ulice (addr:street ), če tega ni. Kot je pogosto v vaseh.

10

Pri dvojezičnih imenih, dejmo prosim striktno uporabljat ločilo “/”. https://wiki.openstreetmap.org/wiki/Multilingual_names#Slovenia

addr:city naj bo striktno ime pošte,
za mesta (LJ) lahko uporabimo is_in:city=* in addr:city za pošto po posameznem delu mesta.

Glede Glavne ulice 4 (post #39) je jasno, da manjka addr:place v navedenem naslovu za pošiljko - tako dobimo unikaten naslov.

11

Iz OSM wiki-ja: addr:place=* should not be used together with addr:street=*.

12

Že nekaj časa sem imel namen urediti tudi dvojezične nazive pošt, a šele Mitja me je s svojim popravkom wiki strani na to spet spomnil, tako da sem to brž uredil z istim mehanizmom preimenovanja v PO_UIME.csv datoteki.

Rezultat je že viden v Ankaranu, Portorožu, Sečovljah in Padni:
https://addr.openstreetmap.si/Ankaran/
https://addr.openstreetmap.si/Piran/
na drugih dvojezičnih področjih pa bo videti jutri zjutraj.

13

Ne bi rad, da zaidemo offtopic, imam le slovnično vprašanje, pri dvojezičnosti. Sicer pa split s posta v temo.
Na tablah na cesti (fotka na wikipediji) je brez presledkov ob ločilu “/”, mi pa uporabljamo s presledki.
Jasno je, da presledki ob pomišljaju , če je al ni spojeno, spremenijo slovnično vrednost. Kako pa je ob ločilu “/”? Je to že bilo debatirano?
Al delamo ‘kompromise’ glede na prostor?

14

Predlagam, da debato o dvojezičnosti preselimo na sosednjo, ločeno temo Dvojezična območja, ker to ni specifično za GURSove podatke.

15

Zaradi preglednosti sem forum admine prosil, da so dosedanjo debato (zgornjih 14 postov) o uvozu GURSovih naslovov preselili iz teme brezplačni podatki GURS - Imamo soglasje! v to novo, ločeno temo.

Tam naj še naprej teče splošna debata o GURSovih podatkih, tu pa specifična o projektu uvoza naslovov.

16

Se moram dopolniti, ta priročnik Pošte v nadaljevanju namreč za takšne primere določa:

Ta informacija bi lahko bila razvidna bodisi iz

17

Vsekakor dodamo tag (mislim, da naselij ne rabimo dodajati kot geometrije, ker bomo imeli samo dodatno zmešnjavo) … čeprav, a nismo tak tag glede na naš wiki že predvideli (addr:place … opis: “No street name, but place name tags instead”)?

18

To je ena od opcij za zagotoviti bolj natančno lokacijsko hierarhijo
Če sedaj poiščeš “Glavna ulica 4” bo nominatim za prikaz rezultatov uporabil tudi poligone in izpisal:

V tem zadetku so statistična regija, občina in država poligoni. Nič ne bi bilo narobe, če bi se med ulico in občino izpisalo še naselje. Iz geometrije bi nominatim to verjetno znal razbrati, iz nekega ad-hoc taga pa verjetno ne. V tem zadetku se že vsebina zelo znanega taga addr:city sploh ne izpiše.

Od vseh podobnih naslovov izpiše samo enega (najbližjega?), ker so po hierarhiji vsi naslovi enaki (vsi v isti občini). Če bi vmes vpeljali še geometrije na nivoju naselij bi (domnevam) bili naslovi različni in bi izpisalo vse:

addr:place naj bi se uporabljal za ime naselja v krajih, kjer ni uličnega sisema, kar je pogosto v vaseh. To že počnemo tudi v našem uvozu. Dokaj logično bi bilo, da bi vsem naslovom (ne glede na to, ali so vezani na ulico ali ne) v tag addr:place vpisali ime naselja, vendar wiki to izrecno prepoveduje:

19

Glede potencialnega uvoza poligonov naselij
S poizvedbo v overpass-u (http://overpass-turbo.eu/s/Lht) sem opazil, da že imamo nekaj področij pod nivoji občin

v Mariboru:

Naselja na Krasu, vsa admin_level=10:
https://www.openstreetmap.org/relation/8005603
https://www.openstreetmap.org/relation/8005604
https://www.openstreetmap.org/relation/8005605
https://www.openstreetmap.org/relation/8005613
https://www.openstreetmap.org/relation/3727934
https://www.openstreetmap.org/relation/3727935

Glede oznak pa bi lahko (poleg običajnih) prav prišla place=civil_parish
(nedavno sem vsem občinam dodal place=municipality in iskalniki to informacijo lepo uporabijo)

20

Malo sem spet pogledal dosedanje testne uvoze in opazil, da je Osmose povsem zadovoljen z npr Rovtami, ki jih je uvozil coloredstone:
http://osmose.openstreetmap.fr/en/map/#zoom=14&lat=45.9847&lon=14.17725&item=xxxx&level=1%2C2%2C3&tags=addr&fixable=

V tem istem naselju Geofabrikov OSM inspector najde “napake” le pri hišnih številkah, ki so bolj oddaljene od točke naselja:
http://tools.geofabrik.de/osmi/?view=addresses&lon=14.17716&lat=45.98714&zoom=15&overlays=buildings,buildings_with_addresses,postal_code,entrances_deprecated,entrances,no_addr_street,street_not_found,place_not_found,misformatted_housenumber_lenient,nodes_with_addresses_defined,nodes_with_addresses_interpolated,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads,nearest_areas,addrx_on_nonclosed_way

Osmose tudi najde napake, kjer naslovi ne izvirajo iz teh GURSovih podatkov, pripravljenih za uvoz, ampak so napačno vpisani v addr:street tage, namesto v addr:place tage:
http://osmose.openstreetmap.fr/en/map/#zoom=16&lat=46.08833&lon=14.25767&item=xxxx&level=1%2C2%2C3&tags=addr&fixable=

Uvoz bi to popravil: http://geojson.io/#data=data:text/x-url,https://addr.openstreetmap.si/Dobrova-Polhov_Gradec/%C4%8Crni_Vrh-housenumbers-preview.geojson&map=16/46.0887/14.2575
Konkretno podružnica osnovne šole:

OSM: https://www.openstreetmap.org/way/611984897
Tudi http://www.ospg.si/kontaktni-podatki/ pravi: Črni Vrh 34, 1355 Polhov Gradec

To mi potrjuje, da imamo prav, da naslove v teh vaseh brez uličnega sistema dajemo v tage addr:place in ne v addr:street.

Opcijsko bi lahko poskrbeli še, da bi urejevalniki omogočali vpis naslovov tudi v addr:place, npr spletni IDeditor tu: https://github.com/openstreetmap/iD/blob/6ce2c5ea46b6bb89f8a3a3dd9d5794a920bbf610/data/address-formats.json#L34
iz

    {
      "countryCodes": ["at", "ch", "de", "si", "pl"],
      "format": [
        ["street", "housenumber"],
        ["postcode", "city"]
      ]
    },

v

    {
      "countryCodes": ["at", "ch", "de", "si", "pl"],
      "format": [
        ["place", "street", "housenumber"],
        ["postcode", "city"]
      ]
    },

Bodisi za vse te sosednje države ali pa naredimo to le za Slovenijo.

Podobno recimo že ima Tajvan:


    {
      "countryCodes": ["tw"],
      "format": [
        ["postcode", "city", "district"],
        ["place", "street"],
        ["housenumber", "floor", "unit"]
      ]
    },

Kaj o tem menite vi?
Varianta je tudi, da urejevalnikom predlagamo, da urejevalniku v enem skupnem spustnem seznamu predlaga tako imena bližnjih cest IN naselij, in potem vrednost vpiše v ustrezen tag.