I am using GPJ_osr_to_grass() and G_make_location().
Paul, can it be that GRASS does not understand a projection created
by GPJ_osr_to_grass()?
BTW, it seems that that GPJ_osr_to_grass() returns always 1 even if it fails
so I test if pointer is set or 0.
Radim
On 11/2/05, Luca Casagrande <luca.casagrande@gmail.com> wrote:
Hi to all!
I was testing the great plugin Radim has made, and i discovered that if i
create a NEW LOCATION from qgis and then print out the region info using
g.region -p inside GRASS, the datum is not recognized:
GRASS 6.0.1 (provadatum):~ > g.region -p
projection: 3 (Latitude-Longitude)
zone: 0
datum: ** unknown (default: WGS84) **
ellipsoid: a=6378388 es=0.00672267
north: 90N
south: 90S
west: 180W
east: 180E
The proj string used in qgis was: +proj=longlat +ellps=intl +pm=rome +no_defs
(Monte Mario Rome)
Am I missing something?
Thx
--
gtalk: luca.casagrande@gmail.com
skype : thedoktor78
msn: doktoreas@hush.com
Hello Radim/Luca
On Thu, 3 Nov 2005, Radim Blazek wrote:
I am using GPJ_osr_to_grass() and G_make_location().
Paul, can it be that GRASS does not understand a projection created
by GPJ_osr_to_grass()?
See comments at bottom.
BTW, it seems that that GPJ_osr_to_grass() returns always 1 even if it fails
so I test if pointer is set or 0.
Well technically it doesn't really fail---if it can't create a projected co-ordinate system, it creates an XY co-ordinate system instead. But this is still considered a valid co-ordinate system so it isn't a failure. Perhaps it could return a different positive value to indicate a different type of success though?
Radim
On 11/2/05, Luca Casagrande <luca.casagrande@gmail.com> wrote:
Hi to all!
I was testing the great plugin Radim has made, and i discovered that if i
create a NEW LOCATION from qgis and then print out the region info using
g.region -p inside GRASS, the datum is not recognized:
GRASS 6.0.1 (provadatum):~ > g.region -p
projection: 3 (Latitude-Longitude)
zone: 0
datum: ** unknown (default: WGS84) **
ellipsoid: a=6378388 es=0.00672267
north: 90N
south: 90S
west: 180W
east: 180E
The proj string used in qgis was: +proj=longlat +ellps=intl +pm=rome +no_defs
(Monte Mario Rome)
Am I missing something?
Well that proj string does not contain datum information. BUT... Radim says GPJ_osr_to_grass() is used and it takes a WKT string to describe the co-ordinate system, not a PROJ string. So is there any way you can show me the WKT string that was extracted from QGIS and passed to GPJ_osr_to_grass()? Probably there is something not right about the datum information there.
Paul
On 11/3/05, Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:
> BTW, it seems that that GPJ_osr_to_grass() returns always 1 even if it fails
> so I test if pointer is set or 0.
Well technically it doesn't really fail---if it can't create a projected
co-ordinate system, it creates an XY co-ordinate system instead. But this
is still considered a valid co-ordinate system so it isn't a failure.
Perhaps it could return a different positive value to indicate a different
type of success though?
Yes, that would be helpful.
>> The proj string used in qgis was: +proj=longlat +ellps=intl +pm=rome +no_defs
>> (Monte Mario Rome)
>> Am I missing something?
Well that proj string does not contain datum information. BUT... Radim says
GPJ_osr_to_grass() is used and it takes a WKT string to describe the
co-ordinate system, not a PROJ string. So is there any way you can show me
the WKT string that was extracted from QGIS and passed to
GPJ_osr_to_grass()? Probably there is something not right about the datum
information there.
WKT is printed on stderr if QGIS is compiled with debug.
Radim