[NUUG kart] Håndtering av frigitt kartdata
Sverre Didriksen
sverre.didriksen at usit.uio.no
Sat Oct 5 00:09:56 CEST 2013
Jeg synes det bør være litt info om importering av data på den norske
hovedsiden for særnorske tagger. Så jeg har tatt med den frihet å opprette
et lite avsnitt om det.
Kom gjerne med tilbakemeldinger om vi bør ha dette, hvor det bør ligge,
hvilken informasjon som bør være med, osv.
http://wiki.openstreetmap.org/wiki/No:Map_Features#Importere_data
-Sverre
Tormod Nygård wrote on 03.10.2013 22:29:20:
>
> Jeg har gjort det samme som Kristian selv.
>
> Med vennlig hilsen
> Tormod Nygård
>
>
> On Wed, 2013-10-02 at 18:32 +0200, Kristian Nyborg Dahl wrote:
> > Jeg har selv gjort små justeringer på noen corine-objekter blant annet
> > alene for å gi plass til andre objekter. Yttergrensene til disse
> > corine-objektene ble med det ikke nevneverdig bedre. Tror man bør
> > erstatte mer enn bare de som ikke er blitt endret. Derimot er jeg
> > usikker på hvordan en løsning i tilfelle ville sett ut.
> >
> >
> > -Kristian
> >
> >
> >
> >
> > On Wed, 02 Oct 2013 11:37:41 +0200, Sverre Didriksen
> > <sverre.didriksen at usit.uio.no> wrote:
> >
> >
> > Jeg støtter også at Corine-objekter som ikke er endret
> > erstattes. Sjekker man da bare på source-taggen eller vi med
> > endret-dato også? Jeg tror ikke alle er like flinke til å
> > endre source.
> >
> > Jeg synes at vann som er autogenerert med denne skan etter
> > vann-roboten også kan erstattes om de ikke er endret. Det er
> > en del av de. Dette gjelder også kystlinjedeler og øyer også.
> >
> > Når det gjelder objekter som krysser kommunegrenser så kan vi
> > kanskje si at hele objektet alltid skal oppdateres, så den som
> > først legger inn noe tar det selv om det går inn i
> > nabokommunen. Og som det blir sagt så er det polygoner dette
> > bør gjelde for. For linjer spiller dette liten rolle.
> >
> > Støtter at vi må ha en wiki. Litt info om tagging må inn og en
> > oversikt kanskje over hva som tas av hvem. Kanskje med en
> > ansvarlig for hver kommune? Vi kan jo lage en liste og så kan
> > vi bare ha førstemann til mølla-prinsipp f.eks. Det er jo
> > kanskje greit at ikke flere holder på med det samme i samme
> > kommune, iallefall ikke uten at de kommuniserer hva som tas.
> >
> > Jeg synes kanskje det er tidlig å konkludere med hvordan vi
> > gjør dette. Er det ingen andre synspunkter?
> >
> > -Sverre
> >
> >
> >
> > Tyrfing OSM wrote on 02.10.2013 10:45:58:
> >
> > >
> > > Dersom man importerer kommunevis bør man vurdere hva man
> > gjør med
> > > objekter som krysser kommunegrensene. For veier (og andre
> > > linjebaserte objekt) er dette sikkert ikke et problem, men
> > f.eks.
> > > vann (eller andre polygon) som blir importert delvis kan
> > være en
> > > utfordring, ihvertfall dersom noen oppdaterer dem før
> > nabokommunen
> > > (e) blir importert.
> > >
> > > Jeg er enig i at Corine-objekter med fordel kan byttes ut.
> > > Ihvertfall dersom de ikke har blitt manuelt justert.
> > >
> > > Det er også mange andre kjekke objekter som bør inn. F.eks.
> > > kraftlinjer/kabler og demninger.
> > >
> > > Jeg testet litt med en helmanuell import igår (ved å merge
> > ned noen
> > > utvalgte objekter fra sosi-filene til osm). Noen nye
> > objekter og
> > > noen eksisterende der jeg erstattet geometrien. Ca her:
> > http://
> > > www.openstreetmap.org/#map=14/58.9538/6.6792
> > >
> > >
> > >
> > > 1. oktober 2013 kl. 21:56 skrev Espen Oldeman Lund
> > <espen at espenpost.com>:
> > > Så konklusjonen sålangt er å importere veier der det
> > mangler. Stier
> > > tas kun inn av lokalkjente. Vann og bekker(og sikkert myr)
> > > importeres der det er mangler eller dårligere data.
> > >
> > > All import er kanskje hensiktsmessig å gjøre kommunevis og
> > da med
> > > noen testkommuner i første omgang?
> > >
> > > Hva med arealobjekter som skog, jordbruk osv? Bør vi vurdere
> > å kaste
> > > ut Corine-objekter som ikke er endra og heller importere
> > skog fra N50?
> > >
> > > Vi trenger vel også å sette opp noe i wiki'en antar jeg slik
> > at vi
> > > har oversikt etterhvert.
> > >
> > > Espen
> > >
> > >
> >
> > > 2013/10/1 Sverre Didriksen <sverre.didriksen at usit.uio.no>
> > > Jeg tror også det er en god ide. Å ta alt som mangler og i
> > tillegg
> > > det som er grovt inntegnet f.eks. kan være en god modell.
> > Det er jo
> > > en del som er nøyaktig tegnet etter gode flyfoto, det er det
> > viktig
> > > å bevare. Det er ofte minst like bra som det Kartverket
> > har.
> > >
> > > -Sverre
> > >
> > >
> > > Tyrfing OSM wrote on 01.10.2013 15:54:53:
> > >
> > >
> > > >
> > > > Har sett litt på data for vatn og bekker. Endel bekker
> > renner
> > > > oppover, og enkelte vann ser litt omtrentlige ut når man
> > > > sammenlikner med GPS-spor eller Bing. Dvs. jeg tror en
> > manuell (evt
> > > > semimanuell for hvite områder) kan være en god idé.
> > > >
> > >
> > > >
> > > >
> > > > 30. september 2013 kl. 22:30 skrev Sverre Didriksen <
> > > > sverre.didriksen at usit.uio.no>:
> > > > Veier f.eks må vi være forsiktig med. Jeg har erfart at
> > det en del
> > > > steder er mye feil i Kartverkets data. Det er en del gamle
> > veier som
> > > > er igjengrodd og som ikke finnes, men som er i datasettene
> > til
> > > > Kartverket. En import av alle veier vil da kunne gjøre en
> > del skade.
> > > > Jeg tror en kommunevis manuell import vil være det beste,
> > helst
> > > > gjort av noen som er kjent. Men der hvor det er tynt med
> > data er nok
> > > > en import av alt det som mangler helt greit.
> > > >
> > > > -Sverre
> > > >
> > > >
> > > >
> > > > Espen Oldeman Lund <espen at espenpost.com> wrote on
> > 30.09.2013 22:06:45:
> > > >
> > > >
> > > > >
> > > > > Punkt 2 og 3 flyter vel kanskje litt over i hverandre.
> > Men med punkt
> > > > > 3 så tenkte jeg at det ikke var noe organisert
> > importering. Det
> > > > > betyr jo i praksis at det vil ta lang til å importere
> > aktuelle data.
> > > >
> > > > >
> > > > > Jeg tenker i farta at ting som myr og vann bør kunne tas
> > inn litt
> > > > > mer organisert og se hva som har best nøyaktighet og hva
> > som
> > > > > eventuelt mangler i OSM. Veier likeså. Mens f. eks.
> > stier kanskje
> > > > > kun bør importeres av lokalkjente som veit at stien
> > faktisk går der.
> > > > > Stier i N50 har jo ganske varierende kvalitet.
> > > > >
> > > > > Punktene mine var forøvrig kun for å ha noe å diskutere
> > etter, så ta
> > > > > de med en klype salt :-)
> > > > >
> > > > > Espen
> > > > >
> > > > >
> > > >
> > > > > 2013/9/30 Sverre Didriksen
> > <sverre.didriksen at usit.uio.no>
> > > > > Espen Oldeman Lund wrote on 30.09.2013 21:29:05:
> > > > >
> > > > > >
> > > > > > Hei!
> > > > > >
> > > > > > Som dere ser så har jeg sendt en forespørsel til
> > Kartverket om bruk
> > > > > > av de nylig frigitte dataene i OSM. Men som tidligere
> > nevnt så tyder
> > > > > > alt på at data kan brukes i OSM, så jeg tenkte at vi
> > bør begynne å
> > > > > > diskutere hvordan vi håndterer dette framover.
> > > > > >
> > > > > > Det er i hovedsak vbase(veger) og N50 som er aktuelt å
> > bruke i OSM.
> > > > > >
> > > > > > Jeg tenker at de i grove trekk er fire måter og
> > håndtere disse
> > > > dataene på:
> > > > > > 1. Importere direkte uten å se på konflikter
> > > > > > 2. Importere med en mer eller mindre automatisk
> > prosess
> > > > > > 3. Ingen import, men en prosess der hver enkelt OSM'er
> > plukker ut
> > > > > > elementer for sitt lokale område og legger inn i OSM
> > > > > > 4. Ignorere dataene og ikke bruke de i OSM
> > > > > >
> > > > > > Hvilken framgangsmåte som velges avhenger sjølsagt av
> > datasettet.
> > > > > >
> > > > > > N50 inneholder jo en drøss av ulike data så før en går
> > igjennom
> > > > > > detaljene på de, så synes jeg det hadde vært fint å
> > fått generelle
> > > > > > kommentarer fra OSM'er på hvordan vi skal håndtere
> > disse dataene.
> > > > > >
> > > > >
> > > >
> > > > > Hei
> > > > >
> > > > > Jeg synes det er viktig å ikke "ødelegge" noe som ligger
> > i OSM. Det
> > > > > betyr i praksis at dataene dtort sett må flettes slik at
> > vi ikke
> > > > > overskriver noe eller får doble objekter. Selvfølgelig
> > må man også
> > > > > vurdere om nøyaktigheten på noe av det Kartverket har er
> > bedre og at
> > > > > man da tar inn data for å korrigere.
> > > > >
> > > > > Jeg tror derfor at punkt 3 er mest aktuell for de fleste
> > typer
> > > > > elementer, men det finnes unntak. Et av unntakene er
> > kanskje
> > > > > kommune- og fylkesgrenser.
> > > > >
> > > > > -Sverre
> > > > >
> > > >
> > > > >
> > > > > --
> > > > > http://www.turkompisen.no
> > > > > http://www.kresendo.no/
> > > > > http://no.linkedin.com/in/espenisaksen
> > > > >
> > > >
> > > > _______________________________________________
> > > > 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
> >
> > >
> >
> > >
> > > --
> > > http://www.turkompisen.no
> > > http://www.kresendo.no/
> > > http://no.linkedin.com/in/espenisaksen
> > >
> >
> > > _______________________________________________
> > > kart mailing list
> > > kart at nuug.no
> > > http://lists.nuug.no/mailman/listinfo/kart
> >
> >
> >
> > --
> > Using Opera's mail client: http://www.opera.com/mail/
> > _______________________________________________
> > 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/20131005/e257fa30/attachment-0001.htm
More information about the kart
mailing list