[GRASS5] PROJ_INFO and pj_get_kv() and r.in.gdal
neteler at itc.it
Tue Oct 9 08:06:51 EDT 2001
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
I have tried to fix, but didn't manage. Any PROJ experts out
This is one of the few things missing for the stable release.
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.
> 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
More information about the grass-dev