> 
> 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                    |
+------------------------------------------------------------------------------+

