[Gfoss] e' un shape file valido?

Local Chapters GFOSS.it
1

Ciao a tutti,

Penso che cmf2shp abbia un problema dove poligoni hanno buchi. Chiedo
aiuto per capire se il file sia valido come poligono con un bucho. Un
sempio minimo e' allegato. Avete idea che e' andato storto?

Ho seguito la ricetta di Thuban per creare shapes con buchi da python
http://wald.intevation.org/plugins/scmsvn/viewcvs.php/branches/WIP-pyshapelib-Unicode/thuban/libraries/pyshapelib/pytest.py?rev=2799&root=thuban&view=markup

In qGIS si vede il confine del buco ma non sembra un buco ma penso di
aver testato nel passato con ArcMap dove si vede il bucho..

shp2postgres lo traduce in un Multipolygon con due parti senza bucho:

"MULTIPOLYGON(((1663684.82 4729154.48,1663709.67 4729173.43,1663713.46
4729176.02,1663719.02 4729181.8,1663725.42 4729187.79,1663730.93
4729193.35,1663734.98 4729197.02,1663757.91 4729170.52,1663784.31
4729142.92,1663767.38 4729135.55,1663754.72 4729128.86,1663750.7
4729122.62,1663747.59 4729117.38,1663735.58 4729105.79,1663712.11
4729083.15,1663684.82 4729154.48)),((1663717.76 4729094.6,1663716.96
4729090.92,1663711.02 4729092.16,1663711.79 4729095.97,1663717.76
4729094.6)))"

e shpdump dice:

$ shapelib-winbin-1.2.9/shpdump testOut2/GB-TEST.shp
Shapefile Type: Polygon # of Shapes: 1

File Bounds: ( 1663684.820, 4729083.150,0,0)
         to ( 1663784.310, 4729197.020,0,0)

Shape:0 (Polygon) nVertices=21, nParts=2
  Bounds:( 1663684.820, 4729083.150, 0, 0)
      to ( 1663784.310, 4729197.020, 0, 0)
     ( 1663684.820, 4729154.480, 0, 0) Ring
     ( 1663709.670, 4729173.430, 0, 0)
     ( 1663713.460, 4729176.020, 0, 0)
     ( 1663719.020, 4729181.800, 0, 0)
     ( 1663725.420, 4729187.790, 0, 0)
     ( 1663730.930, 4729193.350, 0, 0)
     ( 1663734.980, 4729197.020, 0, 0)
     ( 1663757.910, 4729170.520, 0, 0)
     ( 1663784.310, 4729142.920, 0, 0)
     ( 1663767.380, 4729135.550, 0, 0)
     ( 1663754.720, 4729128.860, 0, 0)
     ( 1663750.700, 4729122.620, 0, 0)
     ( 1663747.590, 4729117.380, 0, 0)
     ( 1663735.580, 4729105.790, 0, 0)
     ( 1663712.110, 4729083.150, 0, 0)
     ( 1663684.820, 4729154.480, 0, 0)
   + ( 1663717.760, 4729094.600, 0, 0) Ring
     ( 1663716.960, 4729090.920, 0, 0)
     ( 1663711.020, 4729092.160, 0, 0)
     ( 1663711.790, 4729095.970, 0, 0)
     ( 1663717.760, 4729094.600, 0, 0)

--
Bud P. Bruegger, Ph.D. +39-0564-488577 (voice), -21139 (fax)
   European Chair, Global Collaboration Forum on eID
   Chair, Porvoo Subgroup on collab. govs/operating systems
   Leader of the Permanent eID Status Observatory (PESO) project
Servizio Elaborazione Dati e-mail: bud@comune.grosseto.it
Comune di Grosseto jabber: bud@jabber.no
Via Ginori, 43 http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/

test.tgz (607 Bytes)

2

Bud P. Bruegger ha scritto:

Ciao a tutti,

Penso che cmf2shp abbia un problema dove poligoni hanno buchi. Chiedo
aiuto per capire se il file sia valido come poligono con un bucho. Un
sempio minimo e' allegato. Avete idea che e' andato storto?

cmf2shp è il tuo python script che opera su file in cml, vero?

Ho seguito la ricetta di Thuban per creare shapes con buchi da python
http://wald.intevation.org/plugins/scmsvn/viewcvs.php/branches/WIP-pyshapelib-Unicode/thuban/libraries/pyshapelib/pytest.py?rev=2799&root=thuban&view=markup

In qGIS si vede il confine del buco ma non sembra un buco ma penso di
aver testato nel passato con ArcMap dove si vede il bucho..

In Qgis si vede.

shp2postgres lo traduce in un Multipolygon con due parti senza bucho:

Perchè senza buco? La prima parte è l'exterior ring...

"MULTIPOLYGON(((1663684.82 4729154.48,1663709.67 4729173.43,1663713.46
4729176.02,1663719.02 4729181.8,1663725.42 4729187.79,1663730.93
4729193.35,1663734.98 4729197.02,1663757.91 4729170.52,1663784.31
4729142.92,1663767.38 4729135.55,1663754.72 4729128.86,1663750.7
4729122.62,1663747.59 4729117.38,1663735.58 4729105.79,1663712.11
4729083.15,1663684.82 4729154.48)),

...mentre la seconda è un semplice (uno solo) interior ring

((1663717.76 4729094.6,1663716.96

4729090.92,1663711.02 4729092.16,1663711.79 4729095.97,1663717.76
4729094.6)))"

Si tratta di due poligoni sovrapposti: l'exterior ring è il poligono da
bucare, mentre l'interior ring (essendo in questo caso sovrapposto
all'exterior ring) è il buco. In definitiva, l'allegato rappresenta un
poligono con un buco. Sembra che sia tutto ok. Al limite, ti manca solo
come colmare il buco, mediante un'altra MULTIPOLYGON che
presenta solo l'exterior ring.

Ciao
Antonio

3

Ciao Antonio

On Wed, 16 Jan 2008 15:15:06 +0100
Antonio Falciano <afalciano@yahoo.it> wrote:

Bud P. Bruegger ha scritto:
> Ciao a tutti,
>
> Penso che cmf2shp abbia un problema dove poligoni hanno buchi. Chiedo
> aiuto per capire se il file sia valido come poligono con un bucho. Un
> sempio minimo e' allegato. Avete idea che e' andato storto?

cmf2shp è il tuo python script che opera su file in cml, vero?

Si, fin ora ho sopra semplificato, pensando che l'orientamento delle
vertici dei rings nel file CMF siano sempre uguali--ma sembra che
variano caso per caso.

Ho anche seguito le regole sul orientamento che ho trovato in un esempio
come creare poligoni con buchi in shapelib (da python). Dice che il
"main ring" deve essere clockwise e i rings dei buchi
counterclockwise. Ma questo non da i risultati buoni sembra... (in
qGIS non si vedono i buchi...)

Ora ho provato tutte le possibilita' e sembra che funzionano due
possibilita'... Devo ancora fare piu' di test...

-b