Ask A Cartographer

Is there a file size restriction with Bump Mapping tools?

May 18 2010 | 2 comments
Categories: Symbology

I have run used the Bump Mapping tool on supplied data as well as on a subset of a larger raster set. Both worked well. However, I get no output when I ran the tool on the larger raster set, although the logfile states that the process ran successfully. Is there a file size restriction with Bump Mapping tools?

Thanks.

Mapping Center Answer:

No file size restriction, but we have found a couple of things that help the tools run better when you have this kind of problem:

  • Please make sure that your current and scratch workspaces have no spaces in them.
  • In case the tool fails, delete all the intermediate data from the scratch folder before running it again.

This should take care of it for you.

re: Is there a file size restriction with Bump Map posted by w withington on May 20 2010 7:15AM
The above suggestions were observed. Each raster has only one record. All inputs are in the same coordSys. Workspace and Scratch are pathed correctly. Scratch is cleared prior to run. No spaces in path. Folder is at to of directory. I tested each raster input seperately and each worked fine. No output is generated when both raster are input into the model. The only files existing at end of run are in Scratch: ppat1, rsdem, and radi.txt. Given that I've tested each input induvidually with success, this seems like a code issue? Do you have a diagnosis? Below is the log from the failed run. As always, thank you for your help.

Executing: BumpMapModel reclass_tree Domes 18 20 # dem D:\BumpMapTools\ToolData\bump2
Start Time: Thu May 20 08:21:18 2010
Executing (Bump Map - Part 1): BumpMapPart1 reclass_tree Domes 18 20 # %scratchworkspace%\ppat%i%
Start Time: Thu May 20 08:21:18 2010
Running script BumpMapPart1...
Generating point pattern...
Point pattern generated...
Completed script BumpMapPart1...
Executing (Bump Map - Part 1): BumpMapPart1 reclass_shrub Domes 15 10 # D:\BumpMapTools\Scratch\ppat1
Running script BumpMapPart1...
Generating point pattern...
Point pattern generated...
Completed script BumpMapPart1...
Executed (Bump Map - Part 1) successfully.
End Time: Thu May 20 09:04:03 2010 (Elapsed Time: 42 minutes 45 seconds)
Executing (Bump Map - Part 2): BumpMapPart2 dem D:\BumpMapTools\ToolData\bump2
Start Time: Thu May 20 09:04:05 2010
Running script BumpMapPart2...
Generating Euclidean distance...
Vegetation pattern resolution is 1.81818181818...
DEM resoultion is 10...
DEM provided has less resolution as compared to vegetation patterns (trees) generated and will be resampled to match trees resolution. DEM should have equal or better resolution than trees generated to get better results.
Resampling DEM...
DEM resampled...
Adding resampled DEM to vegetation pattern...
Hillshading...
Completed script BumpMapPart2...
Executed (Bump Map - Part 2) successfully.
End Time: Thu May 20 09:46:22 2010 (Elapsed Time: 42 minutes 17 seconds)
Executed (BumpMapModel) successfully.
End Time: Thu May 20 09:46:22 2010 (Elapsed Time: 1 hours 25 minutes 4 seconds)
I think we found out what the problem is posted by Aileen Buckley on Jun 10 2010 5:14PM
Thanks for sending your data. We have reviewed your data and the parameters you are using to create the bump map. The parameters you are using to create domes are (from the log you posted on "Ask a Cartographer"):

1) radius : 20, density: 18
2) radius: 10, density: 15

Your input rasters are in FEET, which means all your parameters are in FEET. Density is important factor here and if you read the tool help it says:

"... a point will be placed randomly within each quadrilateral of an array that is defined by this value. If you input a value of 10, one point will be randomly placed within each quadrilateral of an array that is comprised of quadrilaterals that are 10 units by 10 units in size. The unit for the value that you input to define the size of the quadrilaterals in the array is derived from the coordinate system for the input vegetation mask raster (usually either meters or feet.)"

Now, as your input raster units are in feet, you are creating a random point within each 18 foot by 18 foot array, which is creating thousands of points. The problem actually lies in this very high density of points. Once those points are created, then the tool is trying to create the Euclidean distance surface for every point with radius of 20 feet, which means that the cones will all overlap considering that the points are closer than the radius. Since you have thousand of points very close to each other and your raster size is fairly large (almost 8 times the sample data), this makes the processing very memory intensive, which results in the tool's failure.

Let's assume the tool ran successfully with the parameters provided. The result would be 40 foot wide bumps all overlapping each other as they are only 18 feet apart (this was your density value). These bumps will hardly be visible at the scale of 1:5,000 and we are sure you are not looking for that cartographic output. You asked uswhat parameters we used for our bump map blog outputs and we replied. It seems you have used same parameters for your process but the sample data provided with the tool are in METERS thus every parameter was in meters.

We ran the tool on your data with all your parameters multiplied by 3.3 (that is the roughly the conversion of feet to meters):
1) radius : 66, density: 60
2) radius: 33, density: 50
The process did work through to completion -- it took almost 3 hours to produce the bump map output.

We suggest that you try to find out at what scale you want to show your bumps and take a small subset of your data and then run the tool with your parameters and see if it works in terms of output at that scale. Once you figure out the parameter that give you the cartographic effect you are looking for, go ahead and run the tool using those parameters on your entire data.

Hopefully that takes care of your issues.

If you would like to post a comment, please login.

Contact Us | Legal | Privacy |