<div dir="ltr">I agree...could be slightly inelegant to figure out what version of python is used though...A system call to `where python` on windows would return the interpreter on the path, and you could replace the '.exe' with '.dll' (this is assuming python dll is always alongside the exe, but i think this is the case on all windows distributions), or Evens' suggest by calling python. <div>I cant think of an (easy) way to do it without a system call though. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 September 2016 at 14:56, Sean Gillies <span dir="ltr"><<a href="mailto:sean@mapbox.com" target="_blank">sean@mapbox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Even, James:<div><br></div><div>I suspect users will be find it very surprising if `which python` and the python interpreter used by VRT are not the same. Imagine starting python in an environment created by virtualenv or conda that contains extension modules like scikit-image, scikit-learn, &c. You import osgeo.gdal, open your super duper VRT with `gdal.Open()`, and get an error because your environment's extension modules aren't available in the VRT script. This could be tough to debug for a beginning to intermediate level Python programmer.</div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Sep 15, 2016 at 10:29 AM, James Ramm <span dir="ltr"><<a href="mailto:jamessramm@gmail.com" target="_blank">jamessramm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">excellent, working setting the PYTHONSO variable. Trying to match the version of python on the path would be smart, but it is probably 'good enough' to give PYTHONSO some prominence in the documentation - some kind of warning on how python is discovered perhaps?<div><div><div class="gmail_extra"><br><div class="gmail_quote">On 14 September 2016 at 20:20, James Ramm <span dir="ltr"><<a href="mailto:jamessramm@gmail.com" target="_blank">jamessramm@gmail.com</a>></span> wr<wbr>ote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Ah, that makes sense. I'll have to try the config option in the morning, but it sounds like that could be it</p><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 14 Sep 2016 8:06 p.m., "Even Rouault" <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le mercredi 14 septembre 2016 20:50:04, James Ramm a écrit :<br>> Yes, it is loading a different python....The path printed by sys.path is<br>> different to if I open the command window and type:<br>><br>> python<br>><br>> >>> import sys<br>> >>> print(sys.path)<br>><br>> Gdal and the python bindings were compiled with vs2015 and python 3.5, and<br>> I can correctly import python in the 3.5 interpreter, yet somehow a<br>> different python DLL (2.7) is being loaded at runtime.<br><br>Might be related to the default try order in<br><br> const char* const apszPythonSO[] = { "python27.dll",<br> "python26.dll",<br> "python34.dll",<br> "python35.dll",<br> "python36.dll",<br> "python33.dll",<br> "python32.dll" };<br><br>First found, first served.<br><br>Hum maybe we should try to match the version that issuing python on the<br>command line would start. We could potentially look at the PATH to see if<br>there's something like "bla:\pythonXX" and try the related .dll... Or more<br>costly, but more reliable, try issuing a 'python -c "import sys;<br>print(str(sys.version_info[0]) + str(sys.version_info[1]))"' command<br><br>That's one of the downside of requiring no dependency at build time.<br><br>Anyway you can override the default guess by setting the PYTHONSO config option<br>to point to the desired python dll.<br><br>By the way I've committed the doc in<br><a href="https://trac.osgeo.org/gdal/changeset/35441" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ch<wbr>angeset/35441</a> . Should be reflected online in a<br>few hours.<br><br></blockquote></div></div></div></div></blockquote></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 14 September 2016 at 20:20, James Ramm <span dir="ltr"><<a href="mailto:jamessramm@gmail.com" target="_blank">jamessramm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Ah, that makes sense. I'll have to try the config option in the morning, but it sounds like that could be it</p><div><div>
<div class="gmail_extra"><br><div class="gmail_quote">On 14 Sep 2016 8:06 p.m., "Even Rouault" <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le mercredi 14 septembre 2016 20:50:04, James Ramm a écrit :<br>
> Yes, it is loading a different python....The path printed by sys.path is<br>
> different to if I open the command window and type:<br>
><br>
> python<br>
><br>
> >>> import sys<br>
> >>> print(sys.path)<br>
><br>
> Gdal and the python bindings were compiled with vs2015 and python 3.5, and<br>
> I can correctly import python in the 3.5 interpreter, yet somehow a<br>
> different python DLL (2.7) is being loaded at runtime.<br>
<br>
Might be related to the default try order in<br>
<br>
const char* const apszPythonSO[] = { "python27.dll",<br>
"python26.dll",<br>
"python34.dll",<br>
"python35.dll",<br>
"python36.dll",<br>
"python33.dll",<br>
"python32.dll" };<br>
<br>
First found, first served.<br>
<br>
Hum maybe we should try to match the version that issuing python on the<br>
command line would start. We could potentially look at the PATH to see if<br>
there's something like "bla:\pythonXX" and try the related .dll... Or more<br>
costly, but more reliable, try issuing a 'python -c "import sys;<br>
print(str(sys.version_info[0]) + str(sys.version_info[1]))"' command<br>
<br>
That's one of the downside of requiring no dependency at build time.<br>
<br>
Anyway you can override the default guess by setting the PYTHONSO config option<br>
to point to the desired python dll.<br>
<br>
By the way I've committed the doc in<br>
<a href="https://trac.osgeo.org/gdal/changeset/35441" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ch<wbr>angeset/35441</a> . Should be reflected online in a<br>
few hours.<br>
<br>
<br>
> I am on a<br>
> 'inherited' PC right now, so final thing to do is to ensure that the<br>
> gdal_translate I am running is the one I compiled and there isn't another<br>
> version lurking somewhere....<br>
><br>
><br>
> On 14 September 2016 at 16:50, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>><br>
><br>
> wrote:<br>
> > Le mercredi 14 septembre 2016 17:24:53, jramm a écrit :<br>
> > > Trying to run this using a function relying on scipy.ndimage...<br>
> > ><br>
> > > When running gdal_translate on the VRT, I get ImportError: No module<br>
> ><br>
> > named<br>
> ><br>
> > > scipy.ndimage<br>
> > > This comes after successfully import numpy. scipy.ndimage will happily<br>
> > > import within the python interpreter.<br>
> ><br>
> > Works for me for both inline or offline functions.<br>
> ><br>
> > Are you sure GDAL loads the same python lib as the python version used in<br>
> > the<br>
> > python interpreter ? (check the debug traces with CPL_DEBUG=ON)<br>
> ><br>
> > You can also add at the top of your script<br>
> ><br>
> > import sys<br>
> > print(sys.path)<br>
> ><br>
> > and check if the output points to a location where your scipy package can<br>
> > be<br>
> > found.<br>
> ><br>
> > > Any tips on how to track this down/debug?<br>
> ><br>
> > > The entire VRT file is as follows:<br>
> > I guess this is not the entire VRT since it refers to an inline<br>
> > definition of<br>
> > the script but <PixelFunctionCode> has empty content.<br>
> ><br>
> > > <VRTDataset RasterXSize="111090" RasterYSize="259376"><br>
> > ><br>
> > > <SRS>PROJCS["OSGB 1936 / British National Grid",GEOGCS["OSGB<br>
> > ><br>
> > > 1936",DATUM["OSGB_1936",SPHERO<wbr>ID["Airy<br>
> > > 1830",6377563.396,299.3249646,<wbr>AUTHORITY["EPSG","7001"]],TOWG<br>
> ><br>
> > S84[446.448,-12<br>
> ><br>
> > > 5.157,542.06,0.15,0.247,0.842,<wbr>-20.489],AUTHORITY["EPSG","627<br>
> ><br>
> > 7"]],PRIMEM["Gr<br>
> ><br>
> > > eenwich",0,AUTHORITY["EPSG","8<wbr>901"]],UNIT["degree",0.0174532<br>
> ><br>
> > 925199433,AUTHO<br>
> ><br>
> > > RITY["EPSG","9122"]],AUTHORITY<wbr>["EPSG","4277"]],PROJECTION["<br>
> ><br>
> > Transverse_Merca<br>
> ><br>
> > > tor"],PARAMETER["latitude_of_o<wbr>rigin",49],PARAMETER["central_<br>
> ><br>
> > meridian",-2],P<br>
> ><br>
> > > ARAMETER["scale_factor",0.9996<wbr>012717],PARAMETER["false_easti<br>
> ><br>
> > ng",400000],PAR<br>
> ><br>
> > > AMETER["false_northing",-10000<wbr>0],UNIT["metre",1,AUTHORITY["<br>
> ><br>
> > EPSG","9001"]],A<br>
> ><br>
> > > XIS["Easting",EAST],AXIS["Nort<wbr>hing",NORTH],AUTHORITY["EPSG",<br>
> ><br>
> > "27700"]]</SRS><br>
> ><br>
> > > <GeoTransform>100180.0,5.0,0.0<wbr>,1215730.0,0.0,-5.0</GeoTransf<wbr>orm><br>
> > > <VRTRasterBand dataType="Float32" band="1"<br>
> > > subClass="VRTDerivedRasterBand<wbr>"><br>
> > ><br>
> > > <SimpleSource><br>
> > ><br>
> > > <SourceFilename<br>
> > ><br>
> > > relativeToVrt="0">F:\tif_data\<wbr>large_sparse.tif</SourceFilena<wbr>me><br>
> > ><br>
> > > <SourceProperties BlockXSize="256" BlockYSize="256"<br>
> > ><br>
> > > RasterXSize="111090" RasterYSize="259376"/><br>
> > ><br>
> > > <OpenOptions><br>
> > ><br>
> > > <OOI key="NUM_THREADS">4</OOI><br>
> > > <OOI key="SPARSE_OK">TRUE</OOI><br>
> > ><br>
> > > </OpenOptions><br>
> > ><br>
> > > </SimpleSource><br>
> > > <PixelFunctionType>extract_bl<wbr>obs</PixelFunctionType><br>
> > > <PixelFunctionLanguage>Python<wbr></PixelFunctionLanguage><br>
> > > <PixelFunctionCode><br>
> > ><br>
> > > </PixelFunctionCode><br>
> > ><br>
> > > <BufferRadius>5</BufferRadius<wbr>><br>
> > > <PixelFunctionArguments nodata="0" count_threshold="5"/><br>
> > ><br>
> > > </VRTRasterBand><br>
> > ><br>
> > > </VRTDataset><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > > View this message in context:<br>
> > > <a href="http://osgeo-org.1560.x6.nabble.com/gdal-dev-VRT-derived-" rel="noreferrer" target="_blank">http://osgeo-org.1560.x6.nabbl<wbr>e.com/gdal-dev-VRT-derived-</a><br>
> ><br>
> > band-pixel-functi<br>
> ><br>
> > > ons-written-in-Python-tp528532<wbr>3p5285882.html Sent from the GDAL - Dev<br>
> > > mailing list archive at Nabble.com.<br>
> > > ______________________________<wbr>_________________<br>
> > > gdal-dev mailing list<br>
> > > <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> > > <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman<wbr>/listinfo/gdal-dev</a><br>
> ><br>
> > --<br>
> > Spatialys - Geospatial professional services<br>
> > <a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div></div>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman<wbr>/listinfo/gdal-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><span class="HOEnZb"><font color="#888888"><div data-smartmail="gmail_signature"><div dir="ltr">Sean Gillies</div></div>
</font></span></div>
</blockquote></div><br></div>