[NUUG kart] Import av elver, bekker og vann fra statkart N50
Ola Endre Reitstøen
reitstoen at gmail.com
Wed Feb 4 18:55:44 CET 2015
(glemte reply all)
Du har helt rett Sverre. Jeg var for kjapp når jeg sjekket relasjonen. La
ikke merke til at det hadde gått en oppdelinslinje gjennom den østlige
delen av myra, der den sammenhengene kun deler way med skog. My bad!
Jeg mente selvfølgelig at det kun skal være forskjellige veier der den
grenser til forskjellige andre relsjoner. Det er vel helst der hvor det har
vært delingslinjer hvor en kan slå sammen flere veier.
- Ola Endre
On Wednesday, February 4, 2015, Sverre Didriksen <
sverre.didriksen at usit.uio.no> wrote:
> 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 <javascript:;>>:
> > 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 <javascript:;>> 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 <javascript:;>
> > > > To: gazer2175 at hotmail.com <javascript:;>
> > > > CC: kart at nuug.no <javascript:;>
> > > >
> > > >
> > > >
> > > > 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 <javascript:;>>
> > > 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 <javascript:;>
> > > > Date: Sun, 1 Feb 2015 22:59:29 +0100
> > > > To: gomyhr at gmail.com <javascript:;>
> > > > CC: kart at nuug.no <javascript:;>
> > > > 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 <javascript:;>>:
> > > > 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
> <javascript:;>>:
> > > > > 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
> <javascript:;>>
> > > > > Dato: 29. januar 2015 kl. 19.13
> > > > > Emne: Import av elver, bekker og
> > vann fra
> > > statkart
> > > > N50
> > > > > Til: "kart at nuug.no <javascript:;>"
> > <kart at nuug.no <javascript:;>>
> > > > >
> > > > >
> > > > > 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 <javascript:;>
> > > > >
> > http://lists.nuug.no/mailman/listinfo/kart
> > > > >
> > > >
> > > >
> > > >
> > > >
> > _______________________________________________ kart
> > > mailing
> > > > list kart at nuug.no <javascript:;>
> > > http://lists.nuug.no/mailman/listinfo/kart
> > > >
> > > >
> > _______________________________________________
> > > > kart mailing list
> > > > kart at nuug.no <javascript:;>
> > > > http://lists.nuug.no/mailman/listinfo/kart
> > > >
> > > > _______________________________________________
> > > > kart mailing list
> > > > kart at nuug.no <javascript:;>
> > > > http://lists.nuug.no/mailman/listinfo/kart
> > >
> > > _______________________________________________
> > > kart mailing list
> > > kart at nuug.no <javascript:;>
> > > http://lists.nuug.no/mailman/listinfo/kart
> >
> >
> >
> >
>
> _______________________________________________
> kart mailing list
> kart at nuug.no <javascript:;>
> http://lists.nuug.no/mailman/listinfo/kart
>
--
mvh
Ola Endre Reitstøen
http://www.reitstoen.com
reitstoen at gmail.com
(+47) 977 11 639
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nuug.no/pipermail/kart/attachments/20150204/b90e84bc/attachment-0001.htm
More information about the kart
mailing list