Select to view content in your preferred language

HELP!! SE_SHAPE has radically different vert coords when loaded from different DBs

2848
11
02-10-2012 12:01 PM
DougMatthews
Emerging Contributor
ArcSDE 9.3
SQL Server 2008

We have a C++ application that uses ArcSDE C-api to perform database IO. After years of working properly, all of a sudden, when running against one of our databases we are reading SE_SHAPEs from ONE PARTICULAR table that have really wacky coordinates. Thousands of shapes from dozens of other tables are correct. Copying the table into a different database and running the same application again works properly.

Table is nothing fancy. WGS84. NOT versioned.

I wrote some code to call SE_shape_get_points RIGHT AFTER the SE_SHAPE is read and am experiencing this:

DATABASE_1:
Inspect geometry using ArcMap, vertices look to have correct coordinates.
Run application against DATABASE_1, dumping shape points immediately after reading SE_SHAPE:
********SHAPE DUMP********
  PART 0
    SUBPART 0
      0: x=-4.551839, y=-0.129920  <<<< Correct coordinates
      1: x=-4.522037, y=-0.368338
      2: x=-4.504342, y=-0.627246
      3: x=-4.427042, y=-0.904780
      4: x=-4.269648, y=-1.187902
      5: x=-4.268717, y=-0.904780
      6: x=-2.745073, y=-0.904780
      7: x=-1.243781, y=-0.952277
      8: x=-0.582542, y=-0.952277
      9: x=-0.582542, y=-1.185108
      10: x=-0.519212, y=-1.185108
      ...

DATABASE_2:
Copy table (using ArcCatalog) from DATABASE_1.
Inspect geometry using ArcMap, vertices look to have correct coordinates.
Run application against DATABASE_2, dumping shape points immediately after reading SE_SHAPE:
********SHAPE DUMP********
  PART 0
    SUBPART 0
      0: x=4049780.593044, y=4049790.639405  <<<< VERY Incorrect coordinates
      1: x=4049782.309627, y=4049790.639405
      2: x=4049782.309627, y=4049778.306904
      3: x=4049790.410000, y=4049778.306904
      4: x=4049790.410000, y=4049785.352211
      5: x=4049791.173365, y=4049785.352211
      6: x=4049791.173365, y=4049785.829831
      7: x=4049797.705849, y=4049785.830204
      8: x=4049796.939666, y=4049784.594846
      9: x=4049796.928548, y=4049784.598277
      10: x=4049796.928269, y=4049784.598734
      ...

DATABASE_3:
Copy table (using ArcCatalog) from DATABASE_1.
Inspect geometry using ArcMap, vertices look to have correct coordinates.
Run application against DATABASE_3, dumping shape points immediately after reading SE_SHAPE:
********SHAPE DUMP********
  PART 0
    SUBPART 0
      0: x=-4.551839, y=-0.129920  <<<< Correct coordinates
      1: x=-4.522037, y=-0.368338
      2: x=-4.504342, y=-0.627246
      3: x=-4.427042, y=-0.904780
      4: x=-4.269648, y=-1.187902
      5: x=-4.268717, y=-0.904780
      6: x=-2.745073, y=-0.904780
      7: x=-1.243781, y=-0.952277
      8: x=-0.582542, y=-0.952277
      9: x=-0.582542, y=-1.185108
      10: x=-0.519212, y=-1.185108
      ...

I have tried:

  • Regenerating the table (using our tool that does that) several times.

  • Renaming the table (in case there is something stale associated with the filename in SDE).

  • Inspecting table schema, coordinate system definintions, etc.

  • Restarting DATABASE_2's service.

  • Shaking chicken bones over the keyboard...


Any ideas on what to try next?

Thanks in advance!

-Doug
0 Kudos
11 Replies
VinceAngelo
Esri Esteemed Contributor
The SE_SHAPE object keeps the shape type, envelope (4-D), LLONG (or LONG, for BASIC)
array, part array and SE_COORDREF. If you bind a shape to a query stream (or, less efficiently,
use SE_stream_get_shape), then the SE_COORDREF is that of the shape in the table.
If you use SE_shape_set_coordref on a shape, it *clobbers* the previous SE_COORDREF
without changing the other variables, shifting the location in simple transform (generally
speaking, you should not ever use set_coordref without first using make_nil).

If you use SE_shape_change_coordref (either directly, of by using SE_stream_change_coordref),
it will "project" (really just transform, when without a projection or coordsys change) the shape to
retain coordinate values (as much as possible -- precision cannot be increased).

Thus, a copy utility should SE_layer_get_coordref from the target, create source and target
shapes, bind the source shape (without setting coordref), bind the target shape (ditto), fetch
the row, call change_coordref to change to copy the source shape to the target coordref in the
target shape, and execute the insert. Using the stream function would catch change_coordref
errors as stream errors, so I prefer not to use it, but you could eliminate a shape and make the
copy loop into { fetch, execute }, which has some allure.

- V
0 Kudos
DougMatthews
Emerging Contributor
Problem Solved!

The code that was reading the table's coordref was passing a recycled SE_COORDREF to SE_layerinfo_get_coordref, which was NOT overwriting the recycled data with the new. Seems we've been 'lucky' for years that the last user of this recycled SE_COORDREF left the coordref we wanted. Something seems to have tickled the order of things and the bug surfaced. Creating a new SE_COORDREF to receive the table's coordref data did the trick.

Thank you for your help (and the learnings)!

-Doug
0 Kudos