Latest Contributions by JamesCrandall

Just a quick idea:  make sure you are fully qualifying the field names appropriately.  They are altered after the join and may not be correctly naming the field(s).  A simple suggestion is to run the join manually in ArcGIS and then look at the field properties to see the correct full name(s). Edit: I don't think this matters as it relates to Spatial Joins (I missed that in your OP).  Sorry for any confusion. ... View more

Not exactly sure what your specific problem is that you are experiencing, but here is how you would check out a license, perform the analysis and then check the license back in.       ### see if spatial analyst extension is available for use       availability = arcpy.CheckExtension("Spatial")       if availability == "Available":          arcpy.CheckOutExtension("Spatial")          print "SA Ext has been checked out"       else:          print "%s extension is not available (%s)"%("Spatial Analyst Extension",availability)          print "Please ask someone who has it checked out but not using to turn off the extension"          return                       #run the analysis           arcpy.sa.Sample(rasters2, transect_in, outtab)       #return the extension       arcpy.CheckInExtension("Spatial") ... View more

Edit: if I add the spreadsheet I want to join to my map, then export to GDB, THEN join my feature class to the GDB table and run "table to table (conversion)", it successfully exports the table with the joined information. Yep.  That's exactly what I was talking about in my OP. You could just use in_memory as your workspace to get the Excel sheet(s) as a gdb table, run the join and export (copy rows) to your desired output. I think you need to validate the time required to develop this vs. just doing in manually.  Also consider future useage in your estimate too. ... View more

Interesting. I already have my feature classes in a GDB feature dataset, but the Excel files are all hanging out in a folder elsewhere. You're suggesting that I (have my script) pull in each of those Excel files into GDB tables and then do the join / table-to-table conversion export? Edit: Absolutely I'd consider it because you already manage the Feature in the GDB.  Why not the related attributes too? It is something I'd consider if there is not too much processing overhead.  However, if you do not have any issues with performing the joins to Excel and just need to do it programatically, then that is doable too. Can you manually perform the task? Load your layer, join it to your excel spreadsheet.  Right-click the layer and choose Data-->Export Data.  Does the resulting layer contain the data contained in the excel sheet? ... View more

At least it is a pile of Excel and not a pile of something else 🙂 Just an idea: use a File Geodatabase to as the data container for all of this data management processing you wish to do.  I've simply resigned to the fact that the system engineers at ESRI have tightly coupled the GDB to ArcGIS for a reason and therefore perhaps it is a good idea to follow.  That is, I've found that moving to the gdb model (for example, moving my attribute tables into this container) a good chunck of my problems simply go away. I say it may be worth the effort to skip this idea of tightly coupling your GIS processing to Excel as it can be a management nightmare (field mapping, nulls, field naming,  changes to the base excel tables, $Sheet management, blah, blah, blah) just is downright unappealing IMO. I'd look into making my first Python effort that of converting the Excel tables to a FGDB (it can hold 2 TB from last I heard).  All of your joins and such will be on their best behavior then and you will have a lot more control over that source data.  Does that make sense? I'd like to hear other suggestions, but personally this would be my first move. Edit: just to add to my post.  I'd also consider doing all of your joins and follow-up exports within the "IN_MEMORY" workspace if possible.  You will gain peformance and can easily cleanup the residual data left behind, while generating your desired output to disk. ... View more

The OBJECTID should not be required, if it ever was it is a bug and is fixed in 10.2.1. It is required/an issue at 10.1 SP1 ... View more

This is truly a strange and confusing method available for the da.SearchCursor.  I mean the GROUP BY clause is normally applied because you are attempting to summarize things (say SUM or AVERAGE, or other some such metric).  But it is entirely weird to require ObjectID which would negate any ability to correctly perform such aggragetion, let alone not even be able to include such a thing as COUNT, MIN, MAX, AVERGE, etc... I hope I am simply missing the obvious here. ... View more

You must list all fields that will be included in the sql_clause parameter in the fields parameter. fc = r'H:\Documents\ArcGIS\Default.gdb\RainGauges' fields = ('Data_Type', 'ObjectID') sql=[None, "GROUP BY Data_Type, ObjectID"] cursor = arcpy.da.SearchCursor(fc, fields,sql_clause=sql) for row in cursor:     print row[0] Matthew, I am still not understanding how this will correctly perform any GROUP BY because of the requirement include the unique values in ObjectID field.  How is this ever going to group on the target fields???? ... View more

I get the same runtimeerror as before... 😞 Is "r_Identity" the actual field name? Make sure the spellng is correct. I get the same error in my working example if it is incorrectly spelled. ... View more

OK, James, I tried to rewrite the script by your 2 suggestions: import arcpy fc = "D:\\Projects\\proj1\\SumsOfRoutes.gdb\\all_routes_1stBatch" field1 = "r_Identity" field2 = "Shape_Length" sql = [None,'Group BY r_Identity'] fields=[field1,field2] cursor = arcpy.da.SearchCursor(fc,fields,sql_clause=sql) # print r_Identity and Shape_Length of each feature in feature class for row in cursor:     print str(row) I get the following error: RuntimeError: An invalid SQL stament was used. [SELECT r_Identity, Shape_Length, OBJECTID FROM all_routes_1stBatch GROUP BY r_Identity] Any Ideas as to what's wrong? and the question I asked Joshua:  I know listing only 2 fields will increase the efficiency of the cursor, but will it enable me to use other fields in the layer later on? You cannot include Shape_Length (see bold above) in your select because it is not included in your GROUP BY portion.  Remove it and see if it at least completes without error. ... View more

I just noticed you have this: fields=["*"] This is not allowable in a GROUP BY statement.  That is, you could not write it as: SELECT * FROM table1 GROUP BY table1.field1 You must specify the fields you wish to include in the group by too!!!  Like this: SELECT table1.field1, table1.field2 FROM table1 GROUP BY table1.field1, table1.field2 ... View more

Here's my guess... Change: sql = (None,'GROUP BY r_Identity') To: sql = [None,"GROUP BY r_Identity"] ... View more

Thanks! This helps a ton!  I tried to following script, and it doesn't generate any errors, but I also don't see any sign of the pictures being associated with the points. When I use the Identify tool there is no image. Just to clarify, you do not see a the little attachment paper clip icon in the identify dialog?  To verify you can use the HTML pop up instead of the identify tool as the result will have the image in the dialog popup instead of having to click the attachment. Also, check the Geodatabase itself for the __ATTACH table and it's associated RelationshipClass.  One last thing: have you attempted to manually setup Attachments instead of with Python code? ... View more