|
POST
|
Also asked at GIS Stack Exchange. The organizational preference part is still true. Some sites prefer to upgrade to .1 releases, and skip from 10.4.1 to 10.5.1 to 10.6.1. It really does depend on when you decide to upgrade, and what is available, and what local site testing indicates about the stability of your applications with the candidate version for upgrade. Clients are usually upgraded before Server installs, so larger sites often take a while rolling out an upgrade across their enterprise. Smaller sites have less inertia in the older release. - V
... View more
02-04-2018
07:53 PM
|
1
|
0
|
1440
|
|
POST
|
If you look in the Geoprocessing results log, the Python command for publishing will be present. You can issue that command (or its moral equivalent) using arcpy on an ArcGIS Server host (Windows or Linux). If an SOE is involved, the publishing process is more convoluted (using urllib2 to interact with the admin REST service), but a simple GP tool should be fairly straight-forward. - V
... View more
01-31-2018
08:00 AM
|
1
|
0
|
1501
|
|
IDEA
|
I did not do the testing, but I was told about it, back when initial 64-bit Server testing was performed (during 10.0 development), by someone who had a cause to know. If you haven't tested with ten million rows in point, line, and polygon tables, with vertex densities from 100 to 50k per feature, side by side with 32-bit arcpy, with both local and networked data sources, then we really don't have a basis for evaluation of whether the modern drivers are a significant improvement. I have an ArcPy script I developed for benchmarking the break-even point for querying rows using a where_clause vice testing row contents in a DA SearchCursor, using a series of logrithmically increasing table sizes, from 1K to 10m rows, with thin, medium, and wide column data, and varying volumes of data returned, which I will blog about when I have an opportunity (next week, sometime). If you'd like to use the data to populate 64-bit personal geodatabases, then we'd have a way to know whether the speed is reasonable, and how much slower "slower" is. Compiling the data and script took 8-12 hours, but porting the data from FGDB to PostgreSQL took 5 minutes of effort, and tweaking the script to accept a different input folder took another five (IIRC, benchmark runtime against FGDB was 8-12 hours, but only half that for PG). I'll publish the scripts and the results with my blog entry. - V
... View more
01-30-2018
01:58 PM
|
0
|
1
|
4258
|
|
POST
|
Enterprise-enabling a SQL Server instance is not going to change how the RDBMS implements a native datatype, nor will it change how ArcGIS interacts with an unregistered table. You need to identify which row is causing the issue then review the exact geometry to determine what is wrong. Using the native "IsValid" or "MakeValid" functions may be of help, but Microsoft has a different definition of Valid than Esri. - V
... View more
01-28-2018
07:32 AM
|
0
|
0
|
2265
|
|
POST
|
Two million rows isn't all that much with modern computers. I regularly process 20m x 60k Intersect operations, and they rarely run more than an hour. 8Gb RAM isn't all that much -- 16Gb is a modern low-end RAM allocation. But more important than RAM is the type and speed of your disk. A laptop with a clunky old 40ms HDD seek disk would take a compute-year or more to do what a hot new <1ms SSD can do in minutes. - V
... View more
01-26-2018
01:43 PM
|
2
|
5
|
5021
|
|
POST
|
You should post a new question here in Managing Data, providing key details, and including the exact data which is failing. Some of the things you have tried don't seem to have any bearing on the problem ("Enable Enterprise Geodatabase"?!), so you'll probably want to explain how each was relevant. - V
... View more
01-26-2018
12:57 PM
|
0
|
2
|
2265
|
|
POST
|
Also asked on GIS Stack Exchange. I still question the need to two identical SOEs. - V
... View more
01-24-2018
05:38 AM
|
0
|
0
|
1426
|
|
POST
|
I've used a lot of networks, but haven't seen one with transient failures since I left 10-base2 behind in the early 90s (a tall co-worker kept getting his legs tangled in the coaxial cables running under his desk, and regularly yanked the cable out of the terminator). Best practice is to avoid using network-shared file geodatabase, this is doubly true for editing over a network, and exponentially true for editing over unreliable networks. The code to recover from an I/O failure is in the painfully-difficult to impossible range of the difficulty spectrum, so it doesn't seem like this request, if entered in the Ideas queue, would generate a change. The best mechanism to avoid the pain of network failure is to update to a more reliable network (errors should be on the order of a handful per decade). Changing business practices to copy tables locally before editing them will also help, as would utilizing a PostgreSQL database server to share geometry table resources (with or without an enterprise geodatabase). Good luck! - V
... View more
01-12-2018
11:07 AM
|
2
|
0
|
4442
|
|
POST
|
You wouldn't. But if you query a table with null geometries, a None would be returned for the row's array element where the PointGeometry would result. - V
... View more
01-12-2018
09:06 AM
|
1
|
0
|
1269
|
|
POST
|
That's not a null point so much as a nominal Point. A null point would be a PointGeometry with value of None. Point corresponds to SE_POINT3D in the 'C' API, which is a simple struct type
... View more
01-12-2018
08:07 AM
|
0
|
3
|
2673
|
|
POST
|
I have no idea why any one particular layer would have skipped values (besides when using multiple appends and/or multiple simultaneous inserts). The visibility of messiness is questionable, since these IDs are not intended for any other use. You should not ever exceed 20-50 million rows in any table, so reaching the 2^31-1 rowid limit first seems like quite a challenge. If you want to discover why your your site is exhibiting this specific behavior, please open a Tech Support ticket. They have better means to reproduce this issue than I do. - V
... View more
01-12-2018
07:40 AM
|
0
|
0
|
4266
|
|
POST
|
As described elsewhere in this thread, it's an artifact of how features are loaded, and there's no way to externally influence the behavior. It's not hurting anything, so it does not seem to need remedy. - V
... View more
01-12-2018
07:01 AM
|
0
|
2
|
4266
|
|
POST
|
isMultipart appears to be broken for polygons (or at least using a different definition of "multipart polygon" than any other Esri component has ever used). At a minimum, this difference needs to be documented, with a workaround for obtaining the conventional meaning in a reliable manner (using partCount or WKT type). Unfortunately, large polygons (e.g., 1:100k Canada/US/Russia/Australia/Brazil) are very slow in generating Well-Known Text, so using the .WKT method to test for POLYGON/MULTIPOLYGON is a really inefficient means if determining "multi-ness". - V
... View more
01-12-2018
06:54 AM
|
1
|
1
|
2673
|
|
POST
|
All geometry objects are ingested from Well-Known Text using the SgShape geometry library, which has a default "Left Hand Rule" storage orientation*. No matter how you incorrectly wrap the polygons, if the import succeeds, the result polygon will be native left-hand rule (with the polygon shells corrected, if necessary, so that holes follow the outer rings to which they belong, with opposite ring wrapping direction). - V *Not to be confused with what Google calls "Right Hand Rule" which is the same orientation, but as described with the hand over the "upward" face of the shape with the thumb pointing out, and fingers curling in the direction of outer ring rotation.
... View more
01-10-2018
07:08 AM
|
2
|
9
|
5510
|
|
POST
|
In truth, a polygon with a hole is multi-ring, but not multi-part. If the proper WKT starts with "POLYGON" not "MULTIPOLYGON", it is single part, with one or more interior rings (which is why even a single-ring polygon has two left and right parens - "(( ... ))"). The Geometry object method is poorly documented on this score. - V
... View more
01-10-2018
05:59 AM
|
1
|
0
|
5510
|
| 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 |