Latest Contributions by VinceAngelo

There's nothing inherently wrong about using different spatial references for data over different areas. It certainly won't harm ArcSDE functionality, yet it may confuse clients if the data owned by a single user is in different projections.  There are two easy ways to address this: 1) Use different owners for different projections (different databases is an option, but only if the volume of data warrants the overhead of multiple services) 2) Prefix or suffix the table name with the projection Either way, Desktop is going to let you know if you try merging data in different projections in a single view. - V ... View more

Your URL is mangled or protected.  I don't see anything at ideas.esri.com searching on "file geodatabase raster". - V ... View more

Did you define an SRID in USER_SDO_GEOM_METADATA? - V ... View more

This is not possible.  ArcSDE command-line utilities (and the API itself) have no knowledge of geodatabase concepts like feature datasets (ArcObjects implements them using the 'C' API). - V ... View more

It is never necessary to run 'sdelayer -o delete' before 'sdetable -o delete' (and a there are some good reasons not to do so). Once the geodatabase registry is corrupted, you really ought to involve Tech Support. This is especially true when simple table management directives fail or hang. You'll probably want to check on the status of your last backup and make an extra snapshot of the current state, just in case future steps cause further harm to database integrity. - V ... View more

You should not use ArcSDE command-line tools on tables registered with ArcGIS -- All you'll do is corrupt the ArcGIS registry (which will cause the very problem you're describing).  If a table has been registered with ArcGIS, it should be deleted by ArcGIS.  If you've already deleted it, you need to recreate it (just an object with the same name, not the exact contents), and then use ArcGIS to delete it properly.  If the delete hangs, contact Tech Support for assistance. - V ... View more

You can use a variant of the method ArcSDE uses to maintain OBJECTID rowid columns to maintain your independent IDs. ArcSDE shifted from a simple sequence because of the performance cost during bulk insert, but if you're not doing much bulk assignment, then a simple sequence may be the way to go. - V Note: If you use the TRUNCATE/ALTER/INSERT procedure, you'll need to run an 'sdetable -o describe' as the owner on each table to correct the internal SDE.COLUMN_INFO type codes.  You'll also want to prototype this with a trivial layer, to make sure ArcGIS doesn't object to the type change.  This is especially true for versioned tables. ... View more

SDEBINARY storage isn't really supported on Oracle 10g due to issues with LONG RAW deprecation, and isn't *possible* with 11g (Oracle support for 10g ended in the first half of 2011).  ST_GEOMETRY is generally faster than SDELOB storage (due to elimination of the F table). There is no way to defragment tables fractured by in-situ conversion (without truncating and repopulating them, of course). Doing the job right is going to take longer than doing it quick, but it should save time in the long run as the time savings on each query result adds up.  At a minimum, you should start planning for an 11g/ST_GEOMETRY/ArcGIS 10.1 upgrade. - V ... View more

With database support for ST_GEOMETRY and/or native spatial objects, geometries are just another attribute type. It is a potentially disastrous design flaw to split your business table into spatial and non-spatial components and join the tables during every query. The biggest performance risk for large spatial tables is spatial fragmentation. This occurs when features are unorganized (or organized by something other than geo-location, like timestamp), producing what essentially becomes a full table scan to access all the features in a small geographic region. The hallmark of spatially fragmented data is when rendering produces a random-seeming draw order, vice filling from one side of the field of view to another. There is no silver bullet to solve spatial fragmentation, but there are techniques available to moderate its influence. The best way to get non-Forums access to my time is through your marketing representitive. I am fully allocated to project work at the moment, but there are others within Esri who also have practical experience with large databases, and a marketing rep might be able to organize a virtual consultant from varied resources. - V ... View more

ArcSDE isn't really loaded "on top of" any database -- it's just the wrapper that standardizes geometry delivery to clients.   At least, that's the way it should be -- most of the failed projects I've worked were detemined to partition away the spatial component so it wouldn't impact their design, and failed because they couldn't commit to using a spatial-enabled database. There is no performance limit to ArcSDE, but there are ugly performance limits to databases when they are used to store spatial data inefficiently.  Ironically, the folks who know the most about large databases usually fare the worst when they add a spatial component without letting the reality of spatial fragmentation impact their design. All my large database customers have had non-disclosure clauses in their contacts, so I can't provide details.  I can say that when I refer to hundreds of millions of rows, I'm referring to inidividual tables -- Ten thousand tables with tens of thousands of rows is a very different problem. - V ... View more

The API can't read the old 9.x format (very different -- impossible to model with the 10.0-based API). The only way to convert a 9.x FileGDB is to use ArcGIS 10 to upgrade the original to 10.0 (or copy it into a new 10.0 FGDB). - V ... View more

What version of ArcSDE are you using?  Which service pack has been applied?  What geometry storage type are you using? What version of ArcGIS are you using?  Which Service Pack? What application requires NVARCHAR2 columns? (Last I heard, Oracle recommended *against* using NVARCHAR2 if most of the characters are ACSII7.) Doing a this sort of conversion in-situ is going to fracture your table, causing lots of fragmentation. The best way to implement the change is to copy the table contents with a "CREATE TABLE backup AS SELECT * FROM original", TRUNCATE the original, drop the indexes, do ALTERs until the schema is correct, then INSERT via a SELECT and rebuild indexes.  You'll probably want to add a proper foreign key based on the old OBJECTID while you're at it.  In a perfect world, you'd reorder the rows to defragment the features spatially at the same time (via an ORDER BY during INSERT), but that depends on geometry storage. - V ... View more

There are just too many variables to get a useful response from this query. I've had customers with hundreds of millions of rows of data with both great and terrible performance. It's probably not even safe to assume that an enterprise class database server can handle the load, because the way you organize the data and the way you query it can have a huge impact on the actual load and query performance of large and very large databases. If you can provide details on what you're trying to accomplish, we can provide guidance on what issues you might run into, and how to manage them. - V ... View more

Correct, there is no ST_GEOMETRY for SQL-Server.  You can use Well-Known Text as a transfer mechanism to Microsoft's native Geometry type.  The capabilities of Geometry are documented both online and in the SQL-Server documentation. - V ... View more

The Grid format is binary, and uses compression, while ASCII isn't binary and doesn't.  If the increase is only 4x, it's only because the range of values in the grid is rather small -- I'd expect a larger increase in storage with a wider range of values. There isn't really any way to make an ASCII raster smaller than binary -- even without compression coming into play, rasters that store in a byte are going to require, on average, 3.57 bytes in ASCII (0-9 use two bytes [with spaces], 10-99 use 3, and 100-255 use 4).  The grid format uses compression on four-byte integer or floating-point values, so a grid is already 2x or 4x larger than a GeoTIFF that supports 1- and 2-byte integers. Once you start transcribing into ASCII, you've got the separator space plus 1-11 digits (with the negitive ranges) for integers and 2 characters left of the decimal, the decimal, and 6-8 characters to the right, and then "e" a sign character and to two digits for the exponent (~15 characters for each 4-byte uncompressed float).  Compression usually achieves ~40-60% savings, so the worst case expansion is on the order of 10-12x.  It that light, 4x doesn't look so bad. If you want to reduce the storage, you'll need to look at a raster format that supports smaller pixel depth and lossless compression.  The lossy compression formats (JPEG, MrSID, JP2K) achieve high compression at the cost of precise reproduction of the source data. - V ... View more