Tue, Feb 7 2006
12:08:43
|
|
Request created by guest
|
|
Subject: r.in.srtm: doesn't work, though it's a latlong WGS84 projection
Platform: GNU/Linux/x86
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: CVS 2005.02.07
I cannot import an srtm into a latlong, wgs84 location created interactively
at Grass startup:
$ r.in.srtm input=/home/john/gis/dane/srtm2/N51E016.hgt.zip output=N51E016
Extracting /home/john/gis/dane/srtm2/N51E016...
Archive: /home/john/gis/dane/srtm2/N51E016.hgt.zip
inflating: N51E016.hgt
Converting input file to BIL...
GRASS_INFO_ERROR(14866,1): Projection of dataset does not appear to match current
location.
GRASS_INFO_ERROR(14866,1):
LOCATION PROJ_INFO is:
GRASS_INFO_ERROR(14866,1): name: Latitude-Longitude
GRASS_INFO_ERROR(14866,1): datum: wgs84
GRASS_INFO_ERROR(14866,1): towgs84: 0.000,0.000,0.000
GRASS_INFO_ERROR(14866,1): proj: ll
GRASS_INFO_ERROR(14866,1): ellps: wgs84
GRASS_INFO_ERROR(14866,1):
cellhd.proj = 0 (unreferenced/unknown)
GRASS_INFO_ERROR(14866,1):
You can use the -o flag to r.in.gdal to override this check and use the location
definition for the dataset.
GRASS_INFO_ERROR(14866,1): Consider generating a new location from the input
dataset using the 'location' parameter.
ERROR: N51E016 - map not found
Done: generated map N51E016
(Note: Holes in the data can be closed with 'r.fillnulls' using splines)
My projection looks OK, doesn't it:
GRASS 6.1.cvs (caves_wgs84):~ > g.proj -p
-PROJ_INFO-------------------------------------------------
name : Latitude-Longitude
datum : wgs84
towgs84 : 0.000,0.000,0.000
proj : ll
ellps : wgs84
-PROJ_UNITS------------------------------------------------
unit : degree
units : degrees
meters : 1.0
|
|
Tue, Feb 7 2006
12:14:50
|
|
Mail sent by guest
|
|
Update - I've made a mistake usimg full file name N51E016.hgt.zip for input
instead of N51E016 only. Now I used it correctly but still the error about
projection is present:
$ r.in.srtm input=/home/john/gis/dane/srtm2/N51E016 output=N51E016
Extracting /home/john/gis/dane/srtm2/N51E016...
Archive: /home/john/gis/dane/srtm2/N51E016.hgt.zip
inflating: N51E016.hgt
Converting input file to BIL...
GRASS_INFO_ERROR(15045,1): Projection of dataset does not appear to match
current location.
GRASS_INFO_ERROR(15045,1):
LOCATION PROJ_INFO is:
GRASS_INFO_ERROR(15045,1): name: Latitude-Longitude
GRASS_INFO_ERROR(15045,1): datum: wgs84
GRASS_INFO_ERROR(15045,1): towgs84: 0.000,0.000,0.000
GRASS_INFO_ERROR(15045,1): proj: ll
GRASS_INFO_ERROR(15045,1): ellps: wgs84
GRASS_INFO_ERROR(15045,1):
cellhd.proj = 0 (unreferenced/unknown)
GRASS_INFO_ERROR(15045,1):
You can use the -o flag to r.in.gdal to override this check and use the
location definition for the dataset.
GRASS_INFO_ERROR(15045,1): Consider generating a new location from the input
dataset using the 'location' parameter.
ERROR: N51E016 - map not found
Done: generated map N51E016
(Note: Holes in the data can be closed with 'r.fillnulls' using splines)
Maciek |
|
Tue, Feb 7 2006
22:39:27
|
|
Mail sent by neteler@itc.it
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 7 Feb 2006 22:39:22 +0100
|
From |
Markus Neteler <neteler@itc.it>
|
To |
guest user via RT <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it, paul-grass@stjohnspoint.co.uk, Frank Warmerdam <warmerdam@pobox.com>
|
Subject |
Re: [bug #4064] (grass) r.in.srtm: doesn't work, though it's a latlong WGS84 projection
|
Message-ID |
<20060207213922.GF31202@bartok.itc.it>
|
Mail-Followup-To |
guest user via RT <grass-bugs@intevation.de>, grass5@grass.itc.it, paul-grass@stjohnspoint.co.uk, Frank Warmerdam <warmerdam@pobox.com>
|
References |
<20060207111450.386001005B7@lists.intevation.de>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
In-Reply-To |
<20060207111450.386001005B7@lists.intevation.de>
|
User-Agent |
Mutt/1.4.1i
|
X-PGP-Key |
http://www.gdf-hannover.de/neteler/markus_gpgkey.asc
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Maciek,
(cc Frank)
I had the same problem with v.in.ogr today (using GDAL/OGR from CVS).
Frank, did anything in GDAL/OGR recently change which makes fail the
recognition of the GRASS location projection in r.in.gdal/v.in.ogr?
This used to work.
Markus
On Tue, Feb 07, 2006 at 12:14:50PM +0100, guest user via RT wrote:
> Update - I've made a mistake usimg full file name N51E016.hgt.zip for input
> instead of N51E016 only. Now I used it correctly but still the error about
> projection is present:
>
>
>
> $ r.in.srtm input=/home/john/gis/dane/srtm2/N51E016 output=N51E016
> Extracting /home/john/gis/dane/srtm2/N51E016...
> Archive: /home/john/gis/dane/srtm2/N51E016.hgt.zip
> inflating: N51E016.hgt
> Converting input file to BIL...
>
> GRASS_INFO_ERROR(15045,1): Projection of dataset does not appear to match
> current location.
> GRASS_INFO_ERROR(15045,1):
> LOCATION PROJ_INFO is:
> GRASS_INFO_ERROR(15045,1): name: Latitude-Longitude
> GRASS_INFO_ERROR(15045,1): datum: wgs84
> GRASS_INFO_ERROR(15045,1): towgs84: 0.000,0.000,0.000
> GRASS_INFO_ERROR(15045,1): proj: ll
> GRASS_INFO_ERROR(15045,1): ellps: wgs84
> GRASS_INFO_ERROR(15045,1):
> cellhd.proj = 0 (unreferenced/unknown)
> GRASS_INFO_ERROR(15045,1):
> You can use the -o flag to r.in.gdal to override this check and use the
> location definition for the dataset.
> GRASS_INFO_ERROR(15045,1): Consider generating a new location from the input
> dataset using the 'location' parameter.
> ERROR: N51E016 - map not found
> Done: generated map N51E016
> (Note: Holes in the data can be closed with 'r.fillnulls' using splines)
>
> Maciek
>
> -------------------------------------------- Managed by Request Tracker
--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy
|
|
Tue, Feb 7 2006
22:52:53
|
|
Mail sent by warmerdam@pobox.com
|
|
Return-Path |
<fwarmerdam@gmail.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
DomainKey-Signature |
a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X47F//bi3doX0C+TJbOYTz5aLcfuFQ9FyKgaiLZUuustFOEfRu09a/5GFcXgSZbsOtwtIEJZIHZeo4AePemdo2ha5NmjeATvQhnKSBeP8no+9xEFCR/lI8770ncdZ+GiznkWdQGNuHQ1kn9Mwpvc4V1/Ic7x5q0QKvFHajjxfY0=
|
Message-ID |
<931f8ea90602071352r1ff252f9g9157f30c9787d4fd@mail.gmail.com>
|
Date |
Tue, 7 Feb 2006 16:52:48 -0500
|
From |
Frank Warmerdam <warmerdam@pobox.com>
|
Sender |
fwarmerdam@gmail.com
|
To |
guest user via RT <grass-bugs@intevation.de>, grass5@grass.itc.it, paul-grass@stjohnspoint.co.uk, Frank Warmerdam <warmerdam@pobox.com>
|
Subject |
Re: [bug #4064] (grass) r.in.srtm: doesn't work, though it's a latlong WGS84 projection
|
In-Reply-To |
<20060207213922.GF31202@bartok.itc.it>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=ISO-8859-1
|
Content-Transfer-Encoding |
quoted-printable
|
Content-Disposition |
inline
|
References |
<20060207111450.386001005B7@lists.intevation.de> <20060207213922.GF31202@bartok.itc.it>
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
On 2/7/06, Markus Neteler <neteler@itc.it> wrote:
> Maciek,
> (cc Frank)
>
> I had the same problem with v.in.ogr today (using GDAL/OGR from CVS).
> Frank, did anything in GDAL/OGR recently change which makes fail the
> recognition of the GRASS location projection in r.in.gdal/v.in.ogr?
> This used to work.
Markus,
I can't think of anything.
Best regards,
--
---------------------------------------+-----------------------------------=
---
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.c=
om
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
|
|
Thu, Feb 9 2006
12:08:47
|
|
Mail sent by msieczka
|
|
Markus,
(CCing Frank)
I have built GDAL from CVS today to sort out the
https://intevation.de/rt/webrt?serial_num=4070 bug.
As a side effect, I don't need the to override projection check for r.in.gdal
inside r.in.srtm to make it work anymore. See how the projections "appear to
match" back now:
$ r.in.srtm input=/home/john/gis/dane/srtm2/N51E016 output=N51E016_v2_newgdal
Extracting /home/john/gis/dane/srtm2/N51E016...
Archive: /home/john/gis/dane/srtm2/N51E016.hgt.zip
inflating: N51E016.hgt
Converting input file to BIL...
Projection of input dataset and current location appear to match.
Proceeding with import...
100%
CREATING SUPPORT FILES FOR N51E016_v2_newgdal
r.in.gdal complete.
Color table for [N51E016_v2_newgdal] set to srtm
Done: generated map N51E016_v2_newgdal
(Note: Holes in the data can be closed with 'r.fillnulls' using splines)
I haven't changed anything in my Location setup since the bug report neither
altered Grass61 instalation. All I did was to replace my 2006-01-09 CVS GDAL
build with a fresh one.
Magic?
How is your v.in.ogr problem now Markus?
Maciek
|
|
Thu, Feb 16 2006
14:07:16
|
|
Status changed to resolved by msieczka
|
|
Thu, Feb 16 2006
14:07:16
|
|
Comments added by msieczka
|
|
mysteriously fixed itself
closing it
Maciek
|
|