<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 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">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/<wbr>changeset/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">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",<wbr>SPHEROID["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","<wbr>8901"]],UNIT["degree",0.<wbr>0174532<br>
> ><br>
> > 925199433,AUTHO<br>
> ><br>
> > > RITY["EPSG","9122"]],<wbr>AUTHORITY["EPSG","4277"]],<wbr>PROJECTION["<br>
> ><br>
> > Transverse_Merca<br>
> ><br>
> > > tor"],PARAMETER["latitude_of_<wbr>origin",49],PARAMETER["<wbr>central_<br>
> ><br>
> > meridian",-2],P<br>
> ><br>
> > > ARAMETER["scale_factor",0.<wbr>9996012717],PARAMETER["false_<wbr>easti<br>
> ><br>
> > ng",400000],PAR<br>
> ><br>
> > > AMETER["false_northing",-<wbr>100000],UNIT["metre",1,<wbr>AUTHORITY["<br>
> ><br>
> > EPSG","9001"]],A<br>
> ><br>
> > > XIS["Easting",EAST],AXIS["<wbr>Northing",NORTH],AUTHORITY["<wbr>EPSG",<br>
> ><br>
> > "27700"]]</SRS><br>
> ><br>
> > > <GeoTransform>100180.0,5.0,0.<wbr>0,1215730.0,0.0,-5.0</<wbr>GeoTransform><br>
> > > <VRTRasterBand dataType="Float32" band="1"<br>
> > > subClass="<wbr>VRTDerivedRasterBand"><br>
> > ><br>
> > >     <SimpleSource><br>
> > ><br>
> > >       <SourceFilename<br>
> > ><br>
> > > relativeToVrt="0">F:\tif_data\<wbr>large_sparse.tif</<wbr>SourceFilename><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_<wbr>blobs</PixelFunctionType><br>
> > >     <PixelFunctionLanguage>Python<<wbr>/PixelFunctionLanguage><br>
> > >     <PixelFunctionCode><br>
> > ><br>
> > >       </PixelFunctionCode><br>
> > ><br>
> > >     <BufferRadius>5</BufferRadius><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.<wbr>nabble.com/gdal-dev-VRT-<wbr>derived-</a><br>
> ><br>
> > band-pixel-functi<br>
> ><br>
> > > ons-written-in-Python-<wbr>tp5285323p5285882.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">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/<wbr>mailman/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>