[gdal-dev] VRT derived band pixel functions written in Python
James Ramm
jamessramm at gmail.com
Wed Sep 14 12:20:40 PDT 2016
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" <even.rouault at spatialys.com> 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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160914/679d78d1/attachment.html>
More information about the gdal-dev
mailing list