Hi,
because of conflicts between GRASS and libgrass when used together
(the same names of functions), I have tried to rewrite
GRASS driver in GDAL to use GRASS 5.7 shared libs.
I used GPJ_grass_to_wkt to get projection informations, unfortunately
libgrass_gproj is linked to libgdal which makes circular reference.
The same problem will be with potential GRASS vector driver in OGR.
What is the correct solution?
Radim
Radim Blazek wrote:
because of conflicts between GRASS and libgrass when used together
(the same names of functions), I have tried to rewrite
GRASS driver in GDAL to use GRASS 5.7 shared libs.
I used GPJ_grass_to_wkt to get projection informations, unfortunately
libgrass_gproj is linked to libgdal which makes circular reference.
The same problem will be with potential GRASS vector driver in OGR.What is the correct solution?
Probably to remove the GDAL stuff from libgrass_gproj. 5.0/5.3 worked
OK without it.
Given the nature of GDAL (C++, many dependencies, possible dependency
upon GRASS), the less that depends upon it, the better.
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, 21 May 2004, Glynn Clements wrote:
Radim Blazek wrote:
because of conflicts between GRASS and libgrass when used together
(the same names of functions), I have tried to rewrite
GRASS driver in GDAL to use GRASS 5.7 shared libs.
I used GPJ_grass_to_wkt to get projection informations, unfortunately
libgrass_gproj is linked to libgdal which makes circular reference.
The same problem will be with potential GRASS vector driver in OGR.What is the correct solution?
Probably to remove the GDAL stuff from libgrass_gproj. 5.0/5.3 worked
OK without it.
But then GPJ_grass_to_wkt() won't work as it relies on the co-ordinate system conversion functions in OGR/GDAL. It uses a lot of them and they are far too complicated to make a copy of them all and include in GRASS.
It is conceivably a good idea that the modules that use libgrass_gproj only for re-projecting don't have to rely on being linked to GDAL when they don't use any of it, but that is not relevant here as Radim specifically wants to use one of the libgrass_gproj functions that relies on GDAL/OGR.
Given the nature of GDAL (C++, many dependencies, possible dependency
upon GRASS), the less that depends upon it, the better.
Yes ideally just import/export modules but then that is kind of what we're talking about here?
Hi again
>> What is the correct solution?
>
> Probably to remove the GDAL stuff from libgrass_gproj. 5.0/5.3 worked
> OK without it.But then GPJ_grass_to_wkt() won't work as it relies on the co-ordinate
system conversion functions in OGR/GDAL. It uses a lot of them and they
are far too complicated to make a copy of them all and include in GRASS.It is conceivably a good idea that the modules that use libgrass_gproj
only for re-projecting don't have to rely on being linked to GDAL when
they don't use any of it, but that is not relevant here as Radim
specifically wants to use one of the libgrass_gproj functions that
relies on GDAL/OGR.> Given the nature of GDAL (C++, many dependencies, possible dependency
> upon GRASS), the less that depends upon it, the better.Yes ideally just import/export modules but then that is kind of what
we're talking about here?
As I understand you, the stuff in convert.c isn't used by GRASS modules,
so why not move it into Radim's GDAL code?
Then it's not a problem anymore.
If it is used by some GRASS modules it should be possible to move the
functions in convert.c to a libgrass_gproj_conv, so libgrass_gproj is
"clean" of GDAL stuff, but GRASS modules can still use both.
Just my 3.141592 cents.
Ciao,
Jens