Tue, Feb 28 2006
22:10:52
|
|
Request created by guest
|
|
Subject: r.in.gdal won't import some data into lat long projections
Platform: GNU/Linux/x86
grass obtained from: Other (CDROM etc)
grass binary for platform: Downloaded precompiled Binaries
GRASS Version: 6.0.1
I have an image file (short-int png) that is a projected raster map in the EPSG:4326
(lat/long, wgs84) projection. It's got a nice bounding box that goes around the
outside of the pixels. The bounding box is -119,41.8,-116.8,44.5. The georeferencing
is in a text file with the coverage that states the northern, southern, eastern,
and western borders. This data does not need to be rectified or reprojected;
it is already in the projection of the grass database, so importing the data
should be simple.
In other projections, when I have encountered this sort of data, I have imported
it "overriding" the projection of the file with the projection of the current
database. I then used r.region to set the bounding box of the raster and am done.
So this ought to be easy. I do:
r.in.gdal input=coverage.png output=coverage -o
However this returns:
Over-riding projection check.
Proceeding with import...
WARNING: G_set_window(): Illegal latitude for South
This is because, in the png image, the coordinates of the data run along the
lines of -2000 to 0 in the y direction and -2000 to 0 in the x direction. -2000
isn't a valid southern latitude. Thanks for the warning. It's even a good thing
for the program to stop here to make sure the importer knows that something's
amiss. However I really do mean to do this as the numbering of the pixels in
the PNG image is uninteresting. This says it is a warning, not an error, yet
there is no way to continue ignoring this warning. What matters to me, and to
grass, is the region I am going to assign it after this step.
Solutions:
1. (best in my opinion) Provide a method to ignore this warning. Make sure that
our bases are covered in that similar export warnings and reprojection warnings
are in place.
2. Change the text from "WARNING: G_set_window(): Illegal latitude for South"
to "ERROR: G_set_window(): Illegal latitude for South". Provide another easy
avenue for importing data that doesn't include its georeferencing but is already
projected. Note the idiosynchracies of the latlong projection with respect to
this behaviour in the documentation.
3. Change the r.in stuff to have options for the window be provided with the
command.
4. Add an import command that wraps up the r.in infrastructure so that it supports
shifting data (providing georeferencing from outside the file). If this is done
(I think it'd have to use i. commands) we might as well go all the way and handle
reprojection too. |
|
Tue, Feb 28 2006
22:45:22
|
|
Mail sent by guest
|
|
When submitting the bug the bug tracker told me that my email address would
only be used for sending me information regarding the bug, however it is
listed in plain text for all the nice email harvesters to eat. Please change
the requesting email address to cedricgrass@shockfamily.net instead. |
|
Tue, Feb 28 2006
23:13:27
|
|
Mail sent by guest
|
|
Hi,
(cc RT admin)
I darkly remember that the email scrambling was enabled once
in our RT.
Bernhard, am I wrong and/or can we enable email scrambling to
avoid spam harvesters to find useful addresses?
thanks
Markus |
|
Tue, Feb 28 2006
23:13:44
|
|
User changed to cedricgrass@shockfamily.net by mneteler
|
|
Wed, Mar 1 2006
12:36:04
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Thu, 2 Mar 2006 00:35:20 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #4122] (grass) r.in.gdal won't import some data into lat long projections
|
Message-Id |
<20060302003520.59bff3bd.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20060228211052.C36081005D3@lists.intevation.de>
|
References |
<20060228211052.C36081005D3@lists.intevation.de>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4122
> ---------------------------------------------------------------------
>
> Subject: r.in.gdal won't import some data into lat long projections
>
..
> GRASS Version: 6.0.1
>
> I have an image file (short-int png) that is a projected raster map in
> the EPSG:4326 (lat/long, wgs84) projection. It's got a nice bounding
> box that goes around the outside of the pixels. The bounding box is
> -119,41.8,-116.8,44.5. The georeferencing is in a text file with the
> coverage that states the northern, southern, eastern, and western
> borders. This data does not need to be rectified or reprojected; it is
> already in the projection of the grass database, so importing the data
> should be simple.
>
> In other projections, when I have encountered this sort of data, I
> have imported it "overriding" the projection of the file with the
> projection of the current database. I then used r.region to set the
> bounding box of the raster and am done. So this ought to be easy. I
> do:
>
> r.in.gdal input=coverage.png output=coverage -o
>
> However this returns:
>
> Over-riding projection check.
> Proceeding with import...
> WARNING: G_set_window(): Illegal latitude for South
>
> This is because, in the png image, the coordinates of the data run
> along the lines of -2000 to 0 in the y direction and -2000 to 0 in the
> x direction. -2000 isn't a valid southern latitude. Thanks for the
> warning. It's even a good thing for the program to stop here to make
> sure the importer knows that something's amiss. However I really do
> mean to do this as the numbering of the pixels in the PNG image is
> uninteresting. This says it is a warning, not an error, yet there is
> no way to continue ignoring this warning. What matters to me, and to
> grass, is the region I am going to assign it after this step.
>
> Solutions:
>
> 1. (best in my opinion) Provide a method to ignore this warning. Make
> sure that our bases are covered in that similar export warnings and
> reprojection warnings are in place.
>
> 2. Change the text from "WARNING: G_set_window(): Illegal latitude for
> South" to "ERROR: G_set_window(): Illegal latitude for South". Provide
> another easy avenue for importing data that doesn't include its
> georeferencing but is already projected. Note the idiosynchracies of
> the latlong projection with respect to this behaviour in the
> documentation.
>
> 3. Change the r.in stuff to have options for the window be provided
> with the command.
>
> 4. Add an import command that wraps up the r.in infrastructure so that
> it supports shifting data (providing georeferencing from outside the
> file). If this is done (I think it'd have to use i. commands) we might
> as well go all the way and handle reprojection too.
Unreferenced images are imported as pixels, once you get more than 90
rows it gets upset.
import into a new XY location, use r.region to set correct bounds, check
resolution is correct with r.info, and either copy mapset into a
projected location or change your XY location with g.setproj.
gdal import often support "world files" containing geo-ref info.
Hamish
|
|
Wed, Mar 1 2006
14:26:29
|
|
Mail sent by bernhard@intevation.de
|
|
Return-Path |
<bernhard@intevation.de>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 1 Mar 2006 14:26:27 +0100
|
From |
Bernhard Reiter <bernhard@intevation.de>
|
To |
guest user via RT <grass-bugs@intevation.de>, grass5@intevation.de
|
Subject |
Re: [bug #4122] (grass) r.in.gdal won't import some data into lat long projections
|
Message-ID |
<20060301132627.GA10966@intevation.de>
|
Mail-Followup-To |
guest user via RT <grass-bugs@intevation.de>, grass5@intevation.de
|
References |
<20060228221327.33FD61005D3@lists.intevation.de>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
In-Reply-To |
<20060228221327.33FD61005D3@lists.intevation.de>
|
User-Agent |
Mutt/1.5.6i
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Am 28. Feb 2006 um 23:13:27 schrieb guest user via RT:
> (cc RT admin)
>
> I darkly remember that the email scrambling was enabled once
> in our RT.
> Bernhard, am I wrong and/or can we enable email scrambling to
> avoid spam harvesters to find useful addresses?
We never had email "scrambling" enabled in RT, as far as I can remember.
Also, it would not help anyway, so I do not recommend it.
|
|