Latest Contributions by ShaunWalbridge

If you change the output type to string, you'll see the leading zeros. But as msayler mentioned, if you store things as dates, they will be displayed based on locale and not in the specified format explicitly. ... View more

Jimeno, I'm not sure of the specifics for the points solar radiation tool, but testing it locally, it looks to take about one second per site per day on my machine, which gives me a ballpark estimation of 41 hours for 400 sites, using the defaults for the tool, against a 1m LIDAR dataset, stored as a mosaic. You mentioned that you're using 8 cores, do you have custom code to distribute the workload across those cores? If not, check out multiprocessing along with background processing to take advantage of those additional cores. Use an in-memory workspace to store the results. If memory is available, also try copying your input raster into the in-memory workspace. Use a file geodatabase instead of plain old shapefiles for the outputs. Try adjusting the resolution of the input DEM to see its effects on performance. Also, think about clipping down the DEM as much as possible to just include a buffered area around the points themselves. If the features don't fit into an in-memory workspace, serve them off of a fast disk -- SSD if at all possible. Those are a few things off the top of my head. ... View more

Generally, it'll probably be worth figuring out a way to display multiple search results to your users, unless you do have a relatively limited set of terms, and can come up enumerate the alternatives. One way of handling the ambiguous input from users is to use fuzzy string matching. It's related to the regular expressions Stacy mentioned, but is specifically for the comparison of inexact terms. There are a number of algorithms for fuzzy matching, many of them built in to the database, such as SOUNDEX and Double Metaphone. If you're using SQL Server, you might want to look into Full Text Indexing, which can be used to generate a fuzzy search automatically. By doing it in the database, you'll save the work of having to do as much custom Python code to interact with the results, you can just use the sorted database results instead. If you want to stick to doing things in Python, one way is to build up a list of all of your search terms, and then do the double metaphone or other similarity search against the user's input. One library I've used in the past that is handy is jellyfish, which contains a number of different string comparison engines. cheers, Shaun ... View more

Hi Matthew, Perhaps the simplest approach is to convert the polygon layer into a 'count of overlaps' vector layer, and then rasterize that. There's a tool you can download to do it in one step, or follow the steps in this GIS.SE question to perform the same analysis. From there, you should be able to do a simple Polygon to Raster conversion. If you wanted to include polylines, just buffer them by a small distance to convert them to polygons prior to the 'count overlaps' step. There are other approaches, like generating a fishnet and doing an intersect on your polygon data, but I think the above approach is simplest unless your data is large and complex. cheers, Shaun ... View more

Anthony, There are a few ways to solve your problem. One is to create a model builder workflow which uses the raster calculator tool with the particular math you're using to convert between the images and reflectance. Save this model, and then from the catalog pane, you can right click on the model and select 'Batch', which will allow you to run the calculation on multiple rasters. An alternative approach if you've done any Python programming is to use the arcpy raster functions to do the work directly. This way, you could, say have a file which listed each folder with your rasters, then iterate over the list, and perform the calculation directly in Python, which might look something like: import arcpy band_1 = arcpy.sa.Raster('c:/path/to/band1.tif') band_3 = arcpy.sa.Raster('c:/path/to/band3.tif') sum_reflectance = (band_1 + band_3)/(band_1.maximum + band_3.maximum) cheers, Shaun ... View more

Todd, I think your results line up as expected. The two models differ in how they handle diffuse radiation, as described in the 1999 Fu and Rich paper: In a uniform diffuse model, sometimes referred to as a "uniform overcast sky (UOC)", incoming diffuse radiation is the same from all sky directions. In a standard overcast (SOC) diffuse model, diffuse radiation flux varies with zenith angle. So, in the uniform model, zenith angle has no role, so valleys will receive similar diffuse radiation to peaks, because as long as the sky map isn't blocked, either case will get the same diffuse radiation. Perhaps the best way to build up an intuition for this is to play with the formulae provided in the Solar Analyst user guide, pages 11-12, to see how the results differ for individual sky sectors. cheers, Shaun ... View more

Right, AlterAliasName is new at 10.1 but is the right way of doing this for 10.1+. ... View more

Hello Jimeno, I'm not sure exactly what you're looking for, but you should be able to use the solar functions, perhaps in conjunction with other packages, to answer your question. I see that as you mention, when you run Points Solar Radiation on a single day, you get back the time steps but not the actual time that it corresponds to -- one way to get back the corresponding actual hours would be to use a script such as this one calculating sunrise and sunset or use a package like PyEphem to get more precise calculations. From there, you should be able to combine the solar observations from ArcGIS with 'actual time', so you can correspond the output T0 with the sunrise time and the final Tn with the sunset time. So my psuedo-code for this on a single day would be something like:     import arcpy     import ephem     julian_day = 165         # run solar calculation for all sites on this day; defaults used here     arcpy.PointsSolarRadiation("elevation", "my_sites",         "output_global_radiation", "", 35, 200,         arcpy.sa.TimeWithinDay(julian_day, 0, 24))     # figure out sunrise and sunset. if the points are close together, do this     # once for all sites, if they're geographically spread over a large area, you'll need     # to make these calculations for each site.         obs = ephem.Observer()     obs.lat = ' 34' # obtained from my_sites     obs.long = '-120.0' # obtained from my_sites     obs.elev = 15 # extract from elevation raster at site location     sunrise = obs.previous_rising(ephem.Sun()) # sunrise     noon = obs.next_transit(ephem.Sun(), start=sunrise) # solar noon     sunset = obs.next_setting(ephem.Sun()) # sunset        # then, map those times to the T0...Tn time steps, which are by default in half-hour intervals.     # output this result to a CSV or the like. Does that help get you started? I think something like this is easier than trying to dig up the internals to figure out the corresponding times. cheers, Shaun ... View more

Austin, I can confirm this is fixed in 10.2 SP1 (10.2.1):   http://support.esri.com/en/bugs/nimbus/TklNMDkzMjA0 cheers, Shaun ... View more

At least at 10.1SP1, this issue is resolved, and you can safely use "DELAUNAY" or "CONSTRAINED_DELAUNAY" as the keywords, and any other value will return an error. ... View more

Python 2.7.3 is now confirmed for 10.2, and both and xlrd and xlwt are included in the base install. ... View more

Is there a way for me to do this in the future, or is it best for me to submit to the forum for all the world to see? Yes, you can submit issues by visiting http://support.esri.com and filing a bug there. Generally, most bugs get caught by the exception handling logic and you can directly report them from that application, but in this case the interaction is up the stack and ArcGIS doesn't 'see' the crash, so a support request is necessary. ... View more

Austin, I've submitted a bug report on this issue. cheers, Shaun ... View more