Latest Contributions by VinceE

Thanks anyway Dan, but I am familiar with the error number--it's in my original question. I am also aware that using "None" (without the quotes) still works. Again, that is in my original question. I am not clear on your point regarding "math.nan". I would like to understand why this warning message has been added, or what is happening under the hood. What am I even being warned of here? Seems to me, Python's None data type has been the universal "<Null>-setter" for quite some time: numeric fields, text, fields, date fields, etc. ... View more

Ah, I see, that makes sense. Thanks again for sharing your experience with them, very helpful. ... View more

Thanks for adding to the discussion. Seems to me that if I "Click to add a new row." at the bottom of an attribute table with subtypes defined, and then press "Enter" to confirm that new row (even without creating geometry or entering any attributes), the subtype of the feature will be whatever the default is. I guess this is potentially useful if most of my new features are of a particular subtype. Maybe it's as simple as that. It's just weird to me how the creation of the default is implemented. And then you can't remove it. I have not used ArcMap/ArcCatalog for several years, but it sounds like maybe the implementation had greater utility in that software? ... View more

Agreed, Field Maps was mostly great, but the offline areas were ALWAYS touch and go when I had field teams using them in poor service areas, which made using them a real pain. I haven’t supported field teams in a little while, it’s a shame to hear the application still isn’t completely reliable. edit: At the bottom of this page, there are still tons of links to folks experiencing issues creating offline areas, so looks like Esri still has some work to do. ... View more

Never did unfortunately, just had to manage any data that was collected “offline” differently than the live stuff. ... View more

Thanks, it does, however this is a pretty clunky solution, and one that is not required in VS Code. My response to @Luke_Pinner below has a bunch of screenshots from the simple "import arcpy" working in VS Code. This feels like a problem specific to PyCharm for whatever reason. Would love to hear if you have other ideas. ... View more

    Interesting, thanks for the reply. I might be misunderstanding you, but this is not my experience (at least in VS Code). Using VS Code, I have never imported arcpy.management, arcpy.analysis, arcpy.cartography, etc. in my tools. I have also never seen reference to this import syntax in Esri documentation. This and the anecdotal evidence below make me skeptical that I need to "import arcpy.management". In VS Code, intellisense from base arcpy import: also getting intellisense for management functions with this import style: This is also not how other modules work, at least for me in VS Code. I don't import numpy.random for intellisense regarding "randint". or in PyCharm. Would love to hear other ideas, if you have them. This feels like a PyCharm problem/setting, or something to do with the way ArcPy is written and interpreted by PyCharm, not an import style problem. ... View more

To follow up with this, I have had luck simultaneously using an UpdateCursor and an InsertCursor on the same feature class. I had a field with a list of values in it, and I needed to explode that list out so each item was in a single row with it's own point. This meant updating the current row to include only the first value in the list, and then creating new rows in the same feature class for each subsequent value in the list. Using the Editor class enabled me to do this. I don't know exactly what makes this necessary, but I was not able to do it without the Editor.   with ap.da.Editor(outgdb): with UpdateCursor(infc, '*') as ucurs, InsertCursor(infc, '*') as icurs:         ... View more

This is great, thanks for sharing this. For the fun of it, I rewrote to avoid using the nested cursors. I think a lot of this is a matter of style/opinion, but this separates the reading and editing from the writing, and also only sorts using the lambda function, rather than once with the SQL query and once with the lambda. It's basically the same as yours, it just creates a dictionary of updated values with the OID as the key, which enables writing in the correct order. This only uses two cursors (I believe you are recreating an UpdateCursor with every SearchCursor loop--I don't know how expensive that is). However, this version does have to create the intermediate dictionary. While I still think using the SQL query could be cleaner/easier to read, I assume it is slower because it forces the user to add and calculate a separate coordinate field (unless they have a spatially enabled geodatabase). Because the spirit of the question was specifically about using the SQL query, I am going to leave that as marked correct for posterity, but thanks all the input! from string import ascii_uppercase from arcpy.da import SearchCursor, UpdateCursor fc = r'PATH' # Ensure OID and SHAPE are index 0 and 1. fld = [f.name for f in ap.ListFields(fc) if f.type not in ['Geometry', 'OID']] all_fld = [ap.da.Describe(fc)['OIDFieldName'], 'SHAPE@'] + fld # ['OBJECTID', 'SHAPE@', 'LBL', 'XCOOR', 'YCOOR', 'GRP'] # Indices of fields, used to call specific values in cursor rows. grp_idx = all_fld.index('GRP') lbl_idx = all_fld.index('LBL') # SQL WHERE: where = f"""GRP IS NOT NULL AND TRIM(BOTH ' ' FROM GRP) <> ''""" # Use Python sorted w/ lambda funct; update the given row; store in dict w/ OID key. # Sort by GROUP, then DESC x-coor. row_dict = {} with SearchCursor(fc, all_fld, where) as scurs: scurs_sort = sorted(scurs, key=lambda x: (x[grp_idx], -x[1].centroid.X)) for row in scurs_sort: row = list(row) # Can't update SCurs tuple, unlike UCurs list current_group = row[grp_idx] try: if current_group != previous_group: letter_index = 0 except NameError: letter_index = 0 row[lbl_idx] = ascii_uppercase[letter_index] row_dict[row[0]] = row[1:] letter_index += 1 previous_group = current_group # Write the new row back to the same FC, using the OID as key again. with UpdateCursor(fc, all_fld, where) as ucurs: for oid, *_ in ucurs: new_data = row_dict[oid] ucurs.updateRow([oid, *new_data])   ... View more

Thanks for the input! This is close to the approach I would have used had I not gotten my SQL syntax sorted out, but @JoshuaBixby's comments would be issues with the Cursor. I think I would have had to use a SearchCursor, use sorted() with a lambda function (as you have done), and then use a separate UpdateCursor InsertCursor to write the sorted rows to a blank feature class with the same schema. Probably workable, but involves iterating over the same data more times (three total?) than necessary. ... View more