[NUUG kart] Import av elver, bekker og vann fra statkart N50
Torstein Ingebrigtsen Bø
torsteinibo at gmail.com
Wed Feb 4 10:15:44 CET 2015
Det er jeg som har gjort importen (som nevnt tidligere). Enig i at slike
oppdelinger er unødvendig. Derfor jobber jeg med å lage et script som
kobler sammen veier som har like tagger og linker til relasjoner. Da blir
slike unødvendige oppdelinger fjernet uten at det blir et problem ved
senere importer. :-)
Hilsen
Torstein
4. februar 2015 kl. 10.01 skrev Sverre Didriksen <
sverre.didriksen at usit.uio.no>:
> Det er helt klart god grunner for begge alternativene. Men uansett hva
> man velger så synes jeg at man ikke skal dele opp mer enn nødvendig.
>
> Jeg er ikke helt enig med deg Ola Endre at
> https://www.openstreetmap.org/relation/4531318 er perfekt oppdelt. Den
> er mer oppdelt enn nødvending selv om man ønsker å ha kun en vei mellom
> hvert område. Se f.eks. på grensen mellom myr og skog på østsiden av
> myra. Der er det mange veier med samme kildedato og disse kunne vært
> slått sammen. Det er veiene https://www.openstreetmap.org/way/324972593,
> https://www.openstreetmap.org/way/324971634,
> https://www.openstreetmap.org/way/324972681, osv jeg tenker på. Faktisk
> så trenger denne myra kun 6 ytre veier (såvidt jeg kan se i farten),
> mens den faktisk har 16 nå. Slår man de sammen så blir det ganske
> perfekt. For det er ikke noe tvil om at det er gjort et meget godt
> stykke arbeid her som med litt finpuss kan bli meget bra.
>
> Dere kan jo for sammenligningens skyld se på en av mine manuelle
> importer. Etter konvertering til osm-format kopierer jeg inn et og et
> polygon. Da har jeg full kontroll på flettingen med gamle data. Her er
> alle polygoner hele og da med overlappende veier via de samme punktene
> der denne myra grenser mot skog. Se
> https://www.openstreetmap.org/way/317621986.
>
> -Sverre
>
>
>
> On Tue, 2015-02-03 at 18:18 +0100, Torstein Ingebrigtsen Bø wrote:
> > Sant nok. Jeg ser på wikien at dette er et omdiskutert spørsmål:
> >
> http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Mapping_Style.2C_best_practice
> >
> >
> > Begge metodene er godkjente så kan ikke skjønne at DWG (data working
> > group) kan sette ned foten for å bruke filen fra sosi2osm (gitt at
> > multipolygoner med en vei blir gjort om til et polygon).
> >
> >
> > Personlig liker jeg bedre å ha flere delveier, siden vi da beholder
> > informasjonen om datainnsamlingstidspunkt for veiene. Si for eksempel
> > at en seinere ønsker å oppdatere gamle skoggrenser (da igjengroing er
> > et problem for kart). Da kan man søke etter gamle data og oppdatere
> > denne. Hvis vi går for en felles ytre vei mister vi denne muligheten.
> > Jeg ser tror også fremtidig oppdatering bassert på N50 blir mye
> > vanskeligere hvis vi bruker en ytre. Siden en da må flette inn
> > oppdaterte delveier inn i den store ytre veien, istedenfor å bytte ut
> > del veier.
> >
> > Hilsen
> > Torstein
> >
> >
> >
> > On Mon, 2015-02-02 at 14:35 +0100, Ola Endre Reitstøen wrote:
> > 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
> >
> >
> >
> > 2. februar 2015 kl. 16.36 skrev Sverre Didriksen
> > <sverre.didriksen at usit.uio.no>:
> > Veiene går via de samme punktene der multipolygonene grenser
> > mot
> > hverandre så det er like lett å endre som om det var en vei.
> > Flytter du
> > punktene så flytter du begge veiene.
> >
> > -Sverre
> >
> >
> > On Mon, 2015-02-02 at 14:43 +0100, Torstein Ingebrigtsen Bø
> > wrote:
> > > 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.didriksen at 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.49934&layers=D
> > > >
> > >
> >
> http://www.openstreetmap.org/way/307392548#map=17/60.75513/6.50088&layers=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: torsteinibo at gmail.com
> > > > To: gazer2175 at hotmail.com
> > > > CC: kart at 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"
> > <gazer2175 at 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: torsteinibo at gmail.com
> > > > Date: Sun, 1 Feb 2015 22:59:29 +0100
> > > > To: gomyhr at gmail.com
> > > > CC: kart at 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 filen
> > > > direkte.
> > > >
> > > > Hilsen
> > > > Torstein
> > > >
> > > > 1. februar 2015 kl. 21.27 skrev Geir Ove
> > Myhr
> > > > <gomyhr at 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=YYYY-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ø
> > > > <torsteinibo at 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å
> > > > >
> > > >
> > >
> > https://wiki.openstreetmap.org/wiki/User:Tibnor/N50import
> > > > >
> > > > > Hilsen
> > > > > Torstein I. Bø
> > > > >
> > > > > ---------- Videresendt e-post
> > ----------
> > > > > Fra: Torstein Ingebrigtsen Bø
> > > > <torsteinibo at gmail.com>
> > > > > Dato: 29. januar 2015 kl. 19.13
> > > > > Emne: Import av elver, bekker og
> > vann fra
> > > statkart
> > > > N50
> > > > > Til: "kart at nuug.no"
> > <kart at nuug.no>
> > > > >
> > > > >
> > > > > Hei,
> > > > >
> > > > > Jeg har i det siste jobbet med å
> > lage en
> > > metode for
> > > > å importere data for
> > > > > arealdekke.sosi fra N50 serien.
> > Jeg har
> > > gjort en
> > > > prøveimport av data for
> > > > > Meråker
> > > >
> > >
> > (http://www.openstreetmap.org/#map=13/63.4971/12.0551). Jeg
> > > har lagd
> > > > > noen skript som skal minke feil
> > og
> > > arbeidsmengden
> > > > under importering
> > > > >
> > > (https://github.com/tibnor/kartverket2osm).
> > > > Forslaget for importmetode
> > > > > finnes på
> > > >
> > >
> > https://wiki.openstreetmap.org/wiki/User:Tibnor/N50import
> > > > >
> > > > > Merk at jeg har lagd skript både
> > for å
> > > sette
> > > > rettning på elver og bekker
> > > > > (basert på høydedata). Det er
> > også et
> > > script for å
> > > > ta flette eksisterende
> > > > > data med import data, for å
> > unngå
> > > duplikater.
> > > > >
> > > > > Som dere ser på Meråker importen
> > har jeg
> > > også
> > > > importert arealdekke. Metoden
> > > > > for dette er veldig lik metoden
> > for å
> > > importere
> > > > vann/elv/bekker, så jeg
> > > > > kommer med metode for dette
> > seinere. Av
> > > erfaring bør
> > > > man importere disse
> > > > > hver for seg.
> > > > >
> > > > > Hilsen
> > > > > Torstein I. Bø
> > > > > tibnor
> > > > >
> > > > >
> > > >
> > > > >
> > > _______________________________________________
> > > > > kart mailing list
> > > > > kart at nuug.no
> > > > >
> > http://lists.nuug.no/mailman/listinfo/kart
> > > > >
> > > >
> > > >
> > > >
> > > >
> > _______________________________________________ kart
> > > mailing
> > > > list kart at nuug.no
> > > http://lists.nuug.no/mailman/listinfo/kart
> > > >
> > > >
> > _______________________________________________
> > > > kart mailing list
> > > > kart at nuug.no
> > > > http://lists.nuug.no/mailman/listinfo/kart
> > > >
> > > > _______________________________________________
> > > > kart mailing list
> > > > kart at nuug.no
> > > > http://lists.nuug.no/mailman/listinfo/kart
> > >
> > > _______________________________________________
> > > kart mailing list
> > > kart at nuug.no
> > > http://lists.nuug.no/mailman/listinfo/kart
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nuug.no/pipermail/kart/attachments/20150204/86644fba/attachment-0001.htm
More information about the kart
mailing list