Skip to main content

Hi, 

 

I have a list of polygon geometries in WKT format, some simple polygons and some multipolygons.

All are using the MULTIPOLYGON type in the WKT, for example : 

MULTIPOLYGON(((1 1,1 2,2 2,3 3,3 1,1 1)))
MULTIPOLYGON(((1 1,1 4,4 4,4 1,1 1)),((2 2,2 3,3 3,3 2,2 2)))
MULTIPOLYGON(((1 1,1 5,5 5,5 1,1 1)),((2 2,2 3,3 2,2 2)),((3 4,4 4,4 3,3 4)))

But some of them don't have the first coordinates repeated at the end, so it is not a valid WKT.

If I take the same examples, it would look like : 

MULTIPOLYGON(((1 1,1 2,2 2,3 3,3 1)))
MULTIPOLYGON(((1 1,1 4,4 4,4 1)),((2 2,2 3,3 3,3 2)))
MULTIPOLYGON(((1 1,1 5,5 5,5 1)),((2 2,2 3,3 2)),((3 4,4 4,4 3)))

I want to find all the features lacking the last coordinates repeated.

 

Any idea how ?

 

Until now, I tried building a list with all coordinates, it can work for the simple polygon but for multipolygons I don't know how to handle it.

The GeometryReplacer transformer will automatically repair these geometries for you. So in FME there is no difference between your valid and invalid WKT strings.

But are you certain about the contents of your WKT strings?

Your WKT strings 2 and 3 describe several polygons on top of one another, whereas you probably want to have a polygon with one or more holes in it? You don't need multipolygons for that, polygons suffice. Also the points in the holes need to be in counterclockwise order. 

POLYGON((1 1,1 2,2 2,3 3,3 1))
POLYGON((1 1,1 4,4 4,4 1,1 1),(2 2,2 3,3 3,3 2,2 2))
POLYGON((1 1,1 5,5 5,5 1,1 1),(2 2,3 2,2 3,2 2),(3 4,4 3,4 4,3 4))

 


My initial thought was to be to use the GeometryReplacer: if it's not a valid WKT it should reject it. However... it senses the last coordinate is missing and automatically adds it to close the polygon 😂

 

Then I thought using a GeometryReplacer to build (and automatically correct) the geometry, a GeometryExtractor to save the new geometry in an attribute and compare the attributes. Not good either, not only is the first example you list a simple polygon (and the GeometryExtractor will encode it as such) there's inconsistent whitespace usage between the two. Fortunately it appears to be just the first space right after MULTIPOLYGON, so a simple StringReplacer before comparing the two attributes does the trick. You could consider replacing POLYGON with MULTIPOLYGON to cover your first example too.

 

It's clunky for sure, but it looks like it works. Otherwise regexes would probably be the way to go.


The GeometryReplacer transformer will automatically repair these geometries for you. So in FME there is no difference between your valid and invalid WKT strings.

But are you certain about the contents of your WKT strings?

Your WKT strings 2 and 3 describe several polygons on top of one another, whereas you probably want to have a polygon with one or more holes in it? You don't need multipolygons for that, polygons suffice. Also the points in the holes need to be in counterclockwise order. 

POLYGON((1 1,1 2,2 2,3 3,3 1))
POLYGON((1 1,1 4,4 4,4 1,1 1),(2 2,2 3,3 3,3 2,2 2))
POLYGON((1 1,1 5,5 5,5 1,1 1),(2 2,3 2,2 3,2 2),(3 4,4 3,4 4,3 4))

 

Thanks @geomancer​ for the quick reply.

Indeed, I have another problem with the polygon with holes vs multipolygons.

Some features have polygons on top of each other which correspond to polygons with holes, but others are real multipolygons, and other are multipolygons with one of the polygons that contains holes.

Unfortunately I don't have any information to identify which ones... 😞

 

To handle this, I used : 

  • the GeometryReplacer with my multiploygons
  • then DonutBuilder with Group by and Drop holes=yes
  • and an Aggregator to handle the multiploygons

Which seems to work well.

 

As you wrote, the GeometryReplacer repairs the geometries so I don't have to add the first coordinates at the end. Good news.


My initial thought was to be to use the GeometryReplacer: if it's not a valid WKT it should reject it. However... it senses the last coordinate is missing and automatically adds it to close the polygon 😂

 

Then I thought using a GeometryReplacer to build (and automatically correct) the geometry, a GeometryExtractor to save the new geometry in an attribute and compare the attributes. Not good either, not only is the first example you list a simple polygon (and the GeometryExtractor will encode it as such) there's inconsistent whitespace usage between the two. Fortunately it appears to be just the first space right after MULTIPOLYGON, so a simple StringReplacer before comparing the two attributes does the trick. You could consider replacing POLYGON with MULTIPOLYGON to cover your first example too.

 

It's clunky for sure, but it looks like it works. Otherwise regexes would probably be the way to go.

Thanks @Hans van der Maarel​ for your answer.

The idea is good :)

I tried regexes too, without success (with one simple polygon I achieved to build the right regex but didn't know how to handle the multipolygons, examples 2 or 3).

 

Finally, as the GeometryReplacer adds the missing end point to close the polygon when missing, I don't have to identify the bad geometries anymore.

 

And thank you to improve my english as well, I didn't know about the word "clunky".


Reply