Latest Contributions by VinceAngelo

I'm not familiar with the details, but if you have ArcGIS Server Image extension (ne Image Server), you can leave the image marginalia intact and construct a mosaic on the fly from the base images. It might be less work than starting over with a lossy process, but you'd need an evaluation license for the Image extension (to start). - V ... View more

Sure, provided that: 1) It's not an unmanaged raster catalog (in which case the source rasters still exist as is), 2) The source hasn't been mosaicked into the geodatabase (in which case you'd need to know the source bounds to clip it back out again) 3) A lossy compression algorithm hasn't been used (only LZ77 is lossless) 4) Some other process hasn't been run which changed the source data (reclassification, pixeltype expansion, etc) 5) Your export client (usually ArcGIS) supports export to the original format - V ... View more

ArcSDE has been using the SDE.SERVER_CONFIG table to store initial connection paramaters since 9.0. The 'sdeconfig' utility updates this table; changing the giomgr.defs file only matters if you then use 'sdeconfig -o import' to post the changes to the server. I believe the code for unlimited size is '-1' (you can query the table directly with SQL*Plus to confirm this). I have no idea why changing the MAXBLOBSIZE would impact session-based logfile creation; if it works, this a great question to ask Tech Support. - V ... View more

If you get a failure message during raster load, you probably shouldn't trust that it was loaded successfully, even if something was populated.  If load failure occurs in a mosaic, it can corrupt the entire image, but load failure for a catalog should be correctable by deletion of the affected row(s). If you suspect a software installation issue, it generally doesn't hurt to uninstall, then make sure all the independent subcomponents (like Python) are also uninstalled before reinstalling. If the problem still exists after reinstall, I suggest you post in the Imagery and Raster Data forum next door, with as many details as you can, including the version and service pack of software in use, the number and sizes of the source rasters, the type of geodatabase you are using  (ArcSDE, FGDB,...), the parameters you are using for catalog creation, and the content of your processing scripts. When you're really stuck (especially with a deadline approaching), you should contact Tech Support, since they're the folks who are paid to answer the phones (the folks here in the forums are, for the most part, volunteers, so we tend to only tackle problems we've seen before). - V ... View more

I can't reproduce your issue with ArcSDE 10sp1 (on my 7 year old home PC to a 5 year old ArcSDE dev box on the same net) or ArcSDE 9.3.1sp2 (on my home PC to an office Oracle server over VPN). Both environments return results in 2-3 seconds (equivalent sdequery invocations [with 15 fetches and 2 column display] take 150 & 810 milliseconds, respectively). You'll need to start an incident with Tech Support to resolve this. They'll need to know which version of Java you're using. - V ... View more

It's not the role of Esri documentation to tell how to use native geometry types, just how they integrate with Esri applications.  Since the potential of Spatial Types and Functions is near infinite, it's not really possible for even the database vendors to document the possibilities. Esri maintains a vendor-neutral stance.  They partner with all the database vendors, and really can't delve into "better or worse" evaluations without compromising that neutrality (and/or the terms of the partner agreements). The reason customers should evaluate for themselves is simple:  Every deployment is different.  If an evaluation requires 13 pages of footnotes for 4 pages of content, and is not indicative of performance elsewhere, why publish it? Generally speaking, the reason to use native types is to expliot them with non-Esri clients. If you have no intention of doing spatial queries outside of ArcGIS, then the only reason to use native types would be performance, which is pretty easy to evaluate in a prototype during development. - V ... View more

What version of ArcGIS are you using?  The documentation has plenty of content at 9.3.1 and 10.0, which is roughly where support was introduced. It would be unusual for Esri to publish "pros and cons" since the definition of each is subject to unique interpretation. A search of these forums on "SQL Server geometry geography" brings up a number of real-world issues to consider. - V ... View more

I've never figured out Oracle's naming convention for LOB meta-tables, but anything too large to fit inline will be stored in an exta table.  Coastlines are difficult because the shapes can wander quite a distance, making life difficult for the renderer.  I've found that overlaying a 5 degree grid on the globe and using it to clip all shapes that exceed 5x5 dimensions significantly improves both query and render performance in most cases. - V ... View more

It's been years since I last used the Java API, but when I did I usually found the performance underwhelming (I was writing an engine to process 5000 inserts with complex pre-processing in under 10 seconds , and had gotten insert time with 'C' down to 1.5 seconds when I started using Java -- since the initialization phase took 13-18 seconds [vice 200-300ms with 'C'], the thought of writing several thousand lines of new Java code for the rest of the preprocessing became too daunting). It's difficult to recommend any optimization without learning how the 'C' API performs with similar queries, which would look like: sdequery -l table,shape -C shape,id -E minx,miny,maxx,maxy -N -u user -p pass - V ... View more

How large is the shapefile (storage of .shp/.shx/.dbf combined)? How large is the table (incuding the related LOB table for SDO_GEOMETRY storage)? Databases have a *lot* more overhead to implement ACID (atomicity, consistency, isolation, durability) on each query, while a flat file has none.  This is why flat files are very nearly always faster on a full table scan.  Note that this is not an "ArcSDE performance" issue -- it's a *database* performance issue. If you want to improve database performance, you can follow this simple rule: Never draw all objects in large tables There are many ways to implement this:  You can make the table thinner by generalizing the geometries of objects with many vertices.  You can make the table shorter by unioning rows by attribute. You can avoid querying the table by setting a scale dependency in the client application.  Or some combination of two or three. Since the data is basemap information you have additional options, including storing the data in a different storage format, and using a map cache to avoid repeated rendering. - V ... View more

It would be very rare for a full table scan query in a database to outperform a local flat file.  I've only seen that kind of performance from a DB2 database (which somehow returned 3.7M point features [with ~1K of attributes] in under four seconds). It is impossible to control order of presentation out of databases without providing an explicit ORDER BY clause.  Generally, they will present the data in the order of the driving table or index, but the optimizer and cache have free will without an ORDER BY (which usually slows down performance, since the data is copied to TEMP and sorted before return). Generally speaking, SDO_GEOMETRY will be slower than ST_GEOMETRY or SDELOB/SDEINARY on a full table scan query, simply because the Esri types use a compression algorithim that reduces storge significantly -- less data pages == faster transfer. Keep in mind that ArcSDE only returns the rows the database provides (in the order it provides them, subject to omission for failure to meet spatial filter criteria), so nothing in ArcSDE tuning can change SDO_GEOMETRY return order.  You can only change return order of Esri storage types by specifying an SM_ENVP_BY_GRID search filter (and even that has not been reliable the last few releases).  ArcSDE also has an optimizer that determines whether to query the table directly or use the spatial index (the threshold is based on comparison of the envelope of the search filter to the envelope of the layer, so changing the layer envelope can impact whether an explicit spatial constraint is applied [ArcSDE will filter geometries in the result stream either way]). I usually go out of my way to load data in an order which will permit the fastest possible spatial search performance, which involves exporting all rows in spatial index order and reloading them so that spatial fragmentation is kept to a minimum. - V ... View more

You should contact your distributor. ArcSDE SDK install is not required for users of applications developed with the SDK. All they need is *some* ArcSDE client application (like Desktop, or Server, or IMS, or ArcSDE, or ArcExplorer,...) for the sde/sg/pe DLLs to get resolved.  I try to make sure that ArcSDE is installed (sans post-install), because my tools are meant to work as a complement to sdetable, sdelayer,... - V ... View more

The ArcSDE 'C' & Java SDKs are in a separate media bundle that you need to request through Customer Service (not downloadable). - V ... View more

The problem with your #1-B example is that it ignores the possibility of NULLs. If you want to submit an ER at ideas.esri.com, you'll need to add a bitmap of length (ncols+7)/8 bytes to the front of the bytestream. I still don't think this will result in significant time savings. - V ... View more

If you are changing RDBMS releases (10g ->11g) you should probably upgrade the ArcSDE install before attempting data import. Even when homogeneous, you can't rely on impdb to create the SDE user first. This is why I recommend doing a full ArcSDE install, then a data import, then register the imported layers with ArcSDE (sdelayer -o register). - V ... View more