# Getting meters instead of degrees from GRASS v.distance?

I'm trying to measure the distance between points to a coastline. I have a shapefile of the "High Seas" which I got from NOAA's website here.

http://www.nws.noaa.gov/geodata/catalog/wsom/html/marinezones.htm

I also have a list of points which represent buildings.

I've played with different solutions, but I think that GRASS's v.distance is the best solution. I've been able to get my data into GRASS and can plot the map.

The problem is that when I run the v.distance tool, I'm getting decimal degrees, but I really want either meters, miles, or kilometers.

So the v.distance function seems to be the best option.

However, I've been unable to get meters out of this data. In the help guide, for v.distance, I did find this sentence.

``````In lat-long locations v.distance gives distances (dist and to_along) in meters not in degrees calculated as geodesic distances on a sphere.
``````

Its not exactly clear to me what this means. It sounds like I should set up the location with a EPSG code that uses lat long. I've used a handful to no avail. For example, I tried EPSG 3857, 3786, 4326, all to no avail.

As a side note, I did try QGIS's distance to hub that's part of the MMQGIS plugin. It appears that maps to the nearest centroid of a polygon. I'm trying to get the distance to the nearest pixel/border of a polygon. Or the nearest pixel/edge of a line.

• You need to look into projections. Probably converting to UTM in your case if you want distance in meters, km, miles. Aug 8 '14 at 18:17
• @GISKid That's right. But since these appear to be ocean distances, UTM would be one of the worst choices, given its extreme east-west distortions. Aug 8 '14 at 19:03
• @whuber You're right I didn't think of that, what would you recommend instead? Aug 8 '14 at 19:07
• @GIS I was afraid you would ask that :-). It depends on the extent and location of the coastline. Coastlines of individual countries or small continents can be handled OK with location-specific projections if the query points aren't too far away from them. For high accuracy with global coastlines it might be necessary to break the world up into smaller areas, perform the calculations in the separate areas, and combine the results. Aug 8 '14 at 19:27
• @whuber :( that sounds tedious! Maybe OP can provide more information about where they're looking at so we (you!) can provide better information! Aug 8 '14 at 19:31

To get distances in meters, project the data. How to do that is a mechanical issue readily resolved by referring to the software manuals. The harder part of the question concerns what projection to use?

Because a comment to the question indicates that North America is the region of interest, the shape of this continent--and the situation of its coastlines on both sides--suggests using a conic or polyconic projection. One reasonable choice is the Lambert Conformal Conic. By placing the standard parallels at suitable values, this projection can be adapted to compromise decently between obtaining good coverage of the oceans off the eastern and western coasts while minimizing the range of distortions.

Two excellent tools for studying distortions in projections--and therefore for selecting among options in an objective, intelligent, and guided manner--are the latitude-longitude graticule and the Tissot Indicatrix. This figure illustrates both.

To achieve good accuracy of both coasts of the US, I chose standard parallels of 45 and 25 degrees North (essentially the top and bottom boundaries of the conterminous states). The central parallel is set to 35 degrees North and the central meridian (which determines the orientation of the map) to 102 degrees West.

• The graticule is the grid of gray lines. Look for equal heights of the grid cells in the north-south direction and regularly varying widths (which ought to shrink towards the poles). Such patterns are qualitative signs of good metric accuracy.

• The Tissot indicatrices are the circular figures plotted at strategic points in the ocean. Each is actually two circles: one, in gray, is a constant size throughout the map. Another, in blue, is the actual size of the gray circle. Wherever the blue and gray circles coincide, metric accuracy is high. (You can see a portion of an indicatrix located west of Alaska in the upper left corner where the blue circle is visibly larger than the gray one. This projection will exhibit considerable distortion at latitudes beyond the standard parallels.) Incidentally, the red radii always point north. Their variation across the map shows considerable variation in convergence, which matters for analyses involving bearing or direction, but are irrelevant for distance measurements.

Detailed measurements of these indicatrices indicate that distance measurements will be accurate to within 1.5% throughout the region they cover in this map.

As a point of departure for constructing this projection, consider starting with EPSG:102004 or (for much wider coverage north-south) EPSG:102009.

• Wow. This is helpful. I read a little online about all these transformations and you have some really good insights here. I guess I never put much thought into the projection problem. I ran the program again with projection EPSG:102009 and got what I wanted. My points are across the country... as far south as Brownsville, TX, west as Hawaii, east as Puerto Rico, and North as the northwest territories of Canada. I even have some points in Fairbanks, AK. The numbers I've gotten are reasonable. Might be off by a little, I'm sure, but good enough for what I'm trying to do. Thanks again!
– none
Aug 10 '14 at 16:52

In spite of what it says in the GRASS manual for v.distance, units are the same as the units of the coordinate system, so in a lat/lon coordinate system you will indeed get decimal degrees. In the GRASS 7 manual the above (incorrect) statement is missing.

On the other hand, if you create a Spherical Mercator based LOCATION, EPSG 3857, as you mentioned, the units are meters, and v.distance gives the distance measurements in meters. However be aware of the inaccuracies inherent in this coordinate system.

• Thank you for your helpful comment! I tried this again with 3857 and actually it worked! I decided to use EPSG:102009 whuber's answer. I like GRASS, but I will complain that, at least on Windows, its quite buggy. For example, I can't change the mapsets without on my Windows version without exiting and re-opening the application--it throws some python errors. (It works on my Mac version). I may have been a little frustrated by it so didn't test that correctly.
– none
Aug 10 '14 at 16:48
• Hi Micha, please send a text snippet to me in order to improve the manual. Aug 18 '14 at 6:40
• @befuddled You can indeed change the current mapset: Settings -> GRASS working environment -> Change working environment (and yes, we continue to work on stabilizing winGRASS). Aug 26 '14 at 6:07

You want your data projected into Meters, which you can project in GRASS or use QGIS to do that - North_America_Albers_Equal_Area_Conic projection EPSG 102008 would work for North America, for example.

Then I'm not sure if you can have data in multiple coordinate systems in 1 workspace, or if you should create a new workspace in EPSG: 102008 to store your projected data and then run your distance calculations on.

Once you've got the data in meters in your GRASS workspace, your distance values will be in meters.