Re: [gdal-dev] SQLite driver hit and miss with spatial index

2017-04-06 Thread jratike80 
Frederik Ramm wrote
> Hi,
> 
>while what I wrote in the previous post is still interesting and a
> bit strange, I have meanwhile upgraded to GDAL 2 packages from the
> ubuntugis-unstable repository for Xenial, and now the behaviour is as I
> would expect it: The ogr2ogr -spat command *with* indexes takes
> practically no time (0.05 seconds), and the -spat command *without*
> index takes about 40 seconds as before.
> 
> Sorry for the noise then.
> 
> Bye
> Frederik

Hi Frederik,

Did you also notice that your no-index.sqlite database is not a SpatiaLite
database but a SQLite db with FDO geometries? You can check it with ogrinfo:

ogrinfo no-index.sqlite -sql "select CheckSpatialMetadata()"

The return values are explained in the Spatilite SQL reference
http://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html

I do not know how FDO vs. Spatialite speeds differ in non-indexed searches
but I guess you prefer making controlled tests by change only one thing at a
time.

-Jukka Rahkonen-




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/gdal-dev-SQLite-driver-hit-and-miss-with-spatial-index-tp5316090p5316200.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver hit and miss with spatial index

2017-04-06 Thread Frederik Ramm 
Hi,

   while what I wrote in the previous post is still interesting and a
bit strange, I have meanwhile upgraded to GDAL 2 packages from the
ubuntugis-unstable repository for Xenial, and now the behaviour is as I
would expect it: The ogr2ogr -spat command *with* indexes takes
practically no time (0.05 seconds), and the -spat command *without*
index takes about 40 seconds as before.

Sorry for the noise then.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver?

2016-09-16 Thread Joaquim Luis 

Yes, it had a small image attached.
But never mind, I ended up finding that the crash resulted from the fact  
that some other gdal.dll without sqlite driver managed to get in the way.
The bad new was that, once this solved, I got another crash latter but  
there is nothing in it that I can relate to gdal, so issue is closed here.

Thanks to people that tried to help.

Joaquim


On 2016-09-14 6:55 PM, Joaquim Luis wrote:

FWIW, my reply with an attached image is waiting for approval.




Joaquim, I checked in the mailman backend and I don't see a message  
being held.  But for sure always always when using mailing lists never  
try attaching things, for example if you need to include an image just  
use an external service like http://pasteboard.co/ and include the url  
to that image, in your response.


-jeff



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver?

2016-09-16 Thread Jeff McKenna 

On 2016-09-14 6:55 PM, Joaquim Luis wrote:

FWIW, my reply with an attached image is waiting for approval.




Joaquim, I checked in the mailman backend and I don't see a message 
being held.  But for sure always always when using mailing lists never 
try attaching things, for example if you need to include an image just 
use an external service like http://pasteboard.co/ and include the url 
to that image, in your response.


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/





___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver?

2016-09-14 Thread Joaquim Luis 

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 + visualstudio want to comment?

-kurt

http://cwspencer.co.uk/blog/2012/10/getting-useful-c-exception-information-from-visual-studio/

Which down at the bottom says:

You can get WER to generate full crash dumps when your program crashes  
and you don’t have a debugger >attached by creating the DWORD registry  
keyHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error  
Reporting>\LocalDumps\DumpType and setting it to 1 (for mini dumps) or 2  
(for full dumps). This will create a dump file >in  
%LOCALAPPDATA%\CrashDumps when your program crashes which you can import  
into Visual Studio. This is >particularly useful when you are testing on  
someone else’s machine where you can’t debug directly.


On Wed, Sep 14, 2016 at 2:02 PM, Joaquim Luis  wrote:

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: gdalcpp::gdal_error at memory location  
>>0x00CD6E33E090.

The program '[37264] osmcoastline.exe' has exited with code 0 (0x0).

I can see why it crashes but why it happens. To start with the code is  
completely mysterious for me


class Driver : private init_library {

gdal_driver_type* m_driver;

public:

Driver(const std::string& driver_name) :
init_library(),
#if GDAL_VERSION_MAJOR >= 2
m_driver(GetGDALDriverManager()->GetDriverByName(driver_name.c_str())) {
#else
m_driver(OGRSFDriverRegistrar::GetRegistrar()->GetDriverByName(driver_name.c_str()))  
{

#endif
if (!m_driver) {
throw gdal_error(std::string("unknown driver: '") + driver_name + "'",  
OGRERR_NONE, driver_name);

}
}

m_driver is defined as a function, which is than tested to be NULL (and  
it is) and a crash follows.



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++ 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 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?


You mentionned that you "(re)build" GDAL with sqlite, so I assume  
you added it
after a first build. So I suspect that some files didn't get  
recompiled. The

safest way if not already done is to clean and rebuild.

Otherwise, mostly for a quick check, you may just 'touch'
ogr/ogrsf_frmts/generic/ogrregisterall.cpp but you'll probably miss  
a few files
that will benefit from sqlite being now available. So the clean &  
rebuild path

is the safest ultimately.




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.

  ogrinfo --formats  shows no SQLite driver

3. The program I'm trying to build/run crashes at this line

   https://github.com/osmcode/osmcoastline/blob/master/include/gdalcpp.hp
   p#L132 (no idea why it crashes) apparently because it doesn't  
find the


SQLite driver (driver_name == 'SQLite')


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 is a gdal.dll  
dependency.

However,

gdalinfo --formats

...

 Rasterlite -raster- (rws): Rasterlite
 SAFE -raster- (rov): Sentinel-1 SAR SAFE Product
 SAR_CEOS -raster- (rov): CEOS SAR Image
 SDTS -raster- (rov): SDTS Raster
 SENTINEL2 -raster- (rovs): Sentinel 2
 SGI -raster- (rw+): SGI Image File Format 1.0
 SRTMHGT -raster- (rwv): SRTMHGT File Format
 TIL -raster- (rov): EarthWatch .TIL

...

does not show the SQLite driver and indeed a program that I'm  
building
that needs to link with GDAL (osmcoastline) crashes when it  
doesn't

find >>>that driver.

?

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



http://schwehr.org

Re: [gdal-dev] SQLite driver?

2016-09-14 Thread Kurt Schwehr 
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-useful-c-exception-information-from-visual-studio/

Which down at the bottom says:

You can get WER to generate full crash dumps

when
your program crashes and you don’t have a debugger attached by creating the
DWORD registry keyHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows
Error Reporting\LocalDumps\DumpType and setting it to 1 (for mini dumps) or
2 (for full dumps). This will create a dump file in
%LOCALAPPDATA%\CrashDumps when your program crashes which you can import
into Visual Studio. This is particularly useful when you are testing on
someone else’s machine where you can’t debug directly.

On Wed, Sep 14, 2016 at 2:02 PM, Joaquim Luis  wrote:

> 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: gdalcpp::gdal_error at memory location 0x00CD6E33E090.
> The program '[37264] osmcoastline.exe' has exited with code 0 (0x0).
>
>
> I can see why it crashes but why it happens. To start with the code is
> completely mysterious for me
>
> class Driver : private init_library {
>
> gdal_driver_type* m_driver;
>
> public:
>
> Driver(const std::string& driver_name) :
> init_library(),
> #if GDAL_VERSION_MAJOR >= 2
> m_driver(GetGDALDriverManager()->GetDriverByName(driver_name.c_str())) {
> #else
> m_driver(OGRSFDriverRegistrar::GetRegistrar()->
> GetDriverByName(driver_name.c_str())) {
> #endif
> if (!m_driver) {
> throw gdal_error(std::string("unknown driver: '") + driver_name + "'",
> OGRERR_NONE, driver_name);
> }
> }
>
> m_driver is defined as a function, which is than tested to be NULL (and it
> is) and a crash follows.
>
>
> 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++
>> 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 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?

>>>
>>> You mentionned that you "(re)build" GDAL with sqlite, so I assume you
>>> added it
>>> after a first build. So I suspect that some files didn't get recompiled.
>>> The
>>> safest way if not already done is to clean and rebuild.
>>>
>>> Otherwise, mostly for a quick check, you may just 'touch'
>>> ogr/ogrsf_frmts/generic/ogrregisterall.cpp but you'll probably miss a
>>> few files
>>> that will benefit from sqlite being now available. So the clean &
>>> rebuild path
>>> is the safest ultimately.
>>>
>>>
 > 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.
 >
 >   ogrinfo --formats  shows no SQLite driver
 >
 > 3. The program I'm trying to build/run crashes at this line
 >
 >https://github.com/osmcode/osmcoastline/blob/master/
 include/gdalcpp.hp
 >p#L132 (no idea why it crashes) apparently because it doesn't find
 the
 >
 > SQLite driver (driver_name == 'SQLite')
 >
 >> 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 is a gdal.dll dependency.
 >>> However,
 >>>
 >>> gdalinfo --formats
 >>>
 >>> ...
 >>>
 >>>  Rasterlite -raster- (rws): Rasterlite
 >>>  SAFE -raster- (rov): Sentinel-1 SAR SAFE Product
 >>>  SAR_CEOS -raster- (rov): CEOS SAR Image
 >>>  SDTS -raster- (rov): SDTS Raster
 >>>  SENTINEL2 -raster- (rovs): Sentinel 2
 >>>  SGI -raster- (rw+): SGI Image File Format 1.0

Re: [gdal-dev] SQLite driver?

2016-09-14 Thread Joaquim Luis 

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: gdalcpp::gdal_error at memory location 0x00CD6E33E090.

The program '[37264] osmcoastline.exe' has exited with code 0 (0x0).


I can see why it crashes but why it happens. To start with the code is  
completely mysterious for me


class Driver : private init_library {

gdal_driver_type* m_driver;

public:

Driver(const std::string& driver_name) :
init_library(),
#if GDAL_VERSION_MAJOR >= 2
m_driver(GetGDALDriverManager()->GetDriverByName(driver_name.c_str())) {
#else
m_driver(OGRSFDriverRegistrar::GetRegistrar()->GetDriverByName(driver_name.c_str()))  
{

#endif
if (!m_driver) {
throw gdal_error(std::string("unknown driver: '") + driver_name + "'",  
OGRERR_NONE, driver_name);

}
}

m_driver is defined as a function, which is than tested to be NULL (and it  
is) and a crash follows.



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++ 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 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?


You mentionned that you "(re)build" GDAL with sqlite, so I assume you  
added it
after a first build. So I suspect that some files didn't get  
recompiled. The

safest way if not already done is to clean and rebuild.

Otherwise, mostly for a quick check, you may just 'touch'
ogr/ogrsf_frmts/generic/ogrregisterall.cpp but you'll probably miss a  
few files
that will benefit from sqlite being now available. So the clean &  
rebuild path

is the safest ultimately.




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.

  ogrinfo --formats  shows no SQLite driver

3. The program I'm trying to build/run crashes at this line

   https://github.com/osmcode/osmcoastline/blob/master/include/gdalcpp.hp
   p#L132 (no idea why it crashes) apparently because it doesn't  
find the


SQLite driver (driver_name == 'SQLite')


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 is a gdal.dll dependency.
However,

gdalinfo --formats

...

 Rasterlite -raster- (rws): Rasterlite
 SAFE -raster- (rov): Sentinel-1 SAR SAFE Product
 SAR_CEOS -raster- (rov): CEOS SAR Image
 SDTS -raster- (rov): SDTS Raster
 SENTINEL2 -raster- (rovs): Sentinel 2
 SGI -raster- (rw+): SGI Image File Format 1.0
 SRTMHGT -raster- (rwv): SRTMHGT File Format
 TIL -raster- (rov): EarthWatch .TIL

...

does not show the SQLite driver and indeed a program that I'm  
building

that needs to link with GDAL (osmcoastline) crashes when it doesn't
find >>>that driver.

?

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



http://schwehr.org

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev





http://schwehr.org___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver?

2016-09-14 Thread Kurt Schwehr 
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++
> 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 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?
>>>
>>
>> You mentionned that you "(re)build" GDAL with sqlite, so I assume you
>> added it
>> after a first build. So I suspect that some files didn't get recompiled.
>> The
>> safest way if not already done is to clean and rebuild.
>>
>> Otherwise, mostly for a quick check, you may just 'touch'
>> ogr/ogrsf_frmts/generic/ogrregisterall.cpp but you'll probably miss a
>> few files
>> that will benefit from sqlite being now available. So the clean & rebuild
>> path
>> is the safest ultimately.
>>
>>
>>> > 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.
>>> >
>>> >   ogrinfo --formats  shows no SQLite driver
>>> >
>>> > 3. The program I'm trying to build/run crashes at this line
>>> >
>>> >https://github.com/osmcode/osmcoastline/blob/master/include/
>>> gdalcpp.hp
>>> >p#L132 (no idea why it crashes) apparently because it doesn't find
>>> the
>>> >
>>> > SQLite driver (driver_name == 'SQLite')
>>> >
>>> >> 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 is a gdal.dll dependency.
>>> >>> However,
>>> >>>
>>> >>> gdalinfo --formats
>>> >>>
>>> >>> ...
>>> >>>
>>> >>>  Rasterlite -raster- (rws): Rasterlite
>>> >>>  SAFE -raster- (rov): Sentinel-1 SAR SAFE Product
>>> >>>  SAR_CEOS -raster- (rov): CEOS SAR Image
>>> >>>  SDTS -raster- (rov): SDTS Raster
>>> >>>  SENTINEL2 -raster- (rovs): Sentinel 2
>>> >>>  SGI -raster- (rw+): SGI Image File Format 1.0
>>> >>>  SRTMHGT -raster- (rwv): SRTMHGT File Format
>>> >>>  TIL -raster- (rov): EarthWatch .TIL
>>> >>>
>>> >>> ...
>>> >>>
>>> >>> does not show the SQLite driver and indeed a program that I'm
>>> building
>>> >>> that needs to link with GDAL (osmcoastline) crashes when it doesn't
>>> >>> find >>>that driver.
>>> >>>
>>> >>> ?
>>> >>>
>>> >>> Joaquim
>>> >>> ___
>>> >>> gdal-dev mailing list
>>> >>> gdal-dev@lists.osgeo.org
>>> >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>> >>
>>> >> 
>>> >> http://schwehr.org
>>>
>> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver?

2016-09-14 Thread Joaquim Luis 
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 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?


You mentionned that you "(re)build" GDAL with sqlite, so I assume you  
added it
after a first build. So I suspect that some files didn't get recompiled.  
The

safest way if not already done is to clean and rebuild.

Otherwise, mostly for a quick check, you may just 'touch'
ogr/ogrsf_frmts/generic/ogrregisterall.cpp but you'll probably miss a  
few files
that will benefit from sqlite being now available. So the clean &  
rebuild path

is the safest ultimately.



> 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.
>
>   ogrinfo --formats  shows no SQLite driver
>
> 3. The program I'm trying to build/run crashes at this line
>
> 
https://github.com/osmcode/osmcoastline/blob/master/include/gdalcpp.hp
>p#L132 (no idea why it crashes) apparently because it doesn't find  
the

>
> SQLite driver (driver_name == 'SQLite')
>
>> 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 is a gdal.dll dependency.
>>> However,
>>>
>>> gdalinfo --formats
>>>
>>> ...
>>>
>>>  Rasterlite -raster- (rws): Rasterlite
>>>  SAFE -raster- (rov): Sentinel-1 SAR SAFE Product
>>>  SAR_CEOS -raster- (rov): CEOS SAR Image
>>>  SDTS -raster- (rov): SDTS Raster
>>>  SENTINEL2 -raster- (rovs): Sentinel 2
>>>  SGI -raster- (rw+): SGI Image File Format 1.0
>>>  SRTMHGT -raster- (rwv): SRTMHGT File Format
>>>  TIL -raster- (rov): EarthWatch .TIL
>>>
>>> ...
>>>
>>> does not show the SQLite driver and indeed a program that I'm  
building

>>> that needs to link with GDAL (osmcoastline) crashes when it doesn't
>>> find >>>that driver.
>>>
>>> ?
>>>
>>> Joaquim
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> 
>> http://schwehr.org

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver?

2016-09-14 Thread Even Rouault 
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 why the SQLite driver is not available?

You mentionned that you "(re)build" GDAL with sqlite, so I assume you added it 
after a first build. So I suspect that some files didn't get recompiled. The 
safest way if not already done is to clean and rebuild.

Otherwise, mostly for a quick check, you may just 'touch' 
ogr/ogrsf_frmts/generic/ogrregisterall.cpp but you'll probably miss a few files 
that will benefit from sqlite being now available. So the clean & rebuild path 
is the safest ultimately.

> 
> > 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.
> > 
> >   ogrinfo --formats  shows no SQLite driver
> > 
> > 3. The program I'm trying to build/run crashes at this line
> > 
> >https://github.com/osmcode/osmcoastline/blob/master/include/gdalcpp.hp
> >p#L132 (no idea why it crashes) apparently because it doesn't find the
> > 
> > SQLite driver (driver_name == 'SQLite')
> > 
> >> 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 is a gdal.dll dependency.
> >>> However,
> >>> 
> >>> gdalinfo --formats
> >>> 
> >>> ...
> >>> 
> >>>  Rasterlite -raster- (rws): Rasterlite
> >>>  SAFE -raster- (rov): Sentinel-1 SAR SAFE Product
> >>>  SAR_CEOS -raster- (rov): CEOS SAR Image
> >>>  SDTS -raster- (rov): SDTS Raster
> >>>  SENTINEL2 -raster- (rovs): Sentinel 2
> >>>  SGI -raster- (rw+): SGI Image File Format 1.0
> >>>  SRTMHGT -raster- (rwv): SRTMHGT File Format
> >>>  TIL -raster- (rov): EarthWatch .TIL
> >>> 
> >>> ...
> >>> 
> >>> does not show the SQLite driver and indeed a program that I'm building
> >>> that needs to link with GDAL (osmcoastline) crashes when it doesn't
> >>> find >>>that driver.
> >>> 
> >>> ?
> >>> 
> >>> Joaquim
> >>> ___
> >>> gdal-dev mailing list
> >>> gdal-dev@lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >> 
> >> 
> >> http://schwehr.org

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver?

2016-09-14 Thread Joaquim Luis 
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) 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.
  ogrinfo --formats  shows no SQLite driver

3. The program I'm trying to build/run crashes at this line
   https://github.com/osmcode/osmcoastline/blob/master/include/gdalcpp.hpp#L132
   (no idea why it crashes) apparently because it doesn't find the  
SQLite driver (driver_name == 'SQLite')




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 is a gdal.dll dependency.  
However,


gdalinfo --formats

...
 Rasterlite -raster- (rws): Rasterlite
 SAFE -raster- (rov): Sentinel-1 SAR SAFE Product
 SAR_CEOS -raster- (rov): CEOS SAR Image
 SDTS -raster- (rov): SDTS Raster
 SENTINEL2 -raster- (rovs): Sentinel 2
 SGI -raster- (rw+): SGI Image File Format 1.0
 SRTMHGT -raster- (rwv): SRTMHGT File Format
 TIL -raster- (rov): EarthWatch .TIL
...

does not show the SQLite driver and indeed a program that I'm building  
that needs to link with GDAL (osmcoastline) crashes when it doesn't  
find >>>that driver.


?

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev





http://schwehr.org___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver?

2016-09-14 Thread Joaquim Luis 

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.
   ogrinfo --formats
   shows no SQLite driver

3. The program I'm trying to build/run crashes at this line
https://github.com/osmcode/osmcoastline/blob/master/include/gdalcpp.hpp#L132
(no idea why it crashes) apparently because it doesn't find the SQLite  
driver (driver_name == 'SQLite')




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 is a gdal.dll dependency. However,


gdalinfo --formats

...
 Rasterlite -raster- (rws): Rasterlite
 SAFE -raster- (rov): Sentinel-1 SAR SAFE Product
 SAR_CEOS -raster- (rov): CEOS SAR Image
 SDTS -raster- (rov): SDTS Raster
 SENTINEL2 -raster- (rovs): Sentinel 2
 SGI -raster- (rw+): SGI Image File Format 1.0
 SRTMHGT -raster- (rwv): SRTMHGT File Format
 TIL -raster- (rov): EarthWatch .TIL
...

does not show the SQLite driver and indeed a program that I'm building  
that needs to link with GDAL (osmcoastline) crashes when it doesn't  
find >>that driver.


?

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev





http://schwehr.org___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver?

2016-09-14 Thread Kurt Schwehr 
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 is a gdal.dll dependency. However,
>
> gdalinfo --formats
>
> ...
>   Rasterlite -raster- (rws): Rasterlite
>   SAFE -raster- (rov): Sentinel-1 SAR SAFE Product
>   SAR_CEOS -raster- (rov): CEOS SAR Image
>   SDTS -raster- (rov): SDTS Raster
>   SENTINEL2 -raster- (rovs): Sentinel 2
>   SGI -raster- (rw+): SGI Image File Format 1.0
>   SRTMHGT -raster- (rwv): SRTMHGT File Format
>   TIL -raster- (rov): EarthWatch .TIL
> ...
>
> does not show the SQLite driver and indeed a program that I'm building
> that needs to link with GDAL (osmcoastline) crashes when it doesn't find
> that driver.
>
> ?
>
> Joaquim
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver and drop table problem

2013-06-14 Thread Even Rouault 
Le vendredi 14 juin 2013 20:18:19, Piotr Tracz a écrit :
 Hello,
 
 I think there might be a bug in OGRSQLiteDataSource::ExecuteSQL but
 before I make bug ticket, I want to be sure I'm not missing anything.
 When one try to execute SQL command DROP TABLE xxx, error In
 ExecuteSQL(): sqlite3_step(DROP TABLE xxx):
SQL logic error or missing database occurs.
 
   I think this error is related to how SQLite behaves: DROP TABLE can be
 only executed by sqlite3_exec while GDAL is trying to do that by
   sqlite3_prepare -  sqlite3_step - sqlite3_finalize chain.
 
 Bug is related to GDAL 1.10 version (however previous behaves the same)
 compiled aganist SQLITE 3.7.x.

Can you try downloading 
http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly_spatialite.sqlite and 
then do : ogrinfo poly_spatialite.sqlite -sql drop table poly ?

This works for me with SQLITE 3.6.22 and 3.7.13.

 
 Regards,
 
 Piotr
 
 
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite driver and drop table problem

2013-06-14 Thread Piotr Tracz 

W dniu 2013-06-14 20:58, Even Rouault pisze:

http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly_spatialite.sqlite and
then do : ogrinfo poly_spatialite.sqlite -sql drop table poly ?

This works for me with SQLITE 3.6.22 and 3.7.13.


Yes it works.
False alarm. Error was a reason of some orphaned OGRLayer pointer in 
totally different part of codesource.


Best regards,

Piotr









___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite Driver and non-spatial tables

2012-11-20 Thread Kyle Shannon 
For the record, in case anyone is interested, it appears setting
SQLITE_LIST_ALL_TABLES=YES appears to allow me access to non-spatial
tables.  I didn't find any documentation on the format page though.

On Tue, Nov 13, 2012 at 1:44 PM, Kyle Shannon k...@pobox.com wrote:

 I have a Spatialite enabled SQLite file with both spatial and non-spatial
 tables.  Since my database has a table called geometry_columns, all
 non-spatial tables are not loaded as layers.  If I don't have a
 geometry_columns OGR attempts to load geometry from all the tables, but
 still loads non-spatial tables.  Is that correct?  The behavior doesn't
 seem consistent in the two cases.  I just want to make sure I understand
 the driver's behavior.

 kss
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev