Create drive time analysis - errors

[RussellPagan]

Drive time analysis - Errors

I've used the function to generate drive-time around branches between 150 and 30 branches, between 20minutes and 60 minutes Drive time for trucks at 7 am on Monday morning. that have overlaps and it has given me some great data, 

I would now like to use the  'split' function for the branches to allocate them their own coverage area. So it's the same process - it starts to run then I get an error message. I think it's a much more complex algorithm, so I have tried to select fewer branches and more, remove the information in regards to typical drive time. I can seem to get a result... any ideas? 

It is such a shame as i got (sadly) excited about how this would help with one of the business problems we are facing at present. So any ideas would be appreciated. 

[DavidPike]

Can you share the error message?  And the polygon overlap policy to 'split' was the only option changed and everything else is the same i.e. can you rule out any other changes to your data etc. since you last ran the tool?

[RussellPagan]

Thanks for the reply. It just says Error, not code. Yes the only thing I have changed is the split and the name of the file.... 

[DavidPike]

Ah not good. 

Noob question for anyone else, but has AGOL got any geoprocessing logs etc. or does it just error in the cloud? 

Does anything show up in the dev tools of the browser?

I think you're right, I'm only completely guessing, but conceptually each service area can be created individually  with overlaps, whereas with the split option it has to be computed in one go to calculate the correct isochrone boundary (I think of these as network thiessen polygons).
perhaps test this with only 2 or 3 facilities and see if it errors (appreciate this burns credits).

[RussellPagan]

I did look at how I could cut it up and run it in sections - but the reality is that each area buts up to another, like a daisy chain. So I can test it - but it doesn't really move me forward. Thinking of doing it as a measure rather than time, but with a number of city locations and rural its going to skew the output too much to be useful. Thanks for your view - its good to know that I am in the same place as others on the issue.