Latest Contributions by VinceAngelo

Cluster tolerances don't really mean anything to ArcSDE (it just holds the value for ArcGIS to use), so this isn't particularly useful for comparison purposes. The real questions are: 1) What are the primary and secondary coordref parameters of the layer (most importantly, the x/y offsets and scale)? 2) Do the coordinate values returned by getAllPoints at SP3 & SP6 correspond to the same bytestream, but interpreted by different coordrefs? 3) Does using setCoordref with the appropriate coordref repair "broken" shapes? The changeCoordref request accepts a null transformation when NADCON is not necessary (in this case, there isn't any coordsys change at all, much less a datum change). The goal is to use setCoordref to replace the primary coordref with the appropriate secondary coordref, then use changeCoordref to recode the bytestream so it conforms to the primary coordref. If the answers to question 2 and 3 above are "Yes", then generateLabelPoint or getExtent should be usable as a way to determine if the bytestream is inappropriate for the primary coordref. - V ... View more

It isn't particularly wise to leave the coordinate system undefined. Using an impossibly large spatial reference does more harm than good, and origin and scale parameters cannot be adjusted later with the coordsys. There are several thousand "standard" coordinate systems, and an infinite number of potential spatial references. The Esri Projection Engine is used to define coordinate systems; it is based on the EPSG reference standard. Samples of the most common forms ship with every copy of ArcGIS. The projection gurus established a standard set of parameters for each spatial reference used by ArcGIS, but any of them can (and really should) be overridden to optimize performance for any particular dataset. I agree that the XML definition process leaves a lot to be desired, but coming from the ArcSDE side of the house, and knowing that the Projection Engine and Coordinate Reference code represents nearly half of the ArcSDE functions, I can see how this could be a slippery slope that could have delayed the FileGDB API delivery by years. - V ... View more

Yeah, they were three weeks from delivery, too.  I got called in to evaluate and confirm the bad news. *And* it was meant to be a replacement for a client that lost a 6TB instance when the systems group failed to do backups because "it's a RAID array," and the RAID controller had a memory leak that corrupted 8% of the blocks across five different filesystems. Good times, indeed. - V ... View more

The folks most likely to able to answer this are probably swamped with UC attendance. You might get quicker response by contacting Tech Support. It looks to me like you're missing the AliasName and ModelName tags within Field; though the XSD doesn't seem to require them, all the examples do include both. - V ... View more

If my assumption that native BASIC shapes are returned as BASIC geometry and native HIGH shapes are returned as HIGH is correct, then it depends on how the coordref origin shifted during upgrade as to how the incorrectly coded shapes would be interpreted. The white paper explains the details, but the setCoordref request doesn't change the binary encoding of the geometry, just how is is interpreted, thus doing a setCoordref(hcr) will only alter the envelope if the new coordref is different. It's entirely possible that a shape toward the lower-left boundary could be shifted to a valid- seeming point in the upper-right, and escape notice. If you scan the full table, you should be able to tell which objectid represents the first shape added after the upgrade, since this will be the point where changeCoordref is no longer necessary (SP6) or becomes necessary (SP3). I don't recommend doing BASIC computation with SP3 and HIGH operations with SP6 -- Stick with SP6 and tweak the BASIC shapes into HIGH precision. - V ... View more

It's not enough to check if the bounding box is sensible -- you must check if it is the *same*. This is not an issue with the 'C' API because all shapes from HYBRID layers appear to be HIGH precision. - V ... View more

I took another look at the Java API documentation and SeLayer does NOT include a getSecondaryCoordref request the way the 'C' API does. It's possible that the request exists and the doc is just broken, but given the nature of Javadocs, this seems unlikely (worse, it's not in the 10.0sp1 documentation either). This will make it more difficult to obtain the BASIC coordref without hard-coding it into your application. Note that the coordinate reference is *not* the coordinate system which you referred to earlier. The coordSYS is part of the coordREF, but the coordref also incorporates: + The PRECISION + X/Y offsets and scale + Z offset and scale + M offset and scale + An authenticated SRID + A description At 9.2 and higher, X/Y, Z, and M also have optional cluster tolerances, and 9.3 introduced vertical coordinate systems (vertcs). There's an entire White Paper on coordinate management which should be mandatory reading for anyone who wants to use the 'C' or Java API; I strongly recommend it to you. - V ... View more

HYBRID coordinate references were supposed to be transparent (geometries always interpreted as HIGH precision, even if they were originally stored as BASIC). It is for this reason that the layer upgrade had constraints on what parameters were used (the HIGH precision coordinate grid had to align with the BASIC one [evenly divisible]). This obviated the need to mark shapes as being BASIC or HIGH, and eliminated the need for such functions in the API. It was a clever design, though it appears the Java implementation didn't take it into account. 😞 - V ... View more

There's actually a ton of things you can do to influence how getAllCoords parses the geometry, few of them good (and all of them have to do with coordinate reference override). I seem to remember a bug where HYBRID coordref (BASIC upgraded to HIGH) layers were not interpreted correctly by the Java API.  This would produce the behavior you're seeing (where the the HIGH precision shapes are parsed with the BASIC coordref at SP3, and vice versa at SP6).  The easiest solution would be to use a single coordref for all shapes, but the route to get there depends on whether the layer is versioned, participates in complex topologies, or has CAD objects associated with any rows.  If the layer is a simple feature class, you can backup the table, then use 'sdeexport' and then 'sdeimport' with the 'init' option (all new shapes are always created in the HIGH coordref, and the 'init' option truncates the table and reloads all features); Tech Support would be able to help steer you if this is other than a simple feature class. Client side correction is likely to be clumsy, since you'd have to: + Copy the shape to a temporary object + Get the envelope + Override the coordref on the temp object with the HIGH coordref (via setCoordref) + Get the envelope again + Compare the envelopes + If changed, use the changeCoordref request to transform the temp object into the HIGH coordref in the original shape for use in the application. The only good news is that the changeCoordref will just be a transform, not a true "project", so it won't be as expensive, but it will require you to upgrade the 90% of BASIC shapes on the fly for use (you could go the other direction, but then the shapes are losing precision [which isn't always a bad thing]). You might also see if the 9.3 or 9.3.1 API fixed this issue. - V ... View more

ArcSDE clients don't read geometries from databases -- they read geometries from ArcSDE servers. What version of ArcSDE is installed in the database? What version of ArcSDE is installed in the server? Your client API should always be equal to or greater than the server. Your server install should always be equal to the database. If you use Direct Connect, the client is the server, and should be equal to the database. Given that the last update to 9.2 occurred two years ago (SP3 goes back nearly four years), if you're still using 9.2, you really should be running the terminal release (SP6 + Connection Performance + Memory Allocation + Compress/Concurrent Editors) across the board. Taking a step backwards, what version of Oracle are you using? [A.B.C.D notation, e.g., "10.2.0.3"] If using Direct Connect, what version of Oracle is on your client? The fact that 'C' API applications like ArcGIS read the data successfully indicates a possible problem with your application (and/or the underlying Java SDK).  What are the coordinate reference parameters of the layer being queried?  Does your code change the coordinate reference in any way?  Was the layer upgraded to HIGH precision from a previous BASIC precision layer at 9.1 or earlier (is there an entry in the secondary coordref property)? - V ... View more

A file geodatabase is really a database without the RDBMS. It gets better performance, but it also doesn't have the ACID properties of an RDBMS (or the logging or backup and restore procedures of one, either, unfortunately).   File corruption can happen.  The best way to insulate yourself is to make regular backups.  It also wouldn't hurt to run some sort of validation procedure that visits all the rows in all the tables, since a backup won't help if a corruption is introduced and permeates all your backups (I had a client lose a 9TB RDBMS instance when a mirroring backup process failed to detect filesystem corruption and overwrote the last successful backup with random garbage -- two weeks later they had to restart a 15 week load procedure from CD and DVD media). - V ... View more

"Signal 11" usually refers to a segmentation violation error.  This error occurs any time a program exceeds the bounds assigned to it in memory.  There an infinite number of ways to generate a SIGSEGV fault, but in theory it shouldn't ever occur.   It's too late to fix ArcGIS 9.2 (which is now in "Mature" support status), but if ArcGIS 10 gives you this error, please report it so the bug can be fixed. - V ... View more

If you download the C++ API, the HTML documentation (in the 'doc' directory - surf to index.html) will tell you the objects which are accessible; the .Net wrapper classes could be expected to align with them (tables and rows, with a geodatabase parent container and a number of geometry accessor classes). The FileGDB API uses the shapefile spec to transfer individual geometries in binary form, but there is no support for shapefile access (read or write). If you google 'shapefile specification' you'll find a number of links to the specification itself (which is included in the FGBDAPI docs), plus the Wikipedia site (which has links to open-source shapefile access APIs). - V ... View more

While it's theoretically possible to store both 32-bit and 64-bit database clients and run both 32-bit AGS and 64-bit ArcSDE on a single server, it's much easier to install *only* 32-bit Esri apps on a single host ("easier" as in several hours less hair-pulling before giving up and just using 32-bit ArcSDE). I once set out to prove that 64-bit ArcSDE 9.3.1 ran faster than 32-bit, and it did (a little bit) on a 64-bit Linux VM, but it didn't on a 2008 Server VM (in fact, 32-bit may have been a bit faster). When ArcGIS 10.1 is released, AGS will be 64-bit, and it will be easier to run 64-bit ArcSDE. - V ... View more

ArcSDE is part of the ArcGIS Server product line.  If you have licensed AGS, you should have access to the ArcSDE media through Customer Service's download site, or by ordering the DVD media.  The ArcSDE SDK (Unix and Windows) is only avaliable via disk media, ordered through Customer Service. - V ... View more