[GRASS-dev] Re: PROJ csv files sync GDAL -> GRASS?
Markus Neteler
neteler at osgeo.org
Sat Apr 25 11:55:50 EDT 2009
Hi Paul
(adding list)
On Sun, Apr 19, 2009 at 9:21 PM, Paul Kelly
<paul-grass at stjohnspoint.co.uk> wrote:
> To answer your questions, GRASS does not use these files directly; they are
> used by the GDAL/OGR functions that convert between representations of
> co-ordinate systems (g.proj epsg=xxxx is a good example of where they are
> needed). In times past I don't think they were automatically installed with
> GDAL, or if they were there was some reason that I thought they might not
> always be accessible and so we should provide our own copy of the files with
> GRASS, to ensure that processing co-ordinate systems (generally with g.proj)
> always works correctly and reliably no matter if GDAL's data files were
> installed properly or not.
>
> As you have seen, this is done by calling the SetCSVFilenameHook() function
> before calling any GDAL functions that might need the tables, to tell GDAL
> to look in the GRASS etc/ogr_csv directory when it needs to find any .csv
> files. If we left this out GDAL would just find its own copies of the files
> itself and this should work equally well as long as they are installed with
> GDAL (usually in /usr/local/share/gdal).
>
> I think we can remove the files and the associated stuff you mentioned if
> these conditions are true:
> * The .csv files are always installed by default with GDAL
> * A GDAL installation is not considered a working installation if these
> files are not present
> If these are true then there is no longer any need for us to maintain our
> own "failsafe" copies of these files - if there ever was. But if it is the
> case on some platforms that GRASS runs on that these files might not be
> installed with GDAL and accessible to it, then it seems prudent to keep our
> own copies.
I have no idea if the conditions are true...
Since there are new additional CSV files which haven't been there before I
also don't know if to add those or not.
Markus
More information about the grass-dev
mailing list