[NUUG kart] OSM og script baserte endringer

Tue Oct 11 12:26:03 CEST 2016

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.didriksen at usit.uio.no] 
Sent: 06 October 2016 10:05
To: atle at frenviksveen.net; sandors39 at gmail.com
Cc: kart at 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&lon=11.31505&lat=62.6
0662&zoom=13&opacity=0.31&overlays=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&lon=5.32733&lat=60.39200&zoo
m=15&opacity=0.31

Vann:
http://tools.geofabrik.de/osmi/?view=water&lon=10.45528&lat=60.02023&zo
om=14&opacity=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 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
> _______________________________________________
> kart mailing list
> kart at nuug.no
> https://lists.nuug.no/mailman/listinfo/kart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Grand_River1.jpg
Type: image/jpeg
Size: 10961 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/kart/attachments/20161011/6fc82aeb/attachment-0003.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Grand_River2.jpg
Type: image/jpeg
Size: 14715 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/kart/attachments/20161011/6fc82aeb/attachment-0004.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Grand_River3.jpg
Type: image/jpeg
Size: 14644 bytes
Desc: not available
Url : http://lists.nuug.no/pipermail/kart/attachments/20161011/6fc82aeb/attachment-0005.jpg 