Model Builder: Fixing Service Area Polygon Attribution

[CodyLyons]

I'm trying to set up a model to automate the creation of a Service Area (and the other processes that are involved in that project but aren't important here). The Service Area represents the distance a vehicle can travel outwards from the facility in 9, 15 and 30 minute (450, 900, 1800 second) intervals. We use an chute time impedance to represent how long it takes for the facility to send out their vehicle.

In some cases, the impedance is more than the 9 minute break.

When this happens, the polygons should show that the 450-900 is the first polygon, and the 900-1800 is the second polygon with no 0-450 polygon showing at all. Instead the first polygon shown is the 0-450 and the second is the 450-900 with no 900-1800 showing. All other polygons with impedances low enough show all polygons as they should.

Normally I would just manually edit the feature class resulting from the Service Area, but I hope to automate the entire process if possible. I hope to correct the mistake either during the processing of the Service Area via a setting, or to do so after the polygons are produced with a recalculation of some kind (for example: where there are only two polygons for a facility, recalculate to show the proper break points; or that the outer polygon should always be 1800, the next 900 and the third, if it exists, should always be 450).

If anyone has an idea of how to make this correction in the context of an automated process, that would be wonderful.

Thank you for your time,

Cody

[MelindaMorang]

Hello Cody.  Are you using ArcMap or ArcGIS Pro?  Also, how are you specifying the chute time impedance?

[CodyLyons]

I am using ArcMap. The Chute Time is specified in the 'Add Locations to Service Area Process' tool under the Attr_Transit property.

[MelindaMorang]

I'm still investigating this, but one thing I notice is that 9 minutes is 540 seconds, not 450 as you've written above.  Could that be part of the problem?

[MelindaMorang · Accepted solution]

This looks like a bug, and I can reproduce it (or something similar to it) in both ArcMap and ArcGIS Pro.  I will log the bug so we can fix it.

However, you need a workaround, since a fix won't be available in the short term.  When I switch the output polygons to use Disks instead of Rings, the polygons seem correct, and the FromBreak and ToBreak fields show me what I expect.  (In the case of Disks, the FromBreak is always 0).  Can you use Disks for your workflow?  If you really need Rings, you could generate Disks and then clip out the lower break value polygons using a different tool, although that wouldn't be terribly efficient.

[MelindaMorang]

In ArcMap, with Detailed polygons, I see the behavior you describe.  With regular polygons, and in ArcGIS Pro for all types of polygons, I still see wrong behavior, but the ToBreak field always look correct (the problem is in the FromBreak field).  So, another workaround for you would be to use ArcGIS Pro and base your logic on the ToBreak field, ignoring whatever it says in FromBreak.  I think the polygons are correct; the break field values are just mislabeled.

[CodyLyons]

From what I see, I agree that the fault is in the mislabeled break fields. I was able to come up with my own 'fix' in the short term by simply selecting and recalculating the break fields after the process is complete, so I'm good to go on that account, but I'll keep your suggestion in mind for future purposes.

(The 450/540 doesn't affect the process much at all beyond actually having a correct break point. That was just me doing a dumb for a week after holiday season. I noticed this on Friday, and had to fix all the processes from 450 to 540.)

Nevertheless, it's good that it's been logged now.

Thank you for your assistance,

Cody