Ah, that makes sense. I'll have to try the config option in the morning, but it sounds like that could be it
On 14 Sep 2016 8:06 p.m., "Even Rouault" <[email protected]> wrote: > Le mercredi 14 septembre 2016 20:50:04, James Ramm a écrit : > > Yes, it is loading a different python....The path printed by sys.path is > > different to if I open the command window and type: > > > > python > > > > >>> import sys > > >>> print(sys.path) > > > > Gdal and the python bindings were compiled with vs2015 and python 3.5, > and > > I can correctly import python in the 3.5 interpreter, yet somehow a > > different python DLL (2.7) is being loaded at runtime. > > Might be related to the default try order in > > const char* const apszPythonSO[] = { "python27.dll", > "python26.dll", > "python34.dll", > "python35.dll", > "python36.dll", > "python33.dll", > "python32.dll" }; > > First found, first served. > > Hum maybe we should try to match the version that issuing python on the > command line would start. We could potentially look at the PATH to see if > there's something like "bla:\pythonXX" and try the related .dll... Or more > costly, but more reliable, try issuing a 'python -c "import sys; > print(str(sys.version_info[0]) + str(sys.version_info[1]))"' command > > That's one of the downside of requiring no dependency at build time. > > Anyway you can override the default guess by setting the PYTHONSO config > option > to point to the desired python dll. > > By the way I've committed the doc in > https://trac.osgeo.org/gdal/changeset/35441 . Should be reflected online > in a > few hours. > > > > I am on a > > 'inherited' PC right now, so final thing to do is to ensure that the > > gdal_translate I am running is the one I compiled and there isn't another > > version lurking somewhere.... > > > > > > On 14 September 2016 at 16:50, Even Rouault <[email protected]> > > > > wrote: > > > Le mercredi 14 septembre 2016 17:24:53, jramm a écrit : > > > > Trying to run this using a function relying on scipy.ndimage... > > > > > > > > When running gdal_translate on the VRT, I get ImportError: No module > > > > > > named > > > > > > > scipy.ndimage > > > > This comes after successfully import numpy. scipy.ndimage will > happily > > > > import within the python interpreter. > > > > > > Works for me for both inline or offline functions. > > > > > > Are you sure GDAL loads the same python lib as the python version used > in > > > the > > > python interpreter ? (check the debug traces with CPL_DEBUG=ON) > > > > > > You can also add at the top of your script > > > > > > import sys > > > print(sys.path) > > > > > > and check if the output points to a location where your scipy package > can > > > be > > > found. > > > > > > > Any tips on how to track this down/debug? > > > > > > > The entire VRT file is as follows: > > > I guess this is not the entire VRT since it refers to an inline > > > definition of > > > the script but <PixelFunctionCode> has empty content. > > > > > > > <VRTDataset RasterXSize="111090" RasterYSize="259376"> > > > > > > > > <SRS>PROJCS["OSGB 1936 / British National Grid",GEOGCS["OSGB > > > > > > > > 1936",DATUM["OSGB_1936",SPHEROID["Airy > > > > 1830",6377563.396,299.3249646,AUTHORITY["EPSG","7001"]],TOWG > > > > > > S84[446.448,-12 > > > > > > > 5.157,542.06,0.15,0.247,0.842,-20.489],AUTHORITY["EPSG","627 > > > > > > 7"]],PRIMEM["Gr > > > > > > > eenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532 > > > > > > 925199433,AUTHO > > > > > > > RITY["EPSG","9122"]],AUTHORITY["EPSG","4277"]],PROJECTION[" > > > > > > Transverse_Merca > > > > > > > tor"],PARAMETER["latitude_of_origin",49],PARAMETER["central_ > > > > > > meridian",-2],P > > > > > > > ARAMETER["scale_factor",0.9996012717],PARAMETER["false_easti > > > > > > ng",400000],PAR > > > > > > > AMETER["false_northing",-100000],UNIT["metre",1,AUTHORITY[" > > > > > > EPSG","9001"]],A > > > > > > > XIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG", > > > > > > "27700"]]</SRS> > > > > > > > <GeoTransform>100180.0,5.0,0.0,1215730.0,0.0,-5.0</GeoTransform> > > > > <VRTRasterBand dataType="Float32" band="1" > > > > subClass="VRTDerivedRasterBand"> > > > > > > > > <SimpleSource> > > > > > > > > <SourceFilename > > > > > > > > relativeToVrt="0">F:\tif_data\large_sparse.tif</SourceFilename> > > > > > > > > <SourceProperties BlockXSize="256" BlockYSize="256" > > > > > > > > RasterXSize="111090" RasterYSize="259376"/> > > > > > > > > <OpenOptions> > > > > > > > > <OOI key="NUM_THREADS">4</OOI> > > > > <OOI key="SPARSE_OK">TRUE</OOI> > > > > > > > > </OpenOptions> > > > > > > > > </SimpleSource> > > > > <PixelFunctionType>extract_blobs</PixelFunctionType> > > > > <PixelFunctionLanguage>Python</PixelFunctionLanguage> > > > > <PixelFunctionCode> > > > > > > > > </PixelFunctionCode> > > > > > > > > <BufferRadius>5</BufferRadius> > > > > <PixelFunctionArguments nodata="0" count_threshold="5"/> > > > > > > > > </VRTRasterBand> > > > > > > > > </VRTDataset> > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > > > http://osgeo-org.1560.x6.nabble.com/gdal-dev-VRT-derived- > > > > > > band-pixel-functi > > > > > > > ons-written-in-Python-tp5285323p5285882.html Sent from the GDAL - > Dev > > > > mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > gdal-dev mailing list > > > > [email protected] > > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > -- > > > Spatialys - Geospatial professional services > > > http://www.spatialys.com > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
