topic Re: SDELayer fails in simple case in Data Management Questions

SDELayer fails in simple case

JohnCawley_III — Fri, 07 May 2010 13:49:44 GMT

I am trying to register a very simple MSSql table (with a Geometry shape) as a feature class in ArcSDE using SDELayer, but am unable to do so. I am using ArcSDE 9.3.1 on a SQL Server 2008 database.

I start with a good feature class, Bldg, that has a single (MSSql Geometry) shape in it and which is viewable in ArcCat/ArcMap. Then from MSSql, I make a copy of the table/FC with "select * into sde.Bldg2 from sde.Bldg". (On an aside, I understand that user sde should not own user data, but will fix that later.)

Now I try to register this new table/FC with ArcSDE using this command:

sdelayer -o register -l Bldg2,shape -e na+ -t GEOMETRY -C objectid,SDE %auth

where %auth contains my connection and authentication information for user sde. I receive this error:

ArcSDE 9.3.1 for SQL Server Build 1632 Thu Feb 26 12:05:37 2009
Layer Administration Utility
-----------------------------------------------------
Error: Invalid entity type (-29).
Error: Cannot Create Layer.

After I receive this error, Bldg2 does show up under ArcCat, but as a table, not a feature class.

I've searched the forums here and tried advice from somewhat-related problems, with no success. Thanks in advance for any assistance,
--John

Re: SDELayer fails in simple case

VinceAngelo — Fri, 07 May 2010 14:11:44 GMT

Have you tried specifying coordinate reference parameters (-x/-G/-P or -R)?

I haven't worked much with GEOMETRY on SQL-Server 2008, but the Oracle
metadata includes envelope, projection, and resolution data which allows
for a better guess on coordref, before then passing the existing geometries
through validation.

Your invalid entiity type could be due to coordinate snapping to a single
vertex (or a two-point line), or the table could just have non-polygon features
which don't meet the "nil or polygon" entity flag mask.

- V

Re: SDELayer fails in simple case

EricPaitz — Fri, 07 May 2010 15:20:45 GMT

I assume that the building shape is a closed polygon and not a polyline? Is it a single part or multi part polygon? If so try (just as a test) to register with the entity type as area only. Dont worry about n for nil and + for multi-part.

sdelayer -o register -l Bldg2,shape -e a -t GEOMETRY -C objectid,SDE %auth

Re: SDELayer fails in simple case

JohnCawley_III — Fri, 07 May 2010 16:36:17 GMT

Thanks for your replies!

I tried specifying the srid and "basic" coordinate precision (in case the sdelayer register command was trying to round nearby points to the same point):

sdelayer -o register -l zBldg2,shape -e na+ -t GEOMETRY -C objectid,SDE %auth -R 54 -P basic

This gave the same error "Invalid entity type (-29)", but on a minor note, it did not create a table with the same name afterward.

To keep things simple, I have only a single feature in the feature class, a closed single-part polygon -- the WKT, for example, is:

POLYGON ((-8899212.0936 4488955.4609000012, -8899222.9883 4488964.9522999972,
-8899254.6753 4488928.5802000016, -8899253.7593 4488927.7823000029,
-8899256.4052 4488924.7453000024, -8899268.3965 4488923.9197999984,
-8899271.4336 4488926.5656, -8899270.6356 4488927.4815, -8899307.0077 4488959.1684999987,
-8899316.4991 4488948.2736999989, -8899280.127 4488916.5868000016,
-8899279.3291 4488917.502700001, -8899276.292 4488914.8568999991,
-8899275.4665 4488902.8655000031, -8899266.4037 4488894.9699999988,
-8899254.4123 4488895.7955000028, -8899251.3752 4488893.1497000009,
-8899252.1732 4488892.2337, -8899215.8011 4488860.5468000025, -8899206.3097 4488871.4415000007,
-8899242.6818 4488903.1285, -8899243.4797 4488902.2126, -8899246.5168 4488904.8584000021,
-8899247.3423 4488916.8497999981, -8899244.6964 4488919.8867999986, -8899243.7805 4488919.0887999982,
-8899212.0936 4488955.4609000012))

My reasoning was that if I pulled this single shape from a good working feature class that ArcCat is already happy with (the Bldg FC that I copied the row from), it should be an easy, valid geometry to register.

I tried omitting the nil and multipart portions from the entity type:

sdelayer -o register -l Bldg2,shape -e a -t GEOMETRY -C objectid,SDE %auth

This still gives the invalid entity type error, though.

Thanks,
--John

Re: SDELayer fails in simple case

VinceAngelo — Fri, 07 May 2010 16:47:42 GMT

The ArcSDE 'C' API reports the same "Invalid shape type" error for that WKT.
I haven't been able to parse that vertex stream without error.

- V

Re: SDELayer fails in simple case

JohnCawley_III — Fri, 07 May 2010 16:55:52 GMT

Hmm, it's a simple, non-overlapping polygon (looks like the NW, NE and SE legs of an "x"). The coordinates cluster around -8899000, 4488000, which I don't think should be invalid -- it displays okay in the MSSql Spatial Results tab. It has SRID 54, which sde.sde_spatial_references lists as Web Mercator:

PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Mercator_Auxiliary_Sphere"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0]]

And like I mentioned, ArcSDE seems to be happy enough with the identical shape in another FC.

Any ideas what ArcSDE may not like about it?

Thanks,
--John

Re: SDELayer fails in simple case

VinceAngelo — Fri, 07 May 2010 17:48:20 GMT

Okay, I goofed -- my metadata file contained "np" eflags, which generated the error.

The coordinate system (projection) doesn't matter, but the falsex/falsey/xyunits matter
a great deal. What values do they contain in SRID 54? I used -10000000,0,10000 (with
HIGH precision).

Go ahead and leave your eflags at "na+", since that's not the issue.

- V

Re: SDELayer fails in simple case

JohnCawley_III — Fri, 07 May 2010 17:53:31 GMT

From sde.sde_spatial_references:
    falsex = -20037700
    falsey = -30241100
    xyunits = 10000

Re: SDELayer fails in simple case

JohnCawley_III — Fri, 07 May 2010 17:58:44 GMT

Also, just tried sdelayer register with the -x arg and the values for srid 54:

sdelayer -o register -l zBldg2,shape -e na+ -t GEOMETRY -C objectid,SDE %auth -x -20037700,-30241100,10000

but this still gives the invalid entity type error

Re: SDELayer fails in simple case

VinceAngelo — Fri, 07 May 2010 18:20:14 GMT

Try again with "-P HIGH" -- your Y origin is too far away with BASIC precision.

- V

PS: You'll also need "-G 102100" for PE_PCS_WGS_1984_WEB_MERCATOR_AUXSPHERE

Re: SDELayer fails in simple case

JohnCawley_III — Fri, 07 May 2010 18:35:19 GMT

Okay, I got slightly further.

Running "sdelayer -o describe %auth", I noticed that the Bldg table (that the single feature was copied from into Bldg2) has an Entities value of "nac3+". (c for CAD I understand, as this feature ultimately came from a CAD; 3 for 3-dimensional, I have no idea the source of.)

So I tried "nac3+" instead of "na+" in the register command:

sdelayer -o register -l Bldg2,shape -e nac3+ -t GEOMETRY -C objectid,SDE %auth

This did successfully create a layer. However, from ArcCat, I am able to preview the Bldg feature class, but the new feature class Bldg2 just has a blank preview panel.

So there still seems to be something wrong with the FC it registered, as it is un-preview-able (which in my experience leads to it having other problems further down the line) ...

Would the falsex/falsey/xyunits perhaps have something to do with it being un-preview-able?

Re: SDELayer fails in simple case

JohnCawley_III — Fri, 07 May 2010 18:39:16 GMT

Tried adding the -P and -G arguments:

sdelayer -o register -l Bldg2,shape -e nac3+ -t GEOMETRY -C objectid,SDE %auth -P HIGH -G102100

The table registered again, but is still un-preview-able.

Re: SDELayer fails in simple case

VinceAngelo — Fri, 07 May 2010 18:48:24 GMT

The "3" corrupted the layer definition, since your geometries are 2-D. You should have
the "-x" flag on the command line, in addition to -P and -G.

- V

Re: SDELayer fails in simple case

JohnCawley_III — Fri, 07 May 2010 19:03:46 GMT

Thanks for all your assistance. I tried -P, -G and -x, both with and without the "-e 3", and both with the -x args you used and with the values from srid 54, but all four combos had problems:

sdelayer -o register -l zBldg2,shape -e nac3+ -t GEOMETRY -C objectid,SDE %auth -P HIGH -G102100 -x -10000000,0,10000 # created but unpreviewable
sdelayer -o register -l zBldg2,shape -e nac+ -t GEOMETRY -C objectid,SDE %auth -P HIGH -G102100 -x -10000000,0,10000 # invalid entity type error
sdelayer -o register -l zBldg2,shape -e nac3+ -t GEOMETRY -C objectid,SDE %auth -P HIGH -G102100 -x -20037700,-30241100,10000 # created but unpreviewable
sdelayer -o register -l zBldg2,shape -e nac+ -t GEOMETRY -C objectid,SDE %auth -P HIGH -G102100 -x -20037700,-30241100,10000 # invalid entity type error

So it looks like sdelayer thinks it needs the "3" entity type (even though I have no idea where it is determining that from the 2-dimensional MSSql Geometry type). Is there perhaps a way to strip the "c" and the "3" from the "sdelayer describe" attributes of the source FC (Bldg) prior to using MSSql to copy the single feature from that class to the new table Bldg2 that I'm trying to register?

Or perhaps some other way to prevent the registered layer from being corrupted?

Thanks again,
--John

Re: SDELayer fails in simple case

JohnCawley_III — Mon, 10 May 2010 14:25:06 GMT

The SDELayer register command is insisting that the entity argument include a "3" (eg "nac3") or it fails. When the "3" is included, it registers the MSSql table as a feature class, but the FC is corrupted (Symptoms: from ArcCat, the FC shows up blank; from ArcMap, it shows up blank. In ArcMap, if I open the attribute table, I can get an outline of the shape; but using the Info tool, and clicking on the shape, no information appears.)

To see if I could get SDELayer to work without the "3" in the entity class (which we're assuming is the culprit here), I created a new SRID in sde.sde_spatial_references and verified that it has a zero for its falsez and falsem, and a 1 for its zunits and munits, and a zcluster_tol of 0.001 (which all the rest of my SRIDs have). I set the SRID of the GEOMETRY shape to the SRID I created (71). Still, SDELayer refuses to work unless the "3" is in the entity types.

I found a reference that the "c" cannot be removed from the entity types (http://forums.esri.com/Thread.asp?c=2&f=59&t=238988); but is there a way to get SDELayer to register the FC without a "3"? Or might some other factor than the "3" be causing the corruption in the registered feature class?

Thanks,
--John

Re: SDELayer fails in simple case

VinceAngelo — Mon, 10 May 2010 16:13:43 GMT

At this point, I think you'd be better off taking this issue to Tech Support.

- V

Re: SDELayer fails in simple case

JohnCawley_III — Mon, 10 May 2010 18:51:30 GMT

Thanks, V,
--John

Re: SDELayer fails in simple case

DuaneAnderson1 — Tue, 20 Jul 2010 13:10:09 GMT

Not sure if you ever solved your problem but we have successfully registered a SQL spatial table with the SDELayer command using the following syntax:

sdelayer -o register -l pcown.datest,shape -e a+ -C objectid,SDE -t geometry -R 111 -i xx -s xx -u xx - p xx

where the -R parameter is the SRID value that we know the feature class belongs to.

In our case we generated the non registered SQL table from a feature class that was registered with a know SRID so that helped. It worked however.

I believe in ArcMap/ArcSDE 10 there is a new feature to recognize SQL spatial tables without having to register them.

Duane