[GRASS-user] Projection of latlong sites file doesn't work

GRASS GRASS user
1

I have a file in the following format:

-45.075000,170.975000,80.173343
-45.025000,170.975000,72.205741
...
-44.975000,170.975000,93.254147

i.e. latitude, longitude, and an attribute in the third column.

I import it into a latlong location using v.in.ascii and then try and
project it into a location that uses the New Zealand Mapping Grid
projection, but I get the following output:

------------

v.proj input=lhumile_ddays location=latlong

Input Projection Parameters: +proj=latlong +a=6378388 +rf=297 +no_defs
+towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993
Input Unit Factor: 1

Output Projection Parameters: +proj=nzmg +lat_0=-41.0000000000
+lon_0=173.0000000000 +x_0=2510000.0000000000 +y_0=6023150.0000000000
+a=6378388 +rf=297 +no_defs
+towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993
Output Unit Factor: 1

Creating vector file...
pj_transform() failed
cause: latitude or longitude exceeded limits
Error in pj_do_transform

------------

None of the latitude/longitude values appear to be out of range. Is
there anyway to get more information? Or does anyone else have a clue
on how to fix this?

Thanks for your time.

--
-Joel

"Wish not to seem, but to be, the best."
                -- Aeschylus

2

In addendum, I realised that I had the latitude and longitude reversed
when importing the ascii file. Silly mistake!

-Joel

On 7/25/06, Joel Pitt <joel.pitt@gmail.com> wrote:

I have a file in the following format:

-45.075000,170.975000,80.173343
-45.025000,170.975000,72.205741
...
-44.975000,170.975000,93.254147

i.e. latitude, longitude, and an attribute in the third column.

I import it into a latlong location using v.in.ascii and then try and
project it into a location that uses the New Zealand Mapping Grid
projection, but I get the following output:

------------
> v.proj input=lhumile_ddays location=latlong

Input Projection Parameters: +proj=latlong +a=6378388 +rf=297 +no_defs
+towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993
Input Unit Factor: 1

Output Projection Parameters: +proj=nzmg +lat_0=-41.0000000000
+lon_0=173.0000000000 +x_0=2510000.0000000000 +y_0=6023150.0000000000
+a=6378388 +rf=297 +no_defs
+towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993
Output Unit Factor: 1

Creating vector file...
pj_transform() failed
cause: latitude or longitude exceeded limits
Error in pj_do_transform

------------

None of the latitude/longitude values appear to be out of range. Is
there anyway to get more information? Or does anyone else have a clue
on how to fix this?

Thanks for your time.

--
-Joel

"Wish not to seem, but to be, the best."
                -- Aeschylus

--
-Joel

"Wish not to seem, but to be, the best."
                -- Aeschylus

3

r.cva -f option "calculate the visibility from rather than viewsheds of"

Would someone elaborate on the difference between "visibility from" and "viewshed of".

4

Gary,

Would someone elaborate on the difference between "visibility from" and "viewshed of".

As the original author of r.cva I have to admit that the choice of terminology could perhaps have been clearer, but this choice is explained in the man page if you have that on your system. Also check the info. at http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html

Normally, i.e. without choosing the -f flag / NOT checking the "Calculate visibility from ..." box, r.cva produces output in which each non-NULL cell represents a viewpoint and contains a count of the number of cells visible from that viewpoint. Thus if you specify just one viewpoint, you should get output containing one cell effectively recording the size (in number of cells) of the viewshed of that viewpoint.

If you do set the -f flag / check the "Calcuclate visibility from ..." box, then r.cva produces rather different output in which each non-NULL cell represents a cell which is visible from one or more viewpoints and contains a count of the number of viewpoints from which it is visible. Thus if you specify just one viewpoint, you should get output that is essentially the same as converting the output from r.los into binary form (i.e. you get a traditional viewshed map showing what area is visible from the selected viewpoint).

You can further change exactly what is being calculated by reversing the observer and target offsets. This is because the fact that you can see A from B does not guarantee that you can see B from A, unless the height of the observer is equal to any target offset that may have been set.

These issues have been widely discussed in the archaeological literature. If you have access to a library you should look at:

Conolly, J. and Lake, M. (2006).
           Geographical Information Systems in Archaeology.
           Cambridge Manuals in Archaeology. Cambridge University Press,
           Cambridge.
           Pages 225-233

Wheatley, D. and Gillings, M. (2002).
           Spatial Technology and Archaeology: The Archaeological
           Applications of GIS.
           Taylor & Francis, New York.
           Pages 201-214

Directly related methodological issues are also discussed in:

Fisher, P. F., Farrelly, C., Maddocks, A., and Ruggles, C. (1997).
           Spatial analysis of visible areas from the Bronze Age cairns of
           Mull.
           Journal of Archaeological Science, 24:581-592.

Lake, M. W., Woodman, P. E., and Mithen, S. J. (1998).
           Tailoring GIS software for archaeological applications: An
           example concerning viewshed analysis.
           Journal of Archaeological Science, 25:27-38.

I'm out of contact now for 10 days, so won't be able to answer further questions until after that.

Mark

--
Dr Mark Lake

Institute of Archaeology
University College London
31-34 Gordon Square
London. WC1H 0PY

Tel: +44 (0)207 679 7495
Fax: +44 (0)207 383 2572