I'm attempting to do something with the Service Area solver that I'm not sure it was meant for. This is practically me attempting to find the closest facility, but do it as a pre-processed event, creating a feature class of the polygon rings. I'd like to take a locations lat/long from our CMS and do a spatial intersection on that feature class. To finish the explanation, the breaks I'm adding at 1 2 3 4 5 6 .... 1000, each ring would represent how far in 1KM chunks your point is away from a facility.
The problem is sometimes the polygons are very, very odd. I have checked to ensure the few issues I have seen have nothing to do with network breaks. There are sometimes large areas (up to 100KM) where the polygon information shows it should only have a 1KM difference.
Disabling hierarchy is not an option.
The image attached is one of the examples where a large chunk of road (this is is about 100KM) yet the attributes are: FacilityID 1 FromBreak 747.4 Name 41083 : 747.4 - 748.4 ObjectID 12391 Shape Polygon ToBreak 748.4
Any advice on how I'd pre-process this data would be great.
Just looking at the picture, it looks like an odd shape. But hard to understand what it going on without seeing more. So what version of the ArcGIS software are you using and what network data are you using. Where is the point located? Jay Sandhu
I'm using 10.1 - not SP1 - and DMTI's 2012Q4 data for the network dataset. The point of origin, I believe, is Victoria, BC. That spot in the image is northeast of it. I'm unsure if it's a polygon generalization error, I don't recall seeing a problem when I turned hierarchy off for a quick (...not so quick) test.
I will post an image of the entire polygon when I get back into the office.
Actually, doing further research I don't believe I'll be able to implement this the way I'd like. I read I cannot use my "soft restrictions" which are imperative for proper routing when going as large of distance as our company does. Even if the polygon generation didn't have these gaps, the fact is that the routing would not be accurate enough.
Instead of trying to pre-process this I'll just route on demand.