Dear Grasshoppers,
We are attempting to digitize a base map for Oklahoma using
a lat/long map. Oklahoma spans 3 utm zones, so lat/long seems
to be the way to go, right?
Lat/long is the most effective way to handle this, if you can get it
to work. This is what I've found:
We think we set up the lat/long location properly, using
latitude values for the northern and southern edges and
longitudes for the eastern and western edges. The region
produced has negative longitude values (We assume because we are
in W longitude).
I had to set up the region in the following format:
dd:mm:ssH where H is one of N S E W (in CAPS!)
When we try to digitize the map using the v.digit program of
Grass4.1, we do fine until asked to enter the map registration
points. First we enter a 1 to indicate we will enter points in
Lat/Lon. We then run into the following problems:
Here it gets confusing: lat/long control points here means "control
points different from the location coordinate system" ie if the location
is lat long, you enter 0 for UTM which means 0 for same coordinate
system for the control as for the map.
1) The registration points menu asks us to enter Lat as the X
coordinate and Lon as the Y coord. This seems backwards.
It is. If you have a UTM map, believe the lat/long directions, not
the X,Y. If you have a lat/long location, use X for lat and Y for
long.
2) We enter the points in the format indicated, i.e.,
dd:mm:ss.ffh, but when we hit <ESC> to continue, we are thrown
out of v.digit without explanation.
The explanation flies by faster than you can see. It says that it was
unable to convert the coordinates to the base system, but since both
the control and the location are the same, the conversion fails.
In fact, since you want to pretend they're UTM control points for a
UTM location, you avoid a conversion and it doesn't dump out of
v.digit.
BUT, in the UTM same-control-as-the-location mode, you can't enter dms
format coordinates - you have to use decimal degrees!! It sounds
weird, but that's what works.
On one occassion, we entered the registration points as x,y
coordinates. In that case we were able to proceed with
digitizing, but the map was turned on its side with lat as x and
long as y.
You were getting close here. Just make your decimal lats as x and
your decimal longs as Y and you'll be fine.
We have been unable to find any documentation on using lat/long maps
with v.digit. Neither the man page or the digitizing tutorial for
Grass4.0 address lat/long data in any way.
By the way, if you want to use lat/long control in a UTM location,
they must be entered in the format: dd:mm:ss.ffh, where ff are
decimal seconds (they must be there, even if .00) and h is one of n s
e w (this time in lower case!).
Has anyone had experience digitizing lat/long maps with
Grass4.1? Does Grass work with lat/long data? Is there a
tutorial or documentation anywhere that addresses using lat/long
data in Grass?
The documentation says nothing on this. Let the source be your
guide...
Any help would be greatly appreciated.
Have fun!!!!
Dan Hough email address:dhough@uokmvsa.uoknor.edu
Oklahoma Biological Survey
Norman, OK 73019
+------------------------------------------------------------------------------+
| Kenn Gardels Tel +01 (510) 642-9205 |
| CEDR - 390 Wurster Hall Fax +01 (510) 643-5571 |
| University of California Internet gardels@ced.berkeley.edu |
| Berkeley, CA 94720 Bitnet gardels@UCBCED |
+------------------------------------------------------------------------------+