Re: [NUUG kart] Størrelse på skogsrelasjoner
De små polygonene jeg snakker om likner litt på avskjæret fra pepperkakebaking. N50 fra sosi2osm er et slags rutenett, men ettersom kommunene ikke er rektangulære blir det mange bittesmå polygoner langs kanten rundt hele kommunen. Jeg kan ikke lenke til dem ettersom jeg manuelt slo dem sammen under importen. Å slå dem sammen med nabokommunens polygoner er også en mulighet, men det innebærer jo akkurat det samme (en sammenslåing med et annet område av samme type, for å få færre bittesmå polygoner). Poenget mitt er at dette var masse manuelt arbeid som kunne vært betydelig forenklet vha. script der bittesmå polygoner ble slått sammen til litt større polygoner. Uten fare for å ødelegge noe. Man må bare sette grensene for hvor store polygoner skal kunne bli; og de grensene finnes tydeligvis allerede. Anders -- anders.foug...@gmail.com +47 97158863 Sent from my Commodore 64 Den 02.02.15 11.05, skrev N/A N/A: Om dette gjeld små bitar av eit polygon som er i ein anna kommune så ville eg berre slå dei saman med den store delen i nabokommunen. Kan du linke til desse små multipolygonane? Greit for å vere sikker på at vi forstår kvarandre ;) Date: Mon, 2 Feb 2015 09:58:52 +0100 From: anders.foug...@gmail.com To: kart@nuug.no Subject: Re: [NUUG kart] Størrelse på skogsrelasjoner Jeg synes at det er mer komplisert å jobbe med mange bittesmå skogrelasjoner enn færre, litt større relasjoner. I N50-utdragene jeg har sett er det veldig mange små multipolygoner nær grensen til nabokommunen. Og grenselinjene mellom polygonene går typisk i rette linjer, som fører til at både vann og jorder typisk er delt i to bittesmå multipolygoner. I forbindelse med den importen jeg har gjort rundt Oppdal har hoveddelen av arbeidet vært manuelt arbeid for å fjerne duplikater langs grensene mellom multipolygonene, ettersom jeg har tatt for meg én og én del av kommunen, og én og én arealtype (skog, vann, bekk, elv osv). Mye av dette arbeidet slipper man dersom polygonene er større/sammenslått. Jeg ville derfor foretrukket om de små områdene var slått sammen, bare for å spare arbeid. Det går imidlertid an å dele dem opp igjen etterpå...og da kanskje helst på en måte som ikke skjærer rett gjennom samtlige små vann o.l. som bare gjør det mer komplekst. Å slå sammen til enorme skogpolygoner er ikke noe poeng — jeg tenker mer på de små multipolygonene med 1–20 medlemmer. Anders -- anders.foug...@gmail.com +47 97158863 Sent from my Commodore 64 Den 02.02.15 09.27, skrev Sverre Didriksen: Jeg tror heller ikke det er noen god ide å slå sammen relasjonene ved import. Da vil de strekke seg over så store områder og bli såpass kompliserte at jeg tror faren er stor for at det gjøres feil når man i ettertid skal endre på ting. Jeg har en følelse av at mange sliter litt med relasjoner, spesielt når de er store og kompliserte. Jeg ser stadig relasjoner med feil og det er egentlig ikke så bra. -Sverre On Sat, 2015-01-31 at 18:57 +0100, N/A N/A wrote: Problemet er at eit polygon ikkje kan ha meir enn 2000 punkt. Eg måtte dele opp til fleire slike ruter frå N50 i to delar for at det ikkje skulle bli for mange punkt. Så det å slå saman ruter blir nok ikkje lett. Går vel kanskje der heile sida av ei rute består av meir skog. Eg har ikkje vore borti så store skogområder endå. Alle rutene der eg har arbeidd har grensa til høgfjellet så det å slå saman vil ikkje gå då det vert over 2000 punkt. Eg vil meine at det er enklare å arbeide med mindre relasjonar. Enklare å halde oversikt. Gazer75 __ From: torstein...@gmail.com Date: Sat, 31 Jan 2015 12:18:41 +0100 To: kart@nuug.no Subject: [NUUG kart] Størrelse på skogsrelasjoner Hei, Når man tegner skog kan relasjonene fort bli store (mange medlemmer). I N50 serien deles polygonene ved hver 0.05 bredde- og lengdegrad. Dette gir mange små relasjoner (2-50 medlemmer) og noen få mellomstore relasjoner (50-200 medlemmer). Hvis man slår disse sammen får man gjerne VELDIG store relasjoner (for Meråker ble det et på over 4000 medlemmer). Wikien sier at man bør unngå at relasjonene inneholder mer enn 300 medlemmer (http://wiki.openstreetmap.org/wiki/Relation). Jeg har lagd et script som slår sammen de minste relasjonene med nabo relasjoner, slik at man unngår veldig mange små relasjoner (2-20 medlemmer). Da blir relasjonene på typisk 50 - 200 medlemmer. Så mitt spørsmål er: ved import av N50 data, bør man slå sammen relasjoner til større relasjoner på rundt 50 - 200 medlemmer. Eller bør man la dataen være uforandret og beholde 0.05x0.05 rutenettet med mange små relasjoner? Hilsen tibnor ___ kart mailing list kart@nuug.no
Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50
Når det gjelder https://www.openstreetmap.org/relation/4531318, så mener jeg at denne bør bestå av flere way'er. Alternativt måtte det bli flere overlappende way'er, da myra deler grense med både åpent område og skog på forskjellige steder. Når jeg ser på denne i JOSM, ser den ut til å være perfekt oppdelt. - Ola Endre 2015-02-02 14:11 GMT+01:00 Sverre Didriksen sverre.didrik...@usit.uio.no: Er enig i at multipolygoner må gjøres på en litt enklere måte. Selv om det egentlig er løst på en fin måte her så blir det for komplisert for mange når man skal gjøre endringer i ettertid. Jeg tror også at det er best om man i hovedsak bruker dette på åpninger i f.eks. skog som så igjen har tagg for myr, vann eller hva det er i denne åpningen. Og så bør ytre way være en hel way, med mindre man støter på grensen på 2000 punkter som er et problem på store vann etc. Dette vil medføre at man delvis har to eller flere ways som ligger oppå hverandre, men det ser jeg ikke på som noe problem. Se f.eks. på https://www.openstreetmap.org/relation/4531318. Her burde det nok vært en ytre way, men den er delt opp i mange små. -Sverre On Mon, 2015-02-02 at 10:59 +0100, N/A N/A wrote: Det vil ikkje fungere. Då må ein legge inn data slik som sosi2osm lagar det og det vert det kaos. For eit polygon er det rett og slett ikkje råd og få lagt inn rett dato då det som sagt kan vere opp til fleire ulike datoar på ulike delar. Einaste multipoly relasjon som bør brukast er når det f.eks. er opningar i skog osv. Ein må ikkje legge inn eit polygon som fleire ways med relasjon der ways er medlem av ein anna multipoly relasjon. Dette vil berre føre til rot når folk som ikkje har peiling på relasjonar endrar på ting. Er fleire eksempel på dette rundt om kring. Dato vil kun fungere for stream/river, då desse er kun way frå starten, så det er lite poeng. Det beste er at ein legg inn source:date for den dagen sosi fila var lasta ned frå Kartverket i change set description. Ta ein titt på Voss Kommune. Vil meine at slik data er lagt inn her vil vere det beste kompromisset. Her er det multipolygon kun når ein må for å få det til å fungere. Der inner av skog er eit heilt polygon så taggar eg det med typen areal som f.eks. farmland. Der det er brytning mellom skog rutene, eller der eit anna areal ikkje fult deler med skogen, så må eg lage separat polygon og ikkje ein ny relasjon der er deler opp i ways. http://www.openstreetmap.org/way/307392530#map=17/60.75943/6.49934layers=D http://www.openstreetmap.org/way/307392548#map=17/60.75513/6.50088layers=D Måtte dele opp ein del av rutene med skog frå kartverket då dei enda opp med over 2000 punkt. For min del kunne vi lagt inn data som sosi2osm lagar det, men det ville nok ikkje DWG ha godteke. Hadde spart oss mykje arbeid og ein slepp at svært mange polygon deler punkt. Det hadde vorte ekstremt mange relasjonar som eg tvilar på ville fungert. Voss Kommune åleine er bygd opp av over 11000 relasjonar i råfila frå sosi2osm. __ Date: Mon, 2 Feb 2015 08:12:46 +0100 Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 From: torstein...@gmail.com To: gazer2...@hotmail.com CC: kart@nuug.no Enig. Så bare veiene i relasjonene bør ha dato og ikke relasjonen som helhet. Torstein On Feb 1, 2015 11:17 PM, N/A N/A gazer2...@hotmail.com wrote: Å setje source:date for eit polygon in OSM er nesten umulig å få til utan at alle polygon må delast opp og leggjast inn som relasjon. Dette fordi f.eks. ein innsjø kan ha 2-3 ulike datoar på ulike delar av omrisset. Merka meg at myr områder ofte er frå andre halvdel av 70-talet mens skog kan vere frå 80 og 90 talet. Så kjem elvar og jordbruk som er av endå nyare dato. Når desse grensar til kvarandre på fleire delar så blir det ikkje lett å få til. __ From: torstein...@gmail.com Date: Sun, 1 Feb 2015 22:59:29 +0100 To: gom...@gmail.com CC: kart@nuug.no Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 Takk for innspillene. 1. Jeg endrer source til Kartverket N50. Dette for å skille det fra tidligere import av N5000 (og fremtidige). Jeg synes source:date bør settes til datoen for DATAFANGSTDATO på hvert element. Dette siden den vil variere på import settet. 2. Fikset 3. Kystlinje er nå fjernet. 4. Forklaring forbedret. En kan vurdere å ta ut xxxReplaced.osm da denne genereres i punkt 9 for oppdatert data og kun det valgte området. Evt. kan man kjøre splitter direkte på xxxReplaced.osm og laste opp den resulterende
Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50
Det høres smart ut å forenkle veiene i multipolygoner. Ulempen med at veier overlapper når to multipolygoner grenser mot hverandre er at det blir mer tungvindt seinere å endre denne grensen. For eksempel skogkant mot vannkant. Hvis man endrer vannkanten må man endre skogkanten også. Hvis de bruker felles vei, endres begge hvis man endrer en av dem. Husk også at mange av veiene blir skogkant mot skogkant for å unngå veldig store multipolygoner. Jeg skal se på hvordan man kan slå sammen veier i et multipolygon. Problemet er å unngå at sammenslåelser i vannimporten ikke skaper problemer for arealdekke-importen (det blir ikke et problem hvis man bruker en ytre vei og en vei per indre polygon). Torstein On Feb 2, 2015 2:12 PM, Sverre Didriksen sverre.didrik...@usit.uio.no wrote: Er enig i at multipolygoner må gjøres på en litt enklere måte. Selv om det egentlig er løst på en fin måte her så blir det for komplisert for mange når man skal gjøre endringer i ettertid. Jeg tror også at det er best om man i hovedsak bruker dette på åpninger i f.eks. skog som så igjen har tagg for myr, vann eller hva det er i denne åpningen. Og så bør ytre way være en hel way, med mindre man støter på grensen på 2000 punkter som er et problem på store vann etc. Dette vil medføre at man delvis har to eller flere ways som ligger oppå hverandre, men det ser jeg ikke på som noe problem. Se f.eks. på https://www.openstreetmap.org/relation/4531318. Her burde det nok vært en ytre way, men den er delt opp i mange små. -Sverre On Mon, 2015-02-02 at 10:59 +0100, N/A N/A wrote: Det vil ikkje fungere. Då må ein legge inn data slik som sosi2osm lagar det og det vert det kaos. For eit polygon er det rett og slett ikkje råd og få lagt inn rett dato då det som sagt kan vere opp til fleire ulike datoar på ulike delar. Einaste multipoly relasjon som bør brukast er når det f.eks. er opningar i skog osv. Ein må ikkje legge inn eit polygon som fleire ways med relasjon der ways er medlem av ein anna multipoly relasjon. Dette vil berre føre til rot når folk som ikkje har peiling på relasjonar endrar på ting. Er fleire eksempel på dette rundt om kring. Dato vil kun fungere for stream/river, då desse er kun way frå starten, så det er lite poeng. Det beste er at ein legg inn source:date for den dagen sosi fila var lasta ned frå Kartverket i change set description. Ta ein titt på Voss Kommune. Vil meine at slik data er lagt inn her vil vere det beste kompromisset. Her er det multipolygon kun når ein må for å få det til å fungere. Der inner av skog er eit heilt polygon så taggar eg det med typen areal som f.eks. farmland. Der det er brytning mellom skog rutene, eller der eit anna areal ikkje fult deler med skogen, så må eg lage separat polygon og ikkje ein ny relasjon der er deler opp i ways. http://www.openstreetmap.org/way/307392530#map=17/60.75943/6.49934layers=D http://www.openstreetmap.org/way/307392548#map=17/60.75513/6.50088layers=D Måtte dele opp ein del av rutene med skog frå kartverket då dei enda opp med over 2000 punkt. For min del kunne vi lagt inn data som sosi2osm lagar det, men det ville nok ikkje DWG ha godteke. Hadde spart oss mykje arbeid og ein slepp at svært mange polygon deler punkt. Det hadde vorte ekstremt mange relasjonar som eg tvilar på ville fungert. Voss Kommune åleine er bygd opp av over 11000 relasjonar i råfila frå sosi2osm. __ Date: Mon, 2 Feb 2015 08:12:46 +0100 Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 From: torstein...@gmail.com To: gazer2...@hotmail.com CC: kart@nuug.no Enig. Så bare veiene i relasjonene bør ha dato og ikke relasjonen som helhet. Torstein On Feb 1, 2015 11:17 PM, N/A N/A gazer2...@hotmail.com wrote: Å setje source:date for eit polygon in OSM er nesten umulig å få til utan at alle polygon må delast opp og leggjast inn som relasjon. Dette fordi f.eks. ein innsjø kan ha 2-3 ulike datoar på ulike delar av omrisset. Merka meg at myr områder ofte er frå andre halvdel av 70-talet mens skog kan vere frå 80 og 90 talet. Så kjem elvar og jordbruk som er av endå nyare dato. Når desse grensar til kvarandre på fleire delar så blir det ikkje lett å få til. __ From: torstein...@gmail.com Date: Sun, 1 Feb 2015 22:59:29 +0100 To: gom...@gmail.com CC: kart@nuug.no Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 Takk for innspillene. 1. Jeg endrer source til Kartverket N50. Dette for å skille det fra tidligere import av N5000 (og fremtidige). Jeg synes source:date bør settes til datoen for DATAFANGSTDATO på
Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50
Det der er akkurat det vi må unngå. Den relasjonen er svært sårbar når folk utan erfaring med relasjonar gjer endringar i området. Ser ut til at denne brukaren har berre importert data rett frå råfila. Spent å sjå kor lenge det går før noko i Meråker er øydelagt :) From: sverre.didrik...@usit.uio.no To: gazer2...@hotmail.com CC: kart@nuug.no Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 Date: Mon, 2 Feb 2015 13:11:54 + Er enig i at multipolygoner må gjøres på en litt enklere måte. Selv om det egentlig er løst på en fin måte her så blir det for komplisert for mange når man skal gjøre endringer i ettertid. Jeg tror også at det er best om man i hovedsak bruker dette på åpninger i f.eks. skog som så igjen har tagg for myr, vann eller hva det er i denne åpningen. Og så bør ytre way være en hel way, med mindre man støter på grensen på 2000 punkter som er et problem på store vann etc. Dette vil medføre at man delvis har to eller flere ways som ligger oppå hverandre, men det ser jeg ikke på som noe problem. Se f.eks. på https://www.openstreetmap.org/relation/4531318. Her burde det nok vært en ytre way, men den er delt opp i mange små. -Sverre On Mon, 2015-02-02 at 10:59 +0100, N/A N/A wrote: Det vil ikkje fungere. Då må ein legge inn data slik som sosi2osm lagar det og det vert det kaos. For eit polygon er det rett og slett ikkje råd og få lagt inn rett dato då det som sagt kan vere opp til fleire ulike datoar på ulike delar. Einaste multipoly relasjon som bør brukast er når det f.eks. er opningar i skog osv. Ein må ikkje legge inn eit polygon som fleire ways med relasjon der ways er medlem av ein anna multipoly relasjon. Dette vil berre føre til rot når folk som ikkje har peiling på relasjonar endrar på ting. Er fleire eksempel på dette rundt om kring. Dato vil kun fungere for stream/river, då desse er kun way frå starten, så det er lite poeng. Det beste er at ein legg inn source:date for den dagen sosi fila var lasta ned frå Kartverket i change set description. Ta ein titt på Voss Kommune. Vil meine at slik data er lagt inn her vil vere det beste kompromisset. Her er det multipolygon kun når ein må for å få det til å fungere. Der inner av skog er eit heilt polygon så taggar eg det med typen areal som f.eks. farmland. Der det er brytning mellom skog rutene, eller der eit anna areal ikkje fult deler med skogen, så må eg lage separat polygon og ikkje ein ny relasjon der er deler opp i ways. http://www.openstreetmap.org/way/307392530#map=17/60.75943/6.49934layers=D http://www.openstreetmap.org/way/307392548#map=17/60.75513/6.50088layers=D Måtte dele opp ein del av rutene med skog frå kartverket då dei enda opp med over 2000 punkt. For min del kunne vi lagt inn data som sosi2osm lagar det, men det ville nok ikkje DWG ha godteke. Hadde spart oss mykje arbeid og ein slepp at svært mange polygon deler punkt. Det hadde vorte ekstremt mange relasjonar som eg tvilar på ville fungert. Voss Kommune åleine er bygd opp av over 11000 relasjonar i råfila frå sosi2osm. __ Date: Mon, 2 Feb 2015 08:12:46 +0100 Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 From: torstein...@gmail.com To: gazer2...@hotmail.com CC: kart@nuug.no Enig. Så bare veiene i relasjonene bør ha dato og ikke relasjonen som helhet. Torstein On Feb 1, 2015 11:17 PM, N/A N/A gazer2...@hotmail.com wrote: Å setje source:date for eit polygon in OSM er nesten umulig å få til utan at alle polygon må delast opp og leggjast inn som relasjon. Dette fordi f.eks. ein innsjø kan ha 2-3 ulike datoar på ulike delar av omrisset. Merka meg at myr områder ofte er frå andre halvdel av 70-talet mens skog kan vere frå 80 og 90 talet. Så kjem elvar og jordbruk som er av endå nyare dato. Når desse grensar til kvarandre på fleire delar så blir det ikkje lett å få til. __ From: torstein...@gmail.com Date: Sun, 1 Feb 2015 22:59:29 +0100 To: gom...@gmail.com CC: kart@nuug.no Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 Takk for innspillene. 1. Jeg endrer source til Kartverket N50. Dette for å skille det fra tidligere import av N5000 (og fremtidige). Jeg synes source:date bør settes til datoen for DATAFANGSTDATO på hvert element. Dette siden den vil variere på import settet. 2. Fikset 3. Kystlinje er nå fjernet. 4. Forklaring forbedret. En kan vurdere å ta ut xxxReplaced.osm da denne genereres i punkt 9 for oppdatert data og kun det
Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50
Ideelt sett så går det heilt fint, men berre så lenge det kun er folk som har full kontroll på relasjonar. Men når folk som ikkje har peiling gjer endringar via iD eller Potlatch så skal det lite til før det går galt her. Ein lite tabbe her så får det store følgjefeil då alt heng saman via relasjonar. Date: Mon, 2 Feb 2015 14:35:39 +0100 From: reitst...@gmail.com To: sverre.didrik...@usit.uio.no CC: kart@nuug.no Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 Når det gjelder https://www.openstreetmap.org/relation/4531318, så mener jeg at denne bør bestå av flere way'er. Alternativt måtte det bli flere overlappende way'er, da myra deler grense med både åpent område og skog på forskjellige steder. Når jeg ser på denne i JOSM, ser den ut til å være perfekt oppdelt. - Ola Endre 2015-02-02 14:11 GMT+01:00 Sverre Didriksen sverre.didrik...@usit.uio.no: Er enig i at multipolygoner må gjøres på en litt enklere måte. Selv om det egentlig er løst på en fin måte her så blir det for komplisert for mange når man skal gjøre endringer i ettertid. Jeg tror også at det er best om man i hovedsak bruker dette på åpninger i f.eks. skog som så igjen har tagg for myr, vann eller hva det er i denne åpningen. Og så bør ytre way være en hel way, med mindre man støter på grensen på 2000 punkter som er et problem på store vann etc. Dette vil medføre at man delvis har to eller flere ways som ligger oppå hverandre, men det ser jeg ikke på som noe problem. Se f.eks. på https://www.openstreetmap.org/relation/4531318. Her burde det nok vært en ytre way, men den er delt opp i mange små. -Sverre On Mon, 2015-02-02 at 10:59 +0100, N/A N/A wrote: Det vil ikkje fungere. Då må ein legge inn data slik som sosi2osm lagar det og det vert det kaos. For eit polygon er det rett og slett ikkje råd og få lagt inn rett dato då det som sagt kan vere opp til fleire ulike datoar på ulike delar. Einaste multipoly relasjon som bør brukast er når det f.eks. er opningar i skog osv. Ein må ikkje legge inn eit polygon som fleire ways med relasjon der ways er medlem av ein anna multipoly relasjon. Dette vil berre føre til rot når folk som ikkje har peiling på relasjonar endrar på ting. Er fleire eksempel på dette rundt om kring. Dato vil kun fungere for stream/river, då desse er kun way frå starten, så det er lite poeng. Det beste er at ein legg inn source:date for den dagen sosi fila var lasta ned frå Kartverket i change set description. Ta ein titt på Voss Kommune. Vil meine at slik data er lagt inn her vil vere det beste kompromisset. Her er det multipolygon kun når ein må for å få det til å fungere. Der inner av skog er eit heilt polygon så taggar eg det med typen areal som f.eks. farmland. Der det er brytning mellom skog rutene, eller der eit anna areal ikkje fult deler med skogen, så må eg lage separat polygon og ikkje ein ny relasjon der er deler opp i ways. http://www.openstreetmap.org/way/307392530#map=17/60.75943/6.49934layers=D http://www.openstreetmap.org/way/307392548#map=17/60.75513/6.50088layers=D Måtte dele opp ein del av rutene med skog frå kartverket då dei enda opp med over 2000 punkt. For min del kunne vi lagt inn data som sosi2osm lagar det, men det ville nok ikkje DWG ha godteke. Hadde spart oss mykje arbeid og ein slepp at svært mange polygon deler punkt. Det hadde vorte ekstremt mange relasjonar som eg tvilar på ville fungert. Voss Kommune åleine er bygd opp av over 11000 relasjonar i råfila frå sosi2osm. __ Date: Mon, 2 Feb 2015 08:12:46 +0100 Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 From: torstein...@gmail.com To: gazer2...@hotmail.com CC: kart@nuug.no Enig. Så bare veiene i relasjonene bør ha dato og ikke relasjonen som helhet. Torstein On Feb 1, 2015 11:17 PM, N/A N/A gazer2...@hotmail.com wrote: Å setje source:date for eit polygon in OSM er nesten umulig å få til utan at alle polygon må delast opp og leggjast inn som relasjon. Dette fordi f.eks. ein innsjø kan ha 2-3 ulike datoar på ulike delar av omrisset. Merka meg at myr områder ofte er frå andre halvdel av 70-talet mens skog kan vere frå 80 og 90 talet. Så kjem elvar og jordbruk som er av endå nyare dato. Når desse grensar til kvarandre på fleire delar så blir det ikkje lett å få til. __ From: torstein...@gmail.com Date: Sun, 1 Feb 2015 22:59:29 +0100 To: gom...@gmail.com CC: kart@nuug.no Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 Takk for innspillene. 1. Jeg endrer source til Kartverket N50. Dette for å skille det fra tidligere import
Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50
Det vil ikkje fungere. Då må ein legge inn data slik som sosi2osm lagar det og det vert det kaos. For eit polygon er det rett og slett ikkje råd og få lagt inn rett dato då det som sagt kan vere opp til fleire ulike datoar på ulike delar. Einaste multipoly relasjon som bør brukast er når det f.eks. er opningar i skog osv. Ein må ikkje legge inn eit polygon som fleire ways med relasjon der ways er medlem av ein anna multipoly relasjon. Dette vil berre føre til rot når folk som ikkje har peiling på relasjonar endrar på ting. Er fleire eksempel på dette rundt om kring. Dato vil kun fungere for stream/river, då desse er kun way frå starten, så det er lite poeng. Det beste er at ein legg inn source:date for den dagen sosi fila var lasta ned frå Kartverket i change set description. Ta ein titt på Voss Kommune. Vil meine at slik data er lagt inn her vil vere det beste kompromisset. Her er det multipolygon kun når ein må for å få det til å fungere. Der inner av skog er eit heilt polygon så taggar eg det med typen areal som f.eks. farmland. Der det er brytning mellom skog rutene, eller der eit anna areal ikkje fult deler med skogen, så må eg lage separat polygon og ikkje ein ny relasjon der er deler opp i ways. http://www.openstreetmap.org/way/307392530#map=17/60.75943/6.49934layers=D http://www.openstreetmap.org/way/307392548#map=17/60.75513/6.50088layers=D Måtte dele opp ein del av rutene med skog frå kartverket då dei enda opp med over 2000 punkt. For min del kunne vi lagt inn data som sosi2osm lagar det, men det ville nok ikkje DWG ha godteke. Hadde spart oss mykje arbeid og ein slepp at svært mange polygon deler punkt. Det hadde vorte ekstremt mange relasjonar som eg tvilar på ville fungert. Voss Kommune åleine er bygd opp av over 11000 relasjonar i råfila frå sosi2osm. Date: Mon, 2 Feb 2015 08:12:46 +0100 Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 From: torstein...@gmail.com To: gazer2...@hotmail.com CC: kart@nuug.no Enig. Så bare veiene i relasjonene bør ha dato og ikke relasjonen som helhet. Torstein On Feb 1, 2015 11:17 PM, N/A N/A gazer2...@hotmail.com wrote: Å setje source:date for eit polygon in OSM er nesten umulig å få til utan at alle polygon må delast opp og leggjast inn som relasjon. Dette fordi f.eks. ein innsjø kan ha 2-3 ulike datoar på ulike delar av omrisset. Merka meg at myr områder ofte er frå andre halvdel av 70-talet mens skog kan vere frå 80 og 90 talet. Så kjem elvar og jordbruk som er av endå nyare dato. Når desse grensar til kvarandre på fleire delar så blir det ikkje lett å få til. From: torstein...@gmail.com Date: Sun, 1 Feb 2015 22:59:29 +0100 To: gom...@gmail.com CC: kart@nuug.no Subject: Re: [NUUG kart] Import av elver, bekker og vann fra statkart N50 Takk for innspillene. 1. Jeg endrer source til Kartverket N50. Dette for å skille det fra tidligere import av N5000 (og fremtidige). Jeg synes source:date bør settes til datoen for DATAFANGSTDATO på hvert element. Dette siden den vil variere på import settet.2. Fikset3. Kystlinje er nå fjernet.4. Forklaring forbedret. En kan vurdere å ta ut xxxReplaced.osm da denne genereres i punkt 9 for oppdatert data og kun det valgte området. Evt. kan man kjøre splitter direkte på xxxReplaced.osm og laste opp den resulterende filen direkte. Hilsen Torstein 1. februar 2015 kl. 21.27 skrev Geir Ove Myhr gom...@gmail.com: Hei! Fint du har lagt ut ferdiglagde OSM-filer. Det gjør det mye lettere å sjekke. Jeg tror også det er lurt å begrense N50-uttaket til én datatype om gangen slik du har tenkt. Det gjør det lettere å sjekke de objektene som importeres. Jeg har et par kommentarer i første omgang: 1. Jeg ser du bruker source=statkart N50 og source:date=* på alle ways og relasjoner. Her bør det vel settes source=Kartverket og eventuelt source:date=-MM-DD om relevant, og de bør settes på endringssettet istedenfor på alle objektene slik det er beskrevet på http://wiki.openstreetmap.org/wiki/No:Kartverket_import. 2. Jeg ser at det er en del små vann som er multipolygoner som består en én way som igjen består av et fåtall noder. Det virker på meg unødvendig komplisert å bruke en relasjon i disse tilfellene. 3. Kystlinjene har generelt litt spesiell behandling i OSM, sikkert mest fordi de tilsammen er såpass lange. Det hadde kanskje vært lurt å ta dem inn som en egen kystlinje-import som kun fokuserte på denne. 4. I punkt 3 på https://wiki.openstreetmap.org/wiki/User:Tibnor/N50import#Ved_hver_import er det uklart for meg hva som menes med beskrivelsen av xxxReplaced.osm. 2015-02-01 11:47 GMT+01:00 Torstein Ingebrigtsen Bø torstein...@gmail.com: Hei, jeg fikk liten respons så jeg prøver igjen. Nå har jeg lagd en ny versjon der det meste av arbeidet er gjort på forhånd og lagret på min google drive. Nå kreves kun python og ikke sosi2osm. Er det noen som har tilbakemeldinger? Anvisningen finnes fortsatt på
Re: [NUUG kart] Størrelse på skogsrelasjoner
Om dette gjeld små bitar av eit polygon som er i ein anna kommune så ville eg berre slå dei saman med den store delen i nabokommunen. Kan du linke til desse små multipolygonane? Greit for å vere sikker på at vi forstår kvarandre ;) Date: Mon, 2 Feb 2015 09:58:52 +0100 From: anders.foug...@gmail.com To: kart@nuug.no Subject: Re: [NUUG kart] Størrelse på skogsrelasjoner Jeg synes at det er mer komplisert å jobbe med mange bittesmå skogrelasjoner enn færre, litt større relasjoner. I N50-utdragene jeg har sett er det veldig mange små multipolygoner nær grensen til nabokommunen. Og grenselinjene mellom polygonene går typisk i rette linjer, som fører til at både vann og jorder typisk er delt i to bittesmå multipolygoner. I forbindelse med den importen jeg har gjort rundt Oppdal har hoveddelen av arbeidet vært manuelt arbeid for å fjerne duplikater langs grensene mellom multipolygonene, ettersom jeg har tatt for meg én og én del av kommunen, og én og én arealtype (skog, vann, bekk, elv osv). Mye av dette arbeidet slipper man dersom polygonene er større/sammenslått. Jeg ville derfor foretrukket om de små områdene var slått sammen, bare for å spare arbeid. Det går imidlertid an å dele dem opp igjen etterpå...og da kanskje helst på en måte som ikke skjærer rett gjennom samtlige små vann o.l. som bare gjør det mer komplekst. Å slå sammen til enorme skogpolygoner er ikke noe poeng — jeg tenker mer på de små multipolygonene med 1–20 medlemmer. Anders -- anders.foug...@gmail.com +47 97158863 Sent from my Commodore 64 Den 02.02.15 09.27, skrev Sverre Didriksen: Jeg tror heller ikke det er noen god ide å slå sammen relasjonene ved import. Da vil de strekke seg over så store områder og bli såpass kompliserte at jeg tror faren er stor for at det gjøres feil når man i ettertid skal endre på ting. Jeg har en følelse av at mange sliter litt med relasjoner, spesielt når de er store og kompliserte. Jeg ser stadig relasjoner med feil og det er egentlig ikke så bra. -Sverre On Sat, 2015-01-31 at 18:57 +0100, N/A N/A wrote: Problemet er at eit polygon ikkje kan ha meir enn 2000 punkt. Eg måtte dele opp til fleire slike ruter frå N50 i to delar for at det ikkje skulle bli for mange punkt. Så det å slå saman ruter blir nok ikkje lett. Går vel kanskje der heile sida av ei rute består av meir skog. Eg har ikkje vore borti så store skogområder endå. Alle rutene der eg har arbeidd har grensa til høgfjellet så det å slå saman vil ikkje gå då det vert over 2000 punkt. Eg vil meine at det er enklare å arbeide med mindre relasjonar. Enklare å halde oversikt. Gazer75 __ From: torstein...@gmail.com Date: Sat, 31 Jan 2015 12:18:41 +0100 To: kart@nuug.no Subject: [NUUG kart] Størrelse på skogsrelasjoner Hei, Når man tegner skog kan relasjonene fort bli store (mange medlemmer). I N50 serien deles polygonene ved hver 0.05 bredde- og lengdegrad. Dette gir mange små relasjoner (2-50 medlemmer) og noen få mellomstore relasjoner (50-200 medlemmer). Hvis man slår disse sammen får man gjerne VELDIG store relasjoner (for Meråker ble det et på over 4000 medlemmer). Wikien sier at man bør unngå at relasjonene inneholder mer enn 300 medlemmer (http://wiki.openstreetmap.org/wiki/Relation). Jeg har lagd et script som slår sammen de minste relasjonene med nabo relasjoner, slik at man unngår veldig mange små relasjoner (2-20 medlemmer). Da blir relasjonene på typisk 50 - 200 medlemmer. Så mitt spørsmål er: ved import av N50 data, bør man slå sammen relasjoner til større relasjoner på rundt 50 - 200 medlemmer. Eller bør man la dataen være uforandret og beholde 0.05x0.05 rutenettet med mange små relasjoner? Hilsen tibnor ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart
Re: [NUUG kart] Kunnskapsløshetsvandalisme
Jeg opplever også det samme av og til. Det er ganske håpløst når man har lagt ned mye arbeid i å gjøre ting nøyaktig. Jeg har vurdert å sette opp en form for varsling hver gang objekter jeg har lagt inn blir endret. Utenom det så vet jeg ikke helt hva man kan gjøre. -Sverre On Sat, 2015-01-31 at 00:23 +0100, N/A N/A wrote: Blir nok berre meir og meir av dette jo fleire som bidreg til OSM. Burde nesten vore verifisering for nye slik at ein slepp slikt. Mest vanlege eg har vore borti er folk som brukar Bing. Bing er veldig 50/50 her i landet. Ein del plassar der folk har øydelagt store områder som var godt kartlagt med gps og andre data. Nesten så ei burde blokkere Bing for brukarar som ikkje har ein viss mengde gode endringar. Er spesielt mange iD og Potlatch brukarar som lagar trøbbel med Bing traces. Date: Fri, 30 Jan 2015 23:25:57 +0100 From: vibrog+...@gmail.com To: kart@nuug.no Subject: [NUUG kart] Kunnskapsløshetsvandalisme Jeg opplever så ofte at ting jeg har arbeidet med i OSM er herpet fordi nye bidragsytere har gjort rare ting. Overraskende ofte blir ting slettet helt og tegnet på ny, med det resultat at tagging som ikke vises på standardrendringen ikke er tatt med, relasjonsmedlemskap er borte, ruskete kvalitet, osv. Jeg savner gode verktøy for å tracke endringer i bestemte temaer. Bestemt tagging og relasjoner innenfor et område, feks. Noen som har tips til dette? Alternativet er å sette opp min egen kartdatabase og jobbe lokalt. ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart
Re: [NUUG kart] Kunnskapsløshetsvandalisme
Burde vera mogleg å argumentera https://github.com/openstreetmap/iD/issues for at Bing er slått av som standard når iD blir opna for eit kartutsnitt med senter nord eller sør for SRTM-grensene. Ellers har vel både Potlatch og JOSM åtvaringar om bruk av satellitt-bilete? Ellers er kanskje det ein funksjon som kunne hjelpa? Eg har før argumentert for ein del nye funksjonar som liknar MediaWiki, t.d. diskusjon av endringssett som no er implementert. Innebygd endringsvarsling er også ein funksjon som trengs, dersom det ikkje fins noko bug/issue https://github.com/openstreetmap/openstreetmap-website/issues for det endå så burde nokon oppretta det og så kan me andre bidra med argument og «stemmer». -- Guttorm 31. januar 2015 kl. 00.23 skrev N/A N/A gazer2...@hotmail.com: Blir nok berre meir og meir av dette jo fleire som bidreg til OSM. Burde nesten vore verifisering for nye slik at ein slepp slikt. Mest vanlege eg har vore borti er folk som brukar Bing. Bing er veldig 50/50 her i landet. Ein del plassar der folk har øydelagt store områder som var godt kartlagt med gps og andre data. Nesten så ei burde blokkere Bing for brukarar som ikkje har ein viss mengde gode endringar. Er spesielt mange iD og Potlatch brukarar som lagar trøbbel med Bing traces. Date: Fri, 30 Jan 2015 23:25:57 +0100 From: vibrog+...@gmail.com To: kart@nuug.no Subject: [NUUG kart] Kunnskapsløshetsvandalisme Jeg opplever så ofte at ting jeg har arbeidet med i OSM er herpet fordi nye bidragsytere har gjort rare ting. Overraskende ofte blir ting slettet helt og tegnet på ny, med det resultat at tagging som ikke vises på standardrendringen ikke er tatt med, relasjonsmedlemskap er borte, ruskete kvalitet, osv. Jeg savner gode verktøy for å tracke endringer i bestemte temaer. Bestemt tagging og relasjoner innenfor et område, feks. Noen som har tips til dette? Alternativet er å sette opp min egen kartdatabase og jobbe lokalt. ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart
Re: [NUUG kart] Størrelse på skogsrelasjoner
Jeg synes at det er mer komplisert å jobbe med mange bittesmå skogrelasjoner enn færre, litt større relasjoner. I N50-utdragene jeg har sett er det veldig mange små multipolygoner nær grensen til nabokommunen. Og grenselinjene mellom polygonene går typisk i rette linjer, som fører til at både vann og jorder typisk er delt i to bittesmå multipolygoner. I forbindelse med den importen jeg har gjort rundt Oppdal har hoveddelen av arbeidet vært manuelt arbeid for å fjerne duplikater langs grensene mellom multipolygonene, ettersom jeg har tatt for meg én og én del av kommunen, og én og én arealtype (skog, vann, bekk, elv osv). Mye av dette arbeidet slipper man dersom polygonene er større/sammenslått. Jeg ville derfor foretrukket om de små områdene var slått sammen, bare for å spare arbeid. Det går imidlertid an å dele dem opp igjen etterpå...og da kanskje helst på en måte som ikke skjærer rett gjennom samtlige små vann o.l. som bare gjør det mer komplekst. Å slå sammen til enorme skogpolygoner er ikke noe poeng — jeg tenker mer på de små multipolygonene med 1–20 medlemmer. Anders -- anders.foug...@gmail.com +47 97158863 Sent from my Commodore 64 Den 02.02.15 09.27, skrev Sverre Didriksen: Jeg tror heller ikke det er noen god ide å slå sammen relasjonene ved import. Da vil de strekke seg over så store områder og bli såpass kompliserte at jeg tror faren er stor for at det gjøres feil når man i ettertid skal endre på ting. Jeg har en følelse av at mange sliter litt med relasjoner, spesielt når de er store og kompliserte. Jeg ser stadig relasjoner med feil og det er egentlig ikke så bra. -Sverre On Sat, 2015-01-31 at 18:57 +0100, N/A N/A wrote: Problemet er at eit polygon ikkje kan ha meir enn 2000 punkt. Eg måtte dele opp til fleire slike ruter frå N50 i to delar for at det ikkje skulle bli for mange punkt. Så det å slå saman ruter blir nok ikkje lett. Går vel kanskje der heile sida av ei rute består av meir skog. Eg har ikkje vore borti så store skogområder endå. Alle rutene der eg har arbeidd har grensa til høgfjellet så det å slå saman vil ikkje gå då det vert over 2000 punkt. Eg vil meine at det er enklare å arbeide med mindre relasjonar. Enklare å halde oversikt. Gazer75 __ From: torstein...@gmail.com Date: Sat, 31 Jan 2015 12:18:41 +0100 To: kart@nuug.no Subject: [NUUG kart] Størrelse på skogsrelasjoner Hei, Når man tegner skog kan relasjonene fort bli store (mange medlemmer). I N50 serien deles polygonene ved hver 0.05 bredde- og lengdegrad. Dette gir mange små relasjoner (2-50 medlemmer) og noen få mellomstore relasjoner (50-200 medlemmer). Hvis man slår disse sammen får man gjerne VELDIG store relasjoner (for Meråker ble det et på over 4000 medlemmer). Wikien sier at man bør unngå at relasjonene inneholder mer enn 300 medlemmer (http://wiki.openstreetmap.org/wiki/Relation). Jeg har lagd et script som slår sammen de minste relasjonene med nabo relasjoner, slik at man unngår veldig mange små relasjoner (2-20 medlemmer). Da blir relasjonene på typisk 50 - 200 medlemmer. Så mitt spørsmål er: ved import av N50 data, bør man slå sammen relasjoner til større relasjoner på rundt 50 - 200 medlemmer. Eller bør man la dataen være uforandret og beholde 0.05x0.05 rutenettet med mange små relasjoner? Hilsen tibnor ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart ___ kart mailing list kart@nuug.no http://lists.nuug.no/mailman/listinfo/kart
