• Home
  • Forums
  • FME Form
  • Data
  • Error Message When Writing Lines to SDE: The error number from ArcObjects is: '-2147215922'. The error message from ArcObjects is: {Number of parts in shape is incorrect for its geometry type}
Question

Error Message When Writing Lines to SDE: The error number from ArcObjects is: '-2147215922'. The error message from ArcObjects is: {Number of parts in shape is incorrect for its geometry type}

F
Badge +3

When writing line features onto a poly line SDE feature class I am receiving the following message: “The error number from ArcObjects is: '-2147215922'. The error message from ArcObjects is: {Number of parts in shape is incorrect for its geometry type}.

I have not encountered this error leading up to this point. However, there have been a handful of jobs that have failed on this error. I have reviewed the line(s) in question and have found them to have these characteristics:

  • Vertices >= 2
  • Non-duplicated, stacked, or closely consecutive vertices
  • Longer length than SDE tolerance
  • Single part line features, not aggregates
  • Not self-intersecting

GeometryValidator, GeometryFilter, and GeometryRefiner have been applied with no success. Also, I created a replica file geodatabase and was able to write the features in with out any issue. I verified that it is specific lines and not only the first feature being written causing the error as well. In summary, the jobs are failing on what appear to be uncorrupted, normal lines.

 

Any insight would be greatly appreciated.

 

Thanks,

 

 

12 replies

erik_jan
Rank
Userlevel 2
Badge +12

A question to try to pinpoint the issue:

What is the source of the data?

If the source format is the same as the destination (any type of geodatabase) FME will use the format attributes, and if the source contains points or polygons that you manipulate into lines, the format attribute will still think these features are what they used to be.

If this is the case, you will see a format attribute geodb_geometry with the wrong type. Removing tha attribute will be the solution.

Hope this helps.

mark2atsafe
Rank
Userlevel 4
Badge +25

I've searched all our internal databases and the only cases I find of these error were either fixed long ago, or related to the tolerance of the target table. Can we confirm for sure that the source and destination tables have the same spec?

Otherwise, maybe it's related to the measure attached to that feature? The MeasureRemover would be a way to test that - though if all the other features have measures too, then obviously that's not the issue.

What version of FME are you using?

F
Badge +3

I've searched all our internal databases and the only cases I find of these error were either fixed long ago, or related to the tolerance of the target table. Can we confirm for sure that the source and destination tables have the same spec?

Otherwise, maybe it's related to the measure attached to that feature? The MeasureRemover would be a way to test that - though if all the other features have measures too, then obviously that's not the issue.

What version of FME are you using?

The source table are point geometry, which we use to create line geometry in the same SDE dataset. I thought perhaps the measure may have been an issue and added the MeasureRemover, but to your point, not all lines (or jobs) were failing so I do not think that is the issue.

 

- FME Server 2019.1.3.1 Build 19643 - win64

F
Badge +3

The issue has been identified and solved. I originally suspected that lines were created/split to such a small length that they were within (under) the default SDE tolerance. Furthermore, the tolerance of the data set differed from the tolerance of the the database at large, which could also have presented problems as well.

I solved the issue by filtering out all lines that fell under the tolerance and tightening-up the splitting logic to account for all scenarios that would result in a line shorter than the tolerance would allow. Additionally, I set the tolerance levels to be the same between the data set and the database (all other data sets).

It may be worth mentioning that the above screen shots were the features the error messages referenced in the log file. However, the features causing the error were not referenced in the log as such. It appears the log referenced features that were valid lines while not flagging those that were actually causing the problem.

 

@erik_jan and @mark2atsafe thank you for assisting with this issue.

gisbradokla
Rank
Badge +9

The issue has been identified and solved. I originally suspected that lines were created/split to such a small length that they were within (under) the default SDE tolerance. Furthermore, the tolerance of the data set differed from the tolerance of the the database at large, which could also have presented problems as well.

I solved the issue by filtering out all lines that fell under the tolerance and tightening-up the splitting logic to account for all scenarios that would result in a line shorter than the tolerance would allow. Additionally, I set the tolerance levels to be the same between the data set and the database (all other data sets).

It may be worth mentioning that the above screen shots were the features the error messages referenced in the log file. However, the features causing the error were not referenced in the log as such. It appears the log referenced features that were valid lines while not flagging those that were actually causing the problem.

 

@erik_jan and @mark2atsafe thank you for assisting with this issue.

@fneal​ I am having this problem also. Can you enlighten me as to how you determined the length of what tolerance sde would allow?

My source dataset is AutoCAD dwg and i am sure i do have some very short line segments.

 

Any other insight into which features were the actual offending features? I am running on server and do not see any reference to a feature. in fact the error right after this says that the ffs could not be written or found. I have never seen this before but makes me think i need a network resource to where server can write the ffs when this sort of thing occurs.

F
Badge +3

@fneal​ I am having this problem also. Can you enlighten me as to how you determined the length of what tolerance sde would allow?

My source dataset is AutoCAD dwg and i am sure i do have some very short line segments.

 

Any other insight into which features were the actual offending features? I am running on server and do not see any reference to a feature. in fact the error right after this says that the ffs could not be written or found. I have never seen this before but makes me think i need a network resource to where server can write the ffs when this sort of thing occurs.

I typically check the properties (right click) the feature dataset containing the target feature class. Depending on if you are using Catalog or Pro you should see a an XY Resolution and XY Tolerance in the "general" tab.

gisbradokla
Rank
Badge +9

@fneal​ I am having this problem also. Can you enlighten me as to how you determined the length of what tolerance sde would allow?

My source dataset is AutoCAD dwg and i am sure i do have some very short line segments.

 

Any other insight into which features were the actual offending features? I am running on server and do not see any reference to a feature. in fact the error right after this says that the ffs could not be written or found. I have never seen this before but makes me think i need a network resource to where server can write the ffs when this sort of thing occurs.

Oh thank you

i was imagining something with more calculation from your description. Then you just make sure no lines shorter than that go into the writer?

F
Badge +3

@fneal​ I am having this problem also. Can you enlighten me as to how you determined the length of what tolerance sde would allow?

My source dataset is AutoCAD dwg and i am sure i do have some very short line segments.

 

Any other insight into which features were the actual offending features? I am running on server and do not see any reference to a feature. in fact the error right after this says that the ffs could not be written or found. I have never seen this before but makes me think i need a network resource to where server can write the ffs when this sort of thing occurs.

Yes, any segment within the tolerance would be treated as a point feature by the geodatabase. In my particular case, I had line splitting logic that resulted in lines that fell within the tolerance of .02. I adjusted the splitting logic to avoid those scenarios and I filtered out segments that were within the tolerance regardless of splitting to an exception report.

B
Badge

I have the same issue with polygons also...

 

I am reading a MapInfo TAB file and writting in an ArcSDE feature class (XY tolerance of 0.001 meter). I tried repairing the geometries with GeometryValidator, rebuilding the geometries with GeometryExtractor, filtering the geometries and I still have issues. I tried exporting to a temporary GDB (XY tolerance of 0.001 meter also) and it works. I tried to load in FME the GDB feature class to the ArcSDE feature and it doesn't work.

Another thing I tried is repairing the geometries in ArcMap before writing in ArcSDE with FME : same issue.

I also tried with ArcSDEGridSnapper and it alters too much my geometries : I made a visual inspection and the shapes are altered and perimeters and areas are different (almost 0.2 meter in some cases for area).

 

Last thing I tried is writing from MapInfo to GDB in FME and then importing the GDB feature in ArcSDE feature... it works!

 

Do you have any clue on why it doesn't work in FME but works in ArcMap ?

 

 

Thanks!

gisbradokla
Rank
Badge +9

I have the same issue with polygons also...

 

I am reading a MapInfo TAB file and writting in an ArcSDE feature class (XY tolerance of 0.001 meter). I tried repairing the geometries with GeometryValidator, rebuilding the geometries with GeometryExtractor, filtering the geometries and I still have issues. I tried exporting to a temporary GDB (XY tolerance of 0.001 meter also) and it works. I tried to load in FME the GDB feature class to the ArcSDE feature and it doesn't work.

Another thing I tried is repairing the geometries in ArcMap before writing in ArcSDE with FME : same issue.

I also tried with ArcSDEGridSnapper and it alters too much my geometries : I made a visual inspection and the shapes are altered and perimeters and areas are different (almost 0.2 meter in some cases for area).

 

Last thing I tried is writing from MapInfo to GDB in FME and then importing the GDB feature in ArcSDE feature... it works!

 

Do you have any clue on why it doesn't work in FME but works in ArcMap ?

 

 

Thanks!

I had success getting past this error in 2 ways.

  1. write to file gdb.
  2. i created a filter for several features. (a. short lines. b. lines with arc segments.)

I discovered several CAD polyline features that had a bulge from one vertex to the next but then prior and following that were all straight segments. Not sure if that is your problem. but that was one of mine.

F
Badge +3

I have the same issue with polygons also...

 

I am reading a MapInfo TAB file and writting in an ArcSDE feature class (XY tolerance of 0.001 meter). I tried repairing the geometries with GeometryValidator, rebuilding the geometries with GeometryExtractor, filtering the geometries and I still have issues. I tried exporting to a temporary GDB (XY tolerance of 0.001 meter also) and it works. I tried to load in FME the GDB feature class to the ArcSDE feature and it doesn't work.

Another thing I tried is repairing the geometries in ArcMap before writing in ArcSDE with FME : same issue.

I also tried with ArcSDEGridSnapper and it alters too much my geometries : I made a visual inspection and the shapes are altered and perimeters and areas are different (almost 0.2 meter in some cases for area).

 

Last thing I tried is writing from MapInfo to GDB in FME and then importing the GDB feature in ArcSDE feature... it works!

 

Do you have any clue on why it doesn't work in FME but works in ArcMap ?

 

 

Thanks!

I think that perhaps the reason your work around is effective is likely the same as being able to create arcs in a polygon or line feature class but having trouble writing them in FME.

 

Have you tried using the ArcStroker transformer on your polygons? I sometimes use this on line or polygon features when writing to account for unexpected arcs. Typically use a GeometryFilter (filter on area and arc) then use the ArcStroker on the filtered arcs.

gisbradokla
Rank
Badge +9

I think that perhaps the reason your work around is effective is likely the same as being able to create arcs in a polygon or line feature class but having trouble writing them in FME.

 

Have you tried using the ArcStroker transformer on your polygons? I sometimes use this on line or polygon features when writing to account for unexpected arcs. Typically use a GeometryFilter (filter on area and arc) then use the ArcStroker on the filtered arcs.

That sounds good but in my case the offending feature was still seen as a line/fmeline the arc was just between two vertices. Unless you consider splitting it into segments straighten and then reassemble.

my filter for arcs did nothing to these offenders. But by having a duplicate gdb writer I then did a comparison between what did get into side and was able to find the features that did not get in.

Reply


Community Stats

28,632
Posts
109,177
Replies
36,512
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.