[Gvsig_english] clean polygon? Issue with layers imported fromOracle Spatial

[Rahkonen Jukka]

Hi,
 
It is not a surprise that such features come from Oracle - ring orientation is defined just opposite in Oracle and shapefiles.  See http://www.spatialdbadvisor.com/sql_server_blog/123/loading-shapefiles-into-geography-type-column-in-sql-server-2008/ and the links.
 
Shapefile writer should orientate rings according to shapefile rules. Perhaps gvSIG fails in this.
 
-Jukka Rahkonen-
 
 

	Wolfgang Qual  wrote:
	
	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/5695d858/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 590 bytes
Desc: logo_b.gif
Url : http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20100217/5695d858/attachment.gif