POST
|
I assume your .csv file has the necessary OID field, right? It would be very useful to look at the field values to make sure the join is happening the way you think it is. A while back I wrote a sort of helper python module that among other things, can help diagnose things like this: http://arcscripts.esri.com/details.asp?dbid=15290 Basically all you have to do is copy the lmpy.py file your C:\Python2x\Lib folder. Then in PythonWin, IDLE, etc.: import lmpy lmpy.listRecords("my_feature_layer") This will list the field names and field values of the 1st 25 records such as: (note my example doesn't have a joined table). RECORD #1 ---------------------------------------------------------------------------------------------------- OBJECTID: 1 Shape: <geoprocessing describe geometry object object at 0x00C1A188> Shape_Length: 393.699999988 Shape_Area: 9687.48062441 ACRES: 0.222393953728 RECORD #2 ---------------------------------------------------------------------------------------------------- OBJECTID: 2 Shape: <geoprocessing describe geometry object object at 0x00C1A9F8> Shape_Length: 393.699999988 Shape_Area: 9687.48062441 ACRES: 0.222393953728 RECORD #3 ---------------------------------------------------------------------------------------------------- OBJECTID: 3 Shape: <geoprocessing describe geometry object object at 0x00C1A188> Shape_Length: 393.700000018 Shape_Area: 9687.48062588 ACRES: 0.222393953762 Are the field values in your join table what you expected? Are some of the joined field values NULL? If so, you will need to exclude the NULLs (the "can't update field values to NULL" bug is a long standing issue that was finally fixed with v10). Also, take a look at the lmpy.listfields() function. Could it be you are trying transfer a text field into a integer field or something to that effect?
... View more
09-21-2010
08:17 AM
|
0
|
0
|
328
|
POST
|
How about getting rid of the square brackets, since you are referencing a field name and not actual SQL? I'm assuming this is a PGDB data source that has some other table joined to it. Note that the field name that the 'String' variable represents must be in the "parent" join table, and not the look up table. row.SetValue("ScenarioTemplate_1011." + String, school)
... View more
09-20-2010
08:11 PM
|
0
|
0
|
457
|
POST
|
What ArcMap version was the .lyr file created with? Generally, the .lyr files are version-sensitive and not backwards compatible. Other than that, I'm not sure why it wouldn't work... It's not a composite layer (made up from more than one GIS layer), right? You could just recreate anew it your script (MakeFeatureLayer, AddJoin)... That's what I do (rather than using a .lyr as the data source).
... View more
09-13-2010
08:19 AM
|
0
|
0
|
138
|
POST
|
I agree, this has probably gone on much too long... But... one last blurb (well maybe not the last). having a separate Python thread may attract a whole lot of flies from the cartography forum Not sure they would be flies, but... Actually that's one of the point I made very early on in this discussion... With v10, it would no longer be "Python Geoprocessing" but "Python Scripting" (as in a method to automate GIS processes - cartography included). I'd argue that cartography is, in fact, a form of "geoprocessing". BTW: http://wiki.gis.com/wiki/index.php/Geoprocessing has a decent definition. It's hard to have a GIS "visualization" without some form of visual map, image, animation, table, graph, etc.. Cartography automation through scripting is certainly part of the "geoprocessing" equation. I'd put forth a much simpler definition for geoprocessing: Deriving information from geographic data. workflows can mean BOTH modelbuilder and python By "Workflow", I mean the steps needed to accomplish a "geoprocessing task" that is devoid of the automation provided by Python scripting or Model Builder. It could be combined with the Geoprocessing Tools forum quite easily since most complex "geoprocessing" workflows involve analytical analysis rather than cartography/visualizations, but then again... Really, it wouldn't kill me to drop the "workflow" thing, just an idea. Dan I have to ask: Do you think it a good idea to lump all the forums together if ESRI could institute a robust tagging system? I think it's a great idea! However, in the world I have experience with (the real one), I know that robust tagging probably won't happen, and that my simple request to split a crowded and multi-faceted forum topic probably has a much higher probability of actually occurring in the near future. I really like Bill Hubber's comment here: http://forums.arcgis.com/threads/1757-New-Site-Very-Disappointing?p=19661&viewfull=1#post19661 and some of the ones further down. I'd also love to eventually see the Help systems integrated with the forum systems for a help-wiki hybrid. Maybe the existing help systems (complete with the existing drill-down structure) with a built in wiki-forum section for each help section topic - maybe even a bug and improvement wish list section!. That would indeed be very innovative, efficient, and helpful to all users and ESRi staff! Then all the forum/wiki entries could be searched, abstracted, mixed, match however anyone felt necessary (given the proper interface to do that). Do I think that will happen anytime soon? Cmon... But here's to wishful thinking!
... View more
09-10-2010
12:24 PM
|
0
|
0
|
438
|
POST
|
obviously, I need to get out of the python window in ArcGIS 10 ESRI/Anyone know why there is a performance issue here? I thought that gp-type code (like cursors, ESRI tools, etc.) was supposed to run faster in the Toolbox and PythonWindow environments compared to extrenal IDEs like PythonWin and Wing... What happened to that "in process" thing?
... View more
09-10-2010
09:45 AM
|
0
|
0
|
933
|
POST
|
Hmm indeed. I'm pretty much PythonWin all the way... That new-fangled PythonWindow is strange and scary to me. I still can't figure out how to execute simple Spatial Analyst commands though the blasted thing - the help seems totally contradictory! Good ole' SingleOutpuMapAlgebra tool.... look what they have done to you!
... View more
09-10-2010
09:34 AM
|
0
|
0
|
933
|
POST
|
Just playing around with it, but this code (1.5 million keys) took less than 1 second to execute on my machine: dict = {}
for item in range(1,1500000):
dict[item] = random.uniform(1,10) #return a random float
count = 0
for item in dict:
if dict[item] > 5:
count = count + 1
print count
>>> 833384
... View more
09-10-2010
08:44 AM
|
0
|
0
|
933
|
POST
|
suggestion 1, I don't think I can use SelectLayerByAttribute because I have a standalone table In fact you can use a table with SelectLayerByAttribute, but use the MakeTableView tool 1st (in lieu of MakeFeatureLayer), and use the tableview as input. Re: suggestion 2, I thought this might be the winner, since I do have a series of searches to run over the same table. The dictionary idea is probably only a good idea if you have to search the table a whole lot (like hundreds of times - as noted in another thread, it can be a good replacement for an embedded cursor, or some sort of tracing algorithm), because you right, there is a lot of overhead, but maybe something basic like this would work: #v9.3 code BTW
dict = {}
searchRows = gp.searchcursor(tblPath)
searchRow = searchRows.next()
while searchRow:
dict[searchRow.MY_KEY] = [searchRow.FIELD1,searchRow.FIELD2] #this could be a tuple instead of a list to save memory if you didn't plan on changing the values...
searchRow = searchRows.next()
del searchRow
del searchRows
#yes, there's probably a faster/more elegant way to do this... Kim? .iteritems or .itervalues any faster?
rowCounter1 = 0
rowCounter2 = 0
for myKey in dict:
if dict[myKey][0] == 100 or dict[myKey][1] == "dog":
rowCounter1 = rowCounter1 + 1
if dict[myKey][0] == 200 or dict[myKey][1] == "cat":
rowCounter2 = rowCounter2 + 1
print rowCounter1
print rowCounter2
... View more
09-10-2010
08:36 AM
|
0
|
0
|
933
|
POST
|
It is already a list after a split Yes, typing faster than I was thinking...
... View more
09-10-2010
07:50 AM
|
0
|
0
|
933
|
POST
|
Also, I should mention that if you have to find the selected record count repeated (like in some sort of loop), I would suggest investigating a Python dictionary object. Basically you have to take an initial time hit by loading the table's records into the dictionary, but once it's there.... Holy crap it's fast (light speed and not magnetic speed)! See http://forums.arcgis.com/threads/8428-Setting-a-Single-Record-to-Selected-with-Python?p=25930&viewfull=1#post25930
... View more
09-09-2010
02:24 PM
|
0
|
0
|
2448
|
POST
|
Well.... That's a lot of records - seems 20 seconds would be a reasoable time to expect to return the number of selected records in 2.1 million record table! However: 1. If you add an attribute index, the performance may increase (probably for both the cursor and getcount methods): http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00170000005z000000.htm and http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//005s00000011000000.htm 2. This probably isn't any faster (could be for some weird reason though?), but there is a nifty geoprocessing scripting function that will return the OIDs of a selected set of records within a feature layer. From that you can gleen the selected count. For example: gp.MakeFeatureLayer_management(fc, "fl")
gp.SelectLayerByAttribute_management("fl", "NEW_SELECTION", "WIDGETS > 30")
fidSet = gp.describe("fl").fidset #this returns a big honking text string - can be millions of charatcters long in my experience!
selectedOidList = []
for fid in fidSet.split(";"):
selectedOidList.append(fid)
print len(selectedOidList)
... View more
09-09-2010
02:15 PM
|
0
|
0
|
2448
|
POST
|
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Registering_tables_to_be_used_by_ArcGIS_Desktop says that the RegisterAsVersioned_management tool will take an unregistered table from the DBMS and register it as Versioned. I suppose if you want to drop the versioned status, use the UnregisterAsVersioned_management tool. Doesn't say anything about a tool to unregister the table with SDE though. I think the command line Oracle or SQL or whatever is really the way most DBAs would do (register/unregister) it though.
... View more
09-09-2010
12:32 PM
|
0
|
0
|
193
|
POST
|
Jim, Sorry for the resurgence/mentioning of the organization, tagging and drill down ideas. Those are beside the point... After Chris Mathers became decided, the votes are 6 to 2 in favor of splitting. So, splitting the Geoprocessing forum is the consensus (sorry Dan and Chris: I think you are right, but splitting is more right). Also, after looking at some of the recent posts to the the "ArcGIS Desktop - General" forum , I have some suggestions: 1. Close the "ArcGIS Desktop - General" forum topic, and redirect it to a new forum topic called "Other/General" in the Functions section. As I think Dan was trying to point out, the majority of ArcGIS Desktop questions are being posted to the "General" forum, and in fact the vast majority concern a "function". I don't think this was ESRI's intention at all, but was the logical outcome due to the organization of the new forum and the confusion surrounding it. I would put forth that most posters to the "General" forum don't even know about the Functions sections. Simply redirecting the existing General forum to a new "Other/General" forum (properly placed in the Functions section - NOT the Products section - as it probably should have been originally), would force users to see that there are more focused forum topics for them to post to than "General". 2. Split the existing Geoprocessing forum into: ModelBuilder Scripting (Python) Tools (ArcToolbox) Workflow I believe that a "Workflow" forum would be quite interesting and popular. Many users that post questions in the "General" and the Geoprocessing forum simply want to know the steps needed to get to a desired result. I strongly believe a "Workflow" forum would be one of the most popular and heavily monitored by contributors such as myself, Dan, R.D., etc. (you could always redirect/delete it if I'm wrong). On a side note, I noticed that the "Extensions" forum was recently split into it's proper constituents, so it seems there is a good and recent precedent for splitting the lumps... Anyway... I'm done.
... View more
09-09-2010
11:33 AM
|
0
|
0
|
438
|
POST
|
Classic gp memory leak... Hope that all the progress that ESRI made on this issue doesn't resurface in v10...
... View more
09-09-2010
08:05 AM
|
0
|
0
|
885
|
POST
|
...would multi-level expandable trees that drill down to over 200 nodes be cleaner and simpler than what we have now, which is a single flat level of about 60 forums? Not sure about 200 nodes (completely expanded w/ all software "products" maybe), but based on what I see here: http://forums.arcgis.com/forums/3-ArcGIS and http://forums.arcgis.com/index.php I would have to answer yes, a "multi-level expandable trees that drill down... would be cleaner and simpler than what we have now". Even at the lowest (most drill downs) level I mentioned: ArcGIS Desktop > Functions > Geoprocessing > Automation > ModelBuilder - That's only 5 nodes Anyway, just an idea... Split. Tag. Drill down. It's all the same. Something to make it easier to wade through the newly lumped forums. Empower and encourage contributors to share their knowledge.
... View more
09-08-2010
03:48 PM
|
0
|
0
|
438
|
Title | Kudos | Posted |
---|---|---|
1 | a month ago | |
1 | 02-13-2012 09:06 AM | |
2 | 10-05-2010 07:50 PM | |
1 | 02-08-2012 03:09 PM | |
1 | 10-31-2013 02:18 PM |
Online Status |
Offline
|
Date Last Visited |
a month ago
|