|
POST
|
Mike - I'm afraid you may be courting sorrow and woe. Let's say you've ordered a minivan to tow a small "teardrop" camper, then at the last minute, your spouse mentions that an 8-ton "fifth wheel" camper was ordered instead. Even if you can locate and install a fifth-wheel tow-hitch trailer, and paint a picture of a monster truck on the window of the camper, it's unlikely you're going to be able to visit Rocky Mountain National Park. Right now you're still trying to get the wiring on the fifth-wheel cart correct, but I worry that you may not get this contraption street-legal. If you do get the wiring in place, and if you're only headed to a state park 5 miles away, maybe this will work for a while, but I don't think you'd be able to get warranty service on the minivan engine or transmission (or a refund on the camper). You may need to start an "expectation management" campaign, because the performance characteristics and reliability of your solution may not meet requirements. Even if you store the geometry in PostgreSQL and link to the foreign attributes through views, you're likely to have a temperamental and sluggish application. - V
... View more
10-19-2017
12:58 PM
|
1
|
1
|
2420
|
|
POST
|
I've done more than my fair share of programming in the TCP/IP stack, and there really isn't any reason for transient disconnections on a reliable network. Since TCP/IP hides the physical layer from the application, frequent TCP connection failures are the very definition of an unreliable network. The very nature of Direct Connect connections is to utilize the network protocol of the database API. If they report a connection failure, it's not possible to reject the error and force it to remain connected. At this point, all the cached commands in the Direct Connect thread queue are invalidated. It's not just that this is a non-simple task, it's a nigh-on impossible task. If you then multiply by a dozen different Direct Connect drivers, the magnitude of the problem is exposed. In fact, database transactions are what make it impossible. You can't rejoin a transaction after it fails, and that low-level failure during a COMMIT is what invalidates the uncommitted changes. Remember that the versioned geodatabase model saves the individual undo-able edits as states in the versioned state tree, and the act of "saving" is really only changing the state of the version associated with the edit session to the last created state. So, in a sense, you can access the committed states through the point where the editing failed, but you'd need to take heroic (and unsupported) measures to align the version to that state. If the edit session is not versioned, then a simple implicit ROLLBACK erases any memory of the edits. Best practice remains to save frequently during an edit session. - V
... View more
10-16-2017
10:00 PM
|
1
|
2
|
3852
|
|
POST
|
Please understand that you are saying the equivalent of, "It's a disgrace that a painter can't immediately continue his brush stroke when the ladder he was using is dragged down the street in a brief safety line mishap. It's completely insane that the brush box doesn't articulate this hazard." For a TCP/IP application, losing network access, even briefly, severs the communication link. Even if the database client software has the ability to re-establish communication, it's unlikely that this reconnection protocol will be entirely seamless with respect to the client application, and the hash that this makes within the transaction model isn't likely to make application recovery any easier. It takes a great deal of effort to find the right balance of database API options to implement geodatabases with reliable network access. It's unlikely that the same order of magnitude of performance would be achievable if the client library were optimized for unreliable connectivity (assuming this is even possible). It doesn't seem fair to blame a third party for the error messages generated in some other vendor's library by failure five or six levels away in the OSI model. If you need to work with unreliable network access, you need to use tools which do not require continuous connectivity. There are a number of available options using the Esri technology stack, including disconnected editing and feature stream editing with REST endpoints. - V
... View more
10-16-2017
08:32 AM
|
1
|
4
|
3847
|
|
POST
|
No, the underlying ArcSDE API constant, set to 32 (but not counting the string terminator) has not changed since SDE 3.0.
... View more
10-13-2017
11:57 AM
|
0
|
1
|
3519
|
|
POST
|
If you prepend the column name with "DISTINCT ", the field contents becomes 31 characters long, which happens to be the maximum column name length. Very curious. - V
... View more
10-13-2017
11:44 AM
|
0
|
3
|
3519
|
|
POST
|
The PATH (system environment variable) needs to change with release, since the version number is part of the name with the site package. sys.path is assembled from PATH and site package loading instructions. I prepend C:\Python27\ArcGIS10.n; or C:\Python27\ArcGISx6410.n; to PATH in the cmd.exe window or shell script (where n is the installed release) - V
... View more
10-13-2017
09:00 AM
|
0
|
0
|
3104
|
|
POST
|
If you have both Desktop and Server on your machine, you must have two copies of Python (32-bit and 64-bit). If you had an old version of Python with the 10.3.1 install, then you might have as many as three installs (four, if Server or 64-bit Background Geoprocessing was installed). import arcpy works on every one of my 10.5.1 installs (both 32-bit and 64-bit, since I install Desktop 64-bit Background Geoprocessing), so the problem is specific to your installation. You should make sure the appropriate bin or bin64 folder is in your PATH variable (different install order with default PATH will cause all manner of install issues -- If Windows finds the right DLL name, but it's the incorrect word size, it will report "File Not Found").
... View more
10-13-2017
06:58 AM
|
1
|
2
|
4255
|
|
POST
|
You left off the registered rowid column. You should ALWAYS have a NUMBER(38) column. Simple table creation likely defaults the SRID to zero, which doesn't have Z and M settings. I haven't used Oracle in a while so you 'll need to explore how to specify an appropriate spatial reference ID. - V
... View more
10-13-2017
06:31 AM
|
0
|
0
|
863
|
|
POST
|
The spatial reference properties of a layer are established at creation. You can't add Z or M (or both) to an existing layer. What was the exact SQL you used to create the table? - V
... View more
10-12-2017
12:12 PM
|
0
|
2
|
863
|
|
POST
|
Note: Cross-posted to GIS Stack Exchange, but placed on on hold there as unclear. There are several confusing aspects to this post. First off is the conflict between apparent geographic decimal degrees input (albeit in reversed order -- {Y,X} instead of {X,Y}) and the spatref_epsg variable (which asserts a projected coordinate system over the Caspian Sea, which is nowhere near the central Colorado implied by -105,39). In addition, your indent scheme is wrong as posted here, since the for loop isn't inside the with which processes the input file (the answer this new question is based upon has correct indentation). You also seem to want to use the first field in the CSV, but only insert insert the geometry field into the shapefile. Finally, the insertRow request accepts a row array, but you aren't providing an array parameter. Please update your question to have the correct Python indentation and information about the SpatialReference of the data target. It would probably help to instrument your Python code with print or arcpy.AddMessage so you can share information on the flow of control exhibited by your code. - V
... View more
10-12-2017
11:30 AM
|
1
|
0
|
2778
|
|
POST
|
You seem to be conflating two different abstraction layers. There is a set of database tables which maintains versioned geodatabase metadata, which is documented online, but this has little to do with the layers in a Server map service. Worse yet, even though the default layer name in a map document is based on the data source table, it is not safe to assume that the actual source is the name in the layer list (it could have been changed, or cross-threaded, by mistake or otherwise). Best practice is to save a snapshot of the state of the MXD at the time of publishing, so you can look up the actual source, if needed. Note that the map document is a file, not a database, so while the document has a number of properties, including a layer list, and the layers have properties, including a data source, the data is not in any database, per se, and only accessible via GUI or the arcpy.mapping module through Python. -V
... View more
10-12-2017
09:47 AM
|
4
|
0
|
1289
|
|
POST
|
Note: Previously posted in GIS StackExchange, but put on hold for being unclear. - V
... View more
10-11-2017
12:24 PM
|
2
|
0
|
1289
|
|
POST
|
This is probably one of only two valid reasons to use an account with Administrator access through a Database Connection folder (the other being for geodatabase upgrade). It's also a reminder to make sure that core tables are owned by a "headless" data ownership user, so that it is safe to archive (in FGDB) and delete the tables owned by departing users. - V
... View more
10-08-2017
08:16 PM
|
1
|
0
|
2070
|
|
POST
|
There are tons of examples of queries using a DA Cursor (arcpy.da.SearchCursor) to select the WKT ('shape@wkt') or Esri JSON ('shape@json') from a layer source. Take a stab at it, and post your code if you run into trouble. - V
... View more
09-27-2017
06:16 AM
|
1
|
0
|
7351
|
|
POST
|
Please ask new questions in a new thread. "Lots" should be quantified, with more details on how the data is organized and being used. - V
... View more
09-25-2017
07:05 AM
|
1
|
0
|
1182
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 2 weeks ago | |
| 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 |