Hello everyone,
I am working with line geometry as a reader. Then i buffered the line feature and used generalizer (with Algorithm: Douglas Generalize, share boundaries: No, Tolerance:30), to simplify the buffered line feature and need a output with Esri Geodatabase (File Geodb API).
But it shows the errors:
Failed to write Geometry to feature class 'way_r' with geometry type 'esriGeometryPolyline'. Dropping containing feature
I have also attached the ERROR text. Please help me.
Thanks.
Best answer by takashi
Hi @yasinmelon1, according to the log, it seems that the reason for the failure is mismatch on geometry type between the features (polygon) and the writer feature type setting (line).
"FileGDB Writer: Failed to write Geometry to feature class 'way_r' with geometry type 'esriGeometryPolyline'. Dropping containing feature"
Try changing the geometry type of the writer feature type to polygon.
+21Hi @yasinmelon1, according to the log, it seems that the reason for the failure is mismatch on geometry type between the features (polygon) and the writer feature type setting (line).
"FileGDB Writer: Failed to write Geometry to feature class 'way_r' with geometry type 'esriGeometryPolyline'. Dropping containing feature"
Try changing the geometry type of the writer feature type to polygon.
+21Hi @yasinmelon1, according to the log, it seems that the reason for the failure is mismatch on geometry type between the features (polygon) and the writer feature type setting (line).
"FileGDB Writer: Failed to write Geometry to feature class 'way_r' with geometry type 'esriGeometryPolyline'. Dropping containing feature"
Try changing the geometry type of the writer feature type to polygon.
You could use the "GeometryCoercer" and assign as geometry type "fme_line" to convert the polygons into polylines before you write them in the db.
+21Hi @yasinmelon1, according to the log, it seems that the reason for the failure is mismatch on geometry type between the features (polygon) and the writer feature type setting (line).
"FileGDB Writer: Failed to write Geometry to feature class 'way_r' with geometry type 'esriGeometryPolyline'. Dropping containing feature"
Try changing the geometry type of the writer feature type to polygon.
In this picture is my workflow. Is it the correct decision to use AreaOnAreaOverlayer after buffer?
This workflow this running until 17 hours. Now it is stuck and shows
ResourceManager: Optimizing Memory Usage. Please wait...
could you please tell me, is my workflow is correct? Or some suggestion please.
Thank you.
w-1.jpgw2.jpg
+21According to the log you have posted, the Dissolver is working very long time because it consumes huge memory space to process all the buffer areas at once.
Since the buffer areas would be clipped by administrative boundary finally, I think you can clip them first and then dissolve them for each administrative boundary, so that the memory usage in the Dissolver can be reduced. That is, my idea is to modify the workflow (skeleton) to:
Bufferer -> Generalizer -> Clipper -> Sorter -> Dissolver
These are important points to increase the performance. These all are indispensable.If the administrative boundary polygons don't have any unique ID attribute originally, use a Counter to add sequential number to them and use it as temporary ID.
I'm just afraid that the Sorter might consume large memory space at run-time, but I expect the entire performance could be better than the current workflow.
Hope this works.
+21According to the log you have posted, the Dissolver is working very long time because it consumes huge memory space to process all the buffer areas at once.
Since the buffer areas would be clipped by administrative boundary finally, I think you can clip them first and then dissolve them for each administrative boundary, so that the memory usage in the Dissolver can be reduced. That is, my idea is to modify the workflow (skeleton) to:
Bufferer -> Generalizer -> Clipper -> Sorter -> Dissolver
These are important points to increase the performance. These all are indispensable.If the administrative boundary polygons don't have any unique ID attribute originally, use a Counter to add sequential number to them and use it as temporary ID.
I'm just afraid that the Sorter might consume large memory space at run-time, but I expect the entire performance could be better than the current workflow.
Hope this works.
+21According to the log you have posted, the Dissolver is working very long time because it consumes huge memory space to process all the buffer areas at once.
Since the buffer areas would be clipped by administrative boundary finally, I think you can clip them first and then dissolve them for each administrative boundary, so that the memory usage in the Dissolver can be reduced. That is, my idea is to modify the workflow (skeleton) to:
Bufferer -> Generalizer -> Clipper -> Sorter -> Dissolver
These are important points to increase the performance. These all are indispensable.If the administrative boundary polygons don't have any unique ID attribute originally, use a Counter to add sequential number to them and use it as temporary ID.
I'm just afraid that the Sorter might consume large memory space at run-time, but I expect the entire performance could be better than the current workflow.
Hope this works.
Reader feature type (administrative boundary areas) -> Counter -> Clipper [Clipper port]
+21
If you need to finally get areas which are outside of the buffer areas of highways, I think you will have to clip the administrative boundary area by the buffer areas.
Opposite to the current workflow, send the buffer areas to the Clipper port and send the administrative boundary areas to the Clippee port. The features output via the Outside port would be your desired areas, I think.
+21If you need to finally get areas which are outside of the buffer areas of highways, I think you will have to clip the administrative boundary area by the buffer areas.
Opposite to the current workflow, send the buffer areas to the Clipper port and send the administrative boundary areas to the Clippee port. The features output via the Outside port would be your desired areas, I think.
I'm still unclear what is your requirement. In this super simplified example, which areas do you need to create finally - [A], [B], or [C]?
+21If you need to finally get areas which are outside of the buffer areas of highways, I think you will have to clip the administrative boundary area by the buffer areas.
Opposite to the current workflow, send the buffer areas to the Clipper port and send the administrative boundary areas to the Clippee port. The features output via the Outside port would be your desired areas, I think.
+21
In your workspace, "ESRIWKT|..." has been set to the coordinate system for the source datasets, but in my understanding, a coordinate system from the FME Coordinate System Gallery should be selected here.
How FME Identifies Coordinate Systems
How/Why did you set "ESRWKT|..." coordinate system?
+21
That aside, I found an issue.
You have set the Group By parameter in the Bufferer. Because of this setting, Bufferer works as a blocking transformer and therefore the Clipper won't work as expected with "Clippers First" mode.
If you need to create buffer areas grouping by "highway", you cannot use "Clippers First" mode.
Is it necessary to group buffer areas?
+21
+21
Regarding coordinate system, make sure that Clipper and Clippee have the same coordinate system.
+21
+21
+21
If you post a new question containing detailed and precise explanation on your situation, you might get some good answers.
Anyway, this thread has become too clutter already. I would recommend you to once close this thread and then post a new question specific to the performance issue.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
