[GRASS5] PROJ_INFO and pj_get_kv() and r.in.gdal

[Andreas Lange]

Hi Markus, hi all,

just a comment:

Markus Neteler wrote:
> 
> Hi all,
> 
> while working with/on r.in.gdal I have realized that three
> entries are not written to PROJ_INFO when creating a new
> location from a geocoded dataset. These entries are
> "name", "a" and "es". Example:
> 
> cat PROJ_INFO
> name: Transverse Mercator
> datum: rome40
> dx: -225.000000
> dy: -65.000000
> dz: 9.000000
> proj: tmerc
> ellps: international
> a: 6378388.0000000000
> es: 0.0067226700
> f: 297.0000000000
> lat_0: 0.0000000000
> lon_0: 9.0
> k_0: 0.9996000000
> x_0: 1500000.0000000000
> 
> If "name", "a" and "es" the r.proj, v.proj and s.proj fail because
> the function pj_get_kv() fails. This function is in
> src/libes/proj/get_proj.c
> 
> But...
> In my opinion there is no need to change r.in.gdal ( see wkt_to_grass()
> function there which defines the proj_info and proj_units struct,
> which is later used by G__make_location() ) because
> "name", "a" and "es"
> are redundant. The needed values are "proj" and "ellps".

I think that each location must be self-containted in the way that all
parameters should be numerically defined in the PROJ_INFO file. Else you
can get very confusing results if you transfer a location from one
installation to another installation with different etc/ellipse.table
and/or etc/datum.table files. This is possible because e. g. sometimes
there are different interpretations of ellipsoids and/or datums. 
IMHO the "name" and "ellps" strings are only for infomational purposes
and all functions should read out the values for calculation. But i
can't remember if the functions really behave that way. 
For the ellipsoid you need a and one of es or 1/f or b, but not all. But
it does not harm to have both es and 1/f in the file.

> 
> Question: Can we simplify pj_get_kv() or do we have to update
> wkt_to_grass() in src/raster/r.in.gdal/main.c

I would ask to fix r.in.gdal instead of messing up the working library
code. Or is the problem in the library code? Or in *.proj modules?

> 
> If you look into src/raster/r.in.gdal/main.c you see my additions
> to optionally re-project GCPs in a SAR image from lat/long to
> a user defined target projection. But since pj_get_kv() fails
> here due to the missing values, I had to hard-code lat/long as
> input "projection" (which might not be true for all SAR data).
> 
> Comments would be welcome. I have spend some time to update wkt_to_grass()
> but didn't manage (a bit too complex for me...)

I have no time currently, otherwise i would try to update this myself.

cu,

Andreas


-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net