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

[Paul Kelly]

On Thu, 21 Aug 2008, Paul Kelly wrote:

> 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.

I've committed some changes to SVN trunk now to allow g.proj to compile 
with reduced functionality if HAVE_OGR is not defined.

>> 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).

Been thinking about this a bit more and a more fundamental problem than
the ellipsoid and datum names is the lack of validation of the PROJ.4
parameters that would be possible. All g.proj could do would be to pass
the parameters into the PROJ_INFO and PROJ_UNITS unchanged and any
problems would only show up when they were used for reprojection. I'm not
sure how good the error checking is there as it assumes that the PROJ_INFO
and PROJ_UNITS are valid. g.setproj always creates a valid file because it 
composes the parameters from a set list. g.proj currently uses OGR to 
parse and validate the PROJ parameters before converting them to a 
PROJ_INFO and PROJ_UNITS. So I feel that modifying g.proj to read a set of 
PROJ parameters and pass them directly into PROJ_INFO and PROJ_UNITS would 
lose a piece of functionality, i.e. validating the co-ordinate system. And 
it still would be complicated. At the minute I think it needs a bit more 
thought or discussion.

Paul