|
POST
|
How big is your input flowdir grid (pixel height x pixel width)? Flow accumulaton can take an extreemly long time to run on large grids. I have had some flow accumulation process take a week to run on a fast machine. A few days of run time probably isn't that bad! The larger the flow accumulation you have in your data, the longer the tool will take to run. So, for example, it will take much longer to run for a grid mostly composed of a large single basin that drains to one point (like the Amazone River) than a grid of the same size that has many smaller basins that drain radially outwards from the center (like Mt. Kilimanjaro).
... View more
06-16-2011
03:28 PM
|
0
|
0
|
5388
|
|
POST
|
I could be wrong, but I thought you could only use the geometry objects directly in v10 GP tools (not in v93).
... View more
06-16-2011
10:01 AM
|
0
|
0
|
1231
|
|
POST
|
Disn't look at the polygon, but maybe the Union tool with the "No_GAPS" option?
... View more
06-15-2011
08:53 AM
|
0
|
0
|
998
|
|
POST
|
See the new Dice tool in v10 and/or take a look at one of these tools: http://arcscripts.esri.com/scripts.asp?eLang=39&eProd=&perPage=10&eQuery=densify
... View more
06-13-2011
12:48 PM
|
0
|
0
|
1242
|
|
POST
|
If you were into scripting, you could: For each county: -Build a Thiessen polygon for just the points within the county -Intersect the county boundary with the Thiessen polygon Then merge all the intersect polygon outputs together.
... View more
06-08-2011
09:43 AM
|
0
|
0
|
2953
|
|
POST
|
Maybe some derivation of a Thiessen polygon and/or TIN? http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00080000001m000000.htm
... View more
06-08-2011
09:36 AM
|
0
|
0
|
921
|
|
POST
|
Contour FCs tend to have features with TONS of verticies. Personal experience: In buiding 10ft contours for all the bare earth LiDAR data available for WA State (you can't do it with the out of the box tool BTW), I found some output contour features with over 7,000,000 verticies. That's a lot of verticies! What happens is that the clip tool needs to load these features into the RAM in order to find the XY intersection with the clip layer. Basically, these extreemly large features overwhelm the clip algorithm's ability (remeber 32-bit RAM limitation is < 2.1 GB, actually about 1.7 for ArcMap) to do the calculation. Now in v10 (ArcInfo only maybe?), there is a handy tool called "Dice" that should solve your issue - check it out.
... View more
06-08-2011
08:25 AM
|
0
|
0
|
1703
|
|
POST
|
Too bad you can't set tolerances Do you mean after the fact? Just re-copy the copies with the CopyFeatures tool (or whatever tool) and set the tolerance and resolution settings to the ones I specified in the environment settings (general section). These are the ESRI defaults by the way - the ones you get if you create a brand new FC from scratch. The "METER" units get automatically translated to whatever map units your FCs are defined as.
... View more
06-08-2011
08:10 AM
|
0
|
0
|
9051
|
|
POST
|
Like you said Dan, I too think Bill is on to something. The thought of converting my existing v9.x Python SA code (mostly expresions for the SOMA and MOMA tools) to v10 makes me = 🙂 * -1000000. What added(?) functionality does the new raster algebra syntax allow for? That's not really clear to me...
... View more
06-07-2011
04:29 PM
|
0
|
0
|
1903
|
|
POST
|
Note sure why, but: 1. If I copy data out of our coprorate SDE database to a FGDB and retain the original 1ft XY tolerance I have tons f self-intersection errors. 2. If I copy data out of our coprorate SDE database to a FGDB but specify finer tolerance and/or resolution (example: 0.001 Meters) I have no self-intersection errors. Starting years ago, I use option #2. gp.XYTolerance = "0.001 METERS"
gp.XYResolution = "0.0005 METERS"
... View more
06-07-2011
03:22 PM
|
0
|
0
|
9051
|
|
POST
|
How about this: 1. Use the FeatureToVertices tool to output just the endpoints 2. Use the GenerateNearTable tool to then, for each endpoint, get the nearest polygon. Note in the output table gives you the nearest XY coordinate of the polygon relative to the endpoint. 3. You now have the xy coordinates of the endpoint (you can get these from the output of the FeatureToVertices tool) and you also have the xy coordinates (somewhere along the edge) to the closest polygon. Use the common OBJECTID to associate the endpoint records to the near table records. 4. Now using a cursor, either update (using and update cursor) the existing line segment so as to insert a new vertex for each line - the new vertex being the xy coordinate along the polygon. Or use an insert cursor to write a new line segment that bridges the gap between the endpoint and the polygon edge. You could right the OBJECTID as well, to facilitate dissolving the new line into the existing one. I actually have some sample code for the �??connector arc�?� method: http://forums.arcgis.com/threads/28194-How-to-change-the-geometry-of-a-line-(lastpoint-amp-startpoint)?p=93830&viewfull=1#post93830
... View more
05-26-2011
03:35 PM
|
0
|
0
|
1850
|
|
POST
|
Hmmm... Any chance that ESRI will do that (write a driver) anytime soon? I don't think I have the skillset to pull that off!
... View more
05-26-2011
01:20 PM
|
0
|
0
|
2252
|
|
POST
|
Is there an easy pre-built ODBC driver (or whatever?) that I can install on my machine so that Access or Excel can directly read tables frorm a FGDB? Forgive my ignorance if this is a silly question...
... View more
05-26-2011
10:21 AM
|
0
|
6
|
3754
|
|
POST
|
The sample you code you posted uses something called "DOCELL" notation (sometimes called neighborhood notation) to refer to neighboring cells using relative coordinates (for example, 1,-1). Unfortunately, ESRI still has not ported that functionality in ArcGIS. However, it is currently still supported in GRID via Workstation ArcInfo, so you could actually just run your code as is via Workstation. There are some pretty simple ways to do that via Python even (that is call grid.exe through Python). This probably isn't a very good "beginner" Python project, but there are some ways of doing this in ArcGIS/Python: 1. Load the data into a Python dictionary or numpy array and write your own function (this would require some Python knowledge for sure. 2. A simpler idea is to make 8 separate grids that are each "shifted" in one of the eight directions. So for example, produce a grid shifted one pixel to the north, another shifted 1 pixel to the NE, another shifted to the E, etc. Use the "Shift" tool in ArcToolbox to do this. Name each shifted grid according to the direction of the shift - so you will have grids n, ne, e, se, s, sw, w, nw - also name your original non-shifted grid c (for center). Then use the Combine tool to overlay all the grids together. Hopefully your grids aren't too big; otherwise this might not work due to too many unique values in the combo grid... You may need to adjust the max raster attribute limit in the AdvancedArcMapSettings.exe registry editor to accomplish this. Anyway, PRESTO! In the output combo grid there will then be fields for each of the direction grids (the values representing the elevations of each cardinal direction relative to "c"). Add a new field "TRI" and just calc it according to the TRI equation.
... View more
05-26-2011
10:03 AM
|
0
|
0
|
2964
|
|
POST
|
I do not know any Python so I tried Dan's suggestion. But thanks any how=) Bummer... The line/poly relationships calculated with the PolygonToLine tool are both fast to and give you a lot of pertinent info (such as how long the shared borders are). Downside is that you would need to run things in a cursor and loop to do what you are trying to do.
... View more
05-25-2011
11:59 AM
|
0
|
0
|
2892
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-25-2014 12:57 PM | |
| 1 | 08-29-2024 08:23 AM | |
| 1 | 08-29-2024 08:21 AM | |
| 1 | 02-13-2012 09:06 AM | |
| 2 | 10-05-2010 07:50 PM |
| Online Status |
Offline
|
| Date Last Visited |
08-30-2024
12:25 AM
|