Hello ESRI-community 
,
I am working with creating a Geodatabase of buildings and have run into an issue I wanted to get straightened out.
I have a written a software to parse buildings from GML into ESRI geometries and then store them in a GDB/SDE, but I seem to be able to get the Shapes working properly for some of the more complex building bodies.
The more complex buildings get their GML-data split into multiple parts which I want to merge into one shape in ArcGIS Pro.
So I do this by first creating a Polygon for each part, then taking all those polygons and creating one Polygon out of them.
The Issue I am having however is that some of the polygons end up as interior holes and some as exteriors, see this sample:
I have read some documentation saying that the order of the points in the polygon is important, as depending on if they are CW or CCW will determine if it will be an interior or exterior ring.
I have ensured that the points are in the correct orientation but am still having the same issue.
I have read some other documentation saying that a polygon within an exterior polygon will always end up as an interior polygon, and a polygon within that interior polygon will end up as an exterior polygon and so on.
Could anyone give me some direction on this? I have created a sample application for this which i could attach if what I am trying to accomplish should be working but I have ran into some issue
Thanks!
Best regards
Lars
Accepted Solutions
Hi Lars,
Just to re-iterate the issue one more time: after converting a set of polygons from GML these polygons can be rendered as 'distinct' polygon records as shown below, showing all the expected detail (extrusions etc.):
If we take these 'distinct' polygon records and create one 'multi-part' polygon record using the 'distinct' polygons as parts, the rendered representation has 'holes' as compared to the rendering of the 'distinct' records.
I showed the data to the development team and here is the gist of their reply:
ArcGIS Pro only renders multipart polygons without 'holes' if these polygons are 'simple' polygons. One of the requirements of a 'simple' polygon is that 'rings cannot overlap'. If there's an overlap of parts, rendering can exhibit 'holes' because ArcGIS Pro uses the even-odd rule when rendering polygons. As defined by this rule overlapping parts will produce holes when rendered. Here is a definition of the Even-Odd rule: https://en.wikipedia.org/wiki/Even%E2%80%93odd_rule
So in order to render the converted GML you have two options: add a 'distinct' polygon for each part of the building (and use an id field to identify polygons belonging to a specific building) or union the polygon parts of a building into a single building polygon (in which case you only get the footprint outline of the building).
For the next release, we will try to update our ProConcept documentation to address these rendering behaviors in more detail.
Hello Wolfgang Kaiser,
Attached is the SampleApp I created, I've expanded it with my attempt at Multipatch as well but I am hitting the same issue as I am in my "real" application when I try to add Multipatch there, I get an error saying "No support for this geometry type".
This is my attempt at Multipatch:
But throws this error:
Just remove this Line with multipatch if you only wish to test this using CreateMultiPolygon which was I was originally having issues with in this Thread.
Just to match sure you can only store Multipatch geometries in a feature class that supports Multipatch type geometry:
Ah, of course, I was looking for a way to change the geometry type by going into design mode, didn't realize I had to re-create the entire feature, thanks!
I've created a seperate feature class named BuildingMultipatch and tried creating the building geometry using the code sample I provided earlier, the result is unfortunately the same though.
thanks for the sample code, i was able to duplicate your issue. I am still looking at some details (for example if the renderer or the data is to blame), but if i understand correctly, you expect this geometry:
but instead you get a multipart polygon (or multi patch) geometry with a few holes: 
i will have somebody look over my findings and will get back to you on this thread.
Hello Wolfgang Kaiser, yes, you are correct, there should be no holes at all in this Geometry, so I am expecting a result like the one you show in your first picture (in red).
I didn't put in any checks regarding CW vs CCW rotation of polygons in my SampleApp, mostly because it hasn't affected my results in my regular application. Let me know if you would like an updated SampleApp with this in place as well for completeness sake.
Sounds awesome that you'll be looking into it! I'll be eagerly be awaiting your results thanks a bunch for your help so far!
Hi Lars,
Just to re-iterate the issue one more time: after converting a set of polygons from GML these polygons can be rendered as 'distinct' polygon records as shown below, showing all the expected detail (extrusions etc.):
If we take these 'distinct' polygon records and create one 'multi-part' polygon record using the 'distinct' polygons as parts, the rendered representation has 'holes' as compared to the rendering of the 'distinct' records.
I showed the data to the development team and here is the gist of their reply:
ArcGIS Pro only renders multipart polygons without 'holes' if these polygons are 'simple' polygons. One of the requirements of a 'simple' polygon is that 'rings cannot overlap'. If there's an overlap of parts, rendering can exhibit 'holes' because ArcGIS Pro uses the even-odd rule when rendering polygons. As defined by this rule overlapping parts will produce holes when rendered. Here is a definition of the Even-Odd rule: https://en.wikipedia.org/wiki/Even%E2%80%93odd_rule
So in order to render the converted GML you have two options: add a 'distinct' polygon for each part of the building (and use an id field to identify polygons belonging to a specific building) or union the polygon parts of a building into a single building polygon (in which case you only get the footprint outline of the building).
For the next release, we will try to update our ProConcept documentation to address these rendering behaviors in more detail.
Hello Wolfgang Kaiser,
Thanks a lot for your time and help with this issue. We have gone with the "distinct polygon"-path with other applications but wanted to avoid it seeing all the issues we have had with that route
But now I know which two ways we can do this and will discuss with the end-users, thanks again!
BR
Lars
