[NUUG kart] [Ny] Lagring av N50 import i OSM - multipolygon eller lukkede ways?
Solhagen
solhagen at telefiber.no
Thu Jun 5 23:10:26 CEST 2014
Hei alle importører.
Jeg har kunnskaper om SOSI data og struktur, og føler et ansvar for å
delta i importen av N50 Arealdekke til OSM.
Men jeg er usikker på hvordan OSM gjengen ønsker å gjøre dette.
SOSI og OSM bruker nokså lik struktur på data.
SOSI er slik: Flater -> består av flere kurver med punkt
OSM er slik: a) Multipolygon -> består av flere ways -> består av flere
nodes
eller: b) lukkede ways -> består av flere noder.
Flate i SOSI viser til nummer på Kurve (way) som er del av omkrets. En
øy i flata er nummerert negativ.
Multipolygon i OSM gjør det samme, men her er omkretsen kodet som
"outer" og øya er "inner"
Underforstått: Flater = multipolygon og Kurver = ways og punkt = nodes.
På dette nivået er det lett å oversette fra SOSI til OSM.
For a) gjelder: Alle ways blir bare lagret en gang. Flere multipolygon
kan bruke samme way.
For b) gjelder: Ways blir lagret for hver lukket way. De kan ha felles
grense med naboareal, og bruker da felles nodes.
Andre kartformat som shape lagrer data etter prinsipp b).
Fordeler / ulemper:
* a) tar nok mindre plass i databasen
* b) er lettere å forstå
* a) er mer avansert.
* b) er enklere å importere (shape)
* Programmer som bruker eksporter fra OSM kan fungere dårlig med a)
multipolygon, og forutsetter f.eks at innsjøer bare er omkretset av
natural=water, og ikke waterway=weir.
* b) kan medføre at det er vanskeligere å snappe eller gripe tak i
rett way når det ligger dobbelt.
Særtrekk ved N50 SOSI data:
* Myrer og vann er lagret sammenhengende som en flate (multipolygon).
* Fjell, skog osv er oppdelt i et rutenett som følger lat/lon
rutenett. Oppdelingen skjer med objekttype "FiktivDelelinje"
Kommunegrense skjer med "DataAvgrensing" (for kommunevise filer).
Disse har vi ikke motsvarende tagger for i OSM.
* Fjell, skog, myrer osv er omkretset av felles type:
"Arealbrukgrense", og ikke egne linjer (ways). Vann har egen kode
for omkretsen, men denne kan også danne en myrkant eller skogkant.
Eksempel: en opptelling av SOSI data for N50 Arealdekke i Vinje kommune
blir slik:
Tema Antall Objekttype Punkt Kurve Tekst
Flater Hull/Annet
3101 53654 . . . 0 53654
0 0 0
3101 34955 Innsjø 0 0
0 34955 0
3109 457 InnsjøElvSperre 0 457 0
0 0
3110 20 InnsjøInnsjøSperre 0 20 0
0 0
3201 36809 ElvBekk 0 36019 0
790 0
3202 4606 ElvBekkKant 0 4606 0
0 0
3221 29 FerskvannTørrfallkant 0 29 0
0 0
3221 28 FerskvannTørrfall 0 0
0 28 0
3311 7 SnøIsbre 0 0
0 7 0
4102 96 Steinbrudd 0 0 0
96 0
4110 66798 Arealbrukgrense 0 66798 0 0
0
4121 23 Gravplass 0 0
0 23 0
4131 64 SportIdrettPlass 0 0 0
64 0
4134 3 Golfbane 0
0 0 3 0
4152 16 Steintipp 0
0 0 16 0
4401 6243 Skog 0 0
0 6243 0
4403 4881 Tregruppe 4881 0 0
0 0
4451 3216 DyrketMark 0 0 0
3216 0
4461 31303 Myr 0
0 0 31303 0
4499 11702 ÅpentOmråde 0 0 0
11702 0
5021 3 BymessigBebyggelse 0 0 0
3 0
5022 96 TettBebyggelse 0 0
0 96 0
6319 12 Alpinbakke 0 0
0 12 0
7900 2 Lufthavn 0
0 0 2 0
9111 4840 KantUtsnitt 0 4840 0
0 0
9111 63176 . . . 0
0 0 0 63176
9199 8395 FiktivDelelinje 0 8395
0 0 0
---- ------ ---------------------- -----
----- ----- ------- -------
SUM: 331486 4881 174853
0 88576 63176
Jeg har gjort et par forsøk på komplett import etter prinsipp a). her:
http://www.openstreetmap.org/#map=14/59.6896/8.0668
Spørsmålet er: Skal vi satse på import av komplett arealdekke for
områder med mye multipolygon og små databaser eller skal vi satse på
import av tema for tema (først vann, så skog, så myr, så dyrka mark...)
slik at det blir mye doble ways og data som er enklere å forstå?
Før jeg fortsetter min import, vil jeg gjerne vite hva som er gjeldende
politikk.
Mvh
Svein Olav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nuug.no/pipermail/kart/attachments/20140605/fc457c82/attachment.htm
More information about the kart
mailing list