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

Markus Neteler neteler at itc.it
Tue Oct 9 08:06:51 EDT 2001


Hi Andreas,

even I prefer to have the wkt_to_grass() function fixed in
r.in.gdal (to also provide "name", "a" and "es" in the proj_info
struct).

I have tried to fix, but didn't manage. Any PROJ experts out
there?

This is one of the few things missing for the stable release.

Ciao

 Markus

On Tue, Oct 09, 2001 at 01:35:52PM +0200, Andreas Lange wrote:
> 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
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5



More information about the grass-dev mailing list