[Proj] Virtual File Access

[Greg Troxel]

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).
>
> typedef struct projFileAPI_t {
>     PAFile  (*FOpen)(projCtx ctx, const char *filename, const char *access);
>     size_t  (*FRead)(void *buffer, size_t size, size_t nmemb, PAFile file);
>     int     (*FSeek)(PAFile file, long offset, int whence);
>     long    (*FTell)(PAFile file);
>     void    (*FClose)(PAFile);
> } projFileAPI;
>
> I have reworked the the init file and grid shift file access goes through
> this
> and provided a default "stdio" based implementation.  These changes are
> now available in svn and I have yet to actually try it out beyond use of the
> stdio based implementation, but I'm interested in if anyone sees this as
> useful or has thoughts on how it ought to be done better.
>
> I'm also contemplating an optional build mechanism that will build grid
> shift files and init files right into the shared library for easy deployment
> though I'm not sure exactly how I'll do that yet.

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?

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.

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20130725/0c2747b5/attachment.sig>