I describe an example or a general problem. I have six files (tiles), each one with one o more polygons that have their own (file local) id. As showed in this picture.
No common attributes values exists for each whole polygon so a grouped dissolver would not be a solution. The grid geometry (cutter) is known. The desired result would be:
Any suggestion?
Best answer by ebygomm
View original
+30
Hi @j4
The transformer Dissolver did'nt work?
Thanks,
Danilo
Hi @j4
The transformer Dissolver did'nt work?
Thanks,
Danilo
Dissolver removes common boundaries so the three polygons in the bottom right corner will be merged into one instead three.
+30
Dissolver removes common boundaries so the three polygons in the bottom right corner will be merged into one instead three.
Thanks your reply.
Could you share a amount of data?
Thanks
Thanks your reply.
Could you share a amount of data?
Thanks
@danilo_fme a geopackage is attached.
test_data.zip
+21
Use a spatial relator to find features that touch but have a different filename, assign a group to these features then use that group to dissolve
dissolve_different_tiles.fmwt
Although i think this sort of area will still be problematic
Use a spatial relator to find features that touch but have a different filename, assign a group to these features then use that group to dissolve
dissolve_different_tiles.fmwt
Although i think this sort of area will still be problematic
@egomm "touches" predicate mixes "point touches" and "line touches" so the feature set associated to one feature will be oversized. "Touches" is also a binary operator and there are features along multiples files (as the rotated L-shape one).
+21
@egomm "touches" predicate mixes "point touches" and "line touches" so the feature set associated to one feature will be oversized. "Touches" is also a binary operator and there are features along multiples files (as the rotated L-shape one).
You can use a spatial predicate instead of touches to ignore polygons that only touch at the corners. (Although this would only be a problem if the corner also coincided with a tile boundary) The features over multiple files is handled by the list combiner
You can use a spatial predicate instead of touches to ignore polygons that only touch at the corners. (Although this would only be a problem if the corner also coincided with a tile boundary) The features over multiple files is handled by the list combiner
Ok, it could be a solution. Any suggestion for long polygons in multiple (more than 3) files?
+21
Ok, it could be a solution. Any suggestion for long polygons in multiple (more than 3) files?
Have you tried the attached fme template file?
It should produce this output from your input data
Have you tried the attached fme template file?
It should produce this output from your input data
Ok, this is what I need. Thank you very much @egomm.
+3
@j4
Post_Tiler_Rebuild_out.fmwt
The problem Is of course the lacking information. THis should have not been removed after tiling.
One should always preserve the object ID as wel as the row and column values.
The dataset you provided shows the problem.
You end up with a forced iterative process which not nescesarrily has a solution.
Create lists of the touching polygons, query the list with and a bunch of the objects get re-united. But polygons split over more than one tile pose a problem. There is no way to identify which should be merged.
I embed a workbench, that does 1 pass. I found no way to coherently iterate and dissolve the objects cut by borders.
You might want to see how you can "dissolve" without dissolver.
@j4
Post_Tiler_Rebuild_out.fmwt
The problem Is of course the lacking information. THis should have not been removed after tiling.
One should always preserve the object ID as wel as the row and column values.
The dataset you provided shows the problem.
You end up with a forced iterative process which not nescesarrily has a solution.
Create lists of the touching polygons, query the list with and a bunch of the objects get re-united. But polygons split over more than one tile pose a problem. There is no way to identify which should be merged.
I embed a workbench, that does 1 pass. I found no way to coherently iterate and dissolve the objects cut by borders.
You might want to see how you can "dissolve" without dissolver.
@gio the solution pointed out by @egomm seems to work. Try the attachment.
+3
@j4
I get it that it "works".
I also say that one does not actually knows (unless one has prior knowledge) whether polygons which touch on a border or borders should be dissolved.
Whether those objects were once a single object.
SO it seems like gambling on assumptions.
@j4
I get it that it "works".
I also say that one does not actually knows (unless one has prior knowledge) whether polygons which touch on a border or borders should be dissolved.
Whether those objects were once a single object.
SO it seems like gambling on assumptions.
I agree. In this particular case the initial dataset could be seen as the result of a "Clipper" using a known grid. Maybe FME could have an "UnClipper" transformer that receives the clipped features (clipped input port) and the geometry used as clippers (clipper input port).
+21
I agree. In this particular case the initial dataset could be seen as the result of a "Clipper" using a known grid. Maybe FME could have an "UnClipper" transformer that receives the clipped features (clipped input port) and the geometry used as clippers (clipper input port).
That option still wouldn't solve the issue that gio is concerned about, although I think looking at your input data it's unlikely to be an issue.
But if you have the scenario where two adjacent features have their shared boundary falling exactly on the grid line, they would be dissolved together in error.
That option still wouldn't solve the issue that gio is concerned about, although I think looking at your input data it's unlikely to be an issue.
But if you have the scenario where two adjacent features have their shared boundary falling exactly on the grid line, they would be dissolved together in error.
Yes, that is true.
+2
@j4 If you can, I would try running your workflow in FME 2019. We have done a lot to improve both the performance and the results of the dissolve. Our testing shows that the 2019 Dissolver is between 2 to 76 times faster, depending on the input data.
You can have multiple versions of FME desktop installed, just use a different install folder, i.e. c:\\apps\\fme2019. You can find FME 2019 betas here.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
