[NUUG kart] OSM og script baserte endringer

[SandorS]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nuug.no/pipermail/kart/attachments/20160924/2c04cd86/attachment.htm