geometry_columns

1843
4
03-28-2017 10:04 PM
jayasudha
New Contributor III

There are columns with code for storage_type, geometry_type in geometry_columns table. I could not find enumeration for this code. Please suggest where can i find this.

0 Kudos
4 Replies
JayantaPoddar
MVP Esteemed Contributor

In case you are looking for the configuration keywords,

The configuration keywords associated with each of these storage types are as follows:

Configuration keywordGeometry storage

WKB_GEOMETRY

OGC well-known binary type

SDELOB

ArcSDE compressed binary stored as a binary large object (BLOB)

SDEBINARY

ArcSDE compressed binary

ST_GEOMETRY

Spatial type for Oracle or PostgreSQL

SDO_GEOMETRY

Oracle Spatial (including GeoRaster)

PG_GEOMETRY

PostGIS geometry type

GEOMETRY

Microsoft geometry type

GEOGRAPHY

Microsoft geography type

For more details, see Configuration keywords for enterprise geodatabases—ArcGIS Help | ArcGIS Desktop 



Think Location
0 Kudos
jayasudha
New Contributor III

I am looking for below. 

select storage_type, geometry_type from geometry_columns;

2       11
2       1
2       11
2       9
2       9

0 Kudos
JoelBennett
MVP Regular Contributor

I see this is an old thread, but I came across it having the same question, and I may not be the last.  In my case, I was trying to figure out what the values in the STORAGE_TYPE field meant, hoping they would indicate the specific storage type (ST_GEOMETRY, SDO_GEOMETRY, etc).

As it was, I had an application with these values in it that explain the contents of the GEOMETRY_TYPE column:

//Values as stored in SDE.GEOMETRY_COLUMNS table, GEOMETRY_TYPE field
public const int SDE_GEOM_TYPE_GEOMETRY = 0;
public const int SDE_GEOM_TYPE_POINT = 1;
public const int SDE_GEOM_TYPE_CURVE = 2;
public const int SDE_GEOM_TYPE_LINESTRING = 3;
public const int SDE_GEOM_TYPE_SURFACE = 4;
public const int SDE_GEOM_TYPE_POLYGON = 5;
public const int SDE_GEOM_TYPE_COLLECTION = 6;
public const int SDE_GEOM_TYPE_MULTIPOINT = 7;
public const int SDE_GEOM_TYPE_MULTICURVE = 8;
public const int SDE_GEOM_TYPE_MULTILINESTRING = 9;
public const int SDE_GEOM_TYPE_MULTISURFACE = 10;
public const int SDE_GEOM_TYPE_MULTIPOLYGON = 11;

However, I wrote that while ago, and for the life of me, I had no idea how I got that information.  I figured wherever the answer to that was, I'd also find the answer to the STORAGE_TYPE fields.

In looking in the current documentation, ESRI doesn't say much about the system tables.  However, but they did much more in days gone by, for example in the 9.3 documentation.  In the section for the GEOMETRY_COLUMNS table, my eyes went straight to the table contents the first couple of times I looked at the page, but unfortunately it didn't explain the values. Eventually, though, I read the description, and it was very helpful, because it indicates that this table complies with the OpenGIS SQL specification.

After a visit to Google, I ended up here: Simple Feature Access - Part 2: SQL Option, and the documents there show the values for these two columns.  The values of GEOMETRY_TYPE in the original version 1.1 documents match up exactly with what I had in the code above, and based on my 10.6.1 geodatabase, it appears the SDE.GEOMETRY_COLUMNS table still uses those values.  It is worth noting, though, that the later versions (e.g. 1.2.x) have a different set of values for GEOMETRY_TYPE, so proceed with some caution.

As for STORAGE_TYPE, the values are consistent across the documents:

  • 0 = normalized geometry implementation
  • 1 = binary geometry implementation (Well-known Binary Representation for Geometry)
  • NULL = geometry types implementation (added in version 1.2.0)

However, it appears ESRI has departed a little from this, since in my 10.6.1 geodatabase, I see a value of 2 for ST_GEOMETRY.  I've also come to find they also assign a 2 for SDO_GEOMETRY as well.  This is consistent with the version 1.1 document approach to the values in GEOMETRY_TYPE, since the values of 0 and 1 were not suitable...it looks like they chose an arbitrary value (2) and went with it.  (Note that the correct 1.2.0 value would be NULL, which some might wonder about...)

So it turns out this field won't be the simple solution I was hoping for, but that's ok...there are other ways.  Hope this helps somebody...