[NUUG kart] SSR Sentralt Stedsnavnregister import

Andreas Bertheussen andreas at elektronisk.org
Sat Jul 25 21:52:59 CEST 2015


Hei dere!

Jeg er ny til denne listen. Jeg har forsøkt å sette meg inn i hva som 
har blitt gjort, og hva som er status på SSR-import. Det er jo et svært 
datasett som bare venter på å bli importert, men fremdriften har dabbet 
litt av ut fra det jeg finner på nett.

Eposten min har jeg delt i tre; først nevner jeg resurssene jeg har 
funnet, tidligere arbeid. Deretter foreslår jeg et utgangspunkt for 
"destillering" av datasettet slik at vi kan begynne å matche/merge. Til 
slutt nevner jeg ting jeg ikke har undersøkt i dybden, men som bør avklares.

### 1. Min oppfatning av status.

Jeg har funnet en relevant diskusjon fra tidligere på denne lista ( 
http://www.mail-archive.com/kart%40nuug.no/msg00959.html ), og en på OSM 
import-lista ( 
http://thread.gmane.org/gmane.comp.gis.openstreetmap.imports/1698/ ).

https://wiki.openstreetmap.org/wiki/Import/Catalogue/Central_place_name_register_import_(Norway) 
er tydeligvis der viktige avgjørelser rundt import bør begrunnes og 
dokumenteres. På denne siden har jeg oppdatert litt om GeoJSON-formatet.

Av verktøy har jeg funnet:
  * ssr av Thomas Hirsch (relet): https://github.com/relet/ssr
Denne tar geojson-fila, og hvis forekomst og navneenhet bruker identisk 
navn, så søker den via OSM XAPI for å forsøke å finne matchende 
node/way/polygon feature i OSM. Programmet kjøres i konsoll og ber 
bruker hjelpe til med matching og evt velge å opprette stubb-features.

  *  ssr2osm av Karl Ove Hufthammer (huftis): 
https://github.com/huftis/ssr2osm
Denne tar geojson-fila og spytter ut en CSV-fil for en kommune.  Den 
gjør også en del grep for å redusere datasettet. CSV-fila kan åpnes som 
et lag i JOSM for videre merging.

(Har jeg oversett noen vesentlige kilder eller diskusjoner?)

### 2. Mine tanker og forslag rundt importen:

Det jeg observerer er at ssr starter på utfordringen å matche og merge, 
imens ssr2osm starter med å "destillere" datasettet, slik at matching 
kan gjøres etterpå (i et annet program).

Både merging og destillering er nødvendig, men jeg synes det er viktig å 
diskutere hvordan hver av dem skal gjøres - hvordan "dataflyten" bør 
være fra kartverket til OSM-noder. For å unngå skrot i OSM, så tror jeg 
det vil være lurt å destillere datasettet først for å finne de data som 
er enklest/raskest/tryggest å importere slik at man kan starte med det.

Som jeg har beskrevet på wiki, og som gjort i ssr2osm, så foreslår jeg å 
først kaste bort alle skrivemåter der status verken er Vedtatt, 
Godkjent, Samlevedtatt eller Privat 
(http://kartverket.no/kart/stedsnavn/sentralt-stadnamnregister-ssr/saksbehandlingsstatus-for-skrivematen/). 
Dette luker ut ca 100k navn.

Deretter kan man kaste bort skrivemåter med datofelt skr_sndato som har 
en dato /etter/ datasettet ble hentet (ugyldige). Bør sikkert meldes til 
statkart.

Så kan en trekke ut skrivemåtene der objekt og skrivemåte har et 1:1 
forhold. Dvs alle skrivemåter med unik objekt id (enh_ssrobj_id) og unik 
navneenhet id (enh_ssr_id). For disse skrivemåtene kan man i første 
omgang hoppe over vurderinger som:
  - hvilken skrivemåte skal brukes for en navneenhet (enh_ssr_id) med 
flere skrivemåter? Eks 
http://faktaark.statkart.no/SSRFakta/faktaarkfraobjektid?enhet=81473
  - hvilken navneenheter skal brukes for et gitt objekt? 
(http://faktaark.statkart.no/SSRFakta/faktaarkfraobjektid?enhet=755532 
her er det ett objekt, to navneenheter)

Man sitter altså igjen med to sett, [1:1 (det enkleste)], og [1:fler 
(det mer vanskelige)]. Det enkleste, 1:1-settet, kan man splitte opp i 
fylker/kommuner og fjerne irrelevante feld fra for så å begynne å matche 
og merge. For dette datasettet tror jeg det er lurt å beholde feltene 
enh_navntype og nty_gruppenr fra det opprinnelige datasettet. På den 
måten slipper man å oppdatere datasettet dersom man finner feil eller 
regler for OSM-tagging endres, og omgjøringen til OSM-tags skjer i det 
aller siste leddet (matching/merging).

Man kan kan enten matche via API som ssr-programmet, eller ved å 
konverteres til .osm eller .csv for å matche og merge i JOSM. (Personlig 
synes jeg det er kjekt å ha et GUI som JOSM.).

### 3. Uavklarte/uspesifiserte ting
- Håndtering av flere språk for samme objekt.
- Håndtering av flere objekter på samme koordinat.
- Bruk av  "no-kartverket-ssr:date". For å være nyttig, må den vel være 
den siste av alle skr_sndato (skrivemåtenes statusdato) som angår 
objektid'en, uavhengig av hvilken skrivemåte som er brukt?
- Valg av OSM-tags. ssr og osm2ssr bruker hver sine tabeller; 
https://github.com/huftis/ssr2osm/blob/master/data/objekttypar.csv og 
https://github.com/relet/ssr/blob/master/scripts/manual.py#L48-L225 
Dette er vel ryddigst å starte med på wiki. Enig?

Det ble en lang epost :)
Håper noen andre (fortsatt) har interessen for dette. Jeg setter pris på 
tilbakemeldinger.

Mvh
Andreas.
Kongsberg.


More information about the kart mailing list