Select to view content in your preferred language

True Curves = True Evil

10463
9
02-07-2012 01:45 PM
by Anonymous User
Not applicable
Original User: csny490

I am having some issues with "true curve" features.. true curves being polylines or polygons features that have loopy/circular Bezier curve-type geometry... These features appear to be fully supported in v9.3+ and actively created/preserved by many geoprocessing tools such as Buffer, Clip, Union, etc. However, I am finding that these true curve features are causing the creation of many small holes in my overlays (see first attachment). When present, these "holes" always appear adjacent to true curve geometry inputs in my overlay. I am guessing the issue is that the equations that represent the curve feature aren't being stored/interpolated at a high enough decimal precision so as to provide the "correct" output node locations for the overlaid geometry (see second attachment). My overlays are generally being done at a xy res of .0005 Meters and a xy tol of 1 ft (to minimize slivers). Granted that the "hole" issue is minimized by using a finer xy resolution.... but it seems to me the overlay algorithm should ensure correct/precise polygon adjacency and guard against these holes being created where no holes existed in the input features.

Some comments/questions:
1. I hate true curves, and wish they would just go away.
2. Is there still a not way to stop true curve features from being created in FGDBs / SDE (this is a rhetorical question)? For example, some way to specify that my buffer output is NOT to have curve features?
3. FYI to ESRI, these curve features are causing errors (holes) in the outputs of the overlay tools.
4. I bet a lot of GIS people don't know that these curve geometries are being created/propagated in the geoprocessing tools. It would be good to know under what tools/conditions the curve geometry is created and/or propagated.

Seems the only way I have come up with to avoid this issue is to export the feature classes that contain true curves to a shapefile, and then reimport them back to a FGDB.... I see the Densify tool now standard in v10.0 will convert the curve features to densified geometry (aka "traditional GIS geometry"), but it's a pain to have to do this extra step when it used to not be necessary... and how are you supposed to know what features have curve geometry in the 1st place? There does not appear (?) to be a way to discern true curve geometry via arcpy/Python scripting. Like I said, a Envr. setting to control this behavior (creation/propagation of curve features) would be ideal...

[ATTACH=CONFIG]11778[/ATTACH]
[ATTACH=CONFIG]11777[/ATTACH]
9 Replies
by Anonymous User
Not applicable
Original User: ken2472

Would you be able to share your case with us for investigation?  We'll need the tool with the exact tool parameters you used, as well as a copy of the data.

If you need information on how to upload to our ftp site, please let me know.

Thanks,
Ken
ESRI Geoprocessing Senior Product Engineer
0 Kudos
ChrisSnyder
Honored Contributor
Sure, I forget the ESRI credentials, so it would be great if you could email me the FTP instructions at: chris.snyder(at)dnr(dot)wa(dot)gov, and I'll give you some reprod data.

Another thought on why true curves are bad: Some of us wanna-be hack programmer types are assuming that we will get a series of constituent verticies when we parse the geometry of polygon or line. It's sort of distressing when you find that your FC (buffer of a single point being the worst case eaxample) has far fewer verticies in it than you thought - the rest of the curve/shape is some sort of wacky equation locked away with no way to access it via a Python script - not that I would know what to do with the equation if I had it! Unless we can get some sort of arcpy environmental setting flag to keep these blasted curves at bay, the good ole' shapefile format is looking pretty pretty pretty good.
by Anonymous User
Not applicable
Original User: mdenil

You could densify the curve, which will break it into vertex anchored segments.
Densify_edit (in_features, {densification_method}, {distance}, {max_deviation}, {max_angle})

Long straight lines near the poles, particularly ones perpendicular to radial lines (along longitudes), also act very badly on occasion.
Densifying provides anchor points, but the best one can do is get the segment length below a critical threshold, so the problem is not noticeable.
ChrisSnyder
Honored Contributor
Yes, Densify could work as does exporting to shapefile or coverage, and importing back to Geodatabase format. I did mention these work around options in the last paragraph of my original post. However, both these work arounds would require you to run them on all the inputs, since there doesn't seem to be a way (at least an easy way) to identify features that contain true curve geometry.

Like I said, what I am really hoping for here is a new geoprocessing envr. setting that would ensure that true curve features are NOT propogated to the tool outputs.

arcpy.env.evilTrueCurves = False


Now, it seems all(?) buffer output placed in a geodatabase is going to contain curve features. Try buffering a single point by 500ft or something - put the output directly in a GDB (not a shapefile)... Then export "ALL" the verticies of the buffer polygon using the FeatureVerticesToPoints tool. Uh oh! These circular buffer polygons only have 2 verticies each! What the?!?! How are you to discern this condition, where "normally" you would be expecteding hundreds of densified verticies?

An environment setting would make all of us CAD-haters happy!

I'll also point out that SDE data has a way to keep true curves out... See the blurbs about that buried in here: http://webhelp.esri.com/arcgisserver/9.3/java/index.htm#geodatabases/using_t1450550752.htm

Why not FGDB and PGDB... and in_memory too?
0 Kudos
Bud
by
Esteemed Contributor

I know this post is ancient, but I'm struggling with true curves too.

A question regarding this blurb:
"I'll also point out that SDE data has a way to keep true curves out... See the blurbs about that buried in here: http://webhelp.esri.com/arcgisserver/9.3/java/index.htm#geodatabases/using_t1450550752.htm"

Do you happen to recall what part of that page tells us how to prevent true curves in SDE?

In my case, I'm using SDE.ST_GEOMETRY / Oracle 18c / ArcGIS 10.7.1.

Background info here: 

 

Edit:

I think @ChrisSnyder was referring to SDO_GEOMETRY, not ST_GEOMETRY. So that wouldn't help me.

0 Kudos
Bud
by
Esteemed Contributor

FYI - I submitted an ArcGIS Pro Idea:

Prevent users from creating true curves

0 Kudos
JohnSobetzer
Honored Contributor

Has anything changed since this thread was active?

I ask because we suddenly started receiving file geodatabase feature classes from a vendor that contained true curves.  I turns out other software displaying and editing them using GDAL (which doesn't support true curves) were creating "shifts" as the edited curves in a feature class were destroyed, or whole feature classes had these mini "shifts" when converted to shapefiles.  The easiest solution would be to avoid creating true curves.

ChrisSnyder
Honored Contributor

I don't think anything has changed after all these years... Curve features still send me in to fits of rage these days (in fact just 2 days ago I encountered an odd buffered polygon geometry that when used as input to the Clip_managment tool (for clipping rasters) resulted in this weird inverted output. The fix: Export to shapefile and use the densified geom as the clipping geometry... Problem solved! So, needless to say, I am still hatin' on them!!!

Sure wish there was an envr setting to keep them from happening in the 1st place... or at least a method of detecting their presence in a FC. Nope!

by Anonymous User
Not applicable

There is a workaround now that you can use to keep your true curves using arcpy.  While it is true that arcpy.Geometry() objects do not support true curves, you can still work with them in arcpy.  When the REST API started supporting true curves, some of the tools that handle JSON formats (arcpy.AsShape, arcpy.FeatureSet, etc) will automatically handle the curves for you.  To do any sort of modifications to the curves, you would need to figure out the math and handle it in the JSON structure. Here is a quick test showing getting a single curved line to a geometry object (with a bezier curve and arc):

esri_json = {
  "curvePaths":
    [
      [[6,3],[5,3],
        {
          "b":[
            [3,2],[6,1],[2,4]
          ]
        },
        [1,2],
        {
          "a":[
            [0,2],[0,3],0,0,2.094395102393195,1.83,0.33333333
          ]
        }
      ]
    ],
  "spatialReference": {"wkid":26915}
}

curve_line = arcpy.AsShape(esri_json, True) #very important to set esri_json to True!
arcpy.env.addOutputsToMap = True

# now add it to the map
arcpy.management.CopyFeatures([curve_line], r'in_memory\test')‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

 The line looked like this:

The esri json structure for cuves is described in the Geometry objects in the REST API docs.  You can see that the geometry can be retrieved with true curves by calling the JSON property:

>>> print curve_line.JSON
{"curvePaths":[[[6,3],[5,3],{"b":[[3,2],[6,1],[2,4]]},[1,2],{"a":[[0,2],[0,3],0,0,2.0943951023931948,1.7761476679542356,0.32243301481209313]}]],"spatialReference":{"wkid":26915,"latestWkid":26915}}