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

Zac Spitzer zac.spitzer at gmail.com
Sun Jul 11 22:00:24 EDT 2010


What about a CheckPolygonVertexOrder in FdoSpatialUtility?



On 12 July 2010 11:53, Leaf Li <leaf.li at autodesk.com> wrote:
> 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
>



-- 
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
http://www.ennoble.com.au
http://zacster.blogspot.com
+61 405 847 168


More information about the fdo-internals mailing list