[NUUG kart] Import av Elveg-data: Veien videre

[Sandor Seres]

Fra en brukerssynspunkt:

>> 

>> Det er to ting vi må bestemme oss for - nvdb:id og sammenslåing av veier. Har i tillegg to ting til jeg ønsker å nevne/spørre om.

>> 

-For en Planet map-maker (spesielt, vektor map-maker) nasjonal spesifik info/tagger som nvdb:id eksisterer ikke dersom den har ikke tisvarende OSM tag. Den blir garantert ignorert og forblir i OSM som redundanse. Når en map-maker fra Kanada, Sør-Afrika, Australie, Norge ... trekker ut data fra OSM kildedata han vet bare om OSM taggene. Så, etter min mening, nvdb:id er unødvendig i OSM.

-Om sammenslåoing av veier meningene kan variere. I førige OSM-wiki versjoner anbefalingen var at en vei-/gate-segment/poly-linje går mellom to kryss/node hvor det er flere alternativer for forsettelse (begrenset med antall av interne punter/noder, eventuelt, vei-parametre). I ny versjon man finner ikke noe eksplisitt om dette. Min anbefaling er at mappere (ved opplasting) slår ikke sammen veier. Argumenter:

Å slå sammen tilfeldige veier over en kryss med alternativer (som noen anbefalte/gjorde) er direkte fei dog ikke «show-stopper».

Å slå sammen veier med lineer forbindelser (ende-node av orden en) kan bli farlig. For eksempel 3 segmenter med navner E18, Oslo vei, E18.

Navigasjonssytemer skal uansett dele opp veier og rundkjøringer i polylinjer mellom kryssene selv am alternative veier er ikke i samme klasse. Dette er nødvendig for generering av «rootable network» geometri. Forresten, det nevnte eksempelet hvor et navigasjonssytem instruerte kjøreren å fortsette på hovedveien gjennom en kryss med en lokal (mindre) vei var absolutt korrekt. 

Selvsagt, man gjør sammenslåing av veisegmenter/poly-linjer men dette skjer på brukersside (er server applikasjpn). Sammenslåeingen er nødvendig i data-generalisering mens man lager vektor «scale-levels» (ikke det samme som raster «zoom-levels»). Men disse (heuristiske) algoritmer er komplekse og kompliserte baserte på parametre som kurvatur, samme-navn, «no-name», «forced no-name», osv.

Men, som sagt, meningene kan variere. Mvh. Sandor

 

From: kart-bounces at nuug.no [mailto:kart-bounces at nuug.no] On Behalf Of Christer van der Meeren
Sent: 09 June 2015 13:44
To: NUUGs kartliste
Subject: [NUUG kart] Import av Elveg-data: Veien videre

 

Okei, det ble litt mange "grener på treet" nå. Samler trådene på det jeg opplever vi ikke har bestemt ennå.

Det er to ting vi må bestemme oss for - nvdb:id og sammenslåing av veier. Har i tillegg to ting til jeg ønsker å nevne/spørre om.

 

 

Fjerning av nvdb:id:

Argumenter for:

*	Det er påkrevd dersom veier skal slås sammen (se neste avsnitt)
*	Trengs ikke for å ta inn endringer i fremtidige Elveg-data, da vi kan gjøre dette ved å sammenligne nye og gamle versjoner av Elveg-data direkte

Argumenter mot:

*	Vi har kobling til kildedata for veier som kopieres inn (personlig er jeg usikker nytteverdien av å ha kobling til kildedata kun på veier som kopieres inn, siden dette vil være langt fra alle veier - mye av veinettet i Norge finnes jo allerede i OSM - men dette kan være min uvitenhet som taler)


Sammenslåing av veier:

Argumenter for:

*	Det ser ut til å være gjeldende praksis at én og samme vei så langt det er mulig er én "way" i OSM
*	Enklere å endre på veier i OSM i etterkant, navn/fartsgrense/etc. endres på én way i stedet for 20
*	Det kan gjøres automatisk med bedre resultater enn ved skjønn

Argumenter mot:

*	Om det skal gjøres automatisk, må skriptet må skrives
*	Umulig om nvdb:id skal beholdes

Spørsmål fra min side: Geir Ove, du sier det kan bli en stor jobb å skrive skriptet. Men er det ikke bare å gå gjennom veiene med samme VNR og parsellnummer (og alle andre tags), finne noder med identiske koordinater og slå sammen på disse? Du får tilgi meg min uvitenhet hvis ikke, jeg kjenner ikke til strukturen til dataene. Minner for øvrig om Torsteins waySimplifyer.py <https://github.com/tibnor/kartverket2osm/blob/master/waySimplifyer.py>  om den kan være til hjelp.

 

Replace geometry vs. improve way accuracy:

*	Er det i praksis greit å bruke "replace geometry" det der man kan, så lenge man vet hva man gjør? De to grunnene som er oppgitt på wikien nå sier i praksis at "det er mer å huske på" og "det virker ikke for alle veier", som på ingen måte er blytunge argumenter for aldri å bruke verktøyet. Spør fordi det er et veldig kraftig og effektivt verktøy der det kan brukes, om enn "farlig".

 

Wikisiden (til orientering):

*	Har lagt til en ekstra kolonne i progresjonstabellen slik at man kan oppgi hvilke områder som er unnagjort (kan være greit for større kommuner).
*	Har nevnt på importsiden at om flere ønsker å samarbeide om samme kommune, så kan det kanskje ordnes vha. git eller lignende (dersom man sletter veier fra Elveg når man er ferdig og da jobber med samme versjonshåndterte fil). Manuell samkjøring er naturligvis også et krav. Tror ikke dette vil bli aktuelt, men kanskje greit å nevne. Kan fjerne det om det er hull i hodet.
*	Har lagt til en "do's and don'ts" i workflow-biten.
*	Har lagt til en tom "Q&A"-seksjon som jeg regner med vi kan fylle ut etterhvert som arbeidet skrider fram og vi (i alle fall jeg) sitter med et lass med spørsmål om "best practices" osv. (Når blir et fortau en gangveg? Skal gangveger kobles på bilveger om de slutter i en busslomme, når busstopp legges ved siden av vegen? Og andre detaljrike spørsmål som sikkert bare jeg har.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nuug.no/pipermail/kart/attachments/20150610/80710460/attachment-0001.htm