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 < [email protected]>: > 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 > > <[email protected]>: > > 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" > > > <[email protected]> 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: [email protected] > > > > To: [email protected] > > > > CC: [email protected] > > > > > > > > > > > > > > > > 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" > > <[email protected]> > > > 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: [email protected] > > > > Date: Sun, 1 Feb 2015 22:59:29 +0100 > > > > To: [email protected] > > > > CC: [email protected] > > > > 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 > > > > <[email protected]>: > > > > 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ø > > > > <[email protected]>: > > > > > 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ø > > > > <[email protected]> > > > > > Dato: 29. januar 2015 kl. 19.13 > > > > > Emne: Import av elver, bekker og > > vann fra > > > statkart > > > > N50 > > > > > Til: "[email protected]" > > <[email protected]> > > > > > > > > > > > > > > > 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 > > > > > [email protected] > > > > > > > http://lists.nuug.no/mailman/listinfo/kart > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ kart > > > mailing > > > > list [email protected] > > > http://lists.nuug.no/mailman/listinfo/kart > > > > > > > > > > _______________________________________________ > > > > kart mailing list > > > > [email protected] > > > > http://lists.nuug.no/mailman/listinfo/kart > > > > > > > > _______________________________________________ > > > > kart mailing list > > > > [email protected] > > > > http://lists.nuug.no/mailman/listinfo/kart > > > > > > _______________________________________________ > > > kart mailing list > > > [email protected] > > > http://lists.nuug.no/mailman/listinfo/kart > > > > > > > > > >
_______________________________________________ kart mailing list [email protected] http://lists.nuug.no/mailman/listinfo/kart
