[fdo-internals] RE: FDO RFC 48 - Polygon Vertex Order is ready for review.

[Traian Stanev]

OK, so maybe I am misunderstanding: does "enforced" mean that the provider is enforcing this internally (either in provider code, or by the backend database), or the FDO client application is checking the capability and enforcing this, in case the provider returns "strict".


Traian


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Leaf Li
Sent: Sunday, July 11, 2010 9:54 PM
To: fdo-internals at lists.osgeo.org
Subject: [fdo-internals] RE: FDO RFC 48 - Polygon Vertex Order is ready for review.

Hi Traian,

Thanks for you question. I answer them in lines.

Thanks,
Leaf Li

Date: Thu, 8 Jul 2010 21:55:35 -0700
From: Traian Stanev <traian.stanev at autodesk.com>
Subject: RE: [fdo-internals] FDO RFC 48 - Polygon Vertex Order is
	ready for	review.
To: "'fdo-internals at lists.osgeo.org'" <fdo-internals at lists.osgeo.org>
Message-ID:
	<D20FC5C02CA4AB41891CFE76D91C57A970718D0962 at ADSK-NAMSG-02.MGDADSK.autodesk.com>
	
Content-Type: text/plain; charset="us-ascii"

Hi

I have some concerns with the class capabilities part of the RFC.

The class capabilities will introduce the vertex order hint and the strictness setting. Introducing the vertex order hint will result in many existing SDF files (for example) having the "wrong" vertex order, since there are many SDF files which started life as SHP files.

[Leaf] I agree that the vertex order is a hint if the strictness isn't enforced. However. the "wrong" vertex order isn't caused by introducing the vertex order. They are wrong because they polygon geometry doesn't follow the vertex order rule defined by feature source. Because the vertex order is a hint, whether the vertex order is "wrong" or "correct" is a hint too if the strictness isn't enforced. If you want, you can keep FDO geometry as is. Vertex order rule defined in the class capabilities will not force you do anything.

The above means that having the vertex order hint is not useful for many SDF files (and also many SHP files written out by applications which don't enforce winding order, and also other formats), and the consuming application will have to fix the vertex order if it really cares. MapGuide for example does not care - it can render polygons with any winding you give it. So the vertex order hint seems like it will only add confusion. An application which does care will have to ignore the vertex order capability, since it is not really true (as described above). Hence the vertex order setting is not useful for both applications which do care about vertex order and for applications which don't care about it.

[Leaf] Solution proposed in this RFC isn't to provide a tool to fix the vertex order "error" of a feature. I already mentioned in RFC that we are not going to change the current strategy of FDO Provider to fix polygon vertex order error automatically by FDO Provider. However, users can create a tool to fix the polygon order errors based on vertex order and strictness rule defined in the class capabilities and two utility methods provided in class FdoSpatialUtility.
So my answer to your question is that you create a simple method to fix the polygon vertex order error based on RFC 48 if you care about the vertex order. If not, RFC 48 doesn't change your application at all and just ignore it.

The strictness hint is also problematic. Most providers will use the "not enforced" setting, which means that you can still store any kind of polygon in them. In fact only one data source (and not in all cases) requires strict vertex order - SQL Server. All other cases would mean per-provider coding of strictness enforcement in case we want "enforced" vertex order.

[Leaf] Hard-coding vertex order rule and strictness rule at FDO client application is doable. If the client application handle one kind of data source, it isn't too bad. However, it is a bad idea if the client application handle many types of data source. FDO API should have capability to tell user what the current FDO provider's vertex order and strictness rule are.

Yes. Currently we found SQL Server Spatial is really enforced only. However, we may find more enforced feature source in the future when introducing more and more FDO provider. So how to handle it at that time for the FDO client application? Hard-coded again?

Moreover, I am thinking changing SHP enforced we get lots of complain from users about the wrong vertex order in SHP file. Actually FME SHP FDO Provider is a strict feature source because it corrects the vertex order of polygons when inserting and modifying a feature.

Currently, my suggestions for their capabilities are as follows.

Provider	    Vertex Order	Strictness
WFS           CCW     	Not enforced
SQLite         CCW     	Not enforced
SHP           CW       	Enforced
SDF           CCW     	Not enforced
ArcSDE        CCW     	Not enforced
ODBC         None   	Not enforced
MySQL        CCW     	Not enforced
PostGIS       CCW    	Not enforced
Oracle        CCW   	    Not enforced
SQLSpatial
  Geometry   CCW   	Not enforced 
  Geography   CCW  	Enforced
OGR		
  SHP        CW      	Enforced
  Others     CCW    	Not enforced 


So, if the capability provides no correct information about vertex order and no meaningful enforcement of vertex order, is it needed at all?
[Leaf] They are meaningful. Please see my comments above.

Traian



From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Leaf Li
Sent: Tuesday, July 06, 2010 6:15 AM
To: fdo-internals at lists.osgeo.org
Subject: [fdo-internals] FDO RFC 48 - Polygon Vertex Order is ready for review.

All,

FDO RFC 48 - Polygon Vertex Order is ready for review. Can you review it?
http://trac.osgeo.org/fdo/wiki/FDORfc48

Thanks,
Leaf Li
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals