st_asbinary seems to change the orientation of polygons

GeoffLau · ‎01-19-2014

The environment
-------------------------------------
Oracle on Solaris, SDE , using st_geometry
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Solaris: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

ArcSDE 10.1

The problem
------------------------------------

While testing an Oracle trigger using a table with st_geometry I found that an valid sdo_geometry, when cast to st_geometry and back becomes invalid because the polygon orientation is reversed (Oracle requires exterior polygons to have anti-clockwise orientation).

I created the attached script to test the various combinations of casting using well-known-text and well-known-binary and have found that when an st_geometry is converted to an sdo_geometry using well-known-binary, the polygon orientation is reversed (anti-clockwise becomes clockwise and vice versa)

This seems to me to be a bug in st_asbinary, at least as implemented in the Solaris libraries we have on our database server.

Can someone please test on their environment and confirm?

The critical parts of my script are the tests 8 and 9 where I construct an st_geometry with coordinates 100 100, 200 100, 200 200, 100 200, 100 100.

Casting to sdo_geometry using wkt gives the correct result, but casting using wkb gives 100 100, 100 200, 200 200, 200 100, 100 100.

VinceAngelo · ‎01-19-2014

This sort of issue should really be taken up with Tech Support directly, since no one here
in the User Fourms can certify it as a defect or make any changes.

However, when I run the ring "POLYGON(( 10 30, 20 30, 20 40, 10 40, 10 30))" through the
ArcSDE 'C' API, then dump the shape as WKT and WKB, I get:

ArcSDE 10.2 Dynamic ASCII Table Utility  Sun Jan 19 12:56:40 2014
------------------------------------------------------------------------
         1
            objectid: 1
               shape: Area shape (1 part, 5 vertices)
                      XY max:                   [20.00,40.00]
                      XY min:   [10.00,30.00]
                      Vert# Part#  Sub#     (X,Y)
                          1     1     1     10.00,30.00
                          2     1     1     20.00,30.00
                          3     1     1     20.00,40.00
                          4     1     1     10.00,40.00
                          5     1     1     10.00,30.00
                 wkt: (CLOB - 46 chars)
                       P  O  L  Y  G  O  N     (  (     1  0     3  0
                       ,     2  0     3  0  ,     2  0     4  0  ,
                       1  0     4  0  ,     1  0     3  0  )  )
                 wkb: (BLOB - 93 bytes)
                      01 03 00 00 00 01 00 00 00 05 00 00 00 00 00 00
                      00 00 00 24 40 00 00 00 00 00 00 3e 40 00 00 00
                      00 00 00 24 40 00 00 00 00 00 00 44 40 00 00 00
                      00 00 00 34 40 00 00 00 00 00 00 44 40 00 00 00
                      00 00 00 34 40 00 00 00 00 00 00 3e 40 00 00 00
                      00 00 00 24 40 00 00 00 00 00 00 3e 40

Loading the shape into Oracle, then querying SDE.ST_ASBINARY(shape)
results in the same byte stream.

Decoding the binary stream yields:

01                      (little-endian)
03 00 00 00             (polygon)
01 00 00 00             (1 part)
05 00 00 00             (5 vertices)
00 00 00 00 00 00 24 40 (IEEE 1.000000000000000e+001)
00 00 00 00 00 00 3e 40 (IEEE 3.000000000000000e+001)
00 00 00 00 00 00 24 40 (IEEE 1.000000000000000e+001)
00 00 00 00 00 00 44 40 (IEEE 4.000000000000000e+001)
00 00 00 00 00 00 34 40 (IEEE 2.000000000000000e+001)
00 00 00 00 00 00 44 40 (IEEE 4.000000000000000e+001)
00 00 00 00 00 00 34 40 (IEEE 2.000000000000000e+001)
00 00 00 00 00 00 3e 40 (IEEE 3.000000000000000e+001)
00 00 00 00 00 00 24 40 (IEEE 1.000000000000000e+001)
00 00 00 00 00 00 3e 40 (IEEE 3.000000000000000e+001)

Which supports the assessment that WKB is being written in right-hand rule.

The SDO_UTIL.RECTIFY_GEOMETRY function can be used to reorder the vertices
to left-hand rule.

- V

GeoffLau · ‎01-20-2014

Hi Vince,

Thank you for checking that it happens on your configuration too.

Yes, I'm aware thst sdo_util.recitfy_geometry will fix the problem and once I worked out where the geometry was being made invalid I used that as a workaround.

Erik Sandin from ESRI Australia has kindly raised the issue with support on my behalf. The ESRI Australia support ticket number is E1KA646228.

Regards,

Geoff