[Proj] Virtual File Access

[Greg Troxel]

Frank Warmerdam <warmerdam at pobox.com> writes:

> Suffice it to say that there are other contexts in which deployments of
> PROJ.4 would have been significantly easier and problem free if I could
> just have the data files delivered directly in the .so file, and no need
> for special installation rules, etc.

I can see that.

> If you look at the TIFFClientOpen() call, it includes mechanisms to pass in
> what is essentially a virtual file access api.
>  http://www.libtiff.org/man/TIFFOpen.3t.html

I see - I had not realized that.

> To some extent my introduction of similar capabilities into GDAL, Shapelib,
> and now PROJ.4 mirrors what I saw in libtiff, libpng and libjpeg.

But that's about user data coming from/going to places other than files,
vs. loading issues for things like grid shift.

> I don't recall a concern from anyone else.  If you feel this is a serious
> issue you could request I write this up as an RFC and put it to a vote on
> the metacrs project steering committee.  I'm a bit surprised at the concern
> since in normal situations the introduction of this file indirection won't
> affect PROJ.4 library users.

No, it's certainly not serious enough for me to try to drag this through
a PSC.  My concern is simply an achitectural cleanliness objection, in
that extra mechanisms that arne't necessary are just extra complexity
and sources of potential bugs.  If I'm the only one who has a concern,
you should discount my opinion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.maptools.org/pipermail/proj/attachments/20130726/42bb4466/attachment-0001.pgp