I'm guessing from the conversation that you linked that you're dealing with donut features, or is it just the outcome that's the same?

If so, the Data Inspector is probably going to give you the most information about what the problem is. You could also try poking around with the "homogenize collections" and "instantiate geometry instances" options in the GeometryFilter, or trying to Flatten All Levels (with "split composites" and "explode instances" turned on) in the Deaggregator. Some of these are entirely irrelevant to your problem, but brute force is normally a good place to start. If you're totally stuck and you've got a way of filtering all the problem shapes (i.e. if they're all donut features), it might be worth exploding, intersecting, and rebuilding the shapes.

Otherwise, some things to confirm might include: checking the shapes have >3 coordinates; checking the start and end points match; checking for self-intersections; checking you don't suddenly have a 3D feature hiding among the weeds, and so-on.

If none of that works, can you post a screenshot of a problem feature and its coordinates from the Data Inspector?

Hi,

Just a hint, Is the line is closed or not?

Pratap

Thanks for the feedback.

I'm guessing from the conversation that you linked that you're dealing
with donut features, or is it just the outcome that's the same?

No I don't think the polygon is a donut, but rather has the same outcome. I found a ffs file and converted to a shape. The polygon is definitely a sliver. length of 10km and a width of .001 meters.

What currently happens is the writer rejects the feature and dumps to the .ffs file.

What I want to be able to do is detect features that are going to be rejected before they get to the writer in an automated way, and re-direct them to failed features file myself. The process is part of an automated ETL system. I want to be able to set up notifications to data owners when any of their features get rejected as part of a replication.

I tried the "Homogenize Collections" and the "Instantiate Geometry Instances" in the "Geometry Filter" but the geometry filter still accepts the problem record as an area. Tried the de-aggregator with "flatten alll", "split composites", and "explode Instances" turned on before running it through the geometry validator and the geometry filter. Still passes the validator, and still recognized as a valid area by the geometry filter, and is still rejected by the writer.

Is this possible? Any suggestions on how to accomplish it? Looking for some kind of tester that determines if the geometry will be accepted by the writer?

Thanks again,

Kevin

Hi Kevin,

OK, in that case it's almost certainly the narrowness of the shape that's the problem. Unfortunately I don't have an ArcSDE writer to hand, but most of the Esri writers look something like this. The default Z and M tolerances caught my eye immediately. It looks as though the XY tolerance is picked automatically by the coordinate system, but try overwriting it with a value like 0.0001, and see what happens.

If that doesn't do anything, try as an experiment just running all your features through a Scaler, and scale them all up by 10 or 100 times - do they write successfully now?