Latest Contributions by VinceAngelo

While possible, and supported, ESRI does not recommend production use of virtual servers for any ArcGIS Server components.  I had a client who requested performance testing of physical v. virtual servers for ArcGIS Server 9.3.1, and quickly agreed to our team's "use physical" recommendation when they saw the results. This same client did not even consider running databases on virtual servers (or if they did, the option was eliminated long before we got involved), which made it easier to sell ArcGIS Server Image Extension (Image Server) as "image database software" that needed physical servers with fibre-attached disk ("just like Oracle"). Virtual computing is a great way to configure dozens of test hosts in a single beefy machine, but it just doesn't hold up under the disk and CPU load of database or server-side GIS use. - V ... View more

ArcSDE 8.3 and Oracle 9i are both "retired" (unsupported by their manufacturers), so you have fewer options than most.  What version of Oracle 9i are you using (9.2.x.y)?   Have you applied the terminal ArcSDE 8.3 Service Pack and patch (SP2 w/ Three Tiered Connection Security Patch )? Having the exact error message is very useful, but since the error compains about the rowid colum, 'sdetable -o describe' output would be more critical. - V ... View more

Tables and layers the table registry which have never been registered with the geodatbase should be deleted with 'sdetable -o delete'.  Feature classes should only be deleted though ArcGIS.  There are just too many possible places for references to hide in the metadata tables, and that doesn't even count the cross-references to feature datasets and object behavior (look at the entity-relationship diagram and you'll see what I mean). Given that much of the old geodatabase tables have been denormalized into XML at ArcGIS 10, you won't even have the option of hunting down references in a dozen tables. - V ... View more

Have you looked in the error logs of both ArcSDE and Oracle? If the error is invalid geometry, the only way to detect that is to run queries against each table. The 9.0 API introduced a "invalid_shape_mode" flag to streams, allowing the API to pass back invalid geometry instead of crashing the stream, but ArcGIS doesn't use this (probably because it needs valid geometry to render anyway). I added a hidden "+INVALIDSHAPE" flag to the 'sdequery' utility of se_toolkit, but it's not as useful as it might be, since it doesn't capture just the invalid shapes (it just adds "Invalid" before the shape type -- e.g., "Shape: Invalid Line shape (3 parts, 206 vertices)". Yet you could still scan all the layers, looking for 'Invalid', and then do further research on the ones that had hits: #!/bin/sh SDEUSER=browse_user SDEPASSWORD=password export SDEUSER SDEPASSWORD for layer in `sdelist -o layer` do         count=`sdequery -C shape -l $layer -\# 999999999 +INVALIDSHAPE | grep Invalid | wc -l`         test $count -gt 0 && echo $layer $count done I'll add doing something more useful with SE_stream_set_invalid_shape_mode to my "SDEQUERY_TO_DO" list. - V PS: Oracle has a validation function for SDO_GEOMETRY;  that won't necessarily catch all the topology errors that ArcSDE will catch, but it would be a good start. ... View more

You can certainly load all the rasters into an Oracle database with ArcSDE (as a mosaic, or a catalog of mosaics, since they perform better), but if you're going to serve this data out through ArcGIS Server and you're going to cache the map service (which you should), then it may not be worth the storage and load time to bother.  The ArcGIS Server Image Extension (nee Image Server) could also be used to produce maps of this type. Once you have a map service prepared, you can choose which formats you want the service to support, (and if you're using Image Extension, whether you want users to be permitted to download the base data used to make each map). - V ... View more

BTW: If you assume that each spatial query takes only 200 milliseconds, 750M queries will run 150M seconds (~41666 hours or ~1736 days or ~4.75 years) -- Even if each query is only 20ms, you probably don't want to try to let that job run to completion.  This reminds me that I need to add a progress meter on my spatial fragmentation calculation tool (very verbose option, or verbose with >32k cells). - V ... View more

Can you provide the outputs of 'sdetable -o describe', 'sdelayer -o describe_long', and 'sdelayer -o stats' for the view? If you haven't opened a Tech Support incident, you probably should at this point. - V ... View more

It depends on what your map units are.  If the data is degrees, then the default is two degrees. If the data is feet, the default is two feet.  If your data is in meters, it would be unwise to grid at one meter (you might want to file a bug report on that, since the utility would have to expect to generate 750 *million* grid cells, and over 32k or so is too many).  Frankly, the only sensible default value would be the grid size of first level spatial index (gsize0). - V ... View more

What version of Oracle are you using (11.X.Y.Z)? Is the base table registered with ArcSDE?  Can you bounce that? - V ... View more

Does the spatial index on the geometry column exist? Try letting ArcSDE construct it by "bouncing" the layer: sdelayer -o load_only_io -l mytab,geometry -u user -p pass sdelayer -o normal_io    -l mytab,geometry -u user -p pass - V ... View more

Best practice is to maintain a buffer around your data window, so that search circles which exceed the boundaries don't produce errors.  Therefore you should not use an origin of {-180,-90}.  I prefer {-210,-120} and the ArcGIS standard is {-400,-400}. Your scalefactor puts shape precision in the 4.5 nanometer range (roughly), allowing you to map the transistor gates of older CPUs in latitude/longitude.  Your X/Y tolerance is a little more than two meters (~2.2224m), which is a lot closer to my usual 1000000 scalefactor (0.11m) and a good deal larger than the ArcGIS scalefactor default of 1111948722.222223 (0.1mm). Once you've settled on a viable set of coordref parameters, you can use the -R option to specify the SRID in future layer creation. - V ... View more

If it doesn't work on the command line, remove the final AND clause to let 'sdetable' succeed, and then apply that clause via ALTER VIEW from a SQL client (like SQLDeveloper) later. - V ... View more

Maybe it's an artifact of the posting environment, but as I read it, your WHERE clause isn't legal SQL -- did you mean "AND date = (...subselect...)"?.  Even if it is legal, you might be running into a utility parse buffer issue with the long WHERE constraint. It's not strictly supported, but you can generally add exotic options to the view after it's created (as long as it doesn't result in unsupported columns or polynomial expansion of the registered rowid column)-- but the SQL still has to pass muster with the database. - V ... View more

Nothing in the ArcSDE API measures data flow.  The closest would be using the SDEINTERCEPT environment, but then you'd need to parse a few megabytes of trace files. Your best tool for monitoring ArcSDE network traffic would probably be a network analyzer.  If you're using a Direct Connection, all the traffic is database-dependent, so you might look at a RDBMS tool. - V ... View more

There are several issues here.  The coordinate system stores projection information (PROJCS) if a projection is defined, otherwise it just stores the geographic coordinate system (GEOGCS).  It's confusing that the file is ".prj" when there might not be a projection, but that's the naming convention that has evolved since the original shapefile spec was written.  The larger problem is that the coordinate system is just a tiny part of the coordinate reference, but that is the only part which is stored with shapefiles.  Only ArcSDE requires coordinate references, so these properties are not carried in any transfer format beyond SDEEXPORT. With BASIC precision coordrefs, you couldn't define one spatial reference per coordinate system, since you only had 31 bits available.  With HIGH precision coordrefs, it is possible, but that possibility is also a trap -- needless storage precision (relative to the data precision) increases the storage and slows ArcSDE performance.  For this reason, you should not ignore the spatial reference parameters at data creation -- instead you should generate an appropriate value and use that for all objects (via SRID). If individual GP commands produce unique SRIDs as a matter of course, you should contact Tech Support to generate a defect, since the current commands should all generate the same (somewhat inefficient) SR for any one coordsys. The only exceptions are when you are using data outside the expected range for that coordsys, or when you introdce new dimensionality (M/Z), for which no real standards exist. - V ... View more