[Proj] Virtual File Access

Frank Warmerdam warmerdam at pobox.com
Thu Jul 25 17:36:27 PDT 2013


On Thu, Jul 25, 2013 at 4:55 PM, Greg Troxel <gdt at ir.bbn.com> wrote:

>
> Frank Warmerdam <warmerdam at pobox.com> writes:
>
> > Folks,
> >
> > To smooth out deployment of PROJ.4 at my workplace, I have made some
> > changes so that all file access can go through a virtual layer. This
> > virtual file
> > api looks like the following, and is associated with a "context"
> (projCtx).
> ...
>
> This strikes me as adding extra complexity into proj and implementing
> features that really belong as a separate package.  I'm guessing that
> there is something broken about the environment that you are working in
> that installing a package to a standard path that has a binary or
> library and data files is just too awkward.  Is that a windows-only
> issue?
>

Greg,

Quite possibly there are many things broken about the environment I work
in, but running things on windows is certainly not one of them.


> If this sort of thing really is needed, it seems better to have a
> package that supports building and accessing files from within a library
> as a function that can be hooked into any library's build.   PROJ.4 is
> not special in needing to read data files.


It might possibly be nice to have a generic cross platform way for software
to hook stdio so as to redirect file access, but that does not seem to be
part of the standard C libraries.  I'm sure there are libraries which could
offer an appropriate indirection api, but I'm hesitant to add dependencies
to PROJ.4 without a large need.

But the point I'd like to stress is that I believe it is generally a good
practice for low level libraries to provide a way to hook IO so that
applications can do a variety of things around file access.  Libraries like
libtiff, GDAL, shapelib and libpng have done this for a long time.  I'm
extending it to PROJ.4.


> Has anyone else had this problem?  On what OS?

What do people do about window installers, in terms of interacting with
> (surely there must be) the native packaging system?
>

I'm not clear exactly what information you are looking for.  Normal
practice with applications installers using PROJ.4 would be to install the
files somewhere in the file system, and to call pj_set_searchpath()  to
look in the directory in which things were installed from their application
initialization.  The pj_set_searchpath() and pj_set_finder() were intended
to make finding the data files tractable in cases where applications didn't
mind writing them to disk.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20130725/e5b9e160/attachment.html>


More information about the Proj mailing list