|
POST
|
I wouldn't go as far as saying you can only use one cursor at a time. There are several factors that affect how and whether multiple cursors will work together on a data set. The types of locks that the cursors require are one factor. The order of which cursors are opened first can be a factor. The backend data storage format is another factor. When it comes to using multiple cursors to access spatial data, having the data in an enterprise DBMS makes a big difference.
... View more
01-22-2015
01:59 PM
|
2
|
1
|
1911
|
|
POST
|
If you install 64-bit Background Geoprocessing, background processing in ArcGIS Desktop only uses the 64-bit version. Now, you can disable background processing and keep everything in-process, which would be 32-bit, but you can't do 32-bit background processing when the 64-bit product is installed. Installing the 64-bit Background Geoprocessing won't change ad-hoc Python code in the interactive Python window, that will still run 32-bit. That said, since ArcGIS Desktop is compiled to be Large Address Aware, it seems 4 GB of address space is available on 64-bit Windows instead of the regular 2 GB. If you wrap your code into a Python Toolbox and run it as a tool, I am not sure whether that executes in the background as 64-bit or would still be in-process and 32-bit. I know I have tinkered with this before, but my memory fails me at the moment. For me, the most straightforward way to use 64-bit Python and ArcPy is to develop the code and execute it outside of ArcGIS Desktop, a standalone script some might say. I develop in PyCharm usually, so I just configure PyCharm to use the 64-bit Python interpreter and ArcPy instead of the 32-bit. When I install 64-bit Background Geoprocessing, it usually automatically updates the IDLE (Python GUI) shortcut in All Programs to use 64-bit instead of 32-bit.
... View more
01-22-2015
01:27 PM
|
0
|
0
|
3019
|
|
POST
|
Bigger picture, you don't need to be using both search cursors and update cursors since both cursors are open on the same FC. You can iterate over an update cursor without updating any values, in effect using it like a search cursor. Usually you wouldn't want to do that because it creates more locks and may have a bit more overhead in terms of performance. In this case, since you are going to open update cursors on the FC already, just work with update cursors. Furthermore, you should be able to restructure the code to do everything with a single update cursor. Instead of creating a new update cursor each time, since your insertFD lists aren't doing anything anyways, you can just reset the cursor and iterate over it again. Resetting a cursor and reusing it is much more efficient and clean in terms of locks than recreating new cursors every time.
... View more
01-22-2015
09:23 AM
|
0
|
0
|
2214
|
|
POST
|
Since you are using a search cursor and update cursor against the FC at the same time, and the search cursor creates the first set of locks, it may be causing an issue since the update cursor will want to generate more locks. Not sure, just thinking aloud. One thing to try, put a del rows statement at the bottom of your try statement (indented to the same level as your search cursor statement). Deleting the search cursor explicitly will more cleanly remove the locks before you move onto the next FC. In theory, reassigning the rows variable to a new search cursor object should release the locks on the earlier search cursor, but that may not be happening cleanly.
... View more
01-22-2015
09:17 AM
|
0
|
0
|
2550
|
|
POST
|
Regarding your use of the older/original UpdateCursor, you are using incorrect syntax. You are getting lucky, if one wants to call it that, because there is a bug in the UpdateCursor where passing a Python list instead of a text-based where_clause causes the where_clause to be ignored. In effect, using cursor = arcpy.UpdateCursor(fc) generates the same cursor for you. The fact that switching everything to the Data Access cursors meant the code didn't work at all, not even the first FC, is telling you something is wrong with the code even for the first FC. What exactly happened when you use arcpy.da UpdateCursors? Does it run and nothing happens? An error code is generated?
... View more
01-22-2015
09:06 AM
|
0
|
0
|
2550
|
|
POST
|
By stall out, what exactly do you mean? Does it stop running and hang? Does it complete but not update what you expect? Does it stop running and generate an error?
... View more
01-22-2015
08:36 AM
|
0
|
3
|
2550
|
|
POST
|
Which version of ArcGIS Desktop are you using? Does ListVersions in the ArcPy Data Access (arcpy.da) not work for you? Or, do you want to only work with a subset of all versions? Or yet, do you not know how to iterate over a list?
... View more
01-22-2015
08:34 AM
|
1
|
1
|
1544
|
|
POST
|
At first glance, you seem to be mixing older/original cursors and the newer data access (arcpy.da) cursors. Your syntax for the update cursors seems wrong. The arcpy.da.UpdateCursor syntax is (in_table, field_names, {where_clause}, {spatial_reference}, {explode_to_points}, {sql_clause}) whereas the arcpy.UpdateCursor syntax is (dataset, {where_clause}, {spatial_reference}, {fields}, {sort_fields}). You appear to be passing your field list as a where clause to your update cursors. Overall, I recommend switching to using all arcpy.da cursors.
... View more
01-21-2015
12:45 PM
|
0
|
2
|
2550
|
|
POST
|
Tough part about forums and not knowing people personally, comments can be read multiple ways.... Anyhow, two other bugs were issued related to the aforementioned Support case: BUG-000084666 and BUG-000084667. Even though the impact might seem limited on the surface, cases like this can point to larger issues with managing precision deeper in the software stack. What isn't stated in the public-facing Support system is that the "bug is not coordinate specific and it is not spatial reference specific." Although the illustrative example involved working in a coordinate system that presented an unusual real-world case, it has been demonstrated the issue is abstracted from a single coordinate system. In the end, the true impact may be small but maybe not. It isn't always easy to tell until developers dig into the bug deeper.
... View more
01-21-2015
11:36 AM
|
0
|
1
|
3596
|
|
POST
|
Esri Support issued a formal bug: Bug BUG-000084665: Attempting to create an equilateral triangle with lengths of 0.0027 gives, "The feature could not be created. The geometry is invalid." However, the distance between each vertex is greater than the XY Tolerance (0.001) and the XY Resolution (0.0001). Alternate Solution: Ensure the distance between each vertex is at least 0.0029 units. I can't say I am a fan of the Summary text. I think it downplays the scope and impact of the bug, i.e., someone might think it is about triangles and not the much larger issue of all polygons and lines. The workaround is basically to not trust the XY Tolerance or XY Resolution of spatial references. Caveat utilitor.
... View more
01-21-2015
10:28 AM
|
0
|
3
|
3596
|
|
POST
|
OK, I think I got a better picture of what you are after now. Are you planning on using ArcGIS API for JavaScript and consuming GIS services or build something in ArcGIS Online? I ask because the example you provide is javascript driven and tends to lend itself to Web-based APIs. Unfortunately, my background isn't in those Web-based APIs, so I don't think my advice would be worth much.
... View more
01-21-2015
08:43 AM
|
0
|
0
|
1961
|
|
POST
|
Did you see the screenshot before you posted it? I see your Inbox and other stuff. Trimming the screenshot to relevant parts makes it easier to work with. Anyhow, yes, layer files are supported, but I think you are looking at this from the wrong perspective. Layer files reference data sources, so are you sure the actual data source is supported? Are you working with a personal geodatabases possibly?
... View more
01-21-2015
08:05 AM
|
0
|
0
|
970
|
|
POST
|
It would be helpful if you would elaborate a bit more on what the final product will look like and how users will interact with it. I have a sense of what you are after, but with this much data, understanding the final product can make a big difference on how it should be structured and processed.
... View more
01-20-2015
07:19 PM
|
0
|
2
|
1961
|
|
POST
|
If you have 13.000.000 points in total, what percentage do you think will be dropped? If you are working with upper millions or more than 10.000.000 unique points, then you are likely running into a memory error related to using 32-bit Python. Quoting from Windows Dev Center: Virtual Address Space .... The virtual address space for 32-bit Windows is 4 gigabytes (GB) in size and divided into two partitions: one for use by the process [2 GB] and the other reserved for use by the system [2 GB]. .... If 4-gigabyte tuning (4GT) is enabled, ... a process that has the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set in its image header will have access to the additional 1 GB of memory above the low 2 GB. Even if your operating system is 64-bit and you have lots of RAM, 32-bit applications are still bound by the 4 GB address space. If 32-bit applications are compiled as large-address aware, they can take advantage of more (3 GB for 32-bit OS or 4 GB for 64-bit OS) address space than the normal 2 GB. If you want to dive into the weeds, check out the Memory Limits for Windows and Windows Server Releases. Although Esri has compiled the primary ArcGIS Desktop binaries (arcmap.exe, arccatalog.exe, etc...) as large-address aware, the Python executables that get installed don't seem to be large-address aware. I am not sure how the memory limits play out since ArcMap is LAA but Python.exe isn't. When running a standalone 32-bit Python script, you start to see memory errors once the process gets above 1.5 GB of address space. One way to potentially get around this is to use 64-bit Background Geoprocessing. Installing that software installs 64-bit versions of Python and ArcPy libraries. That said, Python code from the interactive Python window will not be executed as 64-bit so your script would have to be run as a standalone script outside of ArcGIS Desktop, but at least you could still use ArcPy.
... View more
01-20-2015
06:48 PM
|
2
|
2
|
3019
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 06-11-2026 07:04 AM | |
| 1 | 07-17-2026 06:54 AM | |
| 2 | 07-06-2026 12:29 PM | |
| 1 | 07-06-2026 12:00 PM | |
| 2 | 06-05-2026 10:30 AM |
| Online Status |
Offline
|
| Date Last Visited |
Wednesday
|