weighted overlay/cost past and model builder

[JulieRediker1]

Hi Everyone:

I have been killing myself for days trying to figure this out and I've tried numerous solutions but nothing seems to work. The backstory is as follows: there is a sample model that I downloaded from ESRI that produces an "optimized" route for a pipeline. It's rather cumbersome because all of the inputs are hard-coded.

I have been tasked with automating the process. So far I've got one model that lets the user select the appropriate records from a feature class (e.g., from Floodplains "zone = X"), add a field called GRIDCODE and output a raster. But, here's where I'm stuck... let's say I end up with 4 different rasters from the first process (floodplains, wetlands, roads and railroads), the next steps are to reclassify them and then perform a weighted sum. I cannot figure out how to "loop" through those two steps. I've tried python code, iterators and right-click/batch processing. What am I missing? How can I link all of this together so it runs smoothly? If anyone is interested in helping me with this I can post my scripts and models.

Thanks for your time.

Julie

[JamesCrandall]

I don't do much with model builder, but to iterate over each "x" in a workspace...

arcpy.env.workspace = <your workspace goes here>

for raster in arcpy.ListRasters():
      'perform your additional processing on each raster

for featurceClass in arcpy.ListFeatureClasses():
     'do stuff with the FC

for table in arcpy.ListTables():
     'do stuff with the table

[DanPatterson_Retired]

Whenever I see a model like that, my first question, how often do you have to do it that requires a 1 click solution?

Questions

• do the bits to the left of the weighted sum work individually with various input data sources or are they all hardcoded?
• assuming the bits work individually, does the weighted sum work on its  own from the previously constructed bits?
• if he weighted sum works, why don't you split the model there and make the bits on the right of it, its own model?

I think you get my drift...you model components should work with any equivalent input data and you need to provide documentation and checks to ensure that filenames, and paths are fine.

Once the bits work in parallel, assemble them to produce an intermediate product and provide checks to ensure that all is well before you proceed.  Your other major model component also has several sub-elements which need to be checked.  Once all the components work, then you can decide whether it is worth assembling them all as a one push run or whether it is better to work through successive steps (ie separate logically ordered models/tools in a toolbox) so you can check and verify the inputs and outputs.

Anyhow, hope this helps

[JulieRediker1]

Hi Dan:

Thanks for the reply. To answer your questions:

1.

• do the bits to the left of the weighted sum work individually with various input data sources or are they all hardcoded? In the model all of the values for the following commands are hard coded:

               Feature Class To Feature Class (ex: Wetlands -> SYSTEM IN ( 'Lacustrine', 'Palustrine', 'Riverine'))

               Calculate Field (ex:)

               Reclassify: (ex: )

               I do have a model that can be run in batch mode so the user can input whatever layers they need into the model: all outputs go into a "Scatch.gdb" (set as an Enviroment variable)

2. assuming the bits work individually, does the weighted sum work on its  own from the previously constructed bits?

Yes. It does run.

3. if he weighted sum works, why don't you split the model there and make the bits on the right of it, its own model?

That was my original plan but I guess I got caught up in trying to make this a more "user friendly" experience. It does, however, make sense to break it up so you can check the data as you go. This way you'd only have to re-run small pieces instead of the whole thing if the final output needs some tweaking. I guess I just needed some confirmation from someone else...

I should have stayed with my original idea which was just to make the input of the data to the left of the weighted sum a little easier. Thanks for your help.

[JulieRediker1]

Hi Dan:

One other question... do you think it makes sense to keep the Reclassify tool as part of the first part of the tool so that, as each feature class is turned into a raster it is reclassified and then do a weighted sum (2 steps) or, should the user create the rasters, reclassify them and then run them through the weighted sum tool (3 total steps)?

Thanks.

[DanPatterson_Retired]

My preference would be to keep the reclassification as a separate step for the same reason I suggested parsing the main model into the two parts.  In this way, you can model the effect that changes in the classification would have on the final outcomes, OR just to examine the reclassification in isolation.  Sometimes these sorts of exercises can be revealing in themselves.  I can assure you that the total run times between an all in one, vs a step-by-step approach will be miniscule.

It is a pet peeve of mine... I rail against...