|
POST
|
That is an exceptionally convoluted path to do what ArcPy can do in under a page of code (with a da.UpdateCursor, swapping ordinate order). I wouldn't recommend passing ANY GIS data through Excel, just on principle. - V
... View more
02-28-2017
06:25 AM
|
1
|
1
|
4206
|
|
POST
|
Be careful! A "shapefile" is a specific set of files with a published set of formats. It is not possible to create a shapefile "in" a file geodatabase. Creating a feature class in a file geodatabase creates a new table within the FGDB, which is allocated the next available "slot" in the file geodatabase naming scheme. When you import a shapefile into a file geodatabase, you are creating a new table with a similar schema, but the data is no longer in shapefile format. If you physically place the shapefile set member files in the ".gdb" parent folder, you will render these files invisible to Desktop or Server, because a ".gdb"-suffixed folder has a special meaning to the data discovery subroutines. The "system catalog" approach used in file geodatabases (to store the file names and column properties in tables of the geodatabase schema itself) is an old, old trick, that predates the "INFO" days of Arc/Info. It is also used by PostgreSQL; you can see this if you ever wander into a tablespace directory owned by the 'postgres' user. Oracle and SQL Server do the same, but the virtual tables are hidden in the black-box implementation of "tablespaces" and "filegroups". In order to archive a file geodatabase you must capture ALL of the files under the ".gdb" directory (including the directory itself, but with the possible exception of the ".lock" files). Creating a new table will create new files and modify others. Adding rows to a table will modify the data file and any index files. You can guess which "slot" is issued to which table by the growth pattern, but it is not in any way "safe" to archive only the data files in the slot without the framework that supports the content. I should probably also mention that file geodatabase is recommended for local, not network-shared, use. Something about the perfectly reasonable file access pattern used in the ArcObjects and FIle Geodatabase API makes for a significant (~2x) I/O performance penalty over a network. - V
... View more
02-03-2017
09:11 AM
|
2
|
1
|
2334
|
|
POST
|
Placing the double-quotes around "Height" may have forced the SELECT result set to have a column named "Height", which ArcGIS cannot "see" because it requires ANSI-conformant SQL naming. Try eliminating the double-quotes from the SELECT statement. - V
... View more
02-03-2017
08:50 AM
|
1
|
1
|
1338
|
|
POST
|
Unfortunately, the best way to recover corrupt file geodatabases is to create a new file geodatabase, copy out what can be recovered, then pull in contents of your backups for the rest. You can try to work with Tech Support, but if the data no longer exists on disk, there isn't really anything they can do. - V
... View more
02-01-2017
08:40 AM
|
1
|
6
|
10463
|
|
POST
|
Yes, of course. The only exception was when using SDEBINARY geometry storage, when a layer was in load_only I/O mode, where the triggers were disabled, so that a DELETE would not remove the Sn and Fn rows. Most modern databases use ST_Geometry or native SQL storage, so this doesn't even apply. - V
... View more
01-27-2017
07:08 AM
|
1
|
0
|
1315
|
|
POST
|
kimo wrote: Do you need a geometry AND a wkt version? Surely one will do. You would have to be careful to get the one in the list. This is the key point. By specifying an update of the same column in two different forms, but only updating the first referenced input, the code is likely updating the column with the new content, then updating it again with the previous contents. Multiple references to the same geometry column in an UPDATE or INSERT cursor really ought to raise an error. - V
... View more
01-27-2017
07:02 AM
|
1
|
2
|
5492
|
|
POST
|
Contacting Tech Support should be your first impulse to address low-level database errors. You can post here as well, but GeoNet is not a replacement for Tech Support. Storage format does not change without a a specific request to do so. SDELOB storage would remain so until an explicit upgrade was performed. The Adds table should always have the same geometry storage as the base table. If this is not the case, you absolutely need to talk to Tech Support. The error may be due to corruption of the base table schema with respect to the Adds table; SQL*Plus "describe tablename" on both the base table and Adds table is recommended. Esri supports Oracle 11.2.0.3 at ArcGIS 10.3.1, but recommends upgrade to 10.2.0.4 11.2.0.4 (ArcGIS 10.4 and 10.5 only support 10.2.0.4 11.2.0.4 and higher). - V
... View more
01-25-2017
07:25 AM
|
1
|
2
|
4812
|
|
POST
|
Are you editing a versioned feature class? Does the deletes table remove the base table rows you have edited in favor of a newer version? All edits to versioned tables should be made with version-aware means.
... View more
01-13-2017
08:49 AM
|
0
|
0
|
736
|
|
POST
|
This is more a religious issue than a technical one. Esri supports both Linux and Windows platforms, without regard to which one is "better". There are a few technical issues which could steer you to one platform or the other (e.g., Direct Connect to MS SQL Server enterprise geodatabase is not possible from Linux, or the only version of Windows supported by your IT department is under the minimum or over the maximum required for ArcGIS), but from my experience, Server is startlingly OS agnostic. Utilizing a new OS may have a ramp-up cost (if it's new to your IT infrastructure), but once the install is complete, the Server software behaves the same from a client standpoint. The usual hitches in porting between platforms are tied to customized extensions and the curious way case dependency is handled when migrating from case-neutral path strings of Windows to case-dependent paths in Linux. - V
... View more
01-09-2017
08:46 AM
|
1
|
5
|
5003
|
|
POST
|
Please always include error messages as text in the initial posting itself. There are two reasons: Folks are more likely to read it (and therefore answer) vice a zipped text file. The question (and answer, hopefully) is more likely to be found in a free text search by others with the same issue. - V
... View more
01-06-2017
07:35 AM
|
0
|
1
|
3111
|
|
POST
|
Actually, I should clarify that the units are assumed to be meters (the actual units are undefined) with a tenth-millimeter (1.0e-04) coordinate precision (but what's an order of magnitude between friends?) The SgShape library became the Esri reference geometry library 20+ years ago, but wasn't immediately adopted by all products. SgShape's CoordRef default origin and scale are {0.0,0.0,1.0}, which would snap degrees to the nearest degree and invalidate anything outside Quadrant I. The arcpy SpatialReference type manifests the SgShape library's CoordRef as a wrapper, but it sets the nominal origin and scale to {-450359962737.05,-450359962737.05,10000} (which partitions the coordinate space addressable by a long long integer with {0,0} in the center). The arcpy Geometry type retains the double precision array values, so it's only storing them in a feature class that actually truncates the coordinates to four places (as per the SpatialReference) >>> import arcpy
>>> pt = arcpy.Point()
>>> pt.X = 1.23456789
>>> pt.Y = 9.87654321
>>> print pt
1.23456789 9.87654321 NaN NaN
>>> pg = arcpy.PointGeometry(pt)
>>> sr = pg.spatialReference
>>> print sr.falseOriginAndUnits
-450359962737.05 -450359962737.05 10000
>>> print pg.WKT
POINT (1.2345678899999999 9.8765432099999995)
... View more
12-30-2016
11:13 AM
|
1
|
0
|
2513
|
|
POST
|
It's best to consider spatial reference use to be as "optional" as breathing. In reality, every shape has a default spatial reference, which assumes units of meters, and coordinate precision of millimeters. - V
... View more
12-29-2016
01:27 PM
|
1
|
2
|
2513
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 06-30-2026 09:35 AM | |
| 2 | 06-08-2026 09:13 PM | |
| 1 | 05-29-2026 12:51 PM | |
| 1 | 06-01-2026 06:03 PM | |
| 2 | 05-29-2026 08:31 AM |