|
POST
|
What, specifically, is the id of the record you are trying to select? Is it 14036678? If so, it is the underscore that is tripping you up. The LIKE operator is for pattern/wildcard searching. There are two operators, the percent sign (%) and the underscore (_). The % operator matches zero or more characters while the _ operator only matches one character; thus, '11%' will match '11' while '11_' will not.
... View more
11-18-2014
07:43 PM
|
0
|
1
|
1395
|
|
POST
|
I think insert and update cursors were more the target for enabling with statements than search cursors, but people have a tendency to want to keep best practices simple. Instead of having one best practice for insert and update cursors and a different one for search cursors, we have ended up with one for all three. I like list comprehensions, and I think they can work well with search cursors. I was just pointing out the trade-offs of the two approaches, not trying to evangelize one over the other.
... View more
11-18-2014
11:56 AM
|
0
|
0
|
2211
|
|
POST
|
The documentation does give the impression that database locks will be released, but the documentation doesn't get into specifics of which locks. Currently, using a with statement for da-based search cursor releases the read lock on the layer but not the schema lock. My guess is that the schema lock can't be removed because the with statement resets the cursor iteration to streamline using the cursor again. Explicitly deleting the cursor object will remove the final schema lock. Is this poor documentation or a bug? I haven't submitted a Support case to get an answer, but I am leaning toward Esri saying the former.
... View more
11-18-2014
11:52 AM
|
0
|
2
|
2874
|
|
POST
|
I agree a list comprehension can shave several lines off the code block, but we also lose the with statement. I don't know whether it is formally documented, but I have read and heard several Esri staffers say using with statements is a best practice when working with cursors.
... View more
11-17-2014
03:28 PM
|
0
|
7
|
2874
|
|
POST
|
It is easier to look at code and provide feedback than statements describing the code. What code are you using to build the table views?
... View more
11-17-2014
12:54 PM
|
0
|
0
|
766
|
|
POST
|
I did a quick performance check of the code above using pre-computed centroids stored and indexed versus generating centroids on the fly. The latter approach took over 5x longer to run, and that was on a fairly modest-sized dataset.
... View more
11-16-2014
07:50 AM
|
1
|
0
|
6736
|
|
POST
|
I am not sure what your unique identifier is for municipalities, so I went with "id."
SELECT m.shape, m.municipality, s.parcel_count
FROM admin.MUNICIP m,
(SELECT sm.id, count(*) as parcel_count
FROM admin.PARCEL sp, admin.MUNICIP sm
WHERE sm.shape.STIntersects(sp.shape.STCentroid()) = 1
GROUP BY sm.id) s
WHERE s.id = m.id
If you only wanted parcel count by municipality, without the associated shape, then the subquery itself would do the job. Since you want the associated shape, you need to join the subquery results back to the municipality layer for mapping purposes. Performance wise, I am not sure how the above code will do. You mention 17 hours, that does seem excessively long. There are several things that could be going on. One could be poor or nonexistent spatial indexes. Check the execution plan to make sure spatial indexes exist and are being used. I am also thinking that converting to a centroid on the fly could cause a performance hit. For the minimal storage hit of adding a point field, it might make sense to store both the parcel polygon and centroid and then index both of them. Also, if the parcel count isn't changing very much on a minute or hourly basis, it might be worth considering computing it once a day and storing the value for mapping and reporting.
... View more
11-15-2014
05:38 PM
|
0
|
4
|
6736
|
|
POST
|
It seems you are using the older/original search cursor instead of the newer data access (da) search cursor. Have you tried using the da.SearchCursor with a Python with statement? Does that change the result?
... View more
11-14-2014
06:02 PM
|
0
|
0
|
3017
|
|
POST
|
I, too, would be interested if there was a way to see all of the layers and table views created with arcpy outside of ArcMap, but I haven't found a way yet. Obviously within ArcObjects it is being done, but it doesn't seem to be exposed through arcpy. I guess the logic is that if you are creating them in your code then you should have an idea what you have created and can delete them as well, i.e., track it yourself. I wouldn't mind being wrong on this one.
... View more
11-14-2014
08:02 AM
|
0
|
0
|
1607
|
|
POST
|
A cursory performance check shows SQL postfix being the quickest against a file geodatabase and SQL prefix being the slowest. Runtimes relative to SQL postfix: SQL postfix (+0%), List (+3%), Set (+4%), SQL prefix (+14%). Interestingly enough, having the data in a personal geodatabase nearly doubled the runtimes of every approach across the board.
... View more
11-13-2014
08:07 PM
|
0
|
0
|
2874
|
|
POST
|
Although I think the approach is sound, it is bad practice to use a built-in function name as a variable identifier, i.e., naming a list 'list'. The code as written will work, but shadowing a built-in name could cause confusion further down in the script. Another option for finding unique values is to use the set data type, which inherently doesn't allow duplicates.
#Create empty set
salesSet = set()
with arcpy.da.SearchCursor(table, ["Sales"]) as cursor:
for sale, in cursor:
#Add sales to set
salesSet.add(sale)
del sale, cursor
#Iterate through set
for sale in salesSet:
arcpy.MakeFeatureLayer_management(table, "tableView", "Sales = '" + sale + "'")
...
...
A slightly different tack is to let the database engine identify unique values either through a SQL prefix
with arcpy.da.SearchCursor(table, ["Sales"], sql_clause=('DISTINCT', None)) as cursor:
or SQL postfix.
with arcpy.da.SearchCursor(table, ["Sales"], sql_clause=(None, 'GROUP BY Sales')) as cursor:
Performance wise, I am not sure where each approach falls out, but I can't imagine the differences being noticeable. My personal preference is using DISTINCT in a SQL prefix, but I know that ArcGIS 10.1 had issues with SQL clauses in cursors, so using a set data type might work with more versions.
... View more
11-13-2014
07:26 PM
|
0
|
12
|
2874
|
|
POST
|
What is the backend storage format? File geodatabase? ArcSDE geodatabase? I ask because there may be other approaches that work more efficiently if the data is all stored in a DBMS.
... View more
11-13-2014
06:16 PM
|
1
|
4
|
2211
|
|
POST
|
In similar situations in the past, I just resorted to using the pipe symbol or vertical bar as the field separator. Although I have seen crazy data where people use commas, colons, semicolons, and slashes in places they shouldn't be; I seldom run across people using vertical bars in free-form text.
... View more
11-13-2014
02:05 PM
|
0
|
0
|
4182
|
|
POST
|
The following shows the type of situation I caution about above: My original code would generate a distance of 266.7m for the given point on the lake above with a fetch angle of 337.5 degrees. My guess is that you don't want the total length of the line, but the length of the first part ( Part(0) ) of the line, which is 96.16m. Assuming the lines will be built from the point outwards, which I believe will always be the case with this code, the following change to the last loop will return the length of the first part and not the length of all the parts.
for i in drange(0, 360, alpha):
pl = linefromPolarCoord(i, distance, pt, SR).intersect(pn,2)
pl = arcpy.Polyline(pl.getPart(0), SR)
insertCur.insertRow([OID, i, pl.length])
... View more
11-13-2014
09:06 AM
|
0
|
1
|
4648
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 06-11-2026 07:04 AM | |
| 1 | 4 weeks ago | |
| 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 |
yesterday
|