<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 26, 2013 at 6:00 AM, Greg Troxel <span dir="ltr"><<a href="mailto:gdt@ir.bbn.com" target="_blank">gdt@ir.bbn.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Frank Warmerdam <<a href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>> writes:<br>
<br>
Perhaps I am totally misunderstanding what you are doing. Is this<br>
about letting IO done on behalf of a user to read and write the user's<br>
data (not grid shift files, which are part of the library) to come from<br>
different places? Or is it about grid shift files, but the goal is<br>
because the user has them in RAM rather than on the filesystem? I had<br>
the impression that this was about a way to bundle the standard grid<br>
shift/etc. files into the library so that one could have just a single<br>
library file and not the ancilliary files, because managing mulitple<br>
files was somehow too hard.<br></blockquote><div><br></div><div>Greg,<br><br>It is about the grid shift and init files, not user input. PROJ.4 the library doesn't accept user input directly. <br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> Quite possibly there are many things broken about the environment I work<br>
> in, but running things on windows is certainly not one of them.<br>
<br>
</div>I'm glad to hear that :-).<br>
<br>
So what motivates you to add this code, rather than just installing the<br>
files in the right place? What is the essence of the problem?<br></blockquote><div class="im"> <br>The details involve aspects of security and methodology that I am discouraged from discussing in public without explicit permission by my employer. <br>
<br>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.<br>
<br>
> But the point I'd like to stress is that I believe it is generally a good<br>
> practice for low level libraries to provide a way to hook IO so that<br>
> applications can do a variety of things around file access. Libraries like<br>
> libtiff, GDAL, shapelib and libpng have done this for a long time. I'm<br>
> extending it to PROJ.4.<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I find that notion unusual and surprising. I was completely unaware of<br>
those libraries adding what feels like a custom VFS layer. I looked at<br>
<a href="http://www.libtiff.org/libtiff.html" target="_blank">http://www.libtiff.org/libtiff.html</a><br>
and found no mention of it.<br></blockquote><div><br>If you look at the TIFFClientOpen() call, it includes mechanisms to pass in what is essentially a virtual file access api.<br> <a href="http://www.libtiff.org/man/TIFFOpen.3t.html">http://www.libtiff.org/man/TIFFOpen.3t.html</a><br>
<br></div><div>To some extent my introduction of similar capabilities into GDAL, Shapelib, and now PROJ.4 mirrors what I saw in libtiff, libpng and libjpeg.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> I'm not clear exactly what information you are looking for. Normal<br>
> practice with applications installers using PROJ.4 would be to install the<br>
> files somewhere in the file system, and to call pj_set_searchpath() to<br>
> look in the directory in which things were installed from their application<br>
> initialization. The pj_set_searchpath() and pj_set_finder() were intended<br>
> to make finding the data files tractable in cases where applications didn't<br>
> mind writing them to disk.<br>
<br>
</div>Where I'm coming from is that I install proj via pkgsrc (and am the<br>
package maintainer). So it's "pkg_add proj-4.8.0.tar.gz" and then the<br>
library is in /usr/pkg/lib, and the files in /usr/pkg/share/proj (plus<br>
programs in /usr/pkg/bin, man pages...). I expect it's the same for all<br>
other packaging systems, modulo prefix. The path to the files is set<br>
via PROJ_LIB at build time to $(pkgdatadir). So I view it as a bug to<br>
have to set search paths. There is a single correct place for the grid<br>
files, and they are part of the package (or a depending package if one<br>
wants to split things).<br></blockquote><div><br></div><div>As a packager installer files is no problem for you. That's great. There are other deployment scenarios.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, I'd suggest that you consider putting this facility on a branch<br>
instead of in a release until there's both a useful extension<br>
(presumably reading files that were crunched into the library) and<br>
broader consensus that it's a good addition (on the benefit/complexity<br>
tradeoff).<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">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. <br>
<br></div><div class="gmail_extra">Best regards,<br>-- <br>---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>
light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush | Geospatial Software Developer<br>
</div></div>