Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 22/05/2013 09:33, Ivan Mincik ha scritto:

> Definitely, I think that QGIS 2 must be released with SpatiaLite
> 4.

Agreed, it would be a pity not having it.
All the best.

- -- 
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlGc35gACgkQ/NedwLUzIr6yvACfaoJuOnre5Lu/mfw+qxkumxNF
GfMAoIu3seAPmUKBTO1yicf2I1YqawEB
=Cr3l
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[a . furieri]

Hi Giuseppe,

thanks for your further clarifications (really useful to completely
focus the question).


no insert nor update statements are performed to understand what's 
the


layer's geometry type, and the db v4.0 wasn't created by DB Manager



All right, now I finally understand that the question was about 
querying

the spatial  metadata tables in order to detect geometry-type, srid,
dimensions and so on.
(sorry, I previously understood that the problem was creating a further
geometry column, thus defaulting to use AddGeometryColumn() or not)


I'm not really completely sure about this, but I suppose that the
optimal way should probably be the one to ask the data-provider
itself to return such infos. If I remember well the data
provider is always fully aware of metadata related to each single
layer, and the access methods are always fully independent from
any possible versioning idiosyncrasy.

If for some good reason such an approach isn't suitable for python
plug-ins then the alternative approach is obviously the one to
directly query the metadata tables.
and (sadly) in this case v.3 and v.4 behave rather differently:

v.3 (and earlier versions) layout:

SELECT srid, type, coord_dimension
FROM geometry_columns
WHERE Lower(f_table_name) = Lower('points')
  AND Lower(f_geometry_column) = Lower('geom');
==
4326  POINTXY


SELECT srid, type, coord_dimension
FROM geometry_columns
WHERE Lower(f_table_name) = Lower('lines')
  AND Lower(f_geometry_column) = Lower('geom');
==
4326  LINESTRINGXYZM


SELECT srid, type, coord_dimension
FROM geometry_columns
WHERE Lower(f_table_name) = Lower('polygs')
  AND Lower(f_geometry_column) = Lower('geom');
==
4326  MULTIPOLYGONXYZ



v.4 (and subsequent versions) layout:
-
SELECT srid, geometry_type
FROM geometry_columns
WHERE Lower(f_table_name) = Lower('points')
  AND Lower(f_geometry_column) = Lower('geom');
==
4326  1


SELECT srid, geometry_type
FROM geometry_columns
WHERE Lower(f_table_name) = Lower('lines')
  AND Lower(f_geometry_column) = Lower('geom');
==
4326  3002


SELECT srid, geometry_type
FROM geometry_columns
WHERE Lower(f_table_name) = Lower('polygs')
  AND Lower(f_geometry_column) = Lower('geom');
==
4326  1006


in other worlds:
- in v.3 you have to query both "type" and "cood_dimensions"
  columns, because the geometry-type and the dimensions are
  defined separately
- in v.4 just querying "geometry_type" alone will be enough,
  because now each geometry is fully qualified by its numeric
  type (as strictly required by standard OGC and SQL/MM specs).
  a "coord_dimension" column still exists (merely for standard
  conformance, but is completely redundant and meaningless).

1 = 2D, POINT
2 = 2D, LINESTRING
3 = 2D, POLYGON
4 = 2D, MULTIPOINT
5 = 2D, MULTILINESTRIN
6 = 2D, MULTIPOLYGON
7 = 2D, GEOMETRYCOLLECTION

1001 = 3D, POINT
1002 = 3D, LINESTRING
1003 = 3D, POLYGON
1004 = 3D, MULTIPOINT
1005 = 3D, MULTILINESTRIN
1006 = 3D, MULTIPOLYGON
1007 = 3D, GEOMETRYCOLLECTION

2001 = 2D+M, POINT
2002 = 2D+M, LINESTRING
2003 = 2D+M, POLYGON
2004 = 2D+M, MULTIPOINT
2005 = 2D+M, MULTILINESTRIN
2006 = 2D+M, MULTIPOLYGON
2007 = 2D+M, GEOMETRYCOLLECTION

3001 = 3D+M, POINT
3002 = 3D+M, LINESTRING
3003 = 3D+M, POLYGON
3004 = 3D+M, MULTIPOINT
3005 = 3D+M, MULTILINESTRIN
3006 = 3D+M, MULTIPOLYGON
3007 = 3D+M, GEOMETRYCOLLECTION

bye Sandro




--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[Cline, Royce L.]

QGIS is using Spatialite 4. If I execute SELECT spatialite_version() in DB 
Manger, I get 4.0.0.

The problem with creating a new layer is that with SpatiaLite 4, QGIS will not 
load an empty table. The debug info shows:
Debug: src/providers/spatialite/qgsspatialiteprovider.cpp: 523: 
(QgsSpatiaLiteProvider) Invalid SpatiaLite layer

The database and table appears to be created correctly. If I use SQL to insert 
one record with geometry into the table with DB Manager, then I can load the 
table to the canvas in QGIS.

I am using OS X 10.8.3 with QGIS daily builds from Dakota Cartography and 
frameworks from kygnchaos. SpatiaLite 4.0 appears to work without problems in 
python programs I have written. The fact that SELECT spatialite_version() in 
the DB Manager SQL window indicates to me that DB Manger is loading the correct 
version of pysqlite from the kygnchaos frameworks.

Royce



On May 22, 2013, at 5:22 AM, a.furi...@lqt.it wrote:

On Tue, 21 May 2013 13:14:00 -0600, Larry Shaffer wrote:
Is anyone using QGIS master branch with Spatialite 4.0 successfully?
If Spatialite 4.0 is still not supported yet, is anyone working on it?
I can get a vector layer to Save as... to a Spatialite 4.0 db, but
can't create a new one.



On Tue, 21 May 2013 20:42:35 +, Cline, Royce L. wrote:
The other issue I have had with SpatiaLite 4 is with DB Manager. DB
Manager does not recognize geometry for a table in a Spatialite 4
created database (new spatial metadata). Displays the same as a table
without geometry. If the database was created with Spatialite 3 or
converted to a version 3 database with spatialite_convert, then it
will show the table as having geometry. It would appear that DB
Manager is not testing whether the database containing the table is
using the new or old version of the spatial metadata.


both issues are closely related.
since many months the QGIS-spatialite data-provider has been
updated so to be able to connect indifferently both spatialite
v.3.x and v.4.x DB-files. any specific difference affecting the
data layout for Spatial Metadata tables adopted by each version
will be always silently handled in the most appropriate way
by the revised data-provider.
the whole process will be absolutely transparent from the end
user POV.

the relevant QGIS-trunk cumulative patch corresponds to commit
#47097b72 [2012 November 30]

anyway, simply updating the data-provider code itself isn't enough
in order to effectively activate full support for v.4.0.0 DB-files:

a) QGIS binaries must be absolutely built on the top of libspatialite
  4.0.0 (if binaries are actually built on the top of some
  earlier libspatialite version the whole code implementing 4.0.0
  support will be conditionally disabled by CMAKE)
b) at run time QGIS must effectively load libspatialite 4.0.0 (or
  any later version)

if one or the other of these two conditions aren't satisfied, then
QGIS will be completely unable to access any DB-file created by
libspatialite 4.0.0

so the real issue is in that quite almost Linux major distros still
support obsolete versions of libspatialite; the same is true for the
OSGeo4W Win distro.
the net result of this situation is that even building a fresh copy
of QGIS-trunk starting from sources will easily produce an executable
binary completely unable to support v.4.0.0 DB-files.
on the other side, building QGIS-trunk after installing a custom
built libspatialite-4.x will always create binaries perfectly able
to access v.4.0.0 DB-files, even on Windows MSVC/OSGeo4W.

-

the second issue (DB Manager) requires few more considerations.
Spatialite (exactly as PostGIS) supports several "high-level/abstract"
SQL functions allowing to correctly handle Spatial Metadata tables
in the most transparent way; such an approach is obviously intended to
shield against fine-grained implementation details, which can easily
change from version to version.

case A)
if the developer always correctly invoked the expected "high level"
SQL functions, then transitioning from v.3 to v.4 is expected to be
a completely painless process; because in this case the underlying
library will silently accommodate for any possible physical data
layout difference introduced by the most recent version.

case B)
on the other hand, if the developer decided to completely skip
using any appropriate "abstract" SQL function so to directly perform
some INSERT or UPDATE statement affecting the Spatial Metadata tables,
many painful transition issues should be expected to arise while
transitioning to the most recent version.
in this case a patient code correction action has obviously to be
applied case by case.
I strongly fear that this second (worst) case is the most probable
scenario we can expect to face for DB Manager (and possibly for
others plug-ins).

bye Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for?QGIS?2.0?

[a . furieri]

On Wed, 22 May 2013 13:20:03 +0200, Jürgen E. Fischer wrote:

Hi Sandro,

On Wed, 22. May 2013 at 12:22:31 +0200, a.furi...@lqt.it wrote:

so the real issue is in that quite almost Linux major distros still
support obsolete versions of libspatialite; the same is true for the
OSGeo4W Win distro.


I understood that you're going to change that by becoming the 
maintainer of

spatialite in OSGeo4W - at least Paolo said so IIRC.



certainly yes; I'll start working so to update OSGeo4W immediately 
after

releasing the final "stable" 4.1 ... just few days, reasonably before
the end of the current week (so I hope).

this will surely resolve many issues on Windows; sadly enough, will 
have

no effect at all for Linux distros (and I presume on MacOsX as well).

bye Sandro




--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for?QGIS?2.0?

[Jürgen E . Fischer]

Hi Sandro,

On Wed, 22. May 2013 at 12:22:31 +0200, a.furi...@lqt.it wrote:
> so the real issue is in that quite almost Linux major distros still
> support obsolete versions of libspatialite; the same is true for the
> OSGeo4W Win distro.

I understood that you're going to change that by becoming the maintainer of
spatialite in OSGeo4W - at least Paolo said so IIRC.


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de
committ(ed|ing) to Quantum GIS IRC: jef on FreeNode 


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[Giuseppe Sucameli]

Hi all,

On Wed, May 22, 2013 at 12:22 PM,  wrote:

> On Tue, 21 May 2013 20:42:35 +, Cline, Royce L. wrote:
>
>> The other issue I have had with SpatiaLite 4 is with DB Manager. DB
>> Manager does not recognize geometry for a table in a Spatialite 4
>> created database (new spatial metadata). Displays the same as a table
>> without geometry. If the database was created with Spatialite 3 or
>> converted to a version 3 database with spatialite_convert, then it
>> will show the table as having geometry. It would appear that DB
>> Manager is not testing whether the database containing the table is
>> using the new or old version of the spatial metadata.
>>
>>
> the second issue (DB Manager) requires few more considerations.
> [...]
> if the developer decided to completely skip
> using any appropriate "abstract" SQL function so to directly perform
> some INSERT or UPDATE statement affecting the Spatial Metadata tables,


no insert nor update statements are performed to understand what's the
layer's geometry type, and the db v4.0 wasn't created by DB Manager

Surely the problem is a different one, I guess it could depend on the
python connector DB Manager uses, aka the pyspatialite library.

Cheers.


> bye Sandro
>
> --
> Il messaggio e' stato analizzato alla ricerca di virus o
> contenuti pericolosi da MailScanner, ed e'
> risultato non infetto.
>
>
> __**_
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/qgis-**developer
>



-- 
Giuseppe Sucameli
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[a . furieri]

On Tue, 21 May 2013 13:14:00 -0600, Larry Shaffer wrote:

Is anyone using QGIS master branch with Spatialite 4.0 successfully?
If Spatialite 4.0 is still not supported yet, is anyone working on 
it?

I can get a vector layer to Save as... to a Spatialite 4.0 db, but
can't create a new one.




On Tue, 21 May 2013 20:42:35 +, Cline, Royce L. wrote:

The other issue I have had with SpatiaLite 4 is with DB Manager. DB
Manager does not recognize geometry for a table in a Spatialite 4
created database (new spatial metadata). Displays the same as a table
without geometry. If the database was created with Spatialite 3 or
converted to a version 3 database with spatialite_convert, then it
will show the table as having geometry. It would appear that DB
Manager is not testing whether the database containing the table is
using the new or old version of the spatial metadata.



both issues are closely related.
since many months the QGIS-spatialite data-provider has been
updated so to be able to connect indifferently both spatialite
v.3.x and v.4.x DB-files. any specific difference affecting the
data layout for Spatial Metadata tables adopted by each version
will be always silently handled in the most appropriate way
by the revised data-provider.
the whole process will be absolutely transparent from the end
user POV.

the relevant QGIS-trunk cumulative patch corresponds to commit
#47097b72 [2012 November 30]

anyway, simply updating the data-provider code itself isn't enough
in order to effectively activate full support for v.4.0.0 DB-files:

a) QGIS binaries must be absolutely built on the top of libspatialite
   4.0.0 (if binaries are actually built on the top of some
   earlier libspatialite version the whole code implementing 4.0.0
   support will be conditionally disabled by CMAKE)
b) at run time QGIS must effectively load libspatialite 4.0.0 (or
   any later version)

if one or the other of these two conditions aren't satisfied, then
QGIS will be completely unable to access any DB-file created by
libspatialite 4.0.0

so the real issue is in that quite almost Linux major distros still
support obsolete versions of libspatialite; the same is true for the
OSGeo4W Win distro.
the net result of this situation is that even building a fresh copy
of QGIS-trunk starting from sources will easily produce an executable
binary completely unable to support v.4.0.0 DB-files.
on the other side, building QGIS-trunk after installing a custom
built libspatialite-4.x will always create binaries perfectly able
to access v.4.0.0 DB-files, even on Windows MSVC/OSGeo4W.

-

the second issue (DB Manager) requires few more considerations.
Spatialite (exactly as PostGIS) supports several "high-level/abstract"
SQL functions allowing to correctly handle Spatial Metadata tables
in the most transparent way; such an approach is obviously intended to
shield against fine-grained implementation details, which can easily
change from version to version.

case A)
if the developer always correctly invoked the expected "high level"
SQL functions, then transitioning from v.3 to v.4 is expected to be
a completely painless process; because in this case the underlying
library will silently accommodate for any possible physical data
layout difference introduced by the most recent version.

case B)
on the other hand, if the developer decided to completely skip
using any appropriate "abstract" SQL function so to directly perform
some INSERT or UPDATE statement affecting the Spatial Metadata tables,
many painful transition issues should be expected to arise while
transitioning to the most recent version.
in this case a patient code correction action has obviously to be
applied case by case.
I strongly fear that this second (worst) case is the most probable
scenario we can expect to face for DB Manager (and possibly for
others plug-ins).

bye Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[a . furieri]

On Wed, 22 May 2013 09:33:30 +0200, Ivan Mincik wrote:
As I understand from discussion with SpatiaLite author Sandro 
Furieri,
version 4 is really strongly recommended over version 3. Version 3 
was

some kind of not very successful release.



that's not completely true; version 3 simply was the final evolution
step of the legacy development line started since version 2.4

version 4.x starts a brad new development path, is actually based on
a profoundly refactored code base and includes many more advanced
features. just to say:
- v.4 is now supported by an almost complete test coverage
- v.4 has been extensively checked using Valgrind so to completely
  erase any possible memory leak or memory-related issue
- many possible buffer overflow causes have been carefully identified
  and completely eradicated
- many performance optimizations have been introduced here and there
- lots of new cool features are now available

all this considered, I see no reason at all to still continue
using v.3: it's a less advanced implementation, it surely contains
many bugs now definitely resolved in v.4 and it certainly has a
less robust and more error prone code base.

Please note: I'm planning to release v.4.1.0 in the very next days;
a Release Candidate is already available:
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.1.0-RC1

v.4.1.0 is certified to be a completely API/ABI compatible replacement
for v.4.0.0, so I suppose that directly switching to 4.1.0 should
be the most appropriate solution to be adopted for QGIS 2.0

a very closely related topic:
two days ago the SQLite folks have released the latest v.3.7.17:
this very recent release seems to be a significant milestone in
SQLite evolution. please see:
http://www.sqlite.org/releaselog/3_7_17.html

IMHO directly including libsqlite 3.7.17 in QGIS 2.0 should be
a very good opportunity to be carefully evaluated.

as the SQLite developers state:
"Version 3.7.17 of SQLite is recommended for all new development.
Upgrading from all previous SQLite versions is recommended."

bye Sandro




--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[Ivan Mincik]

As I understand from discussion with SpatiaLite author Sandro Furieri,
version 4 is really strongly recommended over version 3. Version 3 was some
kind of not very successful release.

Version 4 should be fully supported in QGIS master [1]. I use SpatiaLite 4
in my GIS PPA [2] and I am building QGIS master with it. Some things are
still not working (I will report if not already) but it may be GDAL problem.
Definitely, I think that QGIS 2 must be released with SpatiaLite 4.


--
1 -
https://groups.google.com/forum/?fromgroups#!topic/spatialite-users/rdY4-p8GTK4
2 - 
https://launchpad.net/~imincik/+archive/gis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[Cline, Royce L.]

The other issue I have had with SpatiaLite 4 is with DB Manager. DB Manager 
does not recognize geometry for a table in a Spatialite 4 created database (new 
spatial metadata). Displays the same as a table without geometry. If the 
database was created with Spatialite 3 or converted to a version 3 database 
with spatialite_convert, then it will show the table as having geometry. It 
would appear that DB Manager is not testing whether the database containing the 
table is using the new or old version of the spatial metadata.

Royce



On May 21, 2013, at 2:44 PM, Jürgen E. Fischer  wrote:

> Hi Larry,
> 
> On Tue, 21. May 2013 at 13:14:00 -0600, Larry Shaffer wrote:
>> Is anyone using QGIS master branch with Spatialite 4.0 successfully?
> 
> The submitter apparently is - it's just that it doesn't seem to work with 
> empty
> tables.
> 
> 
>> Same questions for GDAL 1.10. Are there issues within the QGIS codebase
>> concerning its use that would cause it not to be recommended for 2.0?
> 
> No.
> 
> 
> Jürgen 
> 
> -- 
> Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
> Software Engineer D-26506 Norden   http://www.norbit.de
> committ(ed|ing) to Quantum GIS IRC: jef on FreeNode   
>   
> 
> -- 
> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> Rheinstrasse 13, 26506 Norden
> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[Etienne Tourigny]

IMHO it would be great to make sure latest spatialite and GDAL are tested
and packaged with 2.0 in Mac, osgeo4w and ubuntugis-unstable

I personally use gdal-1.10 with qgis master without any problems (Linux
 Mint 14)

Etienne

On Tue, May 21, 2013 at 4:14 PM, Larry Shaffer wrote:

> Hi,
>
> Recently William upgraded his Mac support frameworks to GDAL 1.10 and
> Spatialite 4.0 [0]. However, it appears that QGIS core code may not be
> ready for Spatialite 4.0 [1].
>
> Is anyone using QGIS master branch with Spatialite 4.0 successfully?
>
> If Spatialite 4.0 is still not supported yet, is anyone working on it?
>
> I can get a vector layer to Save as... to a Spatialite 4.0 db, but can't
> create a new one.
>
>
> Same questions for GDAL 1.10. Are there issues within the QGIS codebase
> concerning its use that would cause it not to be recommended for 2.0?
>
>
> These are two major new FOSSGeo releases that seem a shame to not include
> support for in QGIS 2.0.
>
> [0] http://www.kyngchaos.com/blog/2013/20130501_gdal_1.10
> [1] http://hub.qgis.org/issues/7664
>
> Regards,
>
> Larry
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[Tim Sutton]

Hi

On Tue, May 21, 2013 at 9:14 PM, Larry Shaffer  wrote:
> Hi,
>
> Recently William upgraded his Mac support frameworks to GDAL 1.10 and
> Spatialite 4.0 [0]. However, it appears that QGIS core code may not be ready
> for Spatialite 4.0 [1].
>
> Is anyone using QGIS master branch with Spatialite 4.0 successfully?
>
> If Spatialite 4.0 is still not supported yet, is anyone working on it?
>
> I can get a vector layer to Save as... to a Spatialite 4.0 db, but can't
> create a new one.
>
>
> Same questions for GDAL 1.10. Are there issues within the QGIS codebase
> concerning its use that would cause it not to be recommended for 2.0?
>
>

I cant speak for spatialite, but I normally use a trunk build of gdal
on my desktops with no adverse affects

Regards

Tim


> These are two major new FOSSGeo releases that seem a shame to not include
> support for in QGIS 2.0.
>
> [0] http://www.kyngchaos.com/blog/2013/20130501_gdal_1.10
> [1] http://hub.qgis.org/issues/7664
>
> Regards,
>
> Larry
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



--
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
==
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[Jürgen E . Fischer]

Hi Larry,

On Tue, 21. May 2013 at 13:14:00 -0600, Larry Shaffer wrote:
> Is anyone using QGIS master branch with Spatialite 4.0 successfully?

The submitter apparently is - it's just that it doesn't seem to work with empty
tables.


> Same questions for GDAL 1.10. Are there issues within the QGIS codebase
> concerning its use that would cause it not to be recommended for 2.0?

No.


Jürgen 

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de
committ(ed|ing) to Quantum GIS IRC: jef on FreeNode 


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] State of Spatialite 4.0 and GDAL 1.10 for QGIS 2.0?

[Larry Shaffer]

Hi,

Recently William upgraded his Mac support frameworks to GDAL 1.10 and
Spatialite 4.0 [0]. However, it appears that QGIS core code may not be
ready for Spatialite 4.0 [1].

Is anyone using QGIS master branch with Spatialite 4.0 successfully?

If Spatialite 4.0 is still not supported yet, is anyone working on it?

I can get a vector layer to Save as... to a Spatialite 4.0 db, but can't
create a new one.


Same questions for GDAL 1.10. Are there issues within the QGIS codebase
concerning its use that would cause it not to be recommended for 2.0?


These are two major new FOSSGeo releases that seem a shame to not include
support for in QGIS 2.0.

[0] http://www.kyngchaos.com/blog/2013/20130501_gdal_1.10
[1] http://hub.qgis.org/issues/7664

Regards,

Larry
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer