[gdal-dev] VRT derived band pixel functions written in Python

Even Rouault even.rouault at spatialys.com
Wed Sep 14 12:04:36 PDT 2016 

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 <even.rouault at spatialys.com>
> 
> 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
> > > gdal-dev at lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com

More information about the gdal-dev mailing list