[NUUG kart] OSM og script baserte endringer

Wed Oct 5 11:30:03 CEST 2016

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 man danner polygoner. Disse polygonene ordner man i strukturer ved hjelp av relasjon "polygon-in-polygon" slik at polygonene danner primitive/enkle arealer (en container/enclosing og en virkorlig antall, inklusiv null, hull/excluding polygoner). Så, i denne processen man kommer over (skikkelig) stor antall av feil hull polygoner. Bilde1 viser alle (567631) container/uterste polygonene (ingen av disse er inn i en annen polygon). Bilde2 viser posisjoner av hull, hull-inn-hull... polygoner. Bilde3 viser samme distribusjon i Norge. Ingen av disse hull-polygonene skulle bli i kystlinje tagget datalag og dette er feilen. Noen av disse hullene er topologisk korrekte smo innsjøer men alle innsjøer skulle nå egentlig havne i "lakes" (natural=water og water=lake) OSM datalag. Men de fleste av dem er formelle feil. Nemlig, når mappere flytter data fra kystlinje til insjøer eller elver, krever dette en ganske komplisert manuell editorbasert oppdatering. I denne processen det er veldig lett å håppe over noen øyer i innsjøer som da blir igjen i kystlinje datalag. Konsekvensen er at disse øyer vises både i kystlinje og insjø rendering som vann (blå) dermed de forsvinner. Slik er det praktisk i alle offentlige OSM baserte kartsystemer (OSM front page/Slipymap og de andre lag, Mapbox, Mapquest, Bigmap2 osv). For illustrasjon vi kan ta noen eksempler fra bilde3. I OSM hoved kartet disse er her: http://osm.org/go/0Rva~GXI-?layers=T, http://osm.org/go/0S3PIpDa--?layers=T, og 
http://osm.org/go/0S1qIa6p-?layers=T. Tisvarende situasjoner fra kildedata er vist i bilde4, bilde5 og bilde6 (grønne linjer er container polygoner fra coastline data, svarte linjer er hyll polygoner fra coastline data og blå/lysblå linje/areal er innsjøer fra OSM kildedata. Man kan se at i bildene 4 og 5 eksisterer ikke hull i innsjøene men i bilde6 hull polygonen er replisert i innsjødatalaget også. Alle hullene/øyer i innsjøene skulle forsvinne etter rendering av insjø-laget fordi hullene er allerede blå fra kystlinje renderingen. Forskellige kartsystemer prøver å kompensere for disse feilene på varierende måte. Fe. dersom insjø er i multipolygon format, hullene renderes til land-farge, eller hullene fra kystlinje sjekkes mot injø-containere og dersom  de er innenfor, de renderes som land, osv. Men alt dette er bare maskering av feilene i fremvisningen og GIS er mye, mye, mer enn rendering.
Så, til mylige oppgaver her: la oss anta at alle nødvendige data er tilgjengelig, for eksempel i ESRIs shp format.
1. Opprett en algoritme og skript for ekstraksjon av container og hull polygoner fra kystlinje polygoner som særskilte classer.
2. Samme som i 1. for å sjekke om hull polygoner fra kystlinje er allerede in i innsjø container polygoner.
3. Dersom vi vet at en sett av hull polygoner fra kystlinje er i insjø container polygoner hvordan skal man håndtere tilfeller: hull fra kystlinje har en eksakt replisert hull i injøer, ikke replika men nesten det samme (såkalt korridor replika), har ingen overlappende hullpolygon i innsjøer... osv.
Flere av slike oppgavene er alvorlige emner ikke bare for høyeregrad studenter og forskere i informatik men også i matte (Topologi, Polygon Algebra osv.). Og, det er mye mer enn de tre forslagene.
Dersom man legger på bilde4 kanallinjene (waterway=canal) da får mann en situasjon som i bilde7. Det er en feiltagget sirkular kanallinje og en ekte kanallinje. I konsekvensen, i mapping sytemer fremvises/rendres dette som varierende virtuelle øyer (avhengig av den brukte linjetukkelsen) som fe. here http://osm.org/go/0RvwRVBeY-. Hvordan skal man oppdage og reparere slike feiler? Og det er mange, mange av dem.
Det er også mange, mange, virtuelle (ikke eksisterende) øyer på elver som er med feil vist i OSM baserte kart. Når som helst en "riverline" (waterway=river) løper utenfor tilsvarende elveseksjoner dette vises som en øy. Hvordan skal man oppdage slike tillfeller og eventuelt reparere dem? Oppgaven er utfordrende, kompleks og komplisert.
Det er mange elveseksjoner tagget som innsjøer. Selv om dette kan bli lovlig (i sammsvar med OSM Wiki) logisk er det alvorlige fei. Nemlig, mange, mange elver har unaturlige brudd og samtidig i innsjøer finnes det like mange tynne lange unaturlige objekter. Hvordan skal man gjenkjenne og reparere slike tilfeller? Igjen, en kompleks, fin og nyttig oppgave. Og disse er bare en brødel av muligheter.
Jeg ønsker å understreke igjen at vi har i Norge (medlemer av forumet) løsninger på de nevnte problemene og mye mer. Om disse er ikke i "open source" format betyr ikke at interreserte kan ikke få nødvendige data og hjelp. Tvert imot. Etter min mening, nettopp slik kommunikasjon er formålet med/i forumet.
Unnskyld meg for tekstens ommfang, Sandor. 

-----Original Message-----
From: kart-bounces at nuug.no [mailto:kart-bounces at nuug.no] On Behalf Of Atle Frenvik Sveen
Sent: 29 September 2016 10:37
To: kart at nuug.no
Subject: Re: [NUUG kart] OSM og script baserte endringer

Hei

Jeg ser at det er mulige problemer med masse-import av data, og det er heller ikke slik at kartverkets data er bedre. Men, hvis vi tenker litt fremover og FKB nå blir frigitt vil for eksempel detaljerte bygningsomriss for hele landet bli tilgjengelig, og her vil jeg anta at de i 99% av tilfellene er "bedre" enn omriss som er tegnet inn basert på sattelittfoto av varierende kvalitet  [Citation needed]

Utfordringen er jo fort det at en bygning i OSM har masser av ekstra informasjon man ikke får fra kartverket, så det å bare slette alle bygninger og pøse inn data fra kartverket vil ikke være en farbar vei.
Her synes jeg approachen som foreslåes i denne talken fra SOTM US
(https://www.youtube.com/watch?v=3rQ83mqj4bg) virker lovende.
Kommentarer?

Ellers vil jeg bare få berolige med at det Anne Sofie tenker på å gjøre som en studentoppgave ikke vil importere data inn i OSM uten å ha konsultert miljøet først, det er mer snakk om å se på problemstillinger rundt dette, hva som kan gjøres (f.eks med microtasking som nevnt over).
Hvis det viser seg at resultatet blir et brukbart verktøy vil det være et mål å dele dette med miljøet. (Full disclosure: det var jeg som satte henne på ideen og jeg bidrar som veileder på prosjektet). Dermed: se på dette som en mulighet til å få innspill på hvordan man kan forholde seg til importer (eller bruk av data fra andre kilder: import er et litt belastet ord).

_______________________________________________
kart mailing list
kart at nuug.no
https://lists.nuug.no/mailman/listinfo/kart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bilde1.jpg
Type: image/jpeg
Size: 48926 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/kart/attachments/20161005/fa334caa/attachment-0007.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bilde2.jpg
Type: image/jpeg
Size: 56284 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/kart/attachments/20161005/fa334caa/attachment-0008.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bilde3.jpg
Type: image/jpeg
Size: 35940 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/kart/attachments/20161005/fa334caa/attachment-0009.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bilde4.jpg
Type: image/jpeg
Size: 21645 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/kart/attachments/20161005/fa334caa/attachment-0010.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bilde5.jpg
Type: image/jpeg
Size: 12963 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/kart/attachments/20161005/fa334caa/attachment-0011.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bilde6.jpg
Type: image/jpeg
Size: 20779 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/kart/attachments/20161005/fa334caa/attachment-0012.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bilde7.jpg
Type: image/jpeg
Size: 9508 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/kart/attachments/20161005/fa334caa/attachment-0013.jpg 