r.external - was: Re: [GRASS-dev] some questions about future development

[Paul Kelly]

On Thu, 21 Aug 2008, Glynn Clements wrote:

>
> Paul Kelly wrote:
>
>>> AFAICT, the only "core" GDAL dependencies are the OSR stuff in
>>> lib/proj and g.proj, and the vector library's support for v.external.
>>> In which case, it really ought to be possible to get a usable version
>>> of GRASS with no GDAL dependency in any of the libraries or core
>>> modules (e.g. g.proj, g.region).
>>
>> It used to be possible to compile g.proj without GDAL support, and use it
>> only for reporting on the projection information and verifying datum
>> information, but I removed all the conditional stuff for that when GDAL
>> became a non-optional dependency. Could be put back in I suppose.
>
> That would be useful.

I'll get on to it but it won't be before the end of the weekend I'd say.

> Also, is there any fundamental obstacle to being able to set the
> projection information using PROJ parameters without going via OSR?
> Given that GRASS uses PROJ for the actual projection, it shouldn't
> actually need anything other than PROJ parameters. g.setproj doesn't
> use any lib/proj functions except GPJ_ask_datum_params() (which no
> longer exists).

The main issue is the short ellipsoid names, which can be quite different. 
I believe the GRASS ellipse.table pre-dates the integration of PROJ into 
GRASS in the early 1990s. OSR understands the PROJ ellipsoid names, so at 
present it is used to get the underlying ellipsoid dimensions, which are 
then matched against the GRASS ellipse.table to find the corresponding 
GRASS ellipsoid name. I suppose we could add a list of GRASS ellipsoid 
names and PROJ equivalents somewhere as a way around this.

Datum names would also be a problem, but a very small one as PROJ only 
supports 10 named datums. One of these is not in GRASS and could be added, 
5 of the others have exactly the same short name, and the other 4 differ 
only in the case of the letters (PROJ- upper case, GRASS- lower case).

So if an additional field was added to ellipse.table with a 
PROJ-compatible name, datum GGRS87 was added to GRASS, and PROJ datum 
names were converted to lower case before being imported into GRASS, it 
should be possible to write an OSR-independent function in 
lib/proj/convert.c to convert from PROJ to GRASS format (the 
OSR-dependent parts of lib/proj are already conditionalised on HAVE_OGR; 
there would be no problem in adding more functions outside of that).

Paul