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 featureI have also attached the ERROR text. Please help me.Thanks.

Why Generalizer Failed to write feature class and Dropping containing feature?

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.

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.

like this.

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.

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.

The Bufferer outputs Polygon features, so you cannot write them into a Line feature class as-is. If you need to boundary lines of the buffer areas, you can use the GeometryCoercer (Geometry Type: fme_line) to transform the buffers to their boundary lines, as @ioannakostara suggested already.

Hi ! takashi You was right I have work with polygon feature after buffer. I have to make buffer with a country highway(line) feature and dissolve the buffered amount, after that I have to generalized the polygon. At the final stage, I have to clip it from the country administrative boundary.

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

According 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.

Read the administrative boundary polygons first (i.e. move the reader to the top of the Navigator), and set "Clippers First" to the Clipper Type parameter in the Clipper.
In the Clipper, check "Merge Attributes" to merge unique ID attribute of the administrative boundary polygons (say 'admin ID') to clipped buffer areas.
Use a Sorter to sort the clipped buffer areas by 'admin ID'.
In the Dissolver, set 'admin ID' to the Group By parameter, and set "By Group" to the Input Ordered parameter.

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.

According 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.

Read the administrative boundary polygons first (i.e. move the reader to the top of the Navigator), and set "Clippers First" to the Clipper Type parameter in the Clipper.
In the Clipper, check "Merge Attributes" to merge unique ID attribute of the administrative boundary polygons (say 'admin ID') to clipped buffer areas.
Use a Sorter to sort the clipped buffer areas by 'admin ID'.
In the Dissolver, set 'admin ID' to the Group By parameter, and set "By Group" to the Input Ordered parameter.

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.

Hmm, I assumed that you need to finally create dissolved buffer areas inside of each administrative boundary area. Was I wrong? What are the geometries you finally required?

According 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.

Read the administrative boundary polygons first (i.e. move the reader to the top of the Navigator), and set "Clippers First" to the Clipper Type parameter in the Clipper.
In the Clipper, check "Merge Attributes" to merge unique ID attribute of the administrative boundary polygons (say 'admin ID') to clipped buffer areas.
Use a Sorter to sort the clipped buffer areas by 'admin ID'.
In the Dissolver, set 'admin ID' to the Group By parameter, and set "By Group" to the Input Ordered parameter.

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.

The "Clipped Indicator" attribute (you have named 'Admin_ID') just stores 'yes' (clipped) or 'no' (not clipped). It cannot be used as ID of administrative boundary areas. Why not use a Counter as I suggested?

Reader feature type (administrative boundary areas) -> Counter -> Clipper Clipper port]

Hmm, I assumed that you need to finally create dissolved buffer areas inside of each administrative boundary area. Was I wrong? What are the geometries you finally required?

I'm getting confused...

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.

I'm getting confused...

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.

No, the "Clipped Indicator Attribute" parameter should be the name of an attribute which will be added to every output feature to indicate whether it has been clipped ('yes') or not ('no'). See the help on the Clipper to learn more. Anyway, I don't think you have to use this parameter in this case.

I'm still unclear what is your requirement. In this super simplified example, which areas do you need to create finally - lA], B], or ]C]?

Gray: Highway Line, Blue: Boundary of Administrative Areas,
lA] (Orange): Highway Buffer Areas within Administrative Areas
lB] (Green): Administrative Areas outside of Highway Buffer Areas
lC] (Light Blue): Highway Buffer Areas outside of Administrative Areas

I'm getting confused...

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.