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

[Benjamin Ducke]

Hi Wolfgang, the bleeding occurs because some segments
of the polygon have been digitized in counter-clockwise direction. 
In order to fill a  polygon, the GIS needs to know which side of a 
line segment represents the inside, and which represents the outside.
ArcView (and perhaps some others) do that by checking whether
a pixel lies on the left or right of a line. But if the
line direction is wrong, than that check will fail and the wrong
side (outside) will be filled = bleeding.
Other GIS, like gvSIG, have more accurate ways of deciding between
inside and outside pixels, so there is no bleeding. If you want to
fix the problem in the data, there should be a tool in the
Geoprocessing toolbox (available if you installed the Topology
Extension), which allows you to flip line directions.

Cheers,

Ben

----- Original Message -----
From: "Wolfgang Qual" <wolfgang.qual at muenchen.de>
To: "Users and Developers mailing list" <gvsig_internacional at listserv.gva.es>
Sent: Wednesday, February 17, 2010 1:19:05 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [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 
_______________________________________________
Gvsig_internacional mailing list
Gvsig_internacional at listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional



------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.