Latest Contributions by JoeChampagne

This issue appears to have been around quite a while; has anybody made any headway on addressing this? I'm using Data Driven Pages so simply adding the grid coordinates I want as graphical elements is not a viable workaround for me here. Please see below for a link to an unresolved bug which apparently addresses this issue, as well as a subsequent reference to this bug in the old forums. Bug NIM-042990 grid labels disappear ... View more

I'm not sure why but I've found using 'Locate Features Along Routes' with polygons to really drag. On a feature class with ~10,000 polygons and a route file with 10-20 lines it can take upwards of 30 minutes to run. Granted, all of my data is on network drives but I've found that an Intersect gets the job done much more quickly with a couple of additional steps. My workflow is something like this: 1. Intersect (polygons to be located with your route lines) 2. Add 'FMEAS' and 'TMEAS' fields 3. Explode all of the multi-part features to single part (either with 'Multipart to Singlepart' or using the Advanced Editing tool. 4. Use the Field Calculator with the following Python expressions to get your M-coordinates: a) !SHAPE!.firstPoint.M b) !SHAPE!.lastPoint.M 5. OPTIONAL step of exporting attribute records to a table, in case you want a similar output to the 'Locate' On the same inputs, the Intersect runs in under a minute versus the original 30-plus minutes and the additional steps should take less than five. I hope this helps someone! Also, does anybody know why Locating polygons is slow? EDIT: I discovered one caveat to using this method after originally posting; if a route line crosses a polygon more than once the calculated from and to measurements can mis-behave due to the creation of multipart features by Intersect. I've modified the proposed workflow to circumvent this. ... View more

I've built a model in which I'd like to use an in-line variable substitution from the 'Group by' variable from a Feature Selection iterator. However, Model Builder doesn't appear to pull the value from the input table while editing which invalidates the input parameter for one of my tools. Please see the attached image; note that the indicated value is '1' when the first value from the input features should be '07EE001'. I have also repeatedly verified that valid inputs exist as per: "Z:\Joe_C\BULK_Catchment_Delineation\Stream_Lines\07EE001_PrimaryDirectedNLFlow.shp" At run-time, the value is extracted and used properly in the output paths of other tools but obviously the invalid tools fail to run at all. I have used this technique successfully with 'Iterate Raster', but no matter what I do this value is unavailable for the validation of my 'Project' tool. Any help would be greatly appreciated! [ATTACH=CONFIG]26840[/ATTACH] ... View more