[Gvsig_english] clean polygon? Issue with layers imported from Oracle Spatial

[José Antonio Canalejo Alonso]

Hello Wolfgang,
with the extension "Topologia" [1] you can find where are errors in a data. This extension isn't an stable one but may could help you. You have 17 topology rules for polygons.
In Network Extension is a Clean function. I think only for lines (maybe Fran can give us more information).

[1] https://gvsig.org/web/projects/gvsig-desktop/devel

Regards
Jose

 --
José Antonio Canalejo Alonso
CSGIS
Email:jose.canalejo at csgis.de
Web: http://www.csgis.de




________________________________
De: Wolfgang Qual <wolfgang.qual at muenchen.de>
Para: Users and Developers mailing list <gvsig_internacional at listserv.gva.es>
Enviado: mié,17 febrero, 2010 13:19
Asunto: [Gvsig_english] clean polygon? Issue with layers imported from Oracle Spatial

Dear list,
I wonder whether you have observed "bleeding" polygons - this seems to
be an effect that only occurs when using ArcView 3.2 - bleeding means
that borders of
a polygon are ignored and the whole area of the view is filled. This
happens when zooming into the view and it seems to indicate that the
shapefile has some errors.
Within ArcView, shapefiles can be "repaired" using the command
[Shape].clean. From the manual of ArcView:

"Clean Polygon
Returns a Polygon that has the same vertices as aPolygon but is
"clean". A clean polygon is one that:
1. Has no self-intersections. This means that a segment belonging to
one ring may not intersect a segment belonging to another ring. The
rings of a polygon can touch each other at vertices, but not along
segments.
2. Has the inside of the polygon on the "correct" side of the line
which defines it. The neighborhood to the right of an observer walking
along the ring in vertex order is the inside of the polygon. Vertices
for a single, ringed polygon are, therefore, always in clockwise order.
Rings defining holes in these polygons have a counter-clockwise
orientation. "Dirty" polygons occur when the rings which define holes
in the polygon also go clockwise, which causes overlapping interiors."

These bleeding polygons especially appear with polygon layers that were
exported from our oracle spatial geodatabase - with gvSIG 1.9. However,
the "bleeding"-effect is only visible in ArcView, not gvSIG. Therefore,
one could say that this is not a real problem, just use gvSIG! Well,
this is not a good advice, as other departments/users are using
ESRI-solutions. I do not know what errors are causing this strange
bleeding effect, maybe someone of you knows why this is happening. The
command "clean" does help, but it is not available within gvSIG. Last
week, we found out that a layer created within gvSIG is rendered with
errors using the UMN Mapserver, although no errors are visible in gvSIG
([1], the first layer shows a narrow triangle) . If this layer is
loaded into ArcView 3.2, the bleeding effect can be observed. Once
"clean" is applied, the error will be fixed - both in ArcView AND UMN
Mapserver.

Therefoe, I would like to ask, a) whether this "bleeding" problem is
known and b) whether a "clean"-function is foreseen for gvSIG - or
could be implemented.

Any comments are appreciated very much.
Best,
Wolfgang
 
[1] http://maps.muenchen.de/rgu/test_bplan_shape?zoom=9&lat=5334209.93813&lon=4459255.64274&layers=B00TTT

-- 

 

 Wolfgang
Qual

  Referat
für Gesundheit und Umwelt
Umweltschutz
Umweltvorsorge
RGU-UW 11

Bayerstraße 28a
80335 München

Telefon +49 - 89 - 233 - 4 77 17
Telefax +49 - 89 - 233 - 4 77 05

http://www.muenchen.de/umweltatlas
uw11.rgu at muenchen.de
 
Bitte beachten Sie die Hinweise
zur elektronischen
Kommunikation mit der Landeshauptstadt München:
http://www.muenchen.de/ekomm 


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20100217/76918b4f/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_b.gif
Type: image/gif
Size: 590 bytes
Desc: not available
Url : http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20100217/76918b4f/attachment.gif