[NUUG kart] Håndtering av frigitt kartdata

Sverre Didriksen sverre.didriksen at usit.uio.no
Wed Oct 2 11:37:41 CEST 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nuug.no/pipermail/kart/attachments/20131002/a5df6a13/attachment.htm 


More information about the kart mailing list