FWIW, my reply with an attached image is waiting for approval.
I haven't done serious Windows coding since the NT days, but I found
this. Sounds like this will do it and then you can load the dump in
visual >studio and get the stack track, yes?
Anyone who actually uses windows + visualstu
I haven't done serious Windows coding since the NT days, but I found this.
Sounds like this will do it and then you can load the dump in visual studio
and get the stack track, yes?
Anyone who actually uses windows + visualstudio want to comment?
-kurt
http://cwspencer.co.uk/blog/2012/10/getting-
Yes, but (that I know) we don't get long stack traces in VS.
Exception thrown at 0x7FFF88F87788 in osmcoastline.exe: Microsoft C++
exception: gdalcpp::gdal_error at memory location 0x00CD6E33E090.
Unhandled exception at 0x7FFF88F87788 in osmcoastline.exe: Microsoft
C++ exception:
A stack trace would give others a chance to possibly spot what the crash is.
On Wed, Sep 14, 2016 at 11:31 AM, Joaquim Luis wrote:
> OK, clean & rebuilt (as I (thought) did before) and I can see the SQLite
> driver now.
> However, the osmcoastline still crashes. Unfortunately, it's too damn C++
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" wrote:
> Le mercredi 14 septembre 2016 20:50:04, James Ramm a écrit :
> > Yes, it is loading a different pythonThe path printed by sys.path is
Le mercredi 14 septembre 2016 20:50:04, James Ramm a écrit :
> Yes, it is loading a different pythonThe 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 vs
OK, clean & rebuilt (as I (thought) did before) and I can see the SQLite
driver now.
However, the osmcoastline still crashes. Unfortunately, it's too damn C++
for me to debugg.
Le mercredi 14 septembre 2016 19:43:22, Joaquim Luis a écrit :
Sorry, my bad. When I thought I was using gisinte
Le mercredi 14 septembre 2016 19:43:22, Joaquim Luis a écrit :
> Sorry, my bad. When I thought I was using gisinternals I was actually
> using my build. Gisinternals does show the SQLite driver.
>
> But one of my points still holds. If the Walker shows me that sqlite3.dll
> is a dependency than wh
Sorry, my bad. When I thought I was using gisinternals I was actually
using my build. Gisinternals does show the SQLite driver.
But one of my points still holds. If the Walker shows me that sqlite3.dll
is a dependency than why the SQLite driver is not available?
Hmm, several (weird) thing
Hmm, several (weird) things.
1. I'm using GnuWin ports for unix commands. And:
- this works
gdalinfo --formats | sort
- this not (output is empty)
ogfinfo --formats | sort
Same thing for 'grep'
2. To check I'm using gisinternals and same thing as my build.
ogri
ogrinfo --formats | grep -i lite
SQLite -vector- (rw+v): SQLite / Spatialite
On Wed, Sep 14, 2016 at 9:32 AM, Joaquim Luis wrote:
>
> Sorry Even that you are bombed with so many questions.
>
> I have (re)build GDAL with sqlite and can confirm with The (Dependency)
> Walker that the sqlite3.dll
Sorry Even that you are bombed with so many questions.
I have (re)build GDAL with sqlite and can confirm with The (Dependency)
Walker that the sqlite3.dll is a gdal.dll dependency. However,
gdalinfo --formats
...
Rasterlite -raster- (rws): Rasterlite
SAFE -raster- (rov): Sentinel-1 SAR
FYI,
degrib 2.05 from Dec 2015 is out here:
http://slosh.nws.noaa.gov/degrib2/download.php
-kurt
On Wed, Sep 14, 2016 at 7:16 AM, Even Rouault
wrote:
> Pierre,
>
> > A bug seems to be already opened for this error :
> > https://trac.osgeo.org/gdal/ticket/5768
>
> I had a look and just added s
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
Ok I will do that.
Thanks for your support
Pierre
Le 14 sept. 2016 17:15, "Even Rouault" a
écrit :
> Le mercredi 14 septembre 2016 17:09:18, Pierre Leman a écrit :
> > Hi Even,
> >
> >
> > Thanks for handling this problem so fast it's perfect.
> > Any information about the GDAL 2.2 release date
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.
Any tips on how to track this down/d
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.
Any tips on how to track this down/d
Thanks Even,
No I hadn't and was reading that MSDN page trying to figure out what to do
with that info.
The build is running now
Joaquim,
odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol
_vsnwprintf_s referenced in function StringCchPrintfW
gdal_w64.dll : fatal error L
Le mercredi 14 septembre 2016 17:09:18, Pierre Leman a écrit :
> Hi Even,
>
>
> Thanks for handling this problem so fast it's perfect.
> Any information about the GDAL 2.2 release date ?
Likely April/May next year. But you don't need to wait for that long. You can
compile from source (https://t
Le mercredi 14 septembre 2016 16:43:51, Andrew Bell a écrit :
> Hi,
>
> Each raster band has a function to fetch the type of the raster band
> (GetRasterDataType). This implies that various raster bands in a dataset
> can have differing data types. But as far as I can tell, when creating a
> dat
Joaquim,
> odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol
> _vsnwprintf_s referenced in function StringCchPrintfW
> gdal_w64.dll : fatal error LNK1120: 1 unresolved externals
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 14.0\VC\BIN\amd64\li
Hi Even,
Thanks for handling this problem so fast it's perfect.
Any information about the GDAL 2.2 release date ?
Pierre
2016-09-14 16:16 GMT+02:00 Even Rouault :
> Pierre,
>
> > A bug seems to be already opened for this error :
> > https://trac.osgeo.org/gdal/ticket/5768
>
> I had a look and
Hi,
I did this before with VS2015 but now I'm getting this weired linking
error.
link /nologo /dll /INCLUDE:OSRValidate
/INCLUDE:OPTGetProjectionMethods /INCLUDE:OGR_G_GetPointCount
/INCLUDE:OGRRegisterAll /INCLUDE:GDALSimpleImageWarp
/INCLUDE:GDALReprojectImage /INCLUDE:GD
Hi,
Each raster band has a function to fetch the type of the raster band
(GetRasterDataType). This implies that various raster bands in a dataset
can have differing data types. But as far as I can tell, when creating a
dataset and the associated raster bands, a single data type is specified
for
Pierre,
> A bug seems to be already opened for this error :
> https://trac.osgeo.org/gdal/ticket/5768
I had a look and just added support for that kind of products in GDAL trunk.
The issue was that Template 4.15 (
http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_temp4-15.shtml ) used for
band
Hello,
I'm trying to read a WAFS GRIB2 file using gdal in order to produce Geotiff
image displayable in OsgEarth (file WAFS_blended_2016090700f06.grib2 from
http://www.ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.2016090700/).
When i do, i get an error.
The gdalinfo command give the following in
Le mercredi 14 septembre 2016 09:02:07, Rutger a écrit :
> Then I guess i'm mistaken in thinking that Python would become a slowdown
> in such a case. It's been a while since i tested it. Anyway, thanks for
> your comments and efforts to improve the performance.
>
> I couldnt find any Conda channe
Then I guess i'm mistaken in thinking that Python would become a slowdown in
such a case. It's been a while since i tested it. Anyway, thanks for your
comments and efforts to improve the performance.
I couldnt find any Conda channels* which build from trunk, so i probably
have to wait a while befo
28 matches
Mail list logo
