nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Am I misusing geodesic line length?

D_Hornby_ddh_uni

All,

Generally I work on data in the UK but am currently working on a project processing data for the whole of Latin America, so every country South of Mexico all the way to Argentina.

I am doing a load of network tracing using gROADS and had projected this into the South America Equidistant Conic. In some cases I am generating routes starting in one country and ending up in another.

In an attempt to calculate travel times I need the length of these routes. As I understand it a route generated in Brazil that ended up in Peru should give a sensible length as the coordinate system I am using (South America Equidistant Conic) is appropriate for this region. A route say generated in Mexico ending up in Guatemala would return a distorted length because these countries fall outside the region that the South America Equidistant Conic covers.

Sooo... I thought running the Add Geometry Attribute tool and adding the geodesic line length to the line would be the best way to resolve this issue. Am I correct? Would the geodesic line length be correct for a polyline that is outside the projection region? The help file for this tool simply states it can calculate this length but does not say when not to use it.

Measuring lengths of lines in multiple countries across an entire continent its not something I usually end up computing in little old Britain!

Any advice would be much appreciated.

Find more posts tagged with

Accepted answers

LeeDavis1

I have an interestingly similar problem. I need to calculate a route length very accurately which spans multiple UTM zones. I need to account for projection error, elevation, and curvature of the earth. I still have yet to find a way to calculate 3D geodesic length in one or two operations. I have done some initial experimentation on the effects of earth curvature on length and can tell you that the length adder is very small compared to the length added by elevation.

For your particular problem I have a couple of recommendations. You are incurring alot of geometric error using South America Equidistant Conic, despite it being equidistant. Your distances and drive times will be way off. Here's what I would do:

1. Calculate a route ID number for all routes which you need to estimate.

2. Split up your road network by UTM zone (reproject each to the appropriate UTM zone; using only South zones is OK so you dont have to deal with another split at the equator).

3. Download SRTM 90m DEM for your entire project area.

4. Run Add Surface Information on each UTM zone road feature class using the 90m DEM. By doing this we can ignore geodesic length adder. Make sure to check on Slope Length.

5. Merge together the split up UTM zone feature classes back into one road network feature. Keep SlopeLength field and dont change it.

6. Run summary on Route ID and check on Sum for the SLength field.

7. Ta da, you have a table showing the accurate slope length of all your routes in one table. This can be joined back to your original single roads layer and you can calc the accurate length in that table for other use.

Hope this helps.

Lee

All comments

D_Hornby_ddh_uni

As Homer Simpson would say..Doh!

Good point as long as one does not try to recompute the values in the merged dataset they would be from the individual UTM zone. Thanks!

LeeDavis1

I figured it would be quite a few zones, but you can intersect your roads with a polygon feature of UTM zones. Then there is a tool that will automatically create separate shapefiles based on an attribute. So semi-automated process.

When you merge everything back together it doesn't matter the projection because you have already calculated the accurate 3D length in a column. So you could use the continental one. Would be interesting to compare what the length error really is.

D_Hornby_ddh_uni

Lee,

Thanks for describing this approach. Just one question, step 5 you merge the split up UTM zone feature classes, what projection system are you merging into? Looking at this map Peru alone intersects 8 zones.

Duncan

LeeDavis1

1. Calculate a route ID number for all routes which you need to estimate.

2. Split up your road network by UTM zone (reproject each to the appropriate UTM zone; using only South zones is OK so you dont have to deal with another split at the equator).

3. Download SRTM 90m DEM for your entire project area.

4. Run Add Surface Information on each UTM zone road feature class using the 90m DEM. By doing this we can ignore geodesic length adder. Make sure to check on Slope Length.

5. Merge together the split up UTM zone feature classes back into one road network feature. Keep SlopeLength field and dont change it.

6. Run summary on Route ID and check on Sum for the SLength field.

Hope this helps.

Lee

D_Hornby_ddh_uni

Hi Melita,

So the geodetic distance is based upon an ellipsoidal surface and consequently values returned will be shorter. I think that may be acceptable.

As I understand it a projection is best for a specific region of the world and geometries created using that projection but outside the optimal area become more distorted the further away. I am unsure that polylines (e.g. in Mexico) created by my network tracing that fall outside the optimal region covered by the South America Equidistant Conic would have correct geodetic distances computed because the original geometry (polyline) had been created outside the best region covered by South America Equidistant Conic.

I don't know if this tool does some sort of correction? So I guess what I am saying is the distortion inherent in my polylines carried over when the geodetic lengths are computed?

Duncan

MelitaKennedy

An equidistant conic projection maintains distances along the standard parallels, and along longitude lines (those aren't north-south except the central meridian when projected).

Calculating the geodetic distance is on the ellipsoidal/spheroidal surface so it doesn't take elevations into account. So, in general, I would expect your time-based-on-distance routes to be too short.

DanPatterson_Retired

what is the general spacing between the nodes of the lines would be a first consideration. but you could run some tests.

Calculate the lengths returned around the equator and several other parallels between two widely spaced points and along any meridian under similar conditions, then one between two widely spaced points at 45 degrees to one another.

You can then see how well they do from those calculations done manually or with an online calculator

help support.png

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.