[fdo-users] MPolygon <-> FDO

[Gavin Cramer]

Hi, Dennis.  MPolygon allows rings to be slightly open, while FDO does not.  Your data contains rings whose starting and ending positions have not been latched.  Closing any of these slightly open rings will be required during conversion.  That is all that there needs to be to this issue.

Your examples were useable to create CurveString instances.  However, creating Ring values will require that the X and Y ordinates of the start/end positions match.  There are lots of cases where datatype conversion requires adaptations in conversion code.  In fact, your own code, which computes the mid positions for arcs, is already such a case.

If you want to make a case for more flexibility should be allowed for the reading of existing real-world data, you can propose it.  The requirement for any Z ordinates to match at ring ends was removed in a previous release.  While the FGF data format does redundantly store starting and ending positions of rings, changing the matching requirement could introduce defects in code that assumed the closedness of rings, however.  Plus, some database formats may still require correctly closed rings, even if FDO does not catch it.

Gavin


-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of djonio
Sent: Saturday, March 08, 2008 6:47 AM
To: fdo-users at lists.osgeo.org
Subject: RE: [fdo-users] MPolygon <-> FDO


1) ...."it would be a good precaution to add code to coerce the starting and
ending positions of each ring to match exactly.  That is, the last position
of the last curve segment should be assigned as a copy of the first position
of the first curve segment."
2)... "floating point drift"
3) .... "Overriding the last XY ordinates (using the first ones) used to
create the geometry should fix this."

I am not the brightest bulb on the tree but it looks like CurveString and
Ring are pretty much broken. At best they are totally unreliable.

Gavin,
In rereading this thread it would appear you have know all along that these
methods are a best, flawed. Ok, I can take a little "guided discovery". Not
the most time conserving approach to learning but, OK.

What are the plans to fix these methods?

dennis



Hi, Dennis.  Sorry for the delay.  Yes, trying to create CurveStrings is a
good test, and easy since both the Ring and CurveString types are created
from a CurveStringCollection.

While text conversions can hide small floating point drift, I can see some
drift in your first case.  The last X value is -9.50149754820001, with that
trailing 0001 being drift.  This CurveString would probably return false in
its "IsClosed" method.  Overriding the last XY ordinates (using the first
ones) used to create the geometry should fix this.

Gavin

--
View this message in context: http://www.nabble.com/MPolygon-%3C-%3E-FDO-tp15873165s18162p15912844.html
Sent from the fdo-users mailing list archive at Nabble.com.

_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users