locked
STUnion of Polygon results in some LINESTRING in the GEOMETRYCOLLECTION RRS feed

  • Question

  • Hello,

    I have a table of county boundaries that are stored in geometry datatype.  The county boundaries were populated from WKT which wasn't valid at first, but I did run MakeValid() on them.  Now I am trying to STUnion all of the county boundaries together putting them into an empty GEOMETRYCOLLECTION variable.  After they are all unioned and I view the resulting value, it has lines within it in some spots where I did not expect it.  Further, if I conver the resulting value back to WKT it is a GEOMETRYCOLLECTION that has LINESTRINGS in it.  I was expecting a single large POLYGON.  Can anyone help explain this occurace, and what I might do to get the result to just be an outline POLYGON with out the LINESTRINGS.

    Thanks ahead of time,

    Derek


    derek
    Wednesday, June 16, 2010 11:54 PM

All replies

  • Hi,

    Check this post:

    http://social.msdn.microsoft.com/Forums/en-US/sqlspatial/thread/2bc4c130-4312-48a1-bc5a-a07d193edf29

     

    Quick solution: update your registries to fix the ring orientation (geom = geom.STUnion(geom.STPointN(1)))

    Thursday, June 17, 2010 5:57 AM
  • Thanks it appears that there is to be a cummulative update to fix this.  When I checked our version of SQL server it is: 10.50.1600.1 RTM Standard Edition (64-bit)

    Does anyone know if that is the latest/

    Thanks again,


    derek
    Thursday, June 17, 2010 1:07 PM
  • We are still having this issue and we are running the latest version of SQL Spatial.  Has anyone come across of the issue or possible know of a solution.  Essentially the problems comes from the STUnion of geometry items and when we convert it back to WKT. 

     

    Thanks,

    Derek


    derek
    Thursday, August 5, 2010 10:12 PM
  • Try buffering your polygons ever so slightly (i.e. STBuffer(0.00001)) prior to performing the union, which will expand them to fill in the gaps.
    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Friday, August 6, 2010 6:58 AM
    Answerer
  • Thanks Alastair.  I did end up using the STBuffer but not on the same line as the STUnion.  It seems that when I did use the two together it was quite slow for our application.  Here is the algorithm that I came up with for handeling slivers that come back from STUnion.  If you get a chance to let me know if this a good approach.  We are essentially using STUnion only with census unit polygons.  However, as discussed the STUnion function produces slivers due to low precision .

     With returned WKT Value from STUnion()

                CASE MultiPolygon

                            Loop through all polygons

                                        If polygon(n) has interior rings

    Loop through all interior rings

    Check the size/remove sliver

    End Loop

                            End Loop

                CASE Polygon

                             If polygon(n) has interior rings

    Loop through all interior rings

    Check the size/remove sliver

    End Loop

                CASE GeometryCollection

                            Loop through all geometry objects

                                        If  geometry collection object(n) is polygon

    If polygon has interior rings

    Loop through all interior rings

    Check the size/remove sliver

    End Loop

    If  geometry collection object(n) is linestring

                Check start and endpoint with buffer and overlap

                If they overlap à assume this is polygon that was lost in the STUnion()

                Else remove the linestring as it is a sliver

                            End Loop


    derek
    Wednesday, August 11, 2010 2:57 PM