[GRASSLIST:4172] Re: Map import cluelessness

[C.S. Cornuelle]

Ian,

Thanks.  I did originally attempt what you suggest, but ran up against
a wall - of my own ignorance, probably.  :^)

Namely, setting up the projection of the Mercator location does not 
seem to work for me.  To get concrete:

I start with -

	D   Other Projection

and choose

	Please specify projection name = merc
	Please specify datum name = wgs84 (no real basis for this ...)
	Now select Datum Transformation Parameters = well, see 

	>list
	Number  Details
	---
	1       Used in Default wgs84 region
	        (PROJ.4 Params towgs84=0.000,0.000,0.000)
		Default 3-Parameter Transformation

So I used this, as it is the only choice.

Now we get to the hard part.

	Enter Latitude of True Scale [lat_ts] (0) : 0 (default for
	Mercator as I understand this)

	Enter Central Meridian [lon_0] (96W) : 30E (in my case)

	Enter Scale Factor at the Central Meridian [k_0]
	[1.0000000000]: (no idea what this is, so left it at 1)

	Enter plural form of units [meters]: (OK, it really breaks down
	here for me, since entering anything besides meters leads to a
	request for the conversion from "whatever" to meters, all of
	which in the context of a Mercator projection seems odd to me.)

In the end, this looks just like an (x,y) location.  Clearly I am not
understanding what is going on here.  Perhaps I need to look into 
using something like gdalwarp to translate my scanned Mercator map into
lat-lon or?


Thus spake Ian MacMillan (ian_macmillan at umail.ucsb.edu):

> I am not sure that this will totally solve your problem, but it is 
> necessary for correct projection.  You need to import your original 
> scanned map into an XY location (without any georeferencing), then 
> project that into your desired location (either a lat-long if you have 
> those points, or a mercator if you have those) with i.group, i.target, 
> i.points, i.rectify.  This first step is necessary to originally 
> georeference your scanned image.  Then, if you want to reproject your 
> image (say from a mercator to a lat long) you need to use r.proj from 
> your final desired location (the lat-long) with the correct region 
> setting.  To find a good region setting use m.u2ll or m.ll2u to find 
> the bounding coordinates of your raster in your mercator projection.
> 
> Hope this helps,
> Ian
> 
> 
> 
> On Aug 10, 2004, at 2:55 PM, C.S. Cornuelle wrote:
> 
> >Thus spake Glynn Clements (glynn.clements at virgin.net):
> >
> >>C.S. Cornuelle wrote:
> >>
> >>>Thanks for the succinct description.  It allowed me to get as far
> >>>as i.rectify, where this ancient (according to some web searching)
> >>>problem arose courtesy of my mailbox:
> >>>
> >>>	GIS ERROR: error while writing to temp file
> >>>
> >>>As per a recommendation I tried this:
> >>>
> >>>	watch df -h
> >>>
> >>>and then some of this:
> >>>
> >>>GRASS:/data/grassdata > date;df /data
> >>>Mon Aug  9 17:02:19 MDT 2004
> >>>Filesystem           1K-blocks      Used Available Use% Mounted on
> >>>/dev/hdb4             24590712  11836772  12753940  49% /data
> >>>GRASS:/data/grassdata > date;df /data
> >>>Mon Aug  9 17:02:34 MDT 2004
> >>>Filesystem           1K-blocks      Used Available Use% Mounted on
> >>>/dev/hdb4             24590712  11026744  13563968  45% /data
> >>>
> >>>While the first call of df /data probably did not catch peak disk
> >>>usage, the difference is around 810M, not nearly large enough to
> >>>fill the disk or the partition.
> >>>
> >>>Any ideas on what might be going on here?  Is there a malloc set
> >>>in i.rectify which is causing this?  FYI this map has 7500 rows and
> >>>15600 columns, so it is rather large.  10 points were identified in
> >>>i.points, and the rms value was somewhat high, nearly 100.
> >>
> >>On 32-bit architectures (e.g. x86), files are limited to 2Gb; it may
> >>be that you are exceeding that limit.
> >>
> >>Although Linux supports files larger than 2Gb, the code which deals
> >>with such files has to use "off_t" instead of "long", so the code
> >>would need to be updated to allow for this.
> >>
> >>Actually, the GRASS code often performs offset calculations using
> >>"int"s so, even on platforms where "long" is 64 bits, a lot of GRASS
> >>would still have problems with files larger than 2Gb.
> >
> >This problem does indeed go away when the region is limited to a 
> >smaller
> >subset of the map.
> >
> >However, I have another bonehead problem now.  :^)
> >
> >Not one but two emails are sent to me by i.rectify for this smaller
> >region:
> >
> >Date: Tue, 10 Aug 2004 15:39:12 -0600
> >GIS WARNING: WARNING lote_wholeworld_base at PERMANENT: projection don't
> >match current settings.
> >
> >and then:
> >
> >Date: Tue, 10 Aug 2004 15:39:12 -0600
> >Subject: i.rectify
> >***********************************************
> >Rectify [lote_wholeworld_base at PERMANENT] (LOCATION LOTEWHOLE_MERC)
> >into  [lote_wholeworld_baserec in PERMANENT] (LOCATION GLOBAL_30)
> >complete
> >-----------------------------------------------
> > 600 rows, 600 cols (360000 cells) completed in 0:05
> > 4320000.0 cells per minute
> >
> >I have tried this with several different regions, to no avail.  And
> >searching about did not turn up any references to the GIS WARNING
> >message above.
> >
> >The sequence of actions was to set up a Mercator location, read the
> >scanned map file in with r.in.png, then i.group, i.target, i.points,
> >and finally i.rectify into a lat-lon location.
> >
> >Any ideas?
> >
> >-- 
> >Adios,
> >Chris Cornuelle
> >bob at xmission dot com
> >
> 

-- 
Adios,
Chris Cornuelle
bob at xmission dot com