[NUUG kart] OSM og script baserte endringer

Thu Oct 6 10:04:50 CEST 2016

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