|
POST
|
If you use SQL to DROP registered tables, your geodatabase registry could be corrupted, which can produce cross-association when new layers are registered. At this point, you really ought to contact Tech Support, since they have the tools to diagnose and fix registry issues. - V
... View more
06-07-2010
03:30 AM
|
0
|
0
|
1149
|
|
POST
|
A spatial view requires an existing geometry column; you can't build one on the fly as a part of view creation. This task should be fairly easy to accomplish if you're using a modern ArcSDE (one with ST_GEOMETRY), but if you're not a programmer you're going to need a SQL person to assist you, since writing the trigger to autopopulate the geometry column can be tricky. - V
... View more
06-07-2010
03:10 AM
|
0
|
0
|
1811
|
|
POST
|
What version of Oracle are you using (A.B.C.D notation)? What version of ArcSDE are you using (including service pack)? What version of ArcGIS are you using (w/ SP)? Please provide the 'sdetable -o describe', 'sdetable -o describe_reg', and 'sdelayer -o describe_long' output for table1, plus the USER_SDO_GEOM_METADATA content for that table. Objectids should always be positive non-zero values, so your where clause shouldn't do anything. What does "SELECT COUNT(*) FROM table1 WHERE objectid <= 0" return? How about "SELECT COUNT(*) FROM table1" and "SELECT COUNT(DISTINCT objectid) FROM table1"? If anything, it's not the layer which has been corrupted, but the instance. Have you used DROP TABLE on any table registered with ArcSDE, or any layer registered with the geodatabase? Has the 'table2' table ever existed in instance1? - V
... View more
06-06-2010
04:29 AM
|
0
|
0
|
1149
|
|
POST
|
Databases should always be run on physical servers. ArcSDE should be run on the same physical server as the database (unless you're using clustered database technology). The only reason to run ArcSDE on a virtual server is if you'll only be using Direct Connect. - V
... View more
06-04-2010
04:50 AM
|
0
|
0
|
1822
|
|
POST
|
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
06-02-2010
04:14 AM
|
0
|
0
|
1822
|
|
POST
|
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
05-29-2010
05:11 AM
|
0
|
0
|
876
|
|
POST
|
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
05-27-2010
06:13 AM
|
0
|
0
|
2012
|
|
POST
|
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
05-27-2010
04:19 AM
|
0
|
0
|
1865
|
|
POST
|
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
05-21-2010
07:16 AM
|
0
|
0
|
503
|
|
POST
|
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
05-21-2010
06:54 AM
|
0
|
0
|
500
|
|
POST
|
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
05-21-2010
05:00 AM
|
0
|
0
|
1352
|
|
POST
|
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
05-21-2010
03:42 AM
|
0
|
0
|
500
|
|
POST
|
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
05-20-2010
07:05 PM
|
0
|
0
|
1352
|
|
POST
|
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
05-20-2010
05:42 PM
|
0
|
0
|
2034
|
|
POST
|
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
05-20-2010
04:11 PM
|
0
|
0
|
2034
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 03-27-2026 12:04 PM | |
| 1 | 02-25-2026 07:30 PM | |
| 2 | 10-10-2025 07:28 AM | |
| 2 | 10-07-2025 11:00 AM | |
| 1 | 08-13-2025 07:10 AM |