Print

Print
Nice to see this built-in to PostGIS’ geography type:

“By default, all distance and area calculations are done on the spheroid. You should find that the results of calculations in local areas match up will with local planar results in good local projections. Over larger areas, the spheroidal calculations will be more accurate than any calculation done on a projected plane. All the geography functions have the option of using a sphere calculation, by setting a final boolean parameter to 'FALSE'. This will somewhat speed up calculations, particularly for cases where the geometries are very simple.”

http://postgis.net/docs/using_postgis_dbmanagement.html#PostGIS_Geography

(They need to adjust their documentation, however; further down they say “great circle” when they really mean “geodesic”.)

ArcGIS seems to use chordal distances for almost everything:

“When your input features are not projected (i.e., when coordinates are given in degrees, minutes, and seconds) or when the  output coordinate system is set to a Geographic Coordinate System, or when you specify an output feature class path to a feature dataset that has a Geographic Coordinate System spatial reference, distances will be computed using chordal measurements and the Distance Method parameter will be disabled. Chordal distance measurements are used because they can be computed quickly and provide very good estimates of true geodesic distances, at least for points within about thirty degrees of each other. Chordal distances are based on a sphere rather than the true oblate ellipsoid shape of the earth. Given any two points on the earth's surface, the chordal distance between them is the length of a line, passing through the three dimensional earth, to connect those two points. Chordal distances are reported in meters.”

http://resources.arcgis.com/en/help/main/10.2/index.html#//005p00000005000000#GUID-ABBD96AC-100C-4AA6-9630-8D2A0507166F

The buffer tool is an exception, however:

http://resources.arcgis.com/en/help/main/10.2/index.html#//00080000001s000000

— Andy

On Nov 12, 2014, at 8:41 AM, Bistrais, Bob <[log in to unmask]> wrote:

I suggest looking into the Geography data type in your spatial database (PostGIS supports it, not sure about spatial databases).  The Geography type is based on WGS84 (SRID 4326), and it sounds like this is what you need for this exercise.

 
 
From: Northeast Arc Users Group [[log in to unmask]] on behalf of Czaja, Daniel [[log in to unmask]]
Sent: Wednesday, November 12, 2014 8:17 AM
To: [log in to unmask]
Subject: Re: Finding Distance between points over water

While I have no idea how to do this, it is a fascinating topic. It conjures up images of sailing ships plying the oceans along great circle routes in search of spices and treasure.

 

The one thing that I did find was that the NOAA and the Department of Commerce put out a publication that contains the distances between US ports here: http://www.nauticalcharts.noaa.gov/nsd/distances-ports/distances.pdf. Maybe they could be of assistance.

 

Dan

 

Daniel Czaja, GISP
GIS Coordinator
State of Connecticut Department of Emergency Services and Public Protection

Division of Statewide Emergency Telecommunications
1111 Country Club Road
Middletown, CT  06457-9294

 

Phone: 860.685.8131
Fax: 860.685.8363

 

[log in to unmask]

 

 

"Give me a stopwatch and a map, and I'll fly the Alps in a plane with no windows.  If the map is accurate enough." - The Hunt for the Red October

 

From: Northeast Arc Users Group [mailto:[log in to unmask]] On Behalf Of Don Cooke
Sent: Tuesday, November 11, 2014 12:15 PM
To: [log in to unmask]
Subject: Re: Finding Distance between points over water

 

A friend at GDT suggested a projection-free way to calculate distances between lat/long pairs:  calculate the spherical angle between the two points relative to the center of the earth, then convert the angle to a distance using an assumed radius of the earth.  I guess you need to assume a spherical earth….

 

Interesting way to think about it.  We do tend to get the rope wound around the axle given our comfort with projections.

 

****** Don

From: Northeast Arc Users Group [mailto:[log in to unmask]] On Behalf Of Andy Anderson
Sent: Tuesday, November 11, 2014 8:29 AM
To: [log in to unmask]
Subject: Re: Finding Distance between points over water

 

No single projection will work, you must use different ones over subglobal distances, which prevents a single calculation. But one approach would be to use the plate carrée projection (your attached example) to generate a rough route, then choose an appropriate projection over each leg, e.g. two-point equidistant, and then project to a new raster and redetermine the legs and then calculate the distance. Still won’t be the best possible distance because you’re fixing points, but it should be a better estimate.

 

For the resolution you are using (~70 Km/pixel) I don’t think a land buffer is necessary.

 

— Andy

 

On Nov 11, 2014, at 10:56 AM, Milan Budhathoki <[log in to unmask]> wrote:

 

Hi Chris and Andy,

 

Thank you for your suggestions. I was given just Lat/Long of ship's starting port and destination port in .CSV. Beside these I don't I have any additional information. Yes, prevailing winds and ocean currents will play a role in ships actual path but I think my collaborator is looking for the shortest distance just over water regardless of any other assumption that might affect on actual route. I haven't research at published route documents but this is worth trying. Projection is another issue since dataset has thousands of ports around the globe. I am thinking of  the "Merrcator Projection ?". I did a quick cost-path analysis for one of the ports pair. Due to lack of information to make a cost-raster ( I used just land and water mask as a cost raster) path tends to grip through land as below;

 

<image84 Nov. 11.jpg>
​

 
 


​

Here voyages tends to pass very closely to land (mostly touches land mask). I am thinking to buffer land mask outward with X miles so that ships path will be X miles way from land. Also I am considering to bring ocean depth as another cost-raster if data is publicly available. Eventually, I am write a python script or run model builder once I figure out better way.  

 

I would like to hear more if anyone has any thoughts ! 

 

Thank you ! 

 
 
 
 

On Mon, Nov 10, 2014 at 11:38 AM, Andy Anderson <[log in to unmask]> wrote:

To remove the tedium, write a Python script.

 

Remember, though, that distance calculations depend on the projection you use. If you want the cost-path from, say, New York to Sydney, there is no single projection that will give you an accurate measure.

 

A better approach might be to determine the standard shipping lanes, calculate the distances (if you can’t find them in a table), and piece together routes.

 

More generally, you could set up an iterative algorithm to calculate distances using spheroid-based angular calculations with restrictions based on open water (e.g. at 40° north latitude, longitude will be restricted to roughly –74° to –9° and 128° to 140° and 142° to -124°).

 

— Andy

 

On Nov 10, 2014, at 9:13 AM, Milan Budhathoki <[log in to unmask]> wrote:

 

Looks like email that I sent yesterday didn't go through. 

Here it is again: 

 

Hello Listserv,

 

I have point dataset of ship trips from one port to another. I want to calculate the shortest distance between each port pair  over water. There are thousands of voyages, and 5,000 unique ports from all over the world. One of the approach I can use in ArcGIS  is to run the Cost-Path tool having water/land as a cost raster to make a path only on water. But I assume that the Cost-Path approach would be little tedious for a large dataset. I wonder if anyone in this forum has a suggestion to calculate a shortest distance between two points having restricted path.

 

I will highly appreciate your feedback.

 
 

-- 

Milan Budhathoki

 

------------------------------------------------------------------------- This list (NEARC-L) is an unmoderated discussion list for all NEARC Users.

If you no longer wish to receive e-mail from this list, you can remove yourself by going to http://listserv.uconn.edu/nearc-l.html.

 

------------------------------------------------------------------------- This list (NEARC-L) is an unmoderated discussion list for all NEARC Users.

If you no longer wish to receive e-mail from this list, you can remove yourself by going to http://listserv.uconn.edu/nearc-l.html.



 

--

Milan Budhathoki