[NUUG kart] OSM og script baserte endringer

[Atle Frenvik Sveen]

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).



-- 
  Atle Frenvik Sveen
  atle at frenviksveen.net
  45278689
  atlefren.net

On Mon, Sep 26, 2016, at 10:18 AM, Sverre Didriksen wrote:
> Hei
> 
> Er helt enig i alt som blir sagt her. Vær forsiktig så ikke noe
> ødelgges, og ha respekt for data som andre har lagt inn. 
> 
> Kartverket sine data er ikke nødvendigvis fasit om det er differanse.
> Om man ikke vet med 100% sikkerhet at de dataene man har er bedre så la
> det være slik det er.
> 
> Det jeg er mest bekymret for er de som opererer på egenhånd og som ikke
> er med på lista her. Når de setter igang med import uten å ha
> nødvending erfaring og kunskap, så er det stor fare for at ting blir
> ødelagt. Vi har jo slike som han Visa-import-fyren som har herpet store
> områder hvor det er en massiv jobb å få ryddet opp. Og det er bare et
> eksempel av mange.
> 
> Ellers så må jeg si at det er veldig mange som gjør en fantastisk jobb!
> 
> -Sverre
> 
> 
> 
> 
> On Sat, 2016-09-24 at 08:49 +0200, SandorS wrote:
> > I den senere tiden det var mye snakk om scripter for opplasting av
> > store datamengder til OSM (elveg, N50, barnahager, mikrobryggerier,
> > setrer…) og for endringer av eksisterende data i OSM. Det var også
> > diskusjoner om student oppgaver hvor kandidater skulle lage script
> > for opplasting av noen geo-objekt classe til OSM (jeg inderlig håper
> > at mentorene er klarover farene med slike oppgaver).
> > OSM er i dag en monster når det gjelder datamengden (mange TB), med
> > stor frihet i interpretasjoner og “doocracy” (frivillig) baserte
> > opplastinger og serviser. Den er, mest sannsynlig, rikest samling av
> > geodata og relaterte informasjoner på planeten vår. Men, stor frihet
> > i et system betyr stor entropi (kaos) i systemet. Følgelig, OSM
> > inneholder store mengder feil (hundretusener) som desverre blir bare
> > større og større.
> > Brukere, spesielt “vector-map-maker”e, må kjempe med slike feiler og
> > reparere dem før de lager sine Verdens/Planet kart databaser og
> > rendering systemer. Derfor er de dypt klar over konsekvensene av
> > skriptbaserte/masse opplastinger/endringer. Jeg regner meg selv som
> > en av slike brukere og vil gjerne si noen meninger om emnet.
> > Selvsagt, mine meninger er forsvinnende mellom alle de diverse
> > meningene dog kunne være av interesse for noen av forumets medlemer.
> > -Skript/masse (bulk) opplasting var ment for inisjell/innledende
> > objektklasse opplastinger. Med andre ord, for ennå ikke elsisterende
> > objekttyper (i et område). Tatt i betraktning alle de eksisterende
> > objekttypene i OSM, bulkopplasting metoden frarådes i dag og
> > anbefales individualle (editor baserte) object opplating metoder. Man
> > finner mange slike meninger på OSM forumer, fe.
> > https://help.openstreetmap.org/questions/51858/does-massgis-data-get-
> > double-checked
> > -Selvsagt, ingen kan nekte en mapper for å bruke skriptopplasting.
> > Men en slik aksjon skjuler flere feller og kan forårsake store skader
> > (evt. mye extra arbeide) for mange, mange, map-makere.
> > -Noen ov de nevnte fellene kan være: instanser av objekttypen
> > allerede eksisterer så det er stor fare for replikasjoner med
> > ødeleggende konsekvenser. Så, man prøver å programatisk sjekke om to
> > object versjoner er eksakt like, nesten like, høy sansynlig det same
> > osv. Slike topologi og polygon-algebra algoritmer og programmer er
> > ikke enkle student øvelser, tvert imot.
> > -Også, bulk-/script-opplasting av nye onjekttype kan være farlig. Til
> > og med i noen tilfeller ukorrekt (uansvarlig). Fe. å laste opp
> > fjorder som arealer, uten at kystlinjene tilsvarende endres, kan bli
> > en katastrofe (enten man må eksakt duplisere data eller man mister
> > store mengder av øyer). Husk at allerede vi mister (kan ikke se i OSM
> > baserte kart) tusener av øyer hvor sjøvann overlapper elvemunninger.
> > Videre, å laste opp data av interesse for veldig få brukere, eller
> > veldig begrenset område ansees også som ukorrekt (bare opptar
> > capasitet av allerede veldig belsatet servere).
> > -Skript baserte dataendringer kan også bli veldig farlige eller i det
> > minste unødvendige. Det skjer nesten daglig at mappere gjør
> > massendring og så desperat ber de etterpå for reverting hjelp, se fe.
> > https://help.openstreetmap.org/questions/52108/reverting-a-very-large
> > -changeset
> > Oppstykking (fragmentering) av eksisterende objekter (elveseksjoner),
> > eller endringer av linjeobjektenes (kystlinje, elvelinje) rettning og
> > liknende er farlig og fullstendig unødvendig. Map-makere allerede har
> > robuste algoritmer for effektiv håndtering av disse. Desuten,som
> > kjent, høy/stor areal fragmentering er et mareritt for rendering
> > systemer (sokalt “white-pixel-effect” langs felles grenser). Derfor,
> > (vector) map makere gjør egentlig det omvente, defragmentering.
> > Så, i konklusjon, som en god praksis, man skulle altid presentere en
> > detaljert modell til OSMs lokal forum før en bulk/masse
> > upplasting/endring iverksettes. Medlemenes konstruktive og kritiske
> > meninger kunne skikkelig hjelpe alle parter for å unngå de nevnte
> > fellene.
> > Mvh. Sandor
> >  
> >  
> > Sent from Mail for Windows 10
> >  
> > _______________________________________________
> > 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