Using Iterate Feature Selection in ModelBuilder causes entire model to iterate?
I'm creating a fishnet on ModelBuilder, the extent of which is based on an Input raster.
The output of "Create Fishnet" is gone through an Intersect tool, and then is fed into an Iterate Feature Iterator. The output of the iterator is fed into a Clip tool, in order to make separate clipped images of the original image, based on the features of the Fishnet.
The problem is that after the first execution of Clip, the entire model is iterated from the beginning, instead of moving to clipping with the next feature. This does not happen if I use an Input feature class as feed to the Iterate Feature Selection (e.g., an existing shapefile and not with something that is created with the same model). I've also tried to use "Make Table View" between the Intersect and the Iterator, but the same thing happened.
Any idea as to the cause of this?
arcgis-desktop modelbuilder iteration
add a comment |
I'm creating a fishnet on ModelBuilder, the extent of which is based on an Input raster.
The output of "Create Fishnet" is gone through an Intersect tool, and then is fed into an Iterate Feature Iterator. The output of the iterator is fed into a Clip tool, in order to make separate clipped images of the original image, based on the features of the Fishnet.
The problem is that after the first execution of Clip, the entire model is iterated from the beginning, instead of moving to clipping with the next feature. This does not happen if I use an Input feature class as feed to the Iterate Feature Selection (e.g., an existing shapefile and not with something that is created with the same model). I've also tried to use "Make Table View" between the Intersect and the Iterator, but the same thing happened.
Any idea as to the cause of this?
arcgis-desktop modelbuilder iteration
add a comment |
I'm creating a fishnet on ModelBuilder, the extent of which is based on an Input raster.
The output of "Create Fishnet" is gone through an Intersect tool, and then is fed into an Iterate Feature Iterator. The output of the iterator is fed into a Clip tool, in order to make separate clipped images of the original image, based on the features of the Fishnet.
The problem is that after the first execution of Clip, the entire model is iterated from the beginning, instead of moving to clipping with the next feature. This does not happen if I use an Input feature class as feed to the Iterate Feature Selection (e.g., an existing shapefile and not with something that is created with the same model). I've also tried to use "Make Table View" between the Intersect and the Iterator, but the same thing happened.
Any idea as to the cause of this?
arcgis-desktop modelbuilder iteration
I'm creating a fishnet on ModelBuilder, the extent of which is based on an Input raster.
The output of "Create Fishnet" is gone through an Intersect tool, and then is fed into an Iterate Feature Iterator. The output of the iterator is fed into a Clip tool, in order to make separate clipped images of the original image, based on the features of the Fishnet.
The problem is that after the first execution of Clip, the entire model is iterated from the beginning, instead of moving to clipping with the next feature. This does not happen if I use an Input feature class as feed to the Iterate Feature Selection (e.g., an existing shapefile and not with something that is created with the same model). I've also tried to use "Make Table View" between the Intersect and the Iterator, but the same thing happened.
Any idea as to the cause of this?
arcgis-desktop modelbuilder iteration
arcgis-desktop modelbuilder iteration
edited 18 hours ago
PolyGeo♦
53.3k1779238
53.3k1779238
asked 20 hours ago
kowalskikowalski
114
114
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
This would be expected behaviour. EVERYTHING runs as many times as an iterator loops. If you come from a background of programming this would seem slightly odd and can trip you up.
The solution is to place everything feeding into the iterator into it's own model. Then you drag 'n' drop that model into a master model. Create another model with the iterator and clip and drag 'n' drop that into the master model. So you end up with one model containing two sub-models. To enable models to connect to each other you would need to expose the inputs/outputs as parameters.
So remember the golden rule when using any iterator that everything in the model runs as many times as it loops. I often see models where people connect say a merge tool directly to an iterator. Whilst "it works" it is terribly inefficient, the merge tool only needs to run once as it takes a LIST of inputs, this is why you use the collects tool and sub-modelling.
Yes,I also just saw that in the last line of documentation of Iterate Feature. I did exactly that and it worked! It's an odd behavior regardless, and yes even if it works it is terribly inefficient, especially if the model includes raster processing.Thank you very much!
– kowalski
18 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "79"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fgis.stackexchange.com%2fquestions%2f308517%2fusing-iterate-feature-selection-in-modelbuilder-causes-entire-model-to-iterate%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This would be expected behaviour. EVERYTHING runs as many times as an iterator loops. If you come from a background of programming this would seem slightly odd and can trip you up.
The solution is to place everything feeding into the iterator into it's own model. Then you drag 'n' drop that model into a master model. Create another model with the iterator and clip and drag 'n' drop that into the master model. So you end up with one model containing two sub-models. To enable models to connect to each other you would need to expose the inputs/outputs as parameters.
So remember the golden rule when using any iterator that everything in the model runs as many times as it loops. I often see models where people connect say a merge tool directly to an iterator. Whilst "it works" it is terribly inefficient, the merge tool only needs to run once as it takes a LIST of inputs, this is why you use the collects tool and sub-modelling.
Yes,I also just saw that in the last line of documentation of Iterate Feature. I did exactly that and it worked! It's an odd behavior regardless, and yes even if it works it is terribly inefficient, especially if the model includes raster processing.Thank you very much!
– kowalski
18 hours ago
add a comment |
This would be expected behaviour. EVERYTHING runs as many times as an iterator loops. If you come from a background of programming this would seem slightly odd and can trip you up.
The solution is to place everything feeding into the iterator into it's own model. Then you drag 'n' drop that model into a master model. Create another model with the iterator and clip and drag 'n' drop that into the master model. So you end up with one model containing two sub-models. To enable models to connect to each other you would need to expose the inputs/outputs as parameters.
So remember the golden rule when using any iterator that everything in the model runs as many times as it loops. I often see models where people connect say a merge tool directly to an iterator. Whilst "it works" it is terribly inefficient, the merge tool only needs to run once as it takes a LIST of inputs, this is why you use the collects tool and sub-modelling.
Yes,I also just saw that in the last line of documentation of Iterate Feature. I did exactly that and it worked! It's an odd behavior regardless, and yes even if it works it is terribly inefficient, especially if the model includes raster processing.Thank you very much!
– kowalski
18 hours ago
add a comment |
This would be expected behaviour. EVERYTHING runs as many times as an iterator loops. If you come from a background of programming this would seem slightly odd and can trip you up.
The solution is to place everything feeding into the iterator into it's own model. Then you drag 'n' drop that model into a master model. Create another model with the iterator and clip and drag 'n' drop that into the master model. So you end up with one model containing two sub-models. To enable models to connect to each other you would need to expose the inputs/outputs as parameters.
So remember the golden rule when using any iterator that everything in the model runs as many times as it loops. I often see models where people connect say a merge tool directly to an iterator. Whilst "it works" it is terribly inefficient, the merge tool only needs to run once as it takes a LIST of inputs, this is why you use the collects tool and sub-modelling.
This would be expected behaviour. EVERYTHING runs as many times as an iterator loops. If you come from a background of programming this would seem slightly odd and can trip you up.
The solution is to place everything feeding into the iterator into it's own model. Then you drag 'n' drop that model into a master model. Create another model with the iterator and clip and drag 'n' drop that into the master model. So you end up with one model containing two sub-models. To enable models to connect to each other you would need to expose the inputs/outputs as parameters.
So remember the golden rule when using any iterator that everything in the model runs as many times as it loops. I often see models where people connect say a merge tool directly to an iterator. Whilst "it works" it is terribly inefficient, the merge tool only needs to run once as it takes a LIST of inputs, this is why you use the collects tool and sub-modelling.
edited 18 hours ago
answered 18 hours ago
HornbyddHornbydd
26.1k32757
26.1k32757
Yes,I also just saw that in the last line of documentation of Iterate Feature. I did exactly that and it worked! It's an odd behavior regardless, and yes even if it works it is terribly inefficient, especially if the model includes raster processing.Thank you very much!
– kowalski
18 hours ago
add a comment |
Yes,I also just saw that in the last line of documentation of Iterate Feature. I did exactly that and it worked! It's an odd behavior regardless, and yes even if it works it is terribly inefficient, especially if the model includes raster processing.Thank you very much!
– kowalski
18 hours ago
Yes,I also just saw that in the last line of documentation of Iterate Feature. I did exactly that and it worked! It's an odd behavior regardless, and yes even if it works it is terribly inefficient, especially if the model includes raster processing.Thank you very much!
– kowalski
18 hours ago
Yes,I also just saw that in the last line of documentation of Iterate Feature. I did exactly that and it worked! It's an odd behavior regardless, and yes even if it works it is terribly inefficient, especially if the model includes raster processing.Thank you very much!
– kowalski
18 hours ago
add a comment |
Thanks for contributing an answer to Geographic Information Systems Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fgis.stackexchange.com%2fquestions%2f308517%2fusing-iterate-feature-selection-in-modelbuilder-causes-entire-model-to-iterate%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown