[GRASSLIST:4163] Re: Map import cluelessness

[Ian MacMillan]

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
>