[NUUG kart] Vegdata fra kartverket

Karl Ove Hufthammer karl at huftis.org
Wed Aug 13 21:08:13 CEST 2014


ty. den 12. 08. 2014 klokka 22.37 (+0200) skreiv Thor K. H.:
> Med det så ønsker jeg--viten om hvor uerfaren jeg er sammenlignet med
> 99 % på listen--gjerne en pekepinne i akkurat hvorfor alle adresser
> fra matrikkelen skal beholdes som helt egne separate noder. 
> 
> Som en duct-tape-type utvikler så kan jeg se at det er lettvint, øker
> datasammenhengen og gir en mulighet for dataseparasjon som igjen gjør
> det mer lettvint for senere oppdateringer. Likevel, det føles som et
> sørskilt tap av data. Store boligfelt med enkeltboliger har ikke noe
> semantisk grunnlag for å være representert med individuelle noder,
> utenom ev. k:entrance=yes på inngangsdører, som fortsatt ville være
> del av en way. Videre organisasjoner, bedrifter, osv, blir da adskilt
> fra sin adresse - hvordan skal dette semantiske forholdet ivaretas?
> Relations?

Før syntest eg òg at det var fornuftig at adresser var på bygningar, og
har tagga det slik, men har no innsett at dette ikkje er ideelt. Skal
prøva å forklara kort her korfor.

Grunnen er at ein naiv datamodell med adresser rett og slett ikkje
*fungerer* generelt. Han fungerer i nokre (mange) tilfelle, men bryt
saman i andre. Og han gjer ting unødvendig komplisert.

Først, kva er vitsen med adresser generelt? Dei tener to formål:

  1 Dei seier kor noko *er* i verda.
  2 Dei seier kva adresse ein skal setta på post
    ein sender til ein viss person / ei viss verksemd.

Ang. punkt 1: At ein viss butikk er i «Langegata 27» er nyttig om ein
skal til butikken, veit kor Langegata er, og spesielt om ein veit cirka
kor nummer 27 er. Men om ein har den geografiske posisjonen til
butikken, slik ein har med OSM, gjev ikkje adressa noko relevant
*ekstra* informasjon.

Men motsett er det nyttig å veta kva den *geografiske posisjonen* til ei
adresse er. Om ein skal besøka den gamle klassekameraten sin som har
flytta til Breigata 57 (i ein 
viss by), er det nyttig å kunna søka opp «Breigata 57» i bil-GPS-en sin
og la denne føra seg til adressa.

Derfor er det nyttig å legga inn *adresser* og deira posisjon i OSM.

Men koplinga «POI → adresse» + «adresse → posisjon» er unødvendig, sidan
ein alt har «POI → posisjon».

Då står me att med punkt 2: Adresser kan vera nyttig når ein skal senda
post. Viss ein ser vekk frå at ~ingen (?) faktisk ville brukt OSM til å
finna slik informasjon, har me likevel eit problem. addr:*-taggane
taggar *gateadresser*, ikkje *postadresser*. For POI-ar, som er det mest
aktuelle, er det gjerne snakk om bedrifter. Og desse har gjerne
postboks-
adresser (eller i nokre tilfelle: sentrale postmottak ein heilt annan
plass i landet). Her ville altså addr:*-taggane vore direkte misvisande.

Eit sett adressetaggar (addr:*) vil vera nyttig til å koda éin nyttig
informasjonsbit – ei kopling mellom (dvs. frå) ei abstrakte
«gateadresse» og (dvs. til) éin konkret geografisk posisjon (meir eller
mindre presist definert).

Det er derfor fornuftig at ein potensiell datamodell for adresser bør ha
ein éin-til-éin-forhold mellom gateadresser 
og geografiske posisjonar. Fleire identiske adresser med ulike
posisjonar bryt med dette, og skapar berre forvirring (kven av desse 13
eksemplara av «Breigata 57» i denne byen skal du til?).

Når dette er sagt, er det sjølvsagt også *andre* grunnar 
til adresser på POI-ar eller bygningar er problematisk. Éin bygning kan
for eksempel ha fleire adresser. Og éin POI kan også ha det. Og så kan
éi adresse ha fleire bygningar (og sjølvsagt svært mange POI-ar, for
eksempel for butikkar i kjøpesenter).

Alt ovanfor er grunnar til alle adresser bør vera på nodar, og kvar
adresse bør ha nøyaktig éin node.

Så har me grunnane til at adresser bør vera på bygningar:

Hovudgrunnen er vel at ein ut frå eit søk på bygningen kan få opp
informasjon om kva adresse(r) bygningen har. (Eg ser eigentleg ikkje
poenget med dette, men la oss no seia at ein ønskjer dette.) Då ligg alt
dette inne i datamodellen. Alle adressenodane er/vert plasserte *inni*
bygningar. Ein treng altså berre sjå på kva adresse(r) som ligg inni
bygninge. Dette er trivielt for ei datamaskin!

(At for eksempel standard OSM-søkemotor ikkje viser denne informasjonen
er ikkje eit argument for slik unødvendig duplisering av data. Me taggar
som kjent ikkje for «rendereren».)

Merk òg at eg skriv «adresse(r)». Éin bygning kan ha fleire adresser,
slik at adressa for eksempel blir «Skrågata 14A–C». Alt dette kan lesast
direkte ut frå geodata lagra.

Tilsvarande gjeld POI-ar. Viss ein POI-node er i ein bygning (for
eksempel ein butikk i eit kjøpesenter), *ligg* adresseinformasjonen der
alt. Ein treng berre sjå på kva bygning noden er i, og så sjå kva
adressenodar denne bygningen har. (Ev. kan ein berre finna næraste
adresse.) Dette i motsetning til å legga til 203 identiske nodar, éin
til kvar butikk i kjøpesenteret, som vil vera eit helvete å halda
oppdatert og korrekt.

Å ha adresser utelukkande som adressenodar, med eit éin-til-éin forhold
mellom adresser og posisjonar, er 
rett og slett ein veldig fornuftig datamodell, ein 
datamodell som vil *fungera*. Og ein datamodell som vil vera lett å
halda oppdatert til ei kvar tid.

For øvrig minner eg om dette også er nøyaktig den datamodellen Danmark
har valt (dei har også eit sentralt, offisielt adresseregister dei har
importert). Sitat: «Danish community does not approve merging of address
nodes with buildings.»
Om det funkar for danskane, bør det funka for oss også. :)

Hadde eigentleg tenkt å senda til den internasjoanle importlista i dag,
men sidan det kom nokre motforestillingar mot handteringa av adresser,
får me venta litt, og diskutera oss ferdige først. Det beste vil vera om
me kan få konsensus på måten å handtera dette på.

-- 
Karl Ove Hufthammer
http://huftis.org/
Jabber: karl at huftis.org



More information about the kart mailing list