topic Re: Differences with SRIDs in Coordinate Reference Systems Questions

Differences with SRIDs

JenniferDick — Mon, 15 Sep 2014 20:06:35 GMT

Hello,

Doing some testing on layers that are SDE 9.1 and SDE 10.1. When reviewing the properties for high precision storage the SRID consistently has a different identifier #. For example:

SRID 300004

SRID 300013

SRID 300014

SRID 300005

I've tried to research the different identifiers, - even using the Open GeoSpatial Consortium pages but I don't get any specific explanation as to why there is a different identifier for each layer.

Can anyone point me in a direction as to where I can gain some understanding on the difference between these identifiers?

Thanks in advance,

Jennifer

Re: Differences with SRIDs

OwenEarley — Mon, 15 Sep 2014 23:06:57 GMT

From ArcGIS Help 10.1:

A spatial reference identifier (SRID) is a unique identifier associated with a specific coordinate system, tolerance, and resolution.

My guess is that the layers have the same coordinate system but may differ slightly in tolerance or resolution.

Also, the geometry type may be influencing the SRID:

Some databases and spatial types, such as PostGIS geometry in PostgreSQL or the geography type in SQL Server, use a predefined subset of EPSG codes, and only spatial references with those SRIDs can be used.

Melita Kennedy‌ is the go to person at ESRI for anything to do with coordinate systems and may be able to provide some more information.

Re: Differences with SRIDs

VinceAngelo — Tue, 16 Sep 2014 00:13:58 GMT

One of the main problems with the early ArcSDE feature class loaders was that using default coordinate reference parameters to load several overlapping shapefiles would result in a different coordinate reference for each feature class (due to slightly different data envelopes). I once found 100 different coordinate references for 145 feature classes (and I loaded the first 46 layers).

One of the major changes at ArcGIS 9.2, where HIGH precision coordinate references were introduced, was to standardize the origins for all data in different families of projections, with a standardized precision in the 1.0-0.1 millimeter range. This reduced the number of different coordrefs, but also locked in precisions that were greatly in excess of the accuracy of the data (which has the side effect of increasing the required storage, since the SDEBINARY, SDELOB, and ST_GEOMETRY storage methods rely on compression based on the magnitude of differences in integer space).

If you upgraded your 9.1 coordrefs to HIGH precision using UI tools, it's quite possible that the original "too many coordrefs" issues have been embedded in the newer geodatabase.

One way that coordinate references cannot be reduced is if some data is measured and some carry Z values, but not others. Technically, you can define 2-D layers using 3-D or 4-D coordrefs, but that requires some effort to define the desired coordref up front, then make sure that all feature classes use this common coordref.

I'm working on an add-in to optimize feature classes through a number of techniques, including less aggressive precision, spatial defragmentation, and geometry partitioning, but haven't completed my effort yet.

The Understanding Coordinate Management in the Geodatabase whitepaper will explain all the issues which surround coordinate reference design, and explain the difference between well-known coordinate system codes and coordinate reference IDs (basically, there's some naming collision on the term "SRID").

- V

Re: Differences with SRIDs

JenniferDick — Tue, 16 Sep 2014 02:24:28 GMT

Thanks Owen, appreciate your response,

yes there are difference with the tolerance and resolution between the 9.1 layer and 10.1 layer, but this is probably do to it going to high precision.

Re: Differences with SRIDs

JenniferDick — Tue, 16 Sep 2014 02:30:52 GMT

Thanks Vince,

Yeah it appears that some of my feature classes in the same data set are referencing a different SRID. Appreciate your insights to this, you've provided some food for thought. I'll have to look how the geodatabase was upgrade to get a handle on this. What I have noticed in the new 10.1 SDE layers is the standardizing of the origin of min y -400 and min x -400 for each feature class that i have.

Re: Differences with SRIDs

MelitaKennedy — Wed, 17 Sep 2014 19:53:03 GMT

That means you mostly have data in a geographic coordinate system. We had been supporting longitude ranges from -360 to +360, which is why the minimum value was bumped out to -400.

Re: Differences with SRIDs

JenniferDick — Wed, 17 Sep 2014 20:10:11 GMT

Thanks Melita...

Quick question...do you have any experience or could provide some help with the GeometryDef Grid Count and GeometryDef Grid Size?. I've been receiving some results and there are issues with my 10.1 layers that I need some assistance with.

Hope to hear from you soon

Jennifer

Re: Differences with SRIDs

RobRader1 — Tue, 30 Sep 2014 18:23:18 GMT

Oracle 10.2.1, ArcCatalog 10.2.1, try to convert all the feature classes in afeature dataset to the same projection. Then simply copy this to another oracle database with ST_GEOMETRY and you will see the output is messed up.

SQL> select table_name,srid from sde.st_geometry_columns;

TABLE_NAME SRID
-------------------------------- ----------

WHYDRANTVALVES_1                     3857
PRIMARYOVERHEAD                        3857
TRANSFORMER                                3857
WMAIN_1                                        300004
WHYDRANT_1                                  3857
WATERDIST_NET_1_JUNCTIONS 3857
WFITTING_1                                     3857
WCONTROLVALVE_1                      3857
WPUMP_1                                         3857
WLATERALLINE_1                            300004
WSERVICECONNECTION_1            3857

WSYSTEMVALVE_1                         3857
WCURBSTOPVALVE_1                    3857
GDB_ITEMS                                     4326

If we ignore GDB_ITEMS, it is an out of the box table used for internal storage of information only, then we note that even though the projection was the same on the source system, it is different after a copy paste.

To find out what is different, I look at the ST_COORDINATE_SYSTEMS table:

SQL> desc sde.st_coordinate_systems;
Name                                      Null?    Type
----------------------------------------- -------- ----------------------------
NAME                                               NVARCHAR2(128)
TYPE                                               NVARCHAR2(128)
DEFINITION                                         VARCHAR2(2048)
ORGANIZATION                                       NVARCHAR2(128)
ID                                        NOT NULL NUMBER(38)
DESCRIPTION                                        NVARCHAR2(256)

So we see:

set pagesize 1000
set long 1000000

SQL> select * from sde.st_coordinate_systems where ID in (3857,300004);

NAME
--------------------------------------------------------------------------------
TYPE
--------------------------------------------------------------------------------
DEFINITION
--------------------------------------------------------------------------------
ORGANIZATION
--------------------------------------------------------------------------------
ID
----------
DESCRIPTION
--------------------------------------------------------------------------------
WGS_1984_Web_Mercator_Auxiliary_Sphere
PROJECTED
PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",GEOGCS["GCS_WGS_1984",DATUM["D_W
GS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],U
NIT["Degree",0.0174532925199433]],PROJECTION["Mercator_Auxiliary_Sphere"],PARAME
TER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meri
dian",0.0],PARAMETER["Standard_Parallel_1",0.0],PARAMETER["Auxiliary_Sphere_Type
",0.0],UNIT["Meter",1.0]]
EPSG
3857
WGS 1984 Web Mercator Major Auxiliary Sphere

Only the 3857 is returned at all. The 300004 entry is completely missing.

So in my case I have a bug. One feature dataset is only supposed to have one projection type. Expecially if eveything is part of the same network. I am going to go look for patches in my case. But I was just debugging this and wanted to post how I matched up the projection to an SRID to sort out what string is used for which number in your database.