Hi folks- I have a polyline file (in planar coordinates) and attempting to build a 200ft buffer around each line. Simple, but I am repeatedly getting the error: Cannot write a non-area feature to an area feature class. The bufferer seems to be writing out polygons...fme_geometry is showing polygon. I've tried geometrycoercer, attribute exposer, geometry validator...all successful in saying the polygon geometry is legit. I can even write successfully as a polygon shapefile. But not to a fGDB polygon feature class.
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
+22- Contributor
- 2179 replies
The FGDB feature class has strictly enforced rules for polygons. Some of the buffers might be self-intersecting and causing issues. Can you do a check (use GeometryValidator)?
The FGDB feature class has strictly enforced rules for polygons. Some of the buffers might be self-intersecting and causing issues. Can you do a check (use GeometryValidator)?
Yeah, did the GeometryValidator, everything came out okay. If I change the output to polyline, it succeeds. But not polygon. I've used the same process many times before with no problems, so there is something unique I haven't accounted for.
+9- Safer
- 284 replies
Yeah, did the GeometryValidator, everything came out okay. If I change the output to polyline, it succeeds. But not polygon. I've used the same process many times before with no problems, so there is something unique I haven't accounted for.
Is this an existing feature class? Does it work if you write to a brand new feature class? Do you have multi-part features after the Bufferer?
Nathan
The FGDB feature class has strictly enforced rules for polygons. Some of the buffers might be self-intersecting and causing issues. Can you do a check (use GeometryValidator)?
Hi @NathanAtSafe- I've tried to write to different geodatabases as new feature classes and no luck. I've also tried drop and truncate table. The writer is attached directly to the bufferer. Preceding that is an attribute-only FeatureMerger and LineCombiner. Maybe the LineCombiner is doing something? Even if it is, the error is suggesting a non polygon feature is emerging directly from the bufferer which is puzzling to me. I have seen similar behaviour before when a non-spatial reader may pick up or adopt a geometry for some reason and you have to do a GeometryRemover before building a geometry output.
+9- Safer
- 284 replies
Hi @NathanAtSafe- I've tried to write to different geodatabases as new feature classes and no luck. I've also tried drop and truncate table. The writer is attached directly to the bufferer. Preceding that is an attribute-only FeatureMerger and LineCombiner. Maybe the LineCombiner is doing something? Even if it is, the error is suggesting a non polygon feature is emerging directly from the bufferer which is puzzling to me. I have seen similar behaviour before when a non-spatial reader may pick up or adopt a geometry for some reason and you have to do a GeometryRemover before building a geometry output.
Nathan
@jwhitsett Thanks for the follow up. That is bizarre. If you inspect the output of the Bufferer, do you have any multipart (aggregate) features? I wonder if an area feature with a corrupt linear part might upset your fGDB reader. The GeometryValidator is good but not always perfect at catching these, especially for aggregates. You might also try a Deaggregator before the GeometryValidator, then sending to the fGDB writer. If you're able, uploading a sample of the offending feature(s) and a log file of the translation might help debug.
Nathan
+9- Safer
- 284 replies
So things just got weirder. The input line file is from a separate workbench so I went to that workbench and copied and pasted the whole build (instead of reading it's output as a FC) and lo and behold it worked. Tried going back to the original reader and using the deaggregator...no luck, still errors out. So looks like I can use the original workbench that builds the polylines from a SQL table and just bring that in instead of reading it in as a FC. It's duplicating a process that's already out there, but it works....
Yikes! Glad you found a workaround. That's odd though. If you're keen on optimizing this and getting to the bottom of the error I'd be happy to take a closer look with some test data and a workspace.
+9- Safer
- 284 replies
Sounds good. It's repeatable on my side, but once I put everything together in a format that is zippable and not within our firewall I wouldn't be surprised if the reformatting solves the issue. But let me try, I'd love to find out what is happening...
Thanks,
Nathan
+56- Safer
- 2554 replies
Did you try the GeometryFilter. Probably a bit late since you have a workaround, but that's the first thing I'd try. Easier than searching through all the fme_type and fme_geometry values looking for something that's not right.