Details Ticket 4064


Comment | Reply | Take | Open


Serial Number 4064
Subject r.in.srtm: doesn't work, though it's a latlong WGS84 projection
Area grass6
Queue grass
Requestors werchowyna@epf.pl
Owner none
Status resolved
Last User Contact Thu Feb 9 12:08:47 2006 (3 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Thu Feb 16 14:07:16 2006 (3 yr ago)
Created Tue Feb 7 12:08:43 2006 (3 yr ago)

Transaction History Ticket 4064


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
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request