[GRASS-dev] [GRASS GIS] #2744: r.import latlong bug

[Moritz Lennert]

On 17/09/15 12:56, GRASS GIS wrote:
> #2744: r.import latlong bug
> -------------------------+-------------------------
>   Reporter:  neteler      |      Owner:  grass-dev@…
>       Type:  defect       |     Status:  new
>   Priority:  normal       |  Milestone:  7.1.0
> Component:  Python       |    Version:  svn-trunk
>   Keywords:  r.import     |        CPU:  Unspecified
>   Platform:  Unspecified  |
> -------------------------+-------------------------
>   Would it be possible to catch this user error?
>
>   The user tried to import reprojected METOP-A data (Stereographic
>   projection) into a LatLong location (yeah, things happen):
>
>   {{{
>
>   r.import input=EUMETSAT/output/Soil
>   moisture/1/ascat_METOPA.20090401163331.12715_soil_moisture.tif
>   output=01_third
>   WARNING: Datum <unknown> not recognised by GRASS and no parameters found
>   WARNING: Datum <unknown> not recognised by GRASS and no parameters found
>   WARNING: Datum <unknown> not recognised by GRASS and no parameters found
>   Proceeding with import of 1 raster bands...
>   Importing raster map <01_third>...
>   Traceback (most recent call last):
>     File "/usr/local/grass-7.1.svn/scripts/r.import", line
>   333, in <module>
>       sys.exit(main())
>     File "/usr/local/grass-7.1.svn/scripts/r.import", line
>   258, in main
>       srcregion = grass.parse_key_val(tgtextents,
>   val_type=float, vsep=' ')
>     File
>   "/usr/local/grass-7.1.svn/etc/python/grass/script/utils.py",
>   line 223, in parse_key_val
>       result[k] = val_type(v)
>   ValueError: invalid literal for float(): 53:39:06.894826N
>   }}}
>
>   Probably the Python code which compares the two projections (input file
>   and location) failed?

No, IIUC, the problem seems to be that parse_key_val at line 258 expects 
boundary coordinates to be in float, but r.proj on delivers lat lon 
coordinates in a character string. Maybe you can try with just deleting 
the 'val_type=float' in the call parameters. I'm not sure this is 
absolutely necessary.

Moritz

>
>   Solution: It could be taken from r.pack where a similar test is done.