Latest Contributions by ChrisSnyder

So if I rephrased the title of this thread to be: "Should there be a new Python Scripting forum?" Would you guys (Ted, Goh_Raj, Chris Mathers) go that way? It sounds so far like a shaky "yes", but I want to be sure. I'd poke Dan P. too, but I know he has taken an oath of silence... ... View more

Not sure exactly what you want to do (pictures are always good), but basically you could merge the two FCs into a single FC, and then use the SuperRegionLine tool/script to analyze areas that were common (or unique) to each dataset. ... View more

Besides the new thread ultimately becomes a KB for Python, for User Python examples that solve real world issues Bingo! That's exactly how I used the old "Geoprocessing - Scripting" forum. As some one coming from an AML background, and that had gone on a very foolhardy 6 month adventure in ModelBuilder, having a meaningfully focused forum is probably one of the best, if not THE best, resource available. I credit much of my Python scripting knowledge to people like Dan Patterson, R.D. Harles, Luke Pinner, Kim Oliver, and of course others - People who know what they are doing and are willing to share that knowledge with others. Building a contributor base of knowledgeable people that are passionate about a topic is the #1 key! If ESRI wants to rekindle "GIS automation for the masses" (which I think it does), a "Python Scripting" forum is a no brainer. Build it and they will come... 🙂 ... View more

Ted, what happened to: "...it would be nice to have the capability to just have access to the 1 python forum..." "...which why I am thinking, a python category makes sense." Seems like "Python Scripting" is an important "Function" and is becoming more so for many of us... ... View more

Since I too think ModelBuilder is quite evil, it wouldn't make too sad at all to see it quietly ignored. Contrary to my conviction of it's insidious nature, ModelBuilder does have a large user following and a lot of people have created therads about it, so there would be people benefiting by having a ModelBuilder forum. If someone feels passionate about that one though, they can take up the fight... I'll admit that my true motive here is to have a separate "Python Scripting" forum, and if so if it's a means to an end, I would be happy with: Geoprocessing ({'Other' | 'General' | 'Nothing' | 'Whatever'}):confused: Python Scripting :cool: ... View more

I'm not an SDE admin, so I use MakeQueryTable quite a bit for various things (mainly querying/reporting our overly complex timber sale/activities tracking system). Even without pre-indexing my fields (pre-indexing join fields and query fields would probably be a good idea), performance is exceptional in a local FGDB. The trick then is to then save the feature layer out as a .lyr file (which stores the SQL internally). Of course, all tables need to be in the same FGDB, SDE, or PGDB, otherwise the tool doesn't work. Like Ted said: A sort of non-SDE spatial view. It's very powerful. This sample takes 1 second to return a featurelayer query composed of three related tables (600, 70000, and 50000 records respectively): queryExp = "question_3_fma_summary.RMU_ID = rmu_polyid.RMU_ID AND rmu_polyid.RMU_POLYID = rmus_we_care_about.RMU_POLYID AND\     rmus_we_care_about.MM_POL_LBL in ('reclass-released','reclass-released-may-be-available') AND question_3_fma_summary.COMPSOLD_DATE >= 20030418" gp.MakeQueryTable_management(question3FmaSummaryTbl + ";" + rmuPolyIdTbl + ";" + rmusWeCareAboutFC, featureLayerFL, "ADD_VIRTUAL_KEY_FIELD", "", "", queryExp); showGpMessage() ... View more

Good catch... This was stolen code, so I wasn't completely knowledgeable of it, but I see what you are pointing out. Thanks for the issue description http://forums.arcgis.com/threads/156....Value?p=48310. Is it just me, or wasn't it easier when everything was a string and you could always assume that was the case? I guess it's cooler and more flexible that you can pass objects, but... ... View more

More posts = More activity. More activity = More people reading the threads And then they'd think that if more people are reading a specific forum = Most likely that someone will answer their questions Using this logic, ESRI should then only have a single forum, as that would surely maximize/consolidate posts... My assertion is that if ESRI can provide MEANINGFULLY FOCUSED forum topics, it will results in more and better answers to threads. Why? It's simple: People that contribute their time to answering questions are interested (and hopefully knowledgeable) in the topics that they contribute to. I contribute time to answering topics about geoprocessing work flows, Python scripting, and sometimes spatial analyst stuff. I do not care at all about topics like: "Business Map", "ESRI Nautical Mapping Solutions", or "ArcScetch" (amazingly, each one of these has its own forum topic). If all these random topics are lumped together, contributors like my self - BTW: generally a thread contributor and not a thread creator - are left to wade through a bunch of content that is completely irrelevant to their interest and knowledge base. No one user has excellent knowledge/experience of all ESRI software/programming/functions/features/etc. However, many of us have excellent knowledge/experience in a few specific areas, and these are the topics that we care to contribute to. As a potential contributor to a single "ESRI Forum", how would I find the topics that I am interested in contributing to? By scanning through 500 posts per day? By using a basically non-existent/enforced/functioning tagging method? Cmon... OR As a contributor, would I be more likely to contribute if I knew the questions posted on on a focused forum were specific to my area of knowledge and expertise? YES! This idea is only good to a point of course. There is no use in having a forum called "The Clip Tool". There is clearly not enough user apeal or "critical mass" for such a narowly focused forum. If ESRI "got it" that some topics and concepts have a much wider audience than others (Case in point: "Python Scripting" vs. the "ESRI Nautical Solution"), they could provide a more MEANINGFULLY FOCUSED forum design. If maybe 20% of forum users might use ModelBuilder and/or Python scripting, but < 1% use the ESRI Nautical Solution it seems a no brainer if the idea was to consolidate topics in a meaningful way. The concepts/topics of "Python Scripting" and "Model Builder" clearly have a wide user base and enough critical mass to kindel a lively comunity of contributors that benifits everyone - this was clearly demonstrated in the old forum design that broke out "Model Builder" and "Python Scripting". Clearly, other topics like "MapStudio" and "Public Safety" do not have the same critical mass, and therfore it's questionable to me as to why they have their own specific forum topic. Okay, so let's say we did separate it out into GP Tools, GP Python, GP Model builder, and GP General? How "general" are we talking about here? What kind of questions could be left to post in the GP general category without mentioning a tool, script or model? Sounds odd�?� The idea was simply to rename the existing "Geoprocessing" forum so that instead of "Geoprocessing" we have something like: "Geoprocessing Tools/Workflows/General" (previously known as "Geoprocessing") "Python Scripting Automation" "Model Builder Automation" Only two new forums are being created here. While we're at it, maybe get rid of those forums that have <= 25 threads (which BTW is about 45% OF THEM!!!). See for yourself: http://forums.arcgis.com/forums/3-ArcGIS ... View more

From the Union tool help: "With ArcView and ArcEditor licenses, the number of input feature classes or layers is limited to two." ArcInfo is basically unlimited. As a work around, you could write some code that will recursively go through a list of input layers, union them (two at a time), and then keep unioning those outputs until you are done. I wrote Python code to do this at one point (bug in the Union tool ~5 years ago where the output would be corrupt if > 5 layers were unioned at a time), but I can't seem to find it. ... View more

FYI: Some posts from other forums that basically argue for a split approach. These are not "Geoprocessing" specific, and I'm not counting these as votes, but I'd like to think of them as moral support for the split concept: http://forums.arcgis.com/threads/1757-New-Site-Very-Disappointing?p=19506&viewfull=1#post19506 http://forums.arcgis.com/threads/2103-Who-wants-the-old-forums-back?p=6936 http://forums.arcgis.com/threads/2103-Who-wants-the-old-forums-back?p=6974&viewfull=1#post6974 http://forums.arcgis.com/threads/2103-Who-wants-the-old-forums-back?p=33196&viewfull=1#post33196 http://forums.arcgis.com/threads/2103-Who-wants-the-old-forums-back?p=38688&viewfull=1#post38688 A current tally (hope I have everyone in the correct category): NO SPLIT (3 vote) ---------------- Dan Patterson Ted Cronin Chris Mathers YES SPLIT (6 votes): --------------- Chris Snyder R.D Harles Dave Bouwman Chris Sergant Sheri Norton Lorna Murison Yes of course ESRI employees are avid forum users and contributors, but I am still not counting their votes. I'm not saying this is the case, but there is potential bias in that ESRI made the decision to lump the topics (at a relatively high management level I assume), and that if there was lower level disagrement it would be a disenting opinion. Therefore, it would be hard to discern if the ESRI vote was from the gut or just agreeing with the boss. Yes, nine votes is a disappointingly small sample, but regardless, a 2:1 ratio favoring a split... Anyone?!?! Chime in! ... View more

Manual method: Add two new fields (type double) to the attribute table of your polyline. Call them END_X and END_Y. Right click on the field > Calculate Geometry > Properties > X/Y Coordinate of line end Or some v93 Python code (i didn't test this, but I think it should work the 1st time): gp.AddField_management(myPolylineFC, "END_X", "DOUBLE") gp.AddField_management(myPolylineFC, "END_Y", "DOUBLE") shapeFieldName = gp.describe(myPolylineFC).shapefieldname updateRows = gp.updatecursor(myPolylineFC) updateRow = updateRow.next() while updateRow:    updateRow.END_X = updateRow.getvalue(shapeFieldName).lastpoint.x #start node is ".firstpoint"    updateRow.END_X = updateRow.getvalue(shapeFieldName).lastpoint.y    updateRows.updaterow(updateRow)    updateRow = updateRows.next()            del updateRow del updateRows ... View more

If you don't need to alter the field properties, maybe just use the CopyFeatures tool? ... View more

Here's some Python code that will take an ascii file (output of the ArcGIS RastertoAscii tool, for which no SA license is needed), and reformat it to a .csv file with x, y, z values (x and y are cell centers). Note that depending on the particulars of your DEM, the .csv file will generally be much larger than the input ascii file. This script could easily be altered so as to write the xyz stuff to a binary format like a .dbf, .shp, FGDB, etc. # Description: Format an ascii text file (created using the RasterToAscii in ArcGIS) as a comma delimited .csv file containing x, y, z values # Written By: Chris Snyder, 20101012 import os inputAsciiDemFile = r"D:\csny490\dems\dem90m\dem90.txt" #ascii file created using the RasterToAscii in ArcGIS outputCsvFile = r"D:\csny490\temp\test.csv" #output comma delimited file ascii file (x,y,z fields) if os.path.exists(outputCsvFile):     os.remove(outputCsvFile) inputLines = open(inputAsciiDemFile, 'r') nColumns = int(inputLines.next().split(" ")[-1]) nRows = int(inputLines.next().split(" ")[-1]) xCorner = float(inputLines.next().split(" ")[-1]) yCorner = float(inputLines.next().split(" ")[-1]) cellSize = float(inputLines.next().split(" ")[-1]) nodataValue = int(inputLines.next().split(" ")[-1]) print >> open(outputCsvFile, 'a'), "X,Y,Z" outputLines = open(outputCsvFile, 'a') lineCounter = 0 for inputLine in inputLines:     if divmod(lineCounter,100)[1] == 0:            print "Processing row " + str(lineCounter) + " of " + str(nRows) + "..."     lineCounter = lineCounter + 1     valueList = [float(value) for value in inputLine.split(" ") if value != '\n']     columnCounter = 0     for rasterValue in valueList:         columnCounter = columnCounter + 1         if rasterValue != nodataValue:             xCoord = xCorner + (columnCounter - 1) * cellSize + cellSize / 2             yCoord = yCorner + (nRows - lineCounter) * cellSize + cellSize / 2             outputLines.write(str(xCoord) + "," + str(yCoord) + "," + str(rasterValue) + "\n") outputLines.close() inputLines.close() ... View more

My pleasure. This is actually something I had been meaning to do on my own for a while... Note of course that this is the very basic algorithm. As you suggested, there are a lot of ways to make it better and more full featured. But adding bells a whistles to anything tends to add significant build time, so I just chose to take the simplest route possible. For my purposes, I want to compare GPS-derived line features, and using the actual vertices (rather than densified vertices or measures) lend themselves to a better solution since the vertices more often than not represent points of inflection that the field person thought were important to record. Seems best to be comparing these inflection points rather than artificial points that would be created if using densified or measured points. One very simple enhancement that I almost put in the codse would be a distance threshold. Basically, as traversing through the vertices in orientFC, if there were no vertices from the other FCs within a given distance (500ft for example), that vertex would be skipped (or a > threshold point from the other FC would just be ignored?), as there were no "valid" locations to compare it to. ... View more