ArcSDE Compressed Binary representation

[DariusBuinovskij2]

Hello,

We need to read geometry from ArcSDE Compressed Binary representation. Converting to native database spatial type is not an option.
Due to requirements we try not to use COM objects as well. Is there any code samples or correct documentation how this could be read?
We use .Net C# but any sample in other language like C or Java is ok. We use 10.01 and plan to use 10.02. Is this http://edndoc.esri.com/arcsde/9.2/concepts/geometry/representations/compressed.htm#Physical the latest version of the Compressed Binary representation?  Seems there is a bug of copy paste from older version. Document states: �??The next two bytes of the byte stream are not used currently, but are reserved for future use.�?�  but later 6 and 7 bytes are defined in the table below.

[VinceAngelo]

Once ST_GEOMETRY hit the streets, there wasn't any further need to maintain the
SDEBINARY/SDELOB representation documentation.

While learning to use the ArcSDE API is no picnic, it's got a much shorter start-up
cost than reverse-engineering the BLOB format.  This is especially true if you're
trying to decode annotation or if CAD objects are present (heck, even the API
doesn't expose CAD data).  And if you're just trying to extract the coordinates
to Well-Known ASCII or Well-Known Binary, then you can use published tools
like the ones in se_toolkit to accomplish this.

There's a VB sample out on the web to start from, but it doesn't account for
HIGH precision shapes (or 3-D or measures).

All-in-all, converting to a native type is the best option.

- V

[DariusBuinovskij2]

Thank you for reply, I will check that code. I know that the best option is to move to native types, but there are some limitations, curves for example. Another thing is, that there are databases, where we could not control which geometry storage types i used.

[VinceAngelo]

Curves are stored in CAD objects, which have never been documented.

- V

[MarcoBoeringa]

I don't know what your options are, but the first thing that comes to mind is using ArcEngine, which gives you all the power of ArcObjects to access the full geometry info. Or maybe ArcGIS Runtime, which can be deployed as a "desktop" type applications as well (besides mobile devices platforms), but I have no clear picture of the current limitations regarding geometries in that.

But if ArcEngine or ArcGIS Runtime is no option, other than that, you may get into the "web services" and ArcGIS for Server realm.

You might run an ArcGIS for Server "Feature Service" of your ArcSDE Compressed Binary data, or maybe an OGC WFS, and than use for example ESRI's SOAP API to access this. It is an ESRI "Feature Service" in combination with the latter API, what ESRI is using to make true curves available in ArcGIS for AutoCAD (see the remark by ESRI's Karen Hodge in this lengthy thread). The SOAP API seems to have Curve and PolyCurve (returnable in for example JSON), as possible geometry types, with curve even seeming to support Bezier Curves.

There are some lesser known options, like the ability to create a Server Object Extension based on ArcObjects, possibly allowing you to expose detailed geometry info in whatever format you like via web service, without having to resort to ArcObjects based applications on the client desktop.