POST
|
Jay, Thanks for this. I'll try to implement it when I have a chance. Adam
... View more
07-07-2010
05:11 PM
|
0
|
0
|
942
|
POST
|
Jay, Thanks for this. If the geodesic distances are being calculated for every edge in the network build anyway, is there any way to access them, to put them into a tabular field that can then be passed into the various categories, either directly or through a spaital join with the original feature dataset from which the network was built? This seems like it would be much better than adding projection error to the (total) Length field just to make it match the others. Unless there's a better trick for using the Haversine on complex lines, I suspect that splitting into COGO, with well over a million segments, will crash my machine. Adam
... View more
07-06-2010
03:01 PM
|
0
|
0
|
942
|
POST
|
Jay, Thank you for your response, and sorry for the lack of details. I am solving on Length. The length by category fields were calculated on the the only feature class in the network, prior to building the network, just working with the table in a python script, assigning the [Shape_Length] field to the length-by-category field for each feature in the corresponding category. Below is a summary of inputs for the network build. I've removed all but two of the length-by-category fields - they are all analogous. As you suggest, the discrepancy already appears when using the Network identify tool, so whatever is going wrong is at the network build stage and not the solver. But when using the (simple, non-network) identify tool on the feature dataset used to build the network, on the analogous fields for a network element that is identical to a line in the feature class, there is no discrepancy. In fact, of the four lengths identified in this way (network total length, network length-by-category, underlying feature class total length, and underlying feature class length-by-category), only network total length is different. It can be shorter or longer, depending on the segment (in a way that suggests some sort of implicit reprojection as I mentioned before). Adam --- Name: AfricaRoadsFD_ND Type: Geodatabase-Based Network Dataset Sources: Edge Sources: AfrRoads Connectivity: Group 1: Edge Connectivity: AfrRoads : Bridge (Any Vertex) AfrRoads : Missing (Any Vertex) AfrRoads : Primary (Any Vertex) AfrRoads : Secondary (Any Vertex) AfrRoads : Tertiary (Any Vertex) AfrRoads : Unknown (Any Vertex) AfrRoads : Urban (Any Vertex) Attributes: Length: Usage Type: Cost Data Type: Double Units Type: Meters Use by Default: True Source Attribute Evaluators: AfrRoads (From-To): Field - [Shape] AfrRoads (To-From): Field - [Shape] Default Attribute Evaluators: Default Edges: Constant - 0 Default Junctions: Constant - 0 len22: Usage Type: Cost Data Type: Double Units Type: Meters Use by Default: False Source Attribute Evaluators: AfrRoads (From-To): Field - [LEN22] AfrRoads (To-From): Field - [LEN22] Default Attribute Evaluators: Default Edges: Constant - 0 Default Junctions: Constant - 0 len23: Usage Type: Cost Data Type: Double Units Type: Meters Use by Default: False Source Attribute Evaluators: AfrRoads (From-To): Field - [LEN23] AfrRoads (To-From): Field - [LEN23] Default Attribute Evaluators: Default Edges: Constant - 0 Default Junctions: Constant - 0 Directions: Directions Ready: No -Length Attribute Required -Street Name Field Required [AfrRoads]
... View more
07-06-2010
11:43 AM
|
0
|
0
|
942
|
POST
|
I'm getting some strange results from a closest facility problem (~40 facilities, ~1100 incidents) in Network analyst. In addition to a Total_Length, which is my impedance measure, I am calculating lengths for each route within several mutually exclusive and exhaustive categories. In other words, when summed for any edge in my network dataset, they add to Total_Length for that edge. Let's call them LengthA, LengthB, LengthC etc. I do this by setting them as Accumulation Attributes. The resulting Routes look fine, except that the Total_Length of each is not the same as the sum of the lengths by category. The difference is sometimes too large to be because e.g. I am assigning locations to the nearest network location within 5000 meters. Here's the part that makes me think someone out there will know the answer: All datasets I am using are in the same feature dataset in a sinusoidal projection. The percent difference between Total_Length and Sum(LengthA, LengthB, LengthC...) is highly correlated (0.85) with the percent difference between the analogous straight line distances calculated using latitude/longitude in the Haversine formula and using projected (sinusoidal) coordinates. I can't think of any reason why the Plate Carree ("Geographic") or any projection other than the original sinusoidal would be used for one set of calculations but not the other. I'm running 9.3 SP1 with an ArcInfo license. Any ideas would be greatly appreciated.
... View more
07-05-2010
12:19 PM
|
0
|
8
|
4504
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|