[NUUG kart] Gjentagelser i OSM kildedata

[Sandor Seres]

Noen uker siden foregikk det en diskusjon på en OSM global forum om det finnes 
noen kart som viser kildedata uten korreksjoner. Emnet er essensielt for 
kartografer for å oppdage feil i deres egne eller andres oppdateringer. 
Dessverre, det finnes ikke slike kart i dag og dermed store mengder av feil 
bare akkumuleres. Norge er heller ikke immun mot en slik infeksjon. Det finnes 
store mengder av logiske feil i kildedata som er vanskelig å se i dagens 
offentlige OSM kart.

De fleste av de nevnte kart bruker inngangs data fra osm2pgsql forberedelses 
prosedyre og tilsvarende database. Innen denne prosessen «inspektører» oppdager 
og reparerer/ignorerer for det meste bare formelle feil (systemkrasj feilene) 
og dermed er det igjen enorme mengder av logiske feil. Med forbehold av at en 
«feil» er avhengig av hva man mener med korrekt/riktig, mange kartvisere (for 
eksepel raster bilede baserte) kan leve med slike anomalier. Samtidig, moderne 
vektor baserte GIS systemer og digital kartografi kan ikke tolerere dem. La meg 
illustrere en slik klasse feil, nemlig, data gjentagelse (eller data replikka) 
feil i innsjøer fra Sør-Norge.

I bildet fra lenken https://goo.gl/Uz9BRV  viser en distribusjon av innsjø 
gjentagelser i Sør-Norge (og det er mange av dem). Farger i markører 
representerer forskjellige gjentagelses/replikka klasser som eksakt, korridor, 
redundant… osv. Til eksempel, vi sier at en polygon P1 er en korridor replikka 
av en annen P2 dersom alle punkter av P1 ligger i en korridor/belte langs P2. 
Bredden av korridoren er parameter og en slik gjentagelse ansees som unaturlig. 
Lenken https://goo.gl/hDf8i3 viser en utsnitt fra den forrige distribusjonen 
men med selve innsjøen og tilsvarende øyer/huller. Cyan marker er brukt for 
korridor og magenta for eksakt replikka. Bildet i lenken https://goo.gl/5Aa8Ta 
viser en detalj fra innsjøens utterste (outer) grense og man kan se den 
korridor type overlappen. Samme type detalj ser vi her https://goo.gl/8w4ESR 
men fra innerste/hull gjentagelsen. Bildet i den siste lenken her 
https://goo.gl/FPkdpJ viser en typisk eksakt gjentagelse. Husk at det finnes 
mengder av kombinasjons gjentagelser og mange med forskjellige hull strukturer 
(overskrivelser, kjent som “missing islands”). Ved siden av data redundans, 
gjentagelser krever ekstra prosessering og aller viktigst, er flaskehals i data 
generalisering.

En robust dataforberedelses prosedure (data preparation tool chain) skulle 
oppdage og reparere slike gjentagelses/replikka feilene.

Sandor


Sent from Mail for Windows 10

___
kart mailing list
kart@nuug.no
https://lists.nuug.no/mailman/listinfo/kart

[NUUG kart] Broken multipolygons - igjen

[Sandor Seres]

Noen dager siden vi har snakket om farlige konsekvenser av «broken poligons»
planlagt utelatelse i osm2pgsql.

Der vi har snakket om en model av «data preparation» som er lite (om i det
hele tatt)  avhengig av en slik aksjon.

Vi har også understrekte at broken multipolygons er bare en liten fraksjon
av flere, mye mer alvorlige, anomalier som

inter objekt klasse problemer hvor en klasse overskriver en andre, ofte slik
at vi engang ikke vet om det.

Kort modelbeskrivelse og illustrasjoner (tydelig) var ikke nokk til flere
medlemer og de har uttrukt ønske om filer

som kan brukes (og vi har brukt) for den nevnte topologi subtraksjon av
arealer.

Derfor, vi har lastet opp de nødvendige forests, lakes og rivers filene for
Skandinavia (mere presist, kontinental Norges

«bounding box») i shp format. Videre, vi har også lastet opp forests_NEW
resultatfilen av subtraksjons prosedure som 

var beskrevet. Intereserte kan nedlaste disse og bruke som de ønsker men ved
full respekt av OSM lisenserings regler. 

Lenken er

https://drive.google.com/file/d/0B6qGm3k2qWHqc2ltUy1VSExvTTA/view?usp=sharin
g

og all geometri er i den mest vanlige projeksjon og datum (Mercator sferisk,
WGS84). For analyse, vis alle filene samtidig 

i noen populær shp viser. Legg merke til at når du viser forests_NEW
samtidig med lakes og rivers, du for samme bilde 

uansett rekkefølgen av disse lagene i kontrast med det samme bare med
forests_IN (input data for proseduren).

Mens vi er på linje, vi vil gjerne understreke en gang til alvåret med
situasjonen. La os ta at skogsområde i Norge 

presentert i OSM startsides kart her  
http://osm.org/go/0Tt1PZIt- . Vi ser med en gang at noe er galt fordi
skogstype

symboler er på vann istedenfor skog/grønn. I en annen versjon fe. her
 http://osm.org/go/0Tt1PZIt-?layers=T

vi finner typiske øy/land relaterte navn, igjen, på vann. Og selvsagt, skogs
areal hadde et hull av omtrent samme størrelse

som insjøen i midten men i det hullet var det flere/mange skogs felter også.
Så, på grunn av renderings rekkefølgen

(mindre over større) ale de skogs feltene i hullet ble overskrevet
(forsvunnet). Og det finnes mange omvente esempler

også. Bare i den lille utsnittet fra lenken er det over 40 «missing islans
and forests». Desverre, slik er det med andre OSM

baserte kart også fordi (nesten) alle bruker osm2pgsql.  Samtidig vi ser at
OSM kildedata har potensial for mye mer presis

og korrekt datakvalitet som trengs i enhver modern GIS og digital
kartografi. Bare gå til samme sted med rivers_IN,

lakes_IN og forests_NEW og du vils se en riktig presentasjon uansett
visnings (Z) rekkefølge.

Mvh. Sandor og Henrik

 

 

 

 

___
kart mailing list
kart@nuug.no
https://lists.nuug.no/mailman/listinfo/kart

Re: [NUUG kart] ref [OSM-talk] Fixing broken multipolygons

[Sandor Seres]

Ja, det blir en ganske stort bakover skritt for alle "map-makere" som bruker
osm2pgsql. "Hvite områder/flekker" er (veldig) merkbare for større
objekttyper og som rendres med god kontrast (fe. som skoger, dog noen steder
dette er bare mngel av kildedata). Men, hvite flekker blir for alle areal
objekttyper (elver, innsjøer, farmer...) i alle OSM kart som bruker
osm2pgsql (og det er de fleste). Ignorering av "broken multypolygon
relations" (om vi vet hva egentlig dette betyr) og venting på manuell/editor
("do-ocracy") basert reparasjoner, som er foreslott i de refererte lenkene,
vil ha store og farlige konsekvenser. Og dette gjelder spesielt OSM baserte
GIS systemer og modern vektor-datalag baserte digital kartografi. Der vi
viser individuelle lag (fe. bare skoger), bare noen få lag, endrer lagenes Z
rekkefølge i virkårlig måte, gjør vilkårlig og kontinuerlig skalerin,
rotasjon, tilting, 3D simulering, skygging, navigasjon, statistiske
analyser, kvantitave estimater ... osv. Og, aller verste er at problemene er
mye, mye større, mer alvårlige og kompliderte enn bare "broken
multypolygons". Heldigvis, det finnes en helt annen QA model hvor vi kan unngå
de fleste anomaliene som preger osm2pgsql og hvor vi kan forberede OSM input
data ner den teoretisk mylige kvaliteten. Denne modellen er basert på OSM
kildedata. Om dette har vi snakket flere ganger og la oss illustrer på nytt
nettopp på OSM skog areal objekter.
I forberedelse vi kan behandle individuelle skogtyper eller smelte/merge
sammen flere typer. La oss merge sammen alle skogstyper i en arealtype - skog
(det er den du ser i OSM kart). Dette skjer ved data/geometry ekstraksjon
fra OSM kildedata (OSM dump) og skog relatarte tagger. Denne ekstraksonen
gir oss en stor (kolossal) sett av polilinjer. Så gjør vi trivielle 
korreksjoner 
(som de inspektorene gjør fra lenkene) og mere avanserte som lineære og 
brudd sammenkoblinger, corridor replika filtrering/elimineringer, lukking og 
partiell lukking av opne polygoner osv. som slutter med defragmentering. 
Det finnes ingen relasjons forutsetninger på input siden i det hele tatt. 
Polilinjer og polygoner kan ha vilkorlige gjensidige relasjoner. Sluttresultat 
er et sett av enkle/primitive (skogs) arealer (en og bare en container/outer og 
null eller vilkårlig antall hull polygoner). Disse er topologisk disjunktive og 
kan 
bli kjempe store (med over 60-70 tusen hull). For illustrasjon se på bilde 
Forests_ON_LakesPlusRivers here
https://drive.google.com/file/d/0B6qGm3k2qWHqSkstbDBHTTc0Nlk/view?usp=sharing
 (grønt er skog mens lyse, middelst og mørke blå er elver, innsjøer og
global-ocean). Desverre, her er det veldig stor mengde av innsjøer/elver
dekket (delvis eller helt) av skog. I en annen Z rekkefølge vi kan se
innsjøer/elver over skog arealer i bilde LakesPlusRivers_ON_Forests here
https://drive.google.com/file/d/0B6qGm3k2qWHqOGxfaURtMnlla00/view?usp=sharing
Vi kan se at begge rekkefølger er fulle av feil (skog og vann arealer 
overskriver
hverandre).  Problemet er at man kan ikke ha noen som helst forutsetning om
grensepolygon relasoner mellom areal classene (for illustrasjon se
Borders_OF_ForestsLakes hvor mørke-, lyse-grønn og blå er container, hull og
container polygoner for skog og innsjøer) here 
https://drive.google.com/file/d/0B6qGm3k2qWHqSl93OEFhOGJQMms/view?usp=sharing
Det var/er flere kompensasjons forsøk som rendering av hull, predefinert 
renderings rekkefølge, rendering av mindre objekter over større, ignorering 
av roller/orientasjon i multypolygon osv. (se OSM Wiki endrings historie) 
men med lite help. Selv i kart rendering disse endringene, som regel, hjelper 
noen steder og ødelegger andre steder, så vi har full forståelse for 
frustrasjoner 
av osm2pgsqls skaperne. 
Så, hva kan vi gjøre i en slik situasjon? Heldigvis veldig mye.
La oss bruke S, I, E prefikser og 0, 1 sufikser for skog, insjø, elv og
conteiner/outer, hull polygon på rad (så, S0 og S1 er mørke og lyse grønne
polygoner i bilde Borders_OF_ForestsLakes.jpg). La oss ha {S0} og {S1,I0,E0}
polygon mengder for hele Planeten (deres relasjoner er irrelevante). Da, vi
kan bevise eksistens og finne en såkalt minimal enkle areal dekning
{D}={S0}-{S1,I0,E0}. Med andre ord vi kan finne et minimal sett av
enkle/primitive disjunktive arealer hvor hvert punkt fra en deknings areal D
er et punkt i minst en polygon S0 men ikke punk i noen av S1, I0 ogE0
polygoner og omvent. I visuel interpretasjo dette betyr at i alle enkle
skogs arealene vi har laget (utvidet) tome plasser (huller) for insjøer og
elver. En slik illutrasjon er vist i bilde Forests_ON_LakesPlusRivers_NEW her
https://drive.google.com/file/d/0B6qGm3k2qWHqTmFFR05RZ1V0elE/view?usp=sharing
I en slik datastruktur uansett renderings rekkefølge, skogs arealer er 
presenterte 
med best mylig kvalitet fra OSM kildedata. En slik prosedyre er del av vår 
data-preparation-tools-chain. For interreserte vi understreker at en slik 
prosedure 
er en ekte utfordring for forskere og høyere 

Re: [NUUG kart] Store deler av Haldenområdet "ødelagt"

[Sandor Seres]

Hei, er det denne du tenkte på?

I så fall, har vi denne i originale detaljer både i Mercatot og LatLong og i
original datum.

Mvh. Sandor

 

From: kart-boun...@nuug.no [mailto:kart-boun...@nuug.no] On Behalf Of N/A
N/A
Sent: 31 January 2017 18:26
To: kart@nuug.no
Subject: Re: [NUUG kart] Store deler av Haldenområdet "ødelagt"

 

 

Hei,

Ser ut til at det er resultat av ein import av N50 data som ikkje var bra.
Ein brukar som kallar seg "anders_ar" og import kontoen "anders_ar_import".
Folk som importerer må ikkje erstatte eksisterande data med N50 utan at
desse data er av svært dårleg kvalitet(landsat, Bing som ikkje er
georektifisert riktig osv)

Usikker på korleis ein skal reversere dette då der er fleire sett med
importar i same området. Eg har ikkje kunnskapen til dette og er difor svært
forsiktig når eg driv med N50 import.

Jan T

  _  

From: kart-boun...@nuug.no  on behalf of Espen Arnesen

Sent: Tuesday, January 31, 2017 7:53 AM
To: kart@nuug.no
Subject: [NUUG kart] Store deler av Haldenområdet "ødelagt" 

 

Jeg oppdaget her om dagen at skogsområdene i Ertemarka utenfor Halden viste
skog på vannene og ikke skog i skogen. Jeg tok på meg oppgaven for å fikse
dette. Det tok mye tid, men jeg tenkte det var bare en liten feil som hadde
oppstått. Nå ser jeg at hele elven som går gjennom Tistedal er borte. Der
vet jeg helt sikkert at jeg har brukt mye tid tidligere for å tegne opp
manuelt langs breddene. Nå er hele elven borte.
https://www.openstreetmap.org/search?query=59.12578%2C11.40664#map=18/59.125
78/11.40664 


 
 Image removed by sender.

 
 OpenStreetMap

www.openstreetmap.org

OpenStreetMap is a map of the world, created by people like you and free to
use under an open license.

 

Jeg er ingen "power user", men har gjort mye manuelt i Josm med tanke på
kartlegging av stier og sjekke at kartlagte stier faktisk eksisterer i
virkeligheten.  Nå er jeg litt "lost" og jeg vet ikke hvem som har kunnskap
nok til å fikse opp i alt dette. Mye av dette har kostet meg mange timers
jobb og jeg aner ikke hvor mye som er borte. Noen som kan hjelpe? 

Espen

___
kart mailing list
kart@nuug.no
https://lists.nuug.no/mailman/listinfo/kart

[NUUG kart] Hva du ser er ikke hva du har

[Sandor Seres]

Vi har snakket tidligere om store forskjeller mellom areal objekter i OSM
kildedata og hvordan disse er gjengitt/rendret i forkjellige OSM baserte
kartsystemer. Selvsagt, situasjonen er ikke serlig bedre med linje
objekttyper heller. La oss se på de sju OSM veiklassene med serlig fokus på
rundkjøringer. Det finnes godt over 100K rundkjørings relaterte feil i
kildedata. Mange av disse ser ganske greit ut i kart og kan være av mindre
viktighet men deres rolle i GIS og spesielt i navigasjons systemer er
grunnleggende. Derfor, for navigasjons systemer kunne være av stor interesse
et system/program som oppdager og reparerer slike feilene. Desverre,
foreløpig finnes ikke slike offentlige («open source»  baserte) systemer,
unntatt noen «inspektorer» for trivielle tilfeller. En del av disse feilene
finnes i Norge også og alle eksemplene fremover skal bli av disse.

La oss nevne noen av de typiske rundkjørings feilene:

- Ordinære vei seksjoner er tagget som rundkjøringer. For eksempel
Gardemovegen her  
http://osm.org/go/0TvqQzyyO--  og Preståsvegen her
http://osm.org/go/0TvmM8zkq

Tilsvarende kildedata vises i bilder i tilleget med samme navner og med rød
farge.

- Rundkjøringer er tagget som ordinære veier (med andre ord, ikke tagget som
runkjøringer). For eksempel Slettheiveien/Vågbygd her
http://osm.org/go/0SbM0jfON-  eller Vågdsbygdveiev her
http://osm.org/go/0SbMwaPGO

- Deler/segmenter av rundkjøringen er tagget som «roundabout» mens andre
deler er tagget som ordinære vei seksjoner. For eksempel Barbudalen
rundkjøring her http://osm.org/go/0S0OtFtK1   I tilsvrende bilde av
kildedata rød linje er korrekt mens den blåe segmenten er tagget som ordinær
veistrekning.

- Deler/segmenter av rundkjøringen er fra forskellige vei klasser.

- Rundkjøringens utseende vesentlig avviker fra en regulær sirkulær format.
Disse kaller vi for usikre («unsafe») rundkjøringer.

- For store eller eller rundkjørings polylinje inneholder for få vektorer.
Også usikre.

- Rundkjøringens polylinje savner segmneter (kan ikke kobles sammen til en
sirkular linje).

- Rundkjøringens polylinje inneholder selvkrysninger («self crossings»),
eller multilooper, eller repliserte (men ikke overlappende) segmenter osv.

- Den homogene konveksiteten (kurvaturen) er vesentlig ødelagt (zik-zak
format) for eksempel se Hamnevegen bilde av kildedata. Osv. bare for å nevne
noen.

Ofte er det flere av disse anomalier til stedet i samme objekt. La oss se på
Barbudale rundkjøringen igjen, spesielt på kildedata fra bildet i tillegget.
Ved siden av blandet segmenter det er her to formelle feil også. Først, to
veier (inngående og utgående) skulle aldri møtes i samme node (sitat fra OSM
Wiki «Each road has to be connected with the roundabout in a separate
node...»). Neste, navn tilordningen til rundkjøringen er lovlig bare når den
er uavhengig og ulikt navnene på inn- og utgående veier (sitat fra OSM Wiki
«...if the junction itself is named independently and differently from the
roads crossing it»).

Det er lett å forestille forvirringen av navigasjons systemer når de møter
slike feilaktige rundkjøringer i netverket. Konsekvensene i «turn-by-turn»
navigasjon kan bli til og med katastrofale. Derfor en robust «data
preparation tool chain» skulle oppdage od reparere de fleste av de over 100k
nevnte feilene. Heldigvis, her i Norge vi har slike systemer. Dog det er
noen få ektreme tilfeller hvor manuelt intervensjon er uunngåelig som for
eksempel her

 
http://osm.org/go/wEnl9GWJi--?layers=D  

 

Mvh. Sandor og Henrik

___
kart mailing list
kart@nuug.no
https://lists.nuug.no/mailman/listinfo/kart

[NUUG kart] Til OSM data QA, GIS og programerings entusiaster

[Sandor Seres]

En kuriositet for OSM data QA, GIS og programerings entusiaster.

I vector kart generering nesten bare fatale feiler stopper
visningen/renderingen.  Dersom en ordinæer veiseksjon er tagget som
rundkjøring (eller det motsatte), rundkjøring krysser seg selv, elveseksjon
er tagget som innsjø, skog areal er tegnet over vann, innsjø er ekstremt
fragmentert, innsjø/ocean overlapper elv/elvemunningen med forskjellige øy
strukturer/ konfigurasjoner osv. i renderingen er nesten usynlige feil,
eventuelt kan appfattes som estetisk anomali. Men, slike logiske feil i et
GIS system vesentlig degraderer/begrenser systemets praktisk brukbarhet.
Slik er situasjonen med dagens OSM kildedata.

Offentlig tilgjengelige (open source) inspektorer/validatorer gjør en god
jobb men for det meste i enkle/trivielle tilfeller. De gjør sjelden
reparasjon og nesten ingenting på interklasse (mellom klassene) relaterte
problemer. Vi hadde flere konstruktiv-kritiske diskusjoner på flere osm.org
forumer i forbindelse  med nettopp disse sakene hvor orsaken til anomalier
ligger i sammspill av flere objkt klasser og vi ser at slike diskusjoner
hjelper.

Så, vi vil gjerne presentere en slik multiklass problem felt relatert til
«OSM river systems». Dokumet (white paper) er veldig kompakt (mer eller
mindre i stikkord) men innholder flere eksempler/illustrasjoner og testdata
referanser. Aller viktigst, innholder en formell procces bekrivelse hvordan
kan man lage fra OSM kildedata med anomalier et (sannsynlig) mest korrekt og
komplett datalag i et GIS. Artikkelen kan hentes her:

https://drive.google.com/file/d/0B6qGm3k2qWHqc2RYamllQ2lhSVU/view?usp=sharin
g

Interesserte kan i samme tekst finne referanser til unike data, ikke
tilgjengelige andre steder. Endelig, spørsmål og kritiske meninger er
velkomne.

Mvh. Sandor

 

___
kart mailing list
kart@nuug.no
https://lists.nuug.no/mailman/listinfo/kart

[NUUG kart] Info/Hjelp

[Sandor Seres]

Hei,

jeg har prøvd å få tak i list-moderator men klarte ikke det. Så kanskje noen
fra listen kan hjelpe meg.

Er det noen limit for e-post størrelsen som sendes til medlemer og om så hva
er det?

 

Nemlig, i det siste vi har snakket om OSM relaterte verktøy ute og her
hjemme. Spesielt ble nevnet 

offentlige validatorer og inspektorer for feil detektering fra andre land.
Min mening var (fra lenge siden

og fortsatt er det) at dise er langt fra nokk robuste. Men, jeg vil gjerne
komme med sterke argumenter.

 

Veldig kort. Min venn Henrik og jeg vi bruker ikke OSM diff-er (på geunn av
feil akumuleringen) men ofte

lager en ny dataset fra en siste OSM dump. I denne prosessen vi lager
datalag som planet_land, global_ocean,

forests, lakes, rivers, buildings... veier, gater osv. og de er høy
sansynlig de mest komplete og korrekte som kan

lages fra OSM kildedata. Fra oktober dumpen ville vi gjerne presentere
rivers_system lag og samtidig kommentere

de over 100K logiske og formelle feil forbindet med elver og gjenspeilet i
alle OSM kart.

Desverre, selv med stikkord og veldig kompakt format teksten/mailen er i
overkant av 1,5 A4 størrelse med 7 smo

bilder i attachment. Så, spørsmålet er:

Er dette for stor for å sende til listen? Om så, er det andre måte å
kommunisere artikkelen til medlemene?

Selve river_systems data, antydninger til algoritmer, modeller, problem
definisjoner ikke minst løsninger kunne 

bli av essensiell betydning for OSM GIS entusisater, forskere, kart
entusiaster... og ikke minst for høyre grads 

informatikk og matematikk studenter.

Mvh. Sandor

___
kart mailing list
kart@nuug.no
https://lists.nuug.no/mailman/listinfo/kart

Re: [NUUG kart] OSM og script baserte endringer

[Sandor Seres]

Hei igjen
Selvsagt, det er mange "inspectorer" for å sjekke OSM data. Ja, jeg var gjennom 
de fleste og nettopp derfor maner jeg for mer forsiktighet og kritisk forhold i 
annvendelser, spesielt når du lager kart for store områder. For det meste de 
oppdager trivielle feil mens de alvorlige (formelle og logiske) feilene forblir 
og er der i OSM baserte kart i årevis. Som kjent, det er godt over 100K slike 
feil (ekslusiv trivielle feil) som er nesten som en tidsinvariant atributt av 
OSM kart (dog, sakte voksende). Samtidig, i OSM kildedata eksisterer potensial 
for å oppdage og reparere de fleste av de mest alvorlige feilene. Mit poeng var 
nettopp det og at her hjemme vi har robuste verktøy å gjøre slike ting.
Klart, det er mye mer attrktivt å jobbe på den andre enden, å lage 
rendering/framvisnings skripter, stil lister, kart med bare bestemt innhold, 
søkeskripter, data generaliserings skripter osv. Konsekvensene er at alle 
resultatene er preget av, mer eller mindre, samme type feil (systematiske), dog 
det er flere forsøk for å skyle dem. 
Faren er at etter noen tid emnet kan oppfattes som irriterende og kjedelig i 
hvert fall er det ikke for e-post diskusjon. Men, for å underbygge de nevnte 
påstandene, her er en kuriositet (vel egnet tema til OSM entusiaster, FoU, 
høyeregrads studenter...).
Til å begynne med, se nøye gjennom OSM baserte kart her: 
http://osm.org/go/ZXsOSZY9--?layers=CN (klikk gjennom "Front page" kart lag, 
BigMap2 kart - de fleste er fra renomerte universitets milyøer, MapBox, 
MapQuest osv. på samme sted). Du vil se sterkt varierende presentasjoner av 
"Grand River" men apsolut alle med feil (i noen, skog er rendret over vann, 
hull er rendret til bakgrunsfarge osv.). Jeg har laget en "Map Note" og kanskje 
noen skal manuelt reparer årsaken men poenget er at det er tusenvis av slike 
årsak-feil tilfeller. I kildedata fra den siste OSM "dump"en man kan se at det 
er fire overlappende vann objekter med varierende hull strukturer. Bilde1 viser 
en insjø og bilde2 tre forskellige "riverbank" alle over hverandre. Alle 
"inspektorene" her feiler, ikke å nevne programatiske korreksjoner. Bilde3 
viser hvordan elven skulle egentlig se ut akkurat der (etter feil deteksjon, 
reparasjon og defragmentering).
Mvh. Sandor


-Original Message-
From: Sverre Didriksen [mailto:sverre.didrik...@usit.uio.no] 
Sent: 06 October 2016 10:05
To: a...@frenviksveen.net; sandor...@gmail.com
Cc: kart@nuug.no
Subject: Re: [NUUG kart] OSM og script baserte endringer

Jeg tror vi alle kan bli flinkere til å bruke de verktøy som finnes for å 
sjekke at det ikke er feil der vi har lagt inn data. Tyske Geofabrik har noen 
veldig flotte. Der kan man få sjekket omtrent alt, som kystlinje, 
multipolygoner, tagger, vann, routing, geometri, osv.

Ta en titt på disse eksemplene:

Multipolygoner:
http://tools.geofabrik.de/osmi/?view=multipolygon=11.31505=62.6
0662=13=0.31=invalid_geometry_hull,duplicate_ways
,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,
unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,ro
le_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multi
polygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_no
des,way_nodes


Områder:
http://tools.geofabrik.de/osmi/?view=areas=5.32733=60.39200
m=15=0.31

Vann:
http://tools.geofabrik.de/osmi/?view=water=10.45528=60.02023
om=14=0.31

Tror man kan finne mye rart med disse verktøyene. Men nå må jeg også si at noen 
av de er litt i overkant kravstore. At vi ikke har navn på alle bekker  kan vel 
neppe regnes som feil.

-Sverre




On Wed, 2016-10-05 at 11:30 +0200, Sandor Seres wrote:
> Hei
> Når det gjelder eventuell FKB bruk for OSM oppdateringer, la oss ta 
> emnet når/om det blir aktuelt. Etter min mening, vi har robuste 
> verktøy her hjemme i Norge for å håndtere de nevnte utfordringene.
> Mest sansynlig minst så gode og effektive som de andre har.
> Når det gjelder student veilednings innsatsen din og tilbakemeldingen, 
> den er prisverdig. Som ex universitets professor jeg vet veldig godt 
> hvor vanskelig, men samtidig viktig, det er å finne passende 
> studentoppgaver, spesielt for høyere grads studenter.
> Heldigvis OSM er en gullgruve for dette spesielt i forhold til logiske 
> og formelle feil i OSMs kildedata (tilgjemgelig gjennom regulære 
> dump-er). Her, medlemer av denne listen kan gjøre sikkelig mye og 
> hjepe interesserte. I tilleg til de tipsene allerede formidlet, jeg 
> kommer here med noen få i tilleg. Data og eksemplene er baserte på 
> aller siste "OSM dump" transformerte til den vanlige Mercator sferisk 
> projeksjon, med original datum og justerte til Verdens ramme.
> Når man kjører en robust "data-preparation-tool-chain", man vanligvis 
> begynner med "coastline". Etter feil deteksjon og reparasjon ma

Re: [NUUG kart] Debatt: Inntegning av skog

[Sandor Seres]

En mening fra en Planet-vektor-map-maker side.
En slik oppstykking av skogarealer (eksisterende eller nye) med striper imellom 
er aldeles feil både formælt og essensielt.
Derfor jeg fullstendig støtter Vidars ønske/forslag fo revesering.
Noen få argumenter (fra mange) i stikkord:
-Ved siden av at det er mange geometriske fei, opplasting av lokalspesifik 
data/format på OSM er en slags forurensning av kildedata (selv on OSM sier ikke 
eksplisitt - forbudt). 
-OSM servere er donerte med begrenset kapasitet og ytelse. Opplasting av 
unødvendige data, data av interesse for en forsvinnende mengde av brukere, 
opptar kapasitet for viktigere data. Med sterkere ord vi kaller dette for em 
slags vandalisme.
-Oppstykking av en areal med areal-striper forutsetter at i stripene skal komme 
et nytt areal objekt fra en annen geoobjekt klasse. Dersom dette mangler, eller 
i stripene kommer linje-onjekter (veier, ledninger osv.) dette blir da direkte 
logiske feil. Linjeobjekter i kartografi vises/rendres over allerede 
eksisterende bakgrunnen med predefinerte stiler og farger.
-I vektor map-making skalering av arealer og linjeobjekter utføres på radikalt 
forskellige måter. Som regel, arealer skaleres isometrisk mens linjeobjekter 
ikke-isometrisk. Så, dersom oppstykkingen er begrunnet med veier, ledninger 
osv. da dette fører til presentasjons/renderings "mismatch". Som regel, 
linjeobjektenes bredde skaleres saktere/mindre enn lengde.
-Dersom stripenes bredde er noen få meter, disse forsvinner i kartvisning 
veldig fort (se på en bredde av 10m i 1:2 skala eller mindre og på skjerm 
av 96dpi). Så, dette blir bare en unødvendig/redundant plage i data 
generalisering, tiling, rendering osv.
-Dersom oppstykkingen foregår med poly-linje (som er da felles grense segment 
mellom to areal objekter) da dette er helt greit og mye brukt i areal 
opplastinger. Avanserte vektor map-makers ska uansett rekonstruere store unike 
areal presentasjoner (multipoligon relasjoner) som nøye reflekterer de 
naturlige objektene (i denne tilfellen - skog områder).
Mvh. Sandor.

-Original Message-
From: kart-boun...@nuug.no [mailto:kart-boun...@nuug.no] On Behalf Of Vidar 
Gundersen
Sent: 13 November 2015 08:47
To: kart@nuug.no
Subject: [NUUG kart] Debatt: Inntegning av skog

Hei,
Jeg har lagt merke til at flere i det siste har begynt å stykke opp de store 
skogpolygonene og blant annet frilagt skog langs bilveier, for eksempel i 
Nordmarka.

1. Jeg er ikke sikker på om det er riktig representasjon av skog: Hvor bred 
skal en vei med veigrøfter være før det er naturlig å si at det er et åpent 
område?

2. Det er bortkastet tid, spesielt på nåværende tidspunkt som det mangler mange 
bilveier, dyrket mark, bygninger, osv i de samme områdene.

Det er noe av det som er gjort i Nordmarka som jeg er såpass uenig i at jeg har 
lyst til å reversere det igjen.

Hva synes dere?
___
kart mailing list
kart@nuug.no
http://lists.nuug.no/mailman/listinfo/kart

___
kart mailing list
kart@nuug.no
http://lists.nuug.no/mailman/listinfo/kart

Re: [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-boun...@nuug.no [mailto:kart-boun...@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 

Re: [NUUG kart] Egne flyfoto

[Sandor Seres]

Hei Kristian
I selve fotograferingen blander jeg meg ikke serlig inn i. Men SW har jeg
utviklet komplet.
Dog, orto og skråfotoer var tatt med Pictometry kamera tehnologien. Jeg
tviler på at QGIS
eller noen annen DB system bearbeider de enorme mengder av bilder (hm, du
hørte og vet
om Bloms problemer i denne sammenhengen). 
Jeg kunne tenke meg å hjelpe til. Har demosystem for bilder over Oslo.
Så, ikke nøle å ta kontakt med meg dersom du vil vite, høre og se mere.
Mvh. Sandor

-Original Message-
From: kart-boun...@nuug.no [mailto:kart-boun...@nuug.no] On Behalf Of
Kristian Dahl
Sent: 03 April 2014 22:42
To: kart@nuug.no
Subject: Re: [NUUG kart] Egne flyfoto

Hei Sverre,

er i gang med å bygge et liknende prosjekt. Er i ferd med å bygge meg en
hexarotor som jeg har ambisjoner om at skal være i stand til å servere
Ortorektifiserte og Georefererte luftbilder fra et område av begrenset
størrelse.

Hvis du er interessert, ser delelista mi foreløpig som følger ut:

RC Sender: FrSky Taranis
Mottaker: FrSky X8R
Ramme: DJI F550 Hex Clone
Autopilot: APM 2.5
Motorer: 6x 1000kv
Motorkontrollere: 6x SimonK 30A
Batteri: 3 cellers LiPo 11,1V 6000mAh
GPS/Mag combo: CN06 Plus

Har ikke bestemt meg for kamera eller gimbal enda. Hvis noen her har
erfaring og kanskje noen tips, er jeg interessert.

Ellers går jeg foreløpig ut i fra at QGIS skal ta seg av det meste av
softwarebiten. Mulig dette ikke er helt realistisk.

Blir veldig gira av ideen om å ha egne ODbL-bilder, og kanskje en wms-server
hvor flere kan samarbeide om å laste opp flyfoto.

Med vennlig hilsen,
Kristian

On Thursday 3. April 2014 15:56:19 Sverre Didriksen wrote:
 Hei
 
 Kom over denne, det hadde vært noe:
 http://www.norgeodesi.no/trimble/uav-uas-rpas/trimble-ux5-aerial-imagi
 ng-ro
 ver-system/c-25/c-83/p-187
 
 -Sverre

___
kart mailing list
kart@nuug.no
http://lists.nuug.no/mailman/listinfo/kart

___
kart mailing list
kart@nuug.no
http://lists.nuug.no/mailman/listinfo/kart

Re: [NUUG kart] Egne flyfoto

[Sandor Seres]

Hei,
selvsagt du har rett i postandene. Men det er ganske sikkert områder hvor mann 
kunne få mulighet å teste.
Forresten, det er klart at det er lang vei fra denne ideen til en oppmuntrende 
resultat. Men, uten å prøve... blir ingenting.
Spesielt din siste kommentar er riktig og viktig. Men nettopp derfor er  ideen 
motiverende.
Med det gamle/nåværende teknologien man må balansere mellom fotograferingens 
kostnader og kvaliteten (flyvings høyde,
avstand mellom flyvingslinjene, frekvensen av fotograferingen osv.). Alt dette 
kan (hm, kanskje) bli dramatisk endret med
(relatint billige små) droner.
Uansett, kjempe interresant utfordring etter min mening.
Mvh. Sandor

-Original Message-
From: kart-boun...@nuug.no [mailto:kart-boun...@nuug.no] On Behalf Of Gnonthgol
Sent: 04 April 2014 01:35
To: Sverre Didriksen; kart@nuug.no
Subject: Re: [NUUG kart] Egne flyfoto

Den 03. april 2014 17:56, skreiv Sverre Didriksen:
 Kom over denne, det hadde vært noe: 
 http://www.norgeodesi.no/trimble/uav-uas-rpas/trimble-ux5-aerial-imagi
 ng-rover-system/c-25/c-83/p-187

Det er framleis ein del problem med droner i norsk lovgivning. Slik eg har 
forstått er det endå ikkje lov til å fly droner utan at du har ein pilot som 
kan ta over styringa når som helst og er innanfor synsrekevide. Lovverket er 
ikkje tilpassa slike produkt som rettar seg mot personar som ikkje er i stand 
til eller ønskar å fly sjølv. Det er også ein del restriksjonar mot å fly i 
bebygga områder som gjer at denne type teknolagi er uegna under gjeldande norsk 
lovgivning. Desverre så må me fortsette å klage til norske luftfartsmyndigheter 
om å gjennomse lovgivningen. Det hadde jo ein effekt på NSM at alle 
dronepiloter i Norge søkte om ein kommersiell lisens for å ta luftfoto.Det er 
kansje mulig å lette på restriksjonane om å fly radiostyrte fly i bebygga 
områder og gjere det mulig å sertifisere droner til bruk uten kyndig personell 
til å ta over. Det er bra at dei er forsiktige men teknologien avanserer 
fortere enn lovteksten kan følge.

Framleis er det vanskelig for folk flest å lage flyfoto uten å bruke masse 
pengar eller lovbrudd.

Gnonthgol
___
kart mailing list
kart@nuug.no
http://lists.nuug.no/mailman/listinfo/kart

___
kart mailing list
kart@nuug.no
http://lists.nuug.no/mailman/listinfo/kart

Re: [NUUG kart] SOSI-OSM-Verktøy [svar]

[Sandor Seres]

Er dette svar fra SKV? 
SHP filer med geometri av områdegrenser innen object klasser inneholder
topologi i en skult/implisite format. Dette kan vi programatisk konvertere
til konnektivitet, grenser, komplekse områder osv. Forresten, hva da med mye
brukt SHP file fra andre geo-data kilder som TA, NT, AND og ikke minst OSM,
Geofabrik, CloadMade osv.

-Original Message-
From: kart-boun...@nuug.no [mailto:kart-boun...@nuug.no] On Behalf Of Thomas
Hirsch
Sent: 04 October 2013 16:10
To: Trond Michelsen; NUUG kart
Subject: Re: [NUUG kart] SOSI-OSM-Verktøy [svar]

 Er det noen spesiell grunn til at Kartverket ikke distribuerer dataene som
shapefiler? 

Ja - http://en.wikipedia.org/wiki/Shapefile#Limitations

 
___
kart mailing list
kart@nuug.no
http://lists.nuug.no/mailman/listinfo/kart

___
kart mailing list
kart@nuug.no
http://lists.nuug.no/mailman/listinfo/kart

[NUUG kart] Vei navn

[Sandor Seres]

Hei, to kjappe:
-Er det riktig å kalle en kort veiseksjon etter navnet av en tunnel, ei
brua...? For eksempel en kort seksjon av Bergensbanen kalles
Haverstingtunellen.
-Er det riktig å kale deler/segmenter av et object med variasjoner av et
navn? For eksempel på den samme jernbanen en seksjon kalles for
Bergensbanen mens en annen for Bergensbana.
Takk for hjelpen.
___
kart mailing list
kart@nuug.no
http://lists.nuug.no/mailman/listinfo/kart

Re: [NUUG kart] OSM statistik

[Sandor Seres]

Hei Espen,
Tja, noen ganger jeg (vi i Fater Imaging) lager en rapport som ligner på
statistikken du nevner. Og ikke bare det men mye, mye mer.
Nemlig, vi har en skikkelig robust data-preparation-tool-chain som
detektere formelle og logiske fei i OSM Planet dump og reparerer de fleste.
Og det er mange, mange of dem (se
http://lists.openstreetmap.org/pipermail/dev/2012-November/026063.html som
eksempel).
Uten disse reparasjoner statistikken kan fort bli med store
risiko/usiikerhets marginer. Lengden av enkle poly-linjer (forskjellige
veiklasser, gater, grelselinjer...) og overflaten av enkle arealer
(elvesystemer, insjøer, skoger...) er registrerte egenskaper i vårt
internal dataformat (dog i Mercator sferisk projeksjon).
Dersom av interesse, vi kan diskutere dette dupere. Også, jeg har sendt
flere relaterte diskusjonsartikkler til OSM-dev forum under mitt navn.
Hilsen, Sandor.

Den 00:12 25. februar 2013 skrev Espen Isaksen es...@espenpost.comfølgende:

 Hei!

 Er det noen som kjører statistikk over OSM-data i Norge? Jeg er
 interessert i antall km med ulike vegtyper, antall bygg, antall vann osv.

 Hvis det ikke er noen som har noe av dette så tenkte jeg å sette opp noe
 enkel statistikk som teller opp dette daglig.

 Espen


 --
 http://www.turkompisen.no
 http://www.kresendo.no/
 http://no.linkedin.com/in/espenisaksen



 ___
 kart mailing list
 kart@nuug.no
 http://lists.nuug.no/mailman/listinfo/kart


___
kart mailing list
kart@nuug.no
http://lists.nuug.no/mailman/listinfo/kart