[Qgis-developer] backports for 1.7.3
Hi, Sorry for jumping in the discussion here without all the background. Maybe this has been discussed before by the qgis dev team (if that's the case, disregard what follows), but why not considering beta and RC stages, before declaring an official release ? Lots of projects do that, manily in the hope of avoiding that a last minute bug doesn't go into the release. I'm well aware that this doesn't address all the issues, and also requires additional ressource and delay. I can give you some feedback on how GDAL manages the release process. For "major" releases (any change of X or Y in a X.Y.Z numbering scheme), we generally do 2 betas and as many RC as needed. For micro releases (change in Z), the beta stage is skeeped to go directly to RC. For GDAL, it does not involve too much effort (*) as we only release source code. For QGIS that also delivers binary packages, that would require significant effort, so perhaps only the official release could come with the binary packages. For betas and RCs, power users would have to use latest nighty builds or compile by themselves. Just my 2 cents, Best regards, Even (*) FrankW who manages most of the releases could legitimately object to that statement ;-) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Excel Export from QGIS attribute table
> > I'd be much more interested in reading of xls, xlsx, ods etc as > > tables for joining or generating spatial X,Y layers. FYI, Sandro Furieri has created a lightweight FreeXL library that can read XLS files. It can be integrated with spatialite (through a VirtualXLS module), or standalone. I've developed in GDAL/OGR 1.9.0 a OGR driver that relies on it. See http://gdal.org/ogr/drv_xls.html for the details and limitations. Best regards, Even ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Excel Export from QGIS attribute table
Le jeudi 01 décembre 2011 09:41:12, Even Rouault a écrit : > > > I'd be much more interested in reading of xls, xlsx, ods etc as > > > tables for joining or generating spatial X,Y layers. > > FYI, Sandro Furieri has created a lightweight FreeXL library that can read > XLS files. It can be integrated with spatialite (through a VirtualXLS > module), or standalone. I've developed in GDAL/OGR 1.9.0 a OGR driver that > relies on it. See http://gdal.org/ogr/drv_xls.html for the details and > limitations. Follow-up : two new drivers to read and write ODS and XLSX files have been incorporated into GDAL/OGR trunk. I've blogged about it at http://erouault.blogspot.com/2012/01/welcome-to-200th-gdalogr-driver.html > > Best regards, > > Even > ___ > 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] SpatiaLite layers invisible when loaded from browser
Le mardi 28 février 2012 18:42:13, Paolo Cavallini a écrit : > Hi all. > If I load a SL layer from the browser (from the files list, not from the SL > submenu), the layer is loaded, and can be exported, but is not displayed: > anyone confirms? All the best. I don't confirm. It works for me with both GDAL 1.9.0 and GDAL trunk, at least on the simple example that I've sent to Paolo. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SpatiaLite layers invisible when loaded from browser
Le mercredi 29 février 2012 08:45:21, Paolo Cavallini a écrit :
> Il 28/02/2012 20:23, Even Rouault ha scritto:
> > I don't confirm. It works for me with both GDAL 1.9.0 and GDAL trunk, at
> > least on the attached simple example.
>
> Confirmed: your sample is ok. The sample file[0] does not load correctly
> here. Thanks.
I also reproduce the error with the test-2.3 database. The difference with the
poly.sqlite that I sent before is that test-2.3 contains no spatial index.
The console has interesting error messages :
ERROR 1: In ResetStatement(): sqlite3_prepare(SELECT _rowid_, * FROM 'Towns'
WHERE MBRIntersects("Geometry", BuildMBR(-213552396.323174118996,
-167417043.364000141621, 215180205.733174085617, 176566090.844000160694,
32632))):
no such function: BuildMBR
I'd note that you get the same behaviour when opening from "Open a Vector
Layer" (which uses the OGR driver)
What is more interesting is that the same request run from ogrinfo works
perfectly
I'm afraid the reason why it does not work in QGIS is that it has the bad idea
of embedding directly libspatialite in /usr/lib/libqgis_core.so.1.9.90 instead
of dynamically linking to the one provided by the system. So I highly suspect
a conflict between the libspatialite linked by libgdal.so and the one linked by
libqgis_core, especially if they are not the same version
Another point is that the QGIS File Browser only displays the first OGR layer,
whereas when opening with "Open a Vector Layer", you can choose among all OGR
layers.
>
> [0]http://www.gaia-gis.it/spatialite-2.3.1/test-2.3.zip
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Error in QGIS or not proper KML format?
Le mardi 08 décembre 2015 10:50:04, magerlin a écrit : > When I recieve KML files from af public state bureau the point coordinates > are written like this in the kml file: > > > 8.43307284569448, 55.478226574306 > > > When opening it in Qgis all points get a y coordinate of zero. Removing the > blank between the "," and the y coordinate 55.478 solves the problem. > Google Earth can open the files without problems. > > Shall I claim the producer for not writing proper KLM or is it an error in > Qgis (or OGR or whatever is used for reading KLM)? This is invalid KML. Depending on whether you use the "old" KML driver or the one based on libkml, this will respectively not work / work : https://trac.osgeo.org/gdal/ticket/5140 Yes, the producer should fix their KML. > > > > - > Regards Morten > > Currently using Qgis 2.12.1 (OSGeo4), > Windows 7, 64bit > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/Error-in-QGIS-or-not-proper-KML-format > -tp5240377.html Sent from the Quantum GIS - Developer mailing list archive > at Nabble.com. ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Update to EPSG database v8.8
Hi, Just to inform you I've just completed the update to EPSG v8.8 (previous one was v8.5) in GDAL trunk ( https://trac.osgeo.org/gdal/changeset/32964 ), libgeotiff trunk ( https://trac.osgeo.org/geotiff/changeset/2714 ) and proj.4 master ( https://github.com/OSGeo/proj.4/commit/832329a9aadbfcb7f46919c903f7672e719d2a82 ). (and proposed PostGIS spatial_ref_sys.sql : https://trac.osgeo.org/postgis/ticket/3427 ) As you can see (proj.4 nad/epsg file is probably the most readable to see the diffs), It brings a bunch of new SRS, updated TOWGS84 shifts, etc... Please report if you notice any issue. Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GDAL 2.1 can update Geojson files - What is missing in QGIS to edit GeoJSON files ?
Hi Michael, > > I have read that GDAL can now update GeoJSON since version 2.1.0. See [1] > > If I build QGIS with GDAL 2.1, would I be able to edit the GeoJSON as I can > for Shapefiles ? Yes, that was developed mostly for the QGIS use case and has been tested with it. You have full editing capabilities : adding, deleting, modifying features, adding, deleting fields. > > Another GeoJSON related question. Any idea on the relevance of adding the > ability to create a spatial index file *.qix for GeoJSON layers in order to > improve rendering speed ? The OGR GeoJSON driver proceeds into the ingestion of the full file into memory, which can be a limitation when dealing with huge files ( the json-c lib might typically consume an amount of memory more than 10 times the size of the geojson file). For a in-memory layer like the one used underneath by the GeoJSON driver, the spatial filtering done by OGR uses a basic BBOX filter while iterating over the features (the BBOX isn't stored into the geometry object but recomputed each time it is needed). This could potentially benefit from a in-memory spatial index, but I'd expect that to be only useful for large geojson files (let's say > 100 MB), i.e. the ones that the driver would currently have issues to deal with. A more "streaming-like" approach for the driver not proceeding to full ingestion of features could be desirable to remove that limitation, but that's more involved. A possibility could be to have a "at-hand" parser to delimitate JSon "Feature" objects and use only json-c to parse each feature. But GeoJSON is certainly not the more appropriate file format to deal with huge datasets... Cheers, Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GDAL 2.1 can update Geojson files - What is missing in QGIS to edit GeoJSON files ?
Le jeudi 14 janvier 2016 16:38:43, Matthias Kuhn a écrit : > Hi Michaël > > On 01/14/2016 04:18 PM, kimaidou wrote: > > Hi QGIS, > > > > I have read that GDAL can now update GeoJSON since version 2.1.0. See > > [1] > > > > If I build QGIS with GDAL 2.1, would I be able to edit the GeoJSON as > > I can for Shapefiles ? For the record, capabilities are defined here [2] > > > > Perhaps the GDAL doc about "updating existing GeoJSON files" has a > > different meaning that the need raised by Even Rouault here [3] > > > > Or is the best approach to create a specific QGIS driver for GeoJSON ? > > I would try to propose a PR for this if this is the best way to go. > > Giving GDAL 2.1 a try will be way less effort than implementing a > GeoJSON driver inside QGIS. And if there are things still left to be > fixed, it's probably better to fix things on the GDAL end since this way > the support for it is in a library shared by many FOSSGIS tools. > > (Please note that this recommendation is only meant for non-database > providers. Feel free to propose a native GeoPackage driver ;) ) Just curious to know what advantage a native GeoPackage driver would bring over the one in OGR ? > > All the best -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GDAL 2.1 can update Geojson files - What is missing in QGIS to edit GeoJSON files ?
> It will benefit from expression compiling (for filtering and order by) > which results in performance improvements when it can be applied. I'm not completely sure to know what you refer to in the QGIS context but the OGR SetAttributeFilter() method is directly evaluated by the SQLite request engine as a WHERE clause, and similarly for the ExecuteSQL() API. > > >> All the best -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GDAL 2.1 can update Geojson files - What is missing in QGIS to edit GeoJSON files ?
Le jeudi 14 janvier 2016 18:04:00, Matthias Kuhn a écrit : > On 01/14/2016 05:42 PM, Even Rouault wrote: > >> It will benefit from expression compiling (for filtering and order by) > >> which results in performance improvements when it can be applied. > > > > I'm not completely sure to know what you refer to in the QGIS context but > > the OGR SetAttributeFilter() method is directly evaluated by the SQLite > > request engine as a WHERE clause, and similarly for the ExecuteSQL() > > API. > > It tries to compile QgsExpressions to native SQL syntax. > > I think the point of using OGR that it offers an awesome abstraction > layer where the consumer doesn't need to care about the backend. > > As soon as ExecuteSQL is used this abstraction no longer applies and it > just adds another layer of uncertainty (different library versions...) > and may potentially hide internals of the backends which may be useful > in some cases (datatypes, backend metadata, available indexes, ...), so > the advantage is gone while it complicates advanced topics. > Or did I miss something? - datatypes: all the ones listed in "Table 1. GeoPackage Data Types" http://www.geopackage.org/spec/#_sqlite_container have an OGR equivalent - backend metadata: not sure what you're thinking exactly too. But at some point this has to be translated in the QGIS abstraction too, no ? - available indexes: not present in the OGR abstraction currently (but the abstraction can be extended if needed, as it has been done in the past). Is QGIS aware of which indices exist ? A possibility would be to have a thin GeoPackage provider (I guess it could probably even by generic to most OGR drivers that have native SQL92 capabilities) extending the base OGR one + using its capabilities with the specificities of GPKG (eg adding the SORT BY clause). Or a more quick&dirty way would be to hack that directly in the OGR provider for the vetted OGR drivers. > > >>>> All the best -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GDAL 2.1 can update Geojson files - What is missing in QGIS to edit GeoJSON files ?
Le jeudi 14 janvier 2016 18:49:40, Matthias Kuhn a écrit : > On 01/14/2016 06:32 PM, Even Rouault wrote: > > Le jeudi 14 janvier 2016 18:04:00, Matthias Kuhn a écrit : > >> On 01/14/2016 05:42 PM, Even Rouault wrote: > >>>> It will benefit from expression compiling (for filtering and order by) > >>>> which results in performance improvements when it can be applied. > >>> > >>> I'm not completely sure to know what you refer to in the QGIS context > >>> but the OGR SetAttributeFilter() method is directly evaluated by the > >>> SQLite request engine as a WHERE clause, and similarly for the > >>> ExecuteSQL() API. > >> > >> It tries to compile QgsExpressions to native SQL syntax. > >> > >> I think the point of using OGR that it offers an awesome abstraction > >> layer where the consumer doesn't need to care about the backend. > >> > >> As soon as ExecuteSQL is used this abstraction no longer applies and it > >> just adds another layer of uncertainty (different library versions...) > >> and may potentially hide internals of the backends which may be useful > >> in some cases (datatypes, backend metadata, available indexes, ...), so > >> the advantage is gone while it complicates advanced topics. > >> Or did I miss something? > > > > - datatypes: all the ones listed in "Table 1. GeoPackage Data Types" > > http://www.geopackage.org/spec/#_sqlite_container have an OGR equivalent > > - backend metadata: not sure what you're thinking exactly too. But at > > some point this has to be translated in the QGIS abstraction too, no ? - > > available indexes: not present in the OGR abstraction currently (but the > > abstraction can be extended if needed, as it has been done in the past). > > Is QGIS aware of which indices exist ? > > > > A possibility would be to have a thin GeoPackage provider (I guess it > > could probably even by generic to most OGR drivers that have native > > SQL92 capabilities) extending the base OGR one + using its capabilities > > with the specificities of GPKG (eg adding the SORT BY clause). Or a more > > quick&dirty way would be to hack that directly in the OGR provider for > > the vetted OGR drivers. > > I was referring to databases in general (expression compilation is also > done for MSSQL, Oracle, Postgres) > > I do not doubt that for every requirement an interface can also be > implemented in OGR but it still adds an extra roundtrip in the > development cycle, its presence has to be guaranteed on the client > system (we're still at 1.10.x on win, not sure about all linux distros > and mac) and an extra layer of possible errors, performance loss... I can understand those reasons (althoug I'm a bit skeptical about the performance loss. That would mean the translation from OGRFeature to QGISFeature becomes really significant in performance profiles) > > What would be the advantage of using OGR when using ExecuteSQL? Just that the GPKG driver already exists (that was my main point) and in theory GDAL/OGR is the natural place to deal with file formats. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GDAL 2.1 can update Geojson files - What is missing in QGIS to edit GeoJSON files ?
Le jeudi 14 janvier 2016 20:38:04, Nyall Dawson a écrit :
> On 15 Jan 2016 2:39 AM, "Even Rouault" wrote:
> > A more "streaming-like" approach for the driver not proceeding to full
> > ingestion of features could be desirable to remove that limitation, but
>
> that's
>
> > more involved. A possibility could be to have a "at-hand" parser to
>
> delimitate
>
> > JSon "Feature" objects and use only json-c to parse each feature. But
>
> GeoJSON
>
> > is certainly not the more appropriate file format to deal with huge
>
> datasets...
>
>
> Even,
>
> Editable GeoJSON in OGR is great news!
>
> I've got a question regarding the geojson driver you may be able to assist
> with. Is there any method in the OGR libraries which allow direct parsing
> of a string to a layer? (Ie, without first writing it out to a file).
>
> I'd like to add the ability to directly paste geojson text into QGIS and
> have it inserted as a feature in the current layer (like how you can
> currently paste WKT text as a feature). I don't want to have to manually
> parse the json (that would be a nightmare).
Well, the GeoJSON driver support "filenames" which are in fact GeoJSON content:
$ ogrinfo
'{"type":"Feature","properties":{"foo":"bar"},"geometry":{"type":"Point","coordinates":[2,49]}}'
-ro -al
Layer name: OGRGeoJSON
Geometry: Point
Feature Count: 1
Extent: (2.00, 49.00) - (2.00, 49.00)
Layer SRS WKT:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]
foo: String (0.0)
OGRFeature(OGRGeoJSON):0
foo (String) = bar
POINT (2 49)
Works also with FeatureCollections.
Alternatively, you could also put the content in a in-memory GDAL file
(/vsimem/ virtual file system) and open it.
So you could likely instanciate a temporary layer and get a QGIS feature from
that.
If you are just interested in geometries and not attributes, there's also the C
function :
OGRGeometryHOGR_G_CreateGeometryFromJson (const char *);
>
> If I could somehow take advantage of OGR's geojson driver to do the heavy
> lifting then this work would be trivial.
>
> Any ideas?
>
> Nyall
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GDAL 2.1 can update Geojson files - What is missing in QGIS to edit GeoJSON files ?
Le vendredi 15 janvier 2016 11:55:07, kimaidou a écrit :
> Hi all
>
> I have just tested QGIS master build againt GDAL "trunk" (build via a git
> clone from GDAL github repository & following the doc instructions [1] ).
> It works like a charm with a small roads dataset.
>
> Thanks Even (and other involved devs and funders ) for making this happen !
>
> I have seen one first caveat :
>
> * Export a Shapefile to GeoJSON in QGIS via the "Save as" and choose to
> keep only 1 number for decimal precision
> * Open this GeoJSON file, toggle edition, and add a new feature
> * The new feature geometries are written with default decimal precision
> (for example : 6790978.453365888446569 ) and not like the other original
> features ( for example : 6790978.4 )
>
> We should have a way in QGIS to keep the original decimal precision. Any
> clue on this ? Should I open a ticket ?
This is not something that could get fixed easily. When you open the geojson
file, there's nothing in it explicitly mentionning the decimal precision (and
it could be non uniform). There could be some logic to guess it, but that
wouldn't be trivial since json-c returns a IEEE-754 double and not the
original ASCII representation. A less user friendly but more reliable way
would be to have an open option / env. variable to define the wished precision
when you're in update mode.
>
> Regards
> Michaël
>
> [1] https://trac.osgeo.org/gdal/wiki/BuildingOnUnix
>
> 2016-01-14 20:57 GMT+01:00 Even Rouault :
> > Le jeudi 14 janvier 2016 20:38:04, Nyall Dawson a écrit :
> > > On 15 Jan 2016 2:39 AM, "Even Rouault"
> >
> > wrote:
> > > > A more "streaming-like" approach for the driver not proceeding to
> > > > full ingestion of features could be desirable to remove that
> > > > limitation, but
> > >
> > > that's
> > >
> > > > more involved. A possibility could be to have a "at-hand" parser to
> > >
> > > delimitate
> > >
> > > > JSon "Feature" objects and use only json-c to parse each feature. But
> > >
> > > GeoJSON
> > >
> > > > is certainly not the more appropriate file format to deal with huge
> > >
> > > datasets...
> > >
> > >
> > > Even,
> > >
> > > Editable GeoJSON in OGR is great news!
> > >
> > > I've got a question regarding the geojson driver you may be able to
> >
> > assist
> >
> > > with. Is there any method in the OGR libraries which allow direct
> > > parsing of a string to a layer? (Ie, without first writing it out to
> > > a file).
> > >
> > > I'd like to add the ability to directly paste geojson text into QGIS
> > > and have it inserted as a feature in the current layer (like how you
> > > can currently paste WKT text as a feature). I don't want to have to
> > > manually parse the json (that would be a nightmare).
> >
> > Well, the GeoJSON driver support "filenames" which are in fact GeoJSON
> > content:
> >
> > $ ogrinfo
> > '{"type":"Feature","properties":{"foo":"bar"},"geometry":{"type":"Point",
> > "coordinates":[2,49]}}' -ro -al
> >
> > Layer name: OGRGeoJSON
> > Geometry: Point
> > Feature Count: 1
> > Extent: (2.00, 49.00) - (2.00, 49.00)
> > Layer SRS WKT:
> > GEOGCS["WGS 84",
> >
> > DATUM["WGS_1984",
> >
> > SPHEROID["WGS 84",6378137,298.257223563,
> >
> > AUTHORITY["EPSG","7030"]],
> >
> > AUTHORITY["EPSG","6326"]],
> >
> > PRIMEM["Greenwich",0,
> >
> > AUTHORITY["EPSG","8901"]],
> >
> > UNIT["degree",0.0174532925199433,
> >
> > AUTHORITY["EPSG","9122"]],
> >
> > AUTHORITY["EPSG","4326"]]
> >
> > foo: String (0.0)
> > OGRFeature(OGRGeoJSON):0
> >
> > foo (String) = bar
> > POINT (2 49)
> >
> > Works also with FeatureCollections.
> > Alternatively, you could also put the content in a in-memory GDAL file
> > (/vsimem/ virtual file system) and open it.
> >
> > So you could likely instanciate a temporary layer and get a QGIS feature
> > from that.
> >
> >
> > If you are just interested in geometries and not attributes, there's also
> > the C function :
> >
> > OGRGeometryHOGR_G_CreateGeometryFromJson (const char *);
> >
> > > If I could somehow take advantage of OGR's geojson driver to do the
> > > heavy lifting then this work would be trivial.
> > >
> > > Any ideas?
> > >
> > > Nyall
> >
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Check geometry not fixing errors?
Le vendredi 22 janvier 2016 09:54:07, Paolo Cavallini a écrit : > Il 15/01/2016 17:53, Sandro Mani ha scritto: > > About to leave right now, but if you can just list which layer and which > > checks you picked I should be able to reproduce any issues easily. > > Further test: > > Failed to create the output layer: non riesco a creare il layer (errore > OGR:Geometry type of `Unrecognised: 1003' not supported in shapefiles. > Type can be overridden with a layer creation option > of SHPT=POINT/ARC/POLYGON/MULTIPOINT/POINTZ/ARCZ/POLYGONZ/MULTIPOINTZ. > ) Sounds like a PolygonZ (=1003) is passed to OGR as WKB encoded with ISO SQL/MM to GDAL 1.11 or older. Only GDAL 2.0 will support that. GDAL 1.X will only support old-style 99-402 extended dimension (Z) WKB, so Polygon25D = 0x8003 > > I selected Polygon and/or Multipolygon among Allowed geometry types. > All the best. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Check geometry not fixing errors?
Le vendredi 22 janvier 2016 10:06:59, Paolo Cavallini a écrit : > Il 22/01/2016 10:02, Even Rouault ha scritto: > > Sounds like a PolygonZ (=1003) is passed to OGR as WKB encoded with ISO > > SQL/MM to GDAL 1.11 or older. Only GDAL 2.0 will support that. GDAL 1.X > > will only support old-style 99-402 extended dimension (Z) WKB, so > > Polygon25D = 0x8003 > > Thanks Even. In this case, the plugin would be essentially broken in all > systems with gdal<2 (as in Debian sid9), right? Yes, it seems than any 3D geometry outputted by this plugin will not be GDAL 1.X compatible. 2D geometries should be OK though. Perhaps there's somewhere in QGIS code base a way of converting ISO WKB to old-style WKB ? > I'm using current master from debs. > All the best. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QEP: WFS provider enhancements
Hi, I've submitted a QEP related to enhancements in the WFS provider (WFS 1.1/2.0 support, on-disk cache, server-side joins, ...) : https://github.com/qgis/QGIS-Enhancement-Proposals/issues/53 I'd be happy to hear opinions on this. Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QEP: WFS provider enhancements
Le mardi 26 janvier 2016 20:23:41, Andreas Neumann a écrit : > Hi Even, > > Interesting - does this mean QGIS will be a WFS 2.0 compatible WFS > client in the future? Yes that's the intent (with the restrictions mentionned in the QEP) > > Out of curiosity: may I ask who will be funding the project? I'll be able to communicate on that once this has been secured with them. > How likely > will this land in the upcoming QGIS version (2.16/3.0)? I'm not sure if the planning of the next QGIS version has been decided yet, but this is likely something that would be done this first semester. > > We just talked about the WFS client problems today at my new employer. > We also had problems, that QGIS did not load/display all features that > were served by our WFS server. Other WFS clients (FME, Geomedia) did > load all of the features. Potentially related to > https://hub.qgis.org/issues/11968 - I will have to investigate. > > Anyway - glad to hear that there will be some work done to improve the > sad state of QGIS as a WFS client. > > Thanks, > Andreas > > On 26.01.2016 19:14, Even Rouault wrote: > > Hi, > > > > I've submitted a QEP related to enhancements in the WFS provider (WFS > > 1.1/2.0 support, on-disk cache, server-side joins, ...) : > > https://github.com/qgis/QGIS-Enhancement-Proposals/issues/53 > > > > I'd be happy to hear opinions on this. > > > > Best regards, > > > > Even > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WKB support is only little-endian?
Le mardi 26 janvier 2016 23:11:28, David Adler a écrit :
> We just realized that DB2 on z/OS uses big-endian, first byte = x'00'.
>
> This doesn't appear to work with the QgsGeometry->fromWkb() function.
Looking quickly it seems that indeed QgsGeometryFactory::geomFromWkb() assumes
host ordering, but the QgsConstWkbPtr class used by the various
Qgs{Geometry]v2::fromWkb() methods seem to support byte swapping when WKB
endianness != host endianness. So you might just need to fix
QgsGeometryFactory::geomFromWkb() to make that work.
>
> We have other alternatives but were just wondering.
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Help needed setting up Ubuntu build environment
Le mercredi 10 février 2016 23:43:44, David Adler a écrit : > The instructions at > http://qgis.org/en/site/getinvolved/development/qgisdevelopersguide/qtcreat > or.html have a link for "detailed instructions" but the link doesn't work. > > I'm up to the CMake error "Could not find GEOS". > sudo apt-get install GEOS > sudo apt-get install geos > don't succeed. $ dpkg -l | grep geos ii libgeos-3.4.2 3.4.2-4ubuntu1 amd64Geometry engine for Geographic Information Systems - C++ Library ii libgeos-c13.4.2-4ubuntu1 amd64Geometry engine for Geographic Information Systems - C Library ii libgeos-dev 3.4.2-4ubuntu1 amd64Geometry engine for GIS - Development files > > I haven't previously used QtCreator or CMake on Ubuntu. > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Reading GEOJSON from string using GDAL
Le vendredi 19 février 2016 01:30:59, Nyall Dawson a écrit :
> On 15 January 2016 at 06:57, Even Rouault
wrote:
> >> I've got a question regarding the geojson driver you may be able to
> >> assist with. Is there any method in the OGR libraries which allow
> >> direct parsing of a string to a layer? (Ie, without first writing it
> >> out to a file).
> >>
> >> I'd like to add the ability to directly paste geojson text into QGIS and
> >> have it inserted as a feature in the current layer (like how you can
> >> currently paste WKT text as a feature). I don't want to have to manually
> >> parse the json (that would be a nightmare).
> >
> > Well, the GeoJSON driver support "filenames" which are in fact GeoJSON
> > content:
> >
> > $ ogrinfo
> > '{"type":"Feature","properties":{"foo":"bar"},"geometry":{"type":"Point"
> > ,"coordinates":[2,49]}}' -ro -al
> >
> > Layer name: OGRGeoJSON
> > Geometry: Point
> > Feature Count: 1
> > Extent: (2.00, 49.00) - (2.00, 49.00)
> > Layer SRS WKT:
> > GEOGCS["WGS 84",
> >
> > DATUM["WGS_1984",
> >
> > SPHEROID["WGS 84",6378137,298.257223563,
> >
> > AUTHORITY["EPSG","7030"]],
> >
> > AUTHORITY["EPSG","6326"]],
> >
> > PRIMEM["Greenwich",0,
> >
> > AUTHORITY["EPSG","8901"]],
> >
> > UNIT["degree",0.0174532925199433,
> >
> > AUTHORITY["EPSG","9122"]],
> >
> > AUTHORITY["EPSG","4326"]]
> >
> > foo: String (0.0)
> > OGRFeature(OGRGeoJSON):0
> >
> > foo (String) = bar
> > POINT (2 49)
> >
> > Works also with FeatureCollections.
> > Alternatively, you could also put the content in a in-memory GDAL file
> > (/vsimem/ virtual file system) and open it.
> >
> > So you could likely instanciate a temporary layer and get a QGIS feature
> > from that.
>
> Hi Even,
>
> I'm currently exploring this approach (in memory file), but I'm stuck
> on how to actually write the string contents to a memory file prior to
> opening to it with GDAL. I gather for the python bindings I could
> utilise FileFromMemBuffer, but I can't find any similar replacement in
> the c api.
VSIFileFromMemBuffer :
http://www.gdal.org/cpl__vsi_8h.html#a86b6b1c37bb19d954ee3c4a7e910120c
And some code snippet here :
http://www.gdal.org/cpl__vsi_8h.html#a66e2e6f093fd42f8a941b962d4c8a19e
>
> What's the correct approach to use here?
>
> Nyall
>
> > If you are just interested in geometries and not attributes, there's also
> > the C function :
> >
> > OGRGeometryHOGR_G_CreateGeometryFromJson (const char *);
> >
> >> If I could somehow take advantage of OGR's geojson driver to do the
> >> heavy lifting then this work would be trivial.
> >>
> >> Any ideas?
> >>
> >> Nyall
> >
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Proposed plan to fix issue with concurrent opening of OGR datasources (aka QGIS and MapInfo)
Hi, I'm considering addressing an issue that mainly involves concurrent use of a MapInfo TAB dataset by QGIS and MapInfo, as described in https://hub.qgis.org/issues/14378, although the planned fix would be a bit more general. The problem is that when QGIS opens a OGR datasource it tries to open it with the update mode of the OGROpen() API, which in turn opens the underlying file(s) with a mode (dwDesiredAccess = GENERIC_READ | GENERIC_WRITE and dwShareMode = FILE_SHARE_READ | FILE_SHARE_WRITE with the Windows CreateFile API()) that is incompatible with the mode with which MapInfo tries to open files in read-only (dwDesiredAccess = GENERIC_READ and dwShareMode = FILE_SHARE_READ). Hence MapInfo cannot open a MapInfo dataset already opened by QGIS in update mode. The solution I'm considering would be to modify the QGIS OGR provider to : - try to open the dataset in update mode as currently, but if it is successful, go back to re-opening it in read-only mode. (we need to try to open in update mode so as to have appropriate capabilities) - for operations like addFeatures(), addAttributes(), etc ... that need update permissions, check the current open mode, and if not update mode already, re- open the OGR datasource in update mode - go back to read-only mode when the user exists the edition mode (this would need a new method in the QgsVectorDataProvider API to warn about that, since the provider has currently no way of knowing that) There would be of course a cost to pay due to this open / close operations, so I think I would limit it to shapefiles and mapinfo for now, since the opening of such datasets doesn't involve a lot of I/O ( the most costly is for shapefiles where the whole .shx is ingested into memory ). Another related fix would be to implement reloadData() in the OGR provider so that the user can resynchronize its QGIS session for a dataset modified by another software. Thoughts ? Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Proposed plan to fix issue with concurrent opening of OGR datasources (aka QGIS and MapInfo)
> > - go back to read-only mode when the user exists the edition mode (this > > would need a new method in the QgsVectorDataProvider API to warn about > > that, since the provider has currently no way of knowing that) > > I think the postgres provider already has a similar concept for > connection pooling. For read-only operations, a shared r/o connection > from the connection pool is obtained. When writing is required, a new > "transaction" connection with write capabilities is opened for the > duration of the r/w session. Maybe this concept can be mirrored by the > ogr provider? Hum, I've just looked at QgsTransaction / QgsPostgresTransaction and it is really meant at providers that can implement a real SQL transaction mechanism with BEGIN / COMMIT / ROLLBACK which most OGR datasources don't support, and in particular the MapInfo driver does not. In QgsVectorLayer::startEditing(), if there's a transaction returned by the provider, it goes through "pass- through" mode instead of the edition buffer that gets "committed" only when the user saves its edition session. So I don't think the postgres way can be used in the OGR provider. > > > There would be of course a cost to pay due to this open / close > > operations, so I think I would limit it to shapefiles and mapinfo for > > now, since the opening of such datasets doesn't involve a lot of I/O ( > > the most costly is for shapefiles where the whole .shx is ingested into > > memory ). > > > > Another related fix would be to implement reloadData() in the OGR > > provider so that the user can resynchronize its QGIS session for a > > dataset modified by another software. > > Concerning the reloadData() method, there is already a forceReload() > method which reloads a changed dataset (on request) in QGIS. Hum, there's indeed a forceReload() method, only implemented by the OGR provider AFAICS and only used by qgsattributetabledialog (when you hit the Refresh button in the attribute dialog), that refreshes the read-only connections, but not the main connection maintained by the provider. There's also the reloadData() method implemented by the WFS/WCS/WMS providers, and called by QgsVectorLayer/QgsRasterLayer::reload(), for example when you refresh the view with F5. By implementing that one, I'd also close and re- open the OGRDataSourceH ogrDataSource member of the OGR provider. The existence of both API is a bit confusing. I guess the implementations should do the same thing. Hum. > Is your > plan to implement a "change detection" and trigger this action > automatically? I've considered this, but this is not in my immediate plans. With GDAL 2.0, GDALDatasetGetFileList() could be potentially used for that (since GDAL 2.0, a OGRDataSourceH can be cast as a GDALDatasetH). -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Proposed plan to fix issue with concurrent opening of OGR datasources (aka QGIS and MapInfo)
> > - go back to read-only mode when the user exists the edition mode (this
> > would need a new method in the QgsVectorDataProvider API to warn about
> > that, since the provider has currently no way of knowing that)
>
> Thank you for taking care of that.
>
> Could you elaborate on the last item ? Does it mean adding something
> like beginEdit() / endEdit() on QgsVectorDataProvider ?
Yes
> Is it an API break
API extension I'd say. The default implementation would be {}.
> and if not how does it work for existing code that
> does not call begin/end edit ?
From what I can see in QgsVectorLayer, you cannot call addFeature(),
addFeatures(), changeAttributeValue(), deleteFeature(), deleteFeatures(),
etc.. if there's no mEditBuffer active. And the only way to have one active is
to call startEditing() before. So unless I'm missing something, it doesn't
look like you can do changes to a dataset without doing them between
startEditing() and commitChanges()/rollBack()
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Proposed plan to fix issue with concurrent opening of OGR datasources (aka QGIS and MapInfo)
Le mardi 22 mars 2016 11:39:07, Hugo Mercier a écrit :
> On 22/03/2016 11:27, Even Rouault wrote:
> >>> - go back to read-only mode when the user exists the edition mode (this
> >>> would need a new method in the QgsVectorDataProvider API to warn about
> >>> that, since the provider has currently no way of knowing that)
> >>
> >> Thank you for taking care of that.
> >>
> >> Could you elaborate on the last item ? Does it mean adding something
> >> like beginEdit() / endEdit() on QgsVectorDataProvider ?
> >
> > Yes
> >
> >> Is it an API break
> >
> > API extension I'd say. The default implementation would be {}.
> >
> >> and if not how does it work for existing code that
> >> does not call begin/end edit ?
> >
> > From what I can see in QgsVectorLayer, you cannot call addFeature(),
> > addFeatures(), changeAttributeValue(), deleteFeature(), deleteFeatures(),
> > etc.. if there's no mEditBuffer active. And the only way to have one
> > active is to call startEditing() before. So unless I'm missing
> > something, it doesn't look like you can do changes to a dataset without
> > doing them between startEditing() and commitChanges()/rollBack()
>
> True.
> But you can also directly access the provider update methods without
> edit buffers and without startEditing / commitChanges.
Good point. I didn't think at that use case of direct access to the provider
API.
>
> ... but after all ... if I understood correctly your intents, for
> existing codes that use this direct provider access, update functions
> will reopen the source in write mode and they will always stay in that
> mode because the endEdit() method will never be called ?
Yes.
One possibility would be also to go back to read-only mode with a timer. For a
write operation, outside of beginEdit() / endEdit(), that lead to re-opening
in update-mode, after X seconds without write activity, the dataset would be
re-opened in update mode.
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Proposed plan to fix issue with concurrent opening of OGR datasources (aka QGIS and MapInfo)
Le mardi 22 mars 2016 12:08:07, Even Rouault a écrit :
> Le mardi 22 mars 2016 11:39:07, Hugo Mercier a écrit :
> > On 22/03/2016 11:27, Even Rouault wrote:
> > >>> - go back to read-only mode when the user exists the edition mode
> > >>> (this would need a new method in the QgsVectorDataProvider API to
> > >>> warn about that, since the provider has currently no way of knowing
> > >>> that)
> > >>
> > >> Thank you for taking care of that.
> > >>
> > >> Could you elaborate on the last item ? Does it mean adding something
> > >> like beginEdit() / endEdit() on QgsVectorDataProvider ?
> > >
> > > Yes
> > >
> > >> Is it an API break
> > >
> > > API extension I'd say. The default implementation would be {}.
> > >
> > >> and if not how does it work for existing code that
> > >> does not call begin/end edit ?
> > >
> > > From what I can see in QgsVectorLayer, you cannot call addFeature(),
> > > addFeatures(), changeAttributeValue(), deleteFeature(),
> > > deleteFeatures(), etc.. if there's no mEditBuffer active. And the only
> > > way to have one active is to call startEditing() before. So unless I'm
> > > missing something, it doesn't look like you can do changes to a
> > > dataset without doing them between startEditing() and
> > > commitChanges()/rollBack()
> >
> > True.
> > But you can also directly access the provider update methods without
> > edit buffers and without startEditing / commitChanges.
>
> Good point. I didn't think at that use case of direct access to the
> provider API.
>
> > ... but after all ... if I understood correctly your intents, for
> > existing codes that use this direct provider access, update functions
> > will reopen the source in write mode and they will always stay in that
> > mode because the endEdit() method will never be called ?
>
> Yes.
>
> One possibility would be also to go back to read-only mode with a timer.
> For a write operation, outside of beginEdit() / endEdit(), that lead to
> re-opening in update-mode, after X seconds without write activity, the
> dataset would be re-opened in update mode.
correction: "...would be re-opened in *read-only* mode"
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Proposed plan to fix issue with concurrent opening of OGR datasources (aka QGIS and MapInfo)
Le mardi 22 mars 2016 13:53:10, Matthias Kuhn a écrit : > On 03/22/2016 01:44 PM, Hugo Mercier wrote: > > On 22/03/2016 12:11, Even Rouault wrote: > >>>> True. > >>>> But you can also directly access the provider update methods without > >>>> edit buffers and without startEditing / commitChanges. > >>> > >>> Good point. I didn't think at that use case of direct access to the > >>> provider API. > >>> > >>>> ... but after all ... if I understood correctly your intents, for > >>>> existing codes that use this direct provider access, update functions > >>>> will reopen the source in write mode and they will always stay in that > >>>> mode because the endEdit() method will never be called ? > >>> > >>> Yes. > >>> > >>> One possibility would be also to go back to read-only mode with a > >>> timer. For a write operation, outside of beginEdit() / endEdit(), that > >>> lead to re-opening in update-mode, after X seconds without write > >>> activity, the dataset would be re-opened in update mode. > >> > >> correction: "...would be re-opened in *read-only* mode" > > > > I am not sure to like this timeout ... I prefer when the state of > > objects does not silently change in background :) > > Doing nothing would be ok: existing (plugin) codes would lock under > > windows, which is already the case, and would have the opportunity to be > > safer by calling endEdit(). > > What about adding the re-open file code at the beginning and end of the > dataprovider functions (QgsOgrProvider::addFeatures etc.)? That could be done for sure, but wouldn't there be performance issues if the editing API of the provider are called multiple times in a sequence ? Although the methods that change the features take multiple features at once, so the effect of re-opening at the beginning and end of the provider functions might be limited. > > If we're afraid that there is too little control this way, we could > still add a controlled "update state" to the provider and in case this > is already set, the re-opening will be skipped. That's a bit equivalent to the beginEdit() / endEdit(). We could have as valid scenarios : 1. beginEdit() ( or setUpdateMode(true) ) 2. addFeatures() 3. endEdit() ( or setUpdateMode(false) ) or 1. addFeatures() --> re-open implicitly to update mode if not already done, do the operation and let it in update mode or 1. addFeatures() --> re-open implicitly to update mode if not already done, do the operation and let it in update mode 2. endEdit() ( or setUpdateMode(false) ) --> go back to read-only mode -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Using app MessageBar from providers ?
Hi, For the WFS provider, I'd like some messages, like a partial feature download, to be emitted in a more prominent way than just in the message log. The MessageBar would be appropriate for that, but from what I can see, it is not currently possible for a provider to use it. A search in src/providers shows that the same need was at least encountered once in the GRASS provider but the code is commented out as the provider doesn't link against qgis_app. So unless there's a good reason for a provider not to be able to use the message bar, I was thinking to the following mechanism to implement it : - QgsMessageLog would be extended to have 2 extra arguments bool displayInMessagerBar = false, int duration = 0 in logMessage() / messageReceived() - QgisApp would connect on messageReceived() and when the boolean is set, it would push the message to the main message bar. Any thoughts ? Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Using app MessageBar from providers ?
Le dimanche 10 avril 2016 15:21:14, Luigi Pirelli a écrit : > a provider does not need necessarily an iface where to send GUI > messages (e.g pyqgis scripts) IMHO is one reason. Yes I know. Hence my proposal. The provider would continue using the message log interface, so with its current behaviour still preserved, but with an extra hint when the message is also aimed at being prominently displayed, if possible. In the case qgis_app is started it would listen for that and redirect the message to the message bar too. > > regards > Luigi Pirelli > > *** > *** * Boundless QGIS Support/Development: lpirelli AT > boundlessgeo DOT com * LinkedIn: https://www.linkedin.com/in/luigipirelli > * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli > * GitHub: https://github.com/luipir > * Mastering QGIS: > https://www.packtpub.com/application-development/mastering-qgis > *** > ******* > > On 10 April 2016 at 15:12, Even Rouault wrote: > > Hi, > > > > For the WFS provider, I'd like some messages, like a partial feature > > download, to be emitted in a more prominent way than just in the message > > log. The MessageBar would be appropriate for that, but from what I can > > see, it is not currently possible for a provider to use it. A search in > > src/providers shows that the same need was at least encountered once in > > the GRASS provider but the code is commented out as the provider doesn't > > link against qgis_app. > > > > So unless there's a good reason for a provider not to be able to use the > > message bar, I was thinking to the following mechanism to implement it : > > - QgsMessageLog would be extended to have 2 extra arguments bool > > displayInMessagerBar = false, int duration = 0 in logMessage() / > > messageReceived() > > - QgisApp would connect on messageReceived() and when the boolean is set, > > it would push the message to the main message bar. > > > > Any thoughts ? > > > > Even > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com > > ___ > > Qgis-developer mailing list > > Qgis-developer@lists.osgeo.org > > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Using app MessageBar from providers ?
Le lundi 11 avril 2016 07:19:17, Denis Rouzaud a écrit : > Hi, > > That sounds a bit weird to me. > > Shouldn't it be the application which decide (filter) what to show from > core log messages? > Couldn't we use some error levels or tags to achieve this? QgsMessageLog has the following error levels : INFO, WARNING, CRITICAL. (I couldn't really find a description of the semantics behind by the way) QgsMessageBar has the same + SUCCESS. The default level of QgsMessageLog::logMessage() is WARNING, and greping in the source shows that in most cases, it is let to the default. Tags (as defined in QgsMessageLog) indicate the component from which the messages comes from, so I don't think they can be used for redirect to message bar. CRITICAL is very rarely used, as shown by the following grep in src/ , so if we don't want to have an explicit displayMessage argument, potentially the app could decide to redirect only CRITICAL messages to the MessageBar ? $ grep -r QgsMessageLog::CRITICAL ../src/ | grep -v "src/server" ../src/core/qgsproject.cpp: QgsMessageLog::logMessage( errorString, QString::null, QgsMessageLog::CRITICAL ); ../src/core/qgsgml.cpp:QgsMessageLog::CRITICAL ../src/core/qgsgml.cpp: QgsMessageLog::CRITICAL ../src/providers/ogr/qgsogrprovider.cpp: QgsMessageLog::logMessage( tr( "Possible corruption after REPACK detected. %1 still exists. This may point to a permission or locking problem of the original DBF." ).arg( packedDbf ), tr( "OGR" ), QgsMessageLog::CRITICAL ); ../src/providers/ogr/qgsogrprovider.cpp: QgsMessageLog::logMessage( tr( "Original layer could not be reopened." ), tr( "OGR" ), QgsMessageLog::CRITICAL ); ../src/providers/ogr/qgsogrprovider.cpp:QgsMessageLog::logMessage( tr( "Original datasource could not be reopened." ), tr( "OGR" ), QgsMessageLog::CRITICAL ); > > That just doesn't sound like a good API to have core function with > displayMessage as argument. > > But maybe I'm missing a part of the picture. The precise use case is when the download of a WFS layer fails for some reason (network timeout, invalid server response), it is not always obvious for the user to realize so. A prominent message saying that the layer content is truncated would be helpful so he can decide for example to reload the layer, etc... > > Denis > > On 04/11/2016 01:33 AM, Nathan Woodrow wrote: > > Hey Even, > > > > I think this solution is fine. The other option I thought of in the > > past was to have some kind of signal on the provider that gets passed > > up and connected at a higher level. > > Using QgsMessageLog is a good idea as it's generic and can be used by > > everyone. > > > > Regards, > > > > On Sun, Apr 10, 2016 at 11:25 PM, Even Rouault > > > > mailto:even.roua...@spatialys.com>> wrote: > > Le dimanche 10 avril 2016 15:21:14, Luigi Pirelli a écrit : > > > a provider does not need necessarily an iface where to send GUI > > > messages (e.g pyqgis scripts) IMHO is one reason. > > > > Yes I know. Hence my proposal. The provider would continue using > > the message > > log interface, so with its current behaviour still preserved, but > > with an > > extra hint when the message is also aimed at being prominently > > displayed, if > > possible. In the case qgis_app is started it would listen for that > > and redirect the message to the message bar too. > > > > > regards > > > Luigi Pirelli > > > > * > > ** > > > > > *** * Boundless QGIS Support/Development: > > lpirelli AT > > > > > boundlessgeo DOT com * LinkedIn: > > https://www.linkedin.com/in/luigipirelli > > > > > * Stackexchange: > > http://gis.stackexchange.com/users/19667/luigi-pirelli > > > > > * GitHub: https://github.com/luipir > > > * Mastering QGIS: > > > https://www.packtpub.com/application-development/mastering-qgis > > > > * > > ** > > > > > *** > > > > > > On 10 April 2016 at 15:12, Even Rouault > > > > mailto:even.roua...@spatialys.com>> > > > > wrote: > > > > Hi, > > > > > > > > For the WFS provider, I
Re: [Qgis-developer] Using app MessageBar from providers ?
Le lundi 11 avril 2016 16:25:58, Matthias Kuhn a écrit : > Can't you emit a raiseError(QString) from the dataprovider for this? Oh, I didn't realize that existed. Thanks ! I'll have to do some signal forwarding since the error is emitted from an object that is a bit disconnected from the provider itself, but that should be doable. Testing quickly, I see that pushError() only pushes to the message bar and not the message log. Is it really intended ? Another potential issue with the current implementation, that isn't a problem in my current use case, is that pushError() is without effect if called from the provider constructor, since the raiseError() signal of the provider can of course be forwarded to the layer raiseError() only after construction. Probably that QgsVectorLayer::setDataProvider() should examine the list of errors just after constructing the data provider and raise them. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Different GeoJson results from QgsVectorFileWriter.writeAsVectorFormat() on different systems
Le mercredi 20 avril 2016 17:37:21, Tom Chadwin a écrit :
> My system (QGIS 2.14.1 Win7x64):
>
> { "type": "Feature", "properties": { "ID": "1" }, "geometry": { "type":
> "Point", "coordinates": [ -162.97528075057517, 67.562080385426 ] } }
>
> Travis (QGIS ?2.8.?, Ubuntu Trusty):
>
> { "type": "Feature", "properties": { "ID": 1.00 }, "geometry": {
> "type": "Point", "coordinates": [ -162.975280750575166, 67.562080385426 ]
> } }
>
> The ID field in QGIS says it is:
>
> Type: qlonglong
> Type name: Integer64
> Length: 10
> Precision: 0
>
> What could cause one system to export as an int delimited by quotes, and
> the other to generate 6 decimal places, but not delimit with quotes?
>
>
Answer is there :-)
https://github.com/qgis/QGIS/blob/master/src/core/qgsvectorfilewriter.cpp#L364
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Questions about QgsEditorWidgetWrapper value() / setValue()
Hi, I'm trying to understand the abstraction of QgsEditorWidgetWrapper. 1) Semantics question Am I right that there's no guarantee (and that's actually intended) that the following pseudo-code is true : setValue(v) assert value() == v For example in the QgsValueRelationWidgetWrapper(), value() returns the value of the value column of the referenced layer, which corresponds to the key provided to setValue(). And that's value() that is used when displaying the attribute table in table view mode. So this value() method is more a displayValue(), right ? And setValue() would be setRawValue() / setSourceValue() ? 2) Implementation of QgsRelationReferenceWidgetWrapper. The value() method in that case actually returns the foreign key set by setValue(). Is that intended ? To have similar behaviour as QgsValueRelationWidgetWrapper, one could rather expect value() to return the evaluation of the display expression, no ? If the current behaviour is intended, is there something in the abstraction of QgsEditorWidgetWrapper that could return the evaluation of the display expression for a QgsRelationReferenceWidgetWrapper ? Thanks Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Questions about QgsEditorWidgetWrapper value() / setValue()
Hi Matthias, > > value() should return the real/raw value. Returning the display value is > wrong. OK, looking closer, my below comment about QgsRelationReferenceWidgetWrapper::value() returning the displayed values was actually wrong. > > > 2) Implementation of QgsRelationReferenceWidgetWrapper. > > The value() method in that case actually returns the foreign key set by > > setValue(). Is that intended ? To have similar behaviour as > > QgsValueRelationWidgetWrapper, one could rather expect value() to return > > the evaluation of the display expression, no ? > > If the current behaviour is intended, is there something in the > > abstraction of QgsEditorWidgetWrapper that could return the evaluation > > of the display expression for a QgsRelationReferenceWidgetWrapper ? > > For this there is QgsEditorWidgetFactory::representString > https://qgis.org/api/classQgsEditorWidgetFactory.html#a6805c62cc859478b4d47 > 15b3819ce24f Thanks, that make sense. And it is actually implemented by QgsRelationReferenceWidgetWrapper. Wouldn't make it sense then for QgsRelationReferenceWidgetWrapper to implement it and return the evaluation of the display expression ? Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Questions about QgsEditorWidgetWrapper value() / setValue()
> Thanks, that make sense. And it is actually implemented by > QgsRelationReferenceWidgetWrapper. Arg, I meant QgsValueRelationWidgetFactory. It is *not* by QgsRelationReferenceFactory, hence my question about the appropriatness of doing so. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Processing] GDAL - Clip raster by extent : is NODATA param optional ?
Le lundi 25 avril 2016 22:29:52, Giovanni Manghi a écrit : > > Hi all, > > > > I encountered some trouble to integrate 'GDAL - Clip raster by extent' > > in a model. > > > > The NODATA param is described as 'Nodata value, leave blank to take the > > nodata value from input' and it is not optional. There is no problem if > > the algorithm is executed alone. But when we integrated 'GDAL - Clip > > raster by extent' in a model with an empty value for NODATA, because the > > field is empty, the algorithm can't be added. > > > > The easy way to fix it is to decalre NODATA param as optional. What do > > you think about it ? > > > > Do you know other potential optional parameters ? > > > > René-Luc > > Hi, > > I made a PR to fix it. > > By the way, recently in this GDAL gdal_translate (used to clip by > extent) has been added the parameter > > -wo OPTIMIZE_SIZE=TRUE > > but this is not documented > > http://www.gdal.org/gdal_translate.html > > and in fact the command run from Processing fails on master because of it. > > Can I remove it? Would be appropriate. -wo is a gdalwarp specific option > > cheers > > -- G -- > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] python/ogr problems reading large gml file
Le lundi 02 mai 2016 15:38:45, Richard Duivenvoorde a écrit : > Hi Devs, > > (below all via python/plugin on Debian/Linux): > > Via a WFS I retrieve 1 features as GML as data.gml > To be able to read (attr+geometry) the GML I copy a data.gfs next to it. > > Now all seems ok, untill the number of features returned is > 1500. > Strange errors like: > > ogrinfo -ro data.gml reports a (None) geometry > BUT if I 'touch' the data.gfs ogrinfo, then suddenly all is ok > Seems like ogrinfo does not like the copied gfs at first? > Permissions are ok. A 'touch /tmp/foo/data.gfs' is enough. The OGR GML driver only uses the .gfs file if its modification time is equal or greater than the the one of the .gml file (to avoid using an outdated .gfs file). If you run ogrinfo with --debug on, you'll see a message about that. Should probably be a more verbose warning. > > Off course the same holds for QGIS, if I open the retrieved and saved > gml file as a gml-vectorlayer, a 1000 feature containing one is probably > ok, but <1500 often fails and the 1 one ALWAYS fails (untill I > 'touch' the gfs file). > IF something goes wrong: there is no exception, and 'layer.isValid()' > returns true, but geometry/attributes are None at such moment. > > I'm pretty carefull with closing/opening the files (I think), but it > smells like either files that are still open, OR python loosing it's > handles or so? > > Anybody some idea on what I am doing wrong? > Sorry, cannot sent you a wfs-url it's an internal service here. > > Thansk for any pointers > > Regards, > > Richard Duivenvoorde > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] python/ogr problems reading large gml file
Le lundi 02 mai 2016 16:37:13, Richard Duivenvoorde a écrit :
> Thanks Even!
>
> so
> os.utime(os.path.join('/tmp/foo/data.gfs'), None)
> fixed all my strange problems :-)
>
> apparently it was a some race-problem of the closing time of the gml
> file on disk and the modification time of the gfs: smaller files just
> worked etc etc..
>
> anyway: thanks!
> Maybe a warning about ignoring the 'old' gfs would be nice...
>
> I tried:
> $ ogrinfo --debug data1.gml
> but that did not show me more info
>
> Then I did:
> $ ogrinfo --debug
> ERROR 1: --debug option given without debug level.
The syntax is "--debug on" to enable all debug messages. And "--debug
component_name" to enable only the ones in component_name
>
> Should I be able to use --debug from cli anyway?
>
> Regards,
>
> Richard
>
> On 02-05-16 15:50, Even Rouault wrote:
> > Le lundi 02 mai 2016 15:38:45, Richard Duivenvoorde a écrit :
> >> Hi Devs,
> >>
> >> (below all via python/plugin on Debian/Linux):
> >>
> >> Via a WFS I retrieve 1 features as GML as data.gml
> >> To be able to read (attr+geometry) the GML I copy a data.gfs next to it.
> >>
> >> Now all seems ok, untill the number of features returned is > 1500.
> >> Strange errors like:
> >>
> >> ogrinfo -ro data.gml reports a (None) geometry
> >> BUT if I 'touch' the data.gfs ogrinfo, then suddenly all is ok
> >> Seems like ogrinfo does not like the copied gfs at first?
> >> Permissions are ok. A 'touch /tmp/foo/data.gfs' is enough.
> >
> > The OGR GML driver only uses the .gfs file if its modification time is
> > equal or greater than the the one of the .gml file (to avoid using an
> > outdated .gfs file). If you run ogrinfo with --debug on, you'll see a
> > message about that. Should probably be a more verbose warning.
> >
> >> Off course the same holds for QGIS, if I open the retrieved and saved
> >> gml file as a gml-vectorlayer, a 1000 feature containing one is probably
> >> ok, but <1500 often fails and the 1 one ALWAYS fails (untill I
> >> 'touch' the gfs file).
> >> IF something goes wrong: there is no exception, and 'layer.isValid()'
> >> returns true, but geometry/attributes are None at such moment.
> >>
> >> I'm pretty carefull with closing/opening the files (I think), but it
> >> smells like either files that are still open, OR python loosing it's
> >> handles or so?
> >>
> >> Anybody some idea on what I am doing wrong?
> >> Sorry, cannot sent you a wfs-url it's an internal service here.
> >>
> >> Thansk for any pointers
> >>
> >> Regards,
> >>
> >> Richard Duivenvoorde
> >> ___
> >> Qgis-developer mailing list
> >> Qgis-developer@lists.osgeo.org
> >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Who do I talk about problems with NITF images not using the math model?
Le mardi 03 mai 2016 15:17:57, Jim Bellenger a écrit : > Who do I need to talk to about the issue that QGIS displays NITF imagery > but it doesn't use the RPC math model to orient the image and display the > coordinates? I've just submitted a pull request so that RPC are used to automagically warp the imagery : https://github.com/qgis/QGIS/pull/3056 You can workaround this by doing : gdalwarp your.nitf your.nitf.vrt -of VRT and opening your.nitf.vrt You can also create a real GeoTIFF for a more smoother experience after the initial conversion: gdalwarp your.nitf your.nitf.tif Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Attribute table broken (duplicated fields) in master
Hi, just noticed a recent strange behaviour of the attribute table in table mode : it displays the right number of columns, but their name and content is the one of the first attribute. It affects several providers so it seems to be really an attribute table issue. I indeed see a number of commits in that area in the last couple days. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Attribute table broken (duplicated fields) in master
Le jeudi 05 mai 2016 00:10:09, Matthias Kuhn a écrit : > Hi Even, > > On 04/05/16 23:45, Even Rouault wrote: > > Hi, > > > > just noticed a recent strange behaviour of the attribute table in table > > mode : it displays the right number of columns, but their name and > > content is the one of the first attribute. It affects several providers > > so it seems to be really an attribute table issue. I indeed see a number > > of commits in that area in the last couple days. > > > > Even > > Can you open an issue and assign it to me? Done : http://hub.qgis.org/issues/14766 > Can you try to reorder the > columns (there's a button on the right side of the toolbar) and check if > that fixes the issue. No, that doesn't help. > I'll be out of office though the next days, so I'm sorry that I can't > handle it before the weekend. > > Matthias > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS commit rights
Le lundi 09 mai 2016 19:06:22, Paolo Cavallini a écrit : > Hi Even, > as you may know, we agreed in granting you write access to qgis repo. > It’s obviously a pleasure and an honour for us to have you on board. > If yuo agree, please send us an acceptance of the coding and community > guidelines, and Marco (cc) will add you to GitHub committers. > All the best, and thanks for your precious contributions! Hi, Hereby I state I've read and agreed on the contributor guidelines : http://hub.qgis.org/projects/quantum-gis/wiki/Contributor_Guidelines Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Ubuntu nighly builds stuck on May 9th
Hi, There's perhaps an upload problem somewhere since despite Dash indicating that the nightly builds of master work ( http://dash.orfeo-toolbox.org/index.php?project=QGIS ), the latest packages available on http://qgis.org/ubuntugis-nightly/pool/main/q/qgis/ date from May 9th. Same for debian-nightly Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis-dev segfaults on startup
Le vendredi 20 mai 2016 09:40:28, Paolo Cavallini a écrit : > Hi all, > freshly upgraded qgis form nighly repo on Debian sid segfaults, even > starting --noplugins or on a clean configpath: > === > src/core/qgsproviderregistry.cpp: 204: (init) [0ms] Checking > /usr/lib/qgis/plugins/libogrprovider.so: ...loaded ok (41 file filters) > src/core/qgsproviderregistry.cpp: 137: (init) [1ms] Checking > /usr/lib/qgis/plugins/liboracleplugin.so: ...invalid (has type method) > src/core/qgsproviderregistry.cpp: 145: (init) [3ms] Checking > /usr/lib/qgis/plugins/libpkcs12authmethod.so: ...invalid (no isProvider > method) > src/core/qgsproviderregistry.cpp: 145: (init) [0ms] Checking > /usr/lib/qgis/plugins/libpkipathsauthmethod.so: ...invalid (no > isProvider method) > src/core/qgsproviderregistry.cpp: 137: (init) [8ms] Checking > /usr/lib/qgis/plugins/librasterterrainplugin.so: ...invalid (has type > method) > src/core/qgsproviderregistry.cpp: 137: (init) [2ms] Checking > /usr/lib/qgis/plugins/libroadgraphplugin.so: ...invalid (has type method) > src/core/qgsproviderregistry.cpp: 137: (init) [7ms] Checking > /usr/lib/qgis/plugins/libspatialqueryplugin.so: ...invalid (has type > method) src/core/qgsproviderregistry.cpp: 137: (init) [2ms] Checking > /usr/lib/qgis/plugins/libtopolplugin.so: ...invalid (has type method) > src/providers/wfs/qgswfsutils.cpp: 208: (init) [16ms] Keep-alive > mechanism works > src/core/qgsproviderregistry.cpp: 137: (init) [9ms] Checking > /usr/lib/qgis/plugins/libzonalstatisticsplugin.so: ...invalid (has type > method) > src/app/qgisapp.cpp: 8469: (loadPythonSupport) [0ms] load library > /usr/lib/qgispython (2.15.0) Launching with gdb (apt-get install gdb) and getting a stacktrace might help understanding where the issue is $ gdb qgis run (and when it crashes) bt and/or with Valgrind (apt-get install valgrind) $ valgrind qgis > === > All the best -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugin licence
Le mercredi 25 mai 2016 12:03:58, Nathan Woodrow a écrit : > >>I guess I am just sceptical that GPL's requirement for GPL licensing of a > > product, purely by virtue of importing the first product as a library, is > likely to hold much legal weight. > > That is one of the main things with GPL and why a lot of people do tend to > avoid it I guess. Not much we can do for it now all plugins are GPL. Technically you could licence the plugin with any license you want, but as soon you execute it against QGIS, it must be compatible of GPL v2+, since it is a derived work of QGIS GPLv2 code, and thus it must convey the same rights and obligations offered and constrained by the GPLv2 license. So you could also licence it under X/MIT, BSD 2/3 clauses or which ever other free licences that are compatible with GPLv2+. It cannot be under a proprietary license, because GPLv2 would impose to have access to the source code. The only cases where it makes sense in practice to have a plugin under a permissive license are : - imagine that someone would reimplement a QGIS alternative that would have the same API as QGIS but would be more permissively licensed, then it could make sense to have your plugin under that permissive license. - a more reasonable use case would be a plugin that would be compatible of QGIS and another proprietary GIS through some abstraction layer of their different APIs. The core of your plugin could then be permissively licensed to be compatible of both licensing models. > > On Wed, 25 May 2016 8:01 pm Paolo Cavallini wrote: > > Il 25/05/2016 11:42, Tom Chadwin ha scritto: > > > I guess I am just sceptical that GPL's requirement for GPL licensing of > > > a product, purely by virtue of importing the first product as a > > > library, is likely to hold much legal weight. > > > > We asked for legal advice, and that was the official response. > > All the best. > > > > -- > > Paolo Cavallini - www.faunalia.eu > > QGIS & PostGIS courses: http://www.faunalia.eu/training.html > > ___ > > Qgis-developer mailing list > > Qgis-developer@lists.osgeo.org > > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugin licence
> - a more reasonable use case would be a plugin that would be compatible of > QGIS and another proprietary GIS through some abstraction layer of their > different APIs. The core of your plugin could then be permissively licensed > to be compatible of both licensing models. Actually this point is quite interesting since for example NVidia claims that their proprietary code for their video drivers is not a derived work of the Linux kernel since it is used in the drivers of other OS. So only the adaptation layer between their generic driver and the Linux kernel is GPL. This is of course a much disputable point of view, but nobody has cared enough to challenge NVidia in front of a court. What it shows is that the concept of what is a derived work or not can be somewhat fuzzy. > > > > > On Wed, 25 May 2016 8:01 pm Paolo Cavallini wrote: > > > Il 25/05/2016 11:42, Tom Chadwin ha scritto: > > > > I guess I am just sceptical that GPL's requirement for GPL licensing > > > > of a product, purely by virtue of importing the first product as a > > > > library, is likely to hold much legal weight. > > > > > > We asked for legal advice, and that was the official response. > > > All the best. > > > > > > -- > > > Paolo Cavallini - www.faunalia.eu > > > QGIS & PostGIS courses: http://www.faunalia.eu/training.html > > > ___ > > > Qgis-developer mailing list > > > Qgis-developer@lists.osgeo.org > > > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Plugin licence
Le mercredi 25 mai 2016 13:26:02, Vincent Picavet (ml) a écrit : > Hi, > > On 25/05/2016 12:39, Even Rouault wrote: > [..] > > > > > > > Technically you could licence the plugin with any license you want, but > > as soon you execute it against QGIS, it must be compatible of GPL v2+, > > since it is a derived work of QGIS GPLv2 code, and thus it must convey > > the same rights and obligations offered and constrained by the GPLv2 > > license. > > So you could also licence it under X/MIT, BSD 2/3 clauses or which ever > > other free licences that are compatible with GPLv2+. > > It cannot be under a proprietary license, because GPLv2 would impose to > > have access to the source code. > > > > The only cases where it makes sense in practice to have a plugin under a > > permissive license are : > > - imagine that someone would reimplement a QGIS alternative that would > > have the same API as QGIS but would be more permissively licensed, then > > it could make sense to have your plugin under that permissive license. > > - a more reasonable use case would be a plugin that would be compatible > > of QGIS and another proprietary GIS through some abstraction layer of > > their different APIs. The core of your plugin could then be permissively > > licensed to be compatible of both licensing models. > > > > > > I do agree with this analysis. > > Note that as for the Nvidia case mentionned, the Linux kernel has an > exception to GPL for proprietary modules. Not sure it plays a role on > the issue you mentionned, but it may be a strong difference with other > software which do not have this exception. Are you really sure of that ? If that was the case there would not be all those debates regarding whether proprietary kernel modules are allowed or not. My understanding of https://en.wikipedia.org/wiki/Linux_kernel#Loadable_kernel_modules is that all the subtelty resides in whether a module is a derived work of another one. There's no special explicit exception. The folks that put proprietary modules say they are not derived works from the kernel, hence not bound to GPL. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WFS question in QGIS master
Hi Andreas, > > Is this a problem in the WFS server or in the client issueing an invalid > request? Can QGIS do something do be more tolerant and display this WFS > layer? There are several issues : - the server doesn't like srsname of the form urn:ogc:def:crs:EPSG::X, but only EPSG:X. This is a bit a mix of the fault of the client & server here. The client does some internal normalization of the srsname when parsing the capabilities to store them in the form EPSG:X so that QGIS projection selector like them. And when issuing WFS requests, for WFS 1.0, it keeps EPSG:X and for later versions it uses urn:ogc:def:crs:EPSG::X which is supposed to be the "new" way of specifying them (one could expect the server to return urn:ogc:def:crs:EPSG::X in WFS 2.0). Here it seems the Intergraph server doesn't like at all the new way. Some robustness could be added in the client to retry with the alternate way (and probably first try with the variant that was given in the capabilities) - the schema returned by http://webdienste.zugmap.ch/landwirtschaft_naturschutz_wfs/service.svc/get?request=describefeaturetype&service=wfs&typename=gmgml:LW_Bewirtschaftungseinheiten&version=2.0.0 is a bit too complex for the QGIS client and so it doesn't understand that "gmgml:Polygon_Surface_MultiSurface_CompositeSurfacePropertyType" is a geometry field (hence a geometry less layer reported). That could potentially be improved to hard code that this type is a polygon geometry (I see it is done in OGR GML driver) - the response to GetFeature returned by http://webdienste.zugmap.ch/landwirtschaft_naturschutz_wfs/service.svc/get?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&TYPENAMES=gmgml:LW_Bewirtschaftungseinheiten&SRSNAME=EPSG:21781&COUNT=1 is not conformant with the WFS 2.0 spec. It should be a wfs:FeatureCollection and not a GML feature collection as in WFS 1.1. The QGIS client is robust enough to handle that however... But this is clearly a non conformance to the spec - in the geometries returned, there are constructs like gml:CompositeSurface and gml:Arc that the QGIS GML importer will not handle. Falling back to the OGR GML services to parse them could potentially be done as it is able to handle them (just tried with 'ogrinfo "WFS:http://webdienste.zugmap.ch/landwirtschaft_naturschutz_wfs/service.svc/get"; -ro --debug on gmgml:LW_Bewirtschaftungseinheiten -al -q' ) Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] MapInfo edition in QGIS
Le mardi 21 juin 2016 11:58:53, DelazJ a écrit : > Hi, > > If I recall correctly, with GDAL2 in OSGeo4w, Windows users have now the > capabilities to edit Map Info files. > > Is this available for other platforms, too? I often read "GDAL is in > Osgeo4w" and not "GDAL2 is in QGIS", reason why I'm asking > I mean, if documenting map info files edit, should it be indicated that it > currently concerns only Windows users? That depends on the distribution and repository used. For example, on Ubuntu 16.04 if using ubuntugis-unstable PPA, you get QGIS 2.14.1 + GDAL 2.1.0. Safest answer: people have to check in the About dialog: if it indicates GDAL 2.0 or later, then they have .tab edition capabilities. > > Thank you, > Harrissou -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] MapInfo edition in QGIS
Le mardi 21 juin 2016 12:27:55, vous avez écrit : > Thanks for your answers. Even, I will keep in mind your safest answer. > But before I claim that everybody can somehow easily have access to mapinfo > files editing capabilities, any idea about MAC users? That's the same story. There's nothing OS specific here (the OGR regression tests for .tab edition work on the Travis MacOSX instance). It only depends on against which GDAL version QGIS has been built. > > 2016-06-21 12:14 GMT+02:00 Even Rouault : > > Le mardi 21 juin 2016 11:58:53, DelazJ a écrit : > > > Hi, > > > > > > If I recall correctly, with GDAL2 in OSGeo4w, Windows users have now > > > the capabilities to edit Map Info files. > > > > > > Is this available for other platforms, too? I often read "GDAL is in > > > Osgeo4w" and not "GDAL2 is in QGIS", reason why I'm asking > > > I mean, if documenting map info files edit, should it be indicated that > > > > it > > > > > currently concerns only Windows users? > > > > That depends on the distribution and repository used. For example, on > > Ubuntu > > 16.04 if using ubuntugis-unstable PPA, you get QGIS 2.14.1 + GDAL 2.1.0. > > > > Safest answer: people have to check in the About dialog: if it indicates > > GDAL > > 2.0 or later, then they have .tab edition capabilities. > > > > > Thank you, > > > Harrissou > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Interpretation of a 3 point CircularString with p0 == p2 (circle)
Hi,
I just came into a difference how QGIS and GDAL interpret a CircularString made
of a 3 points p0, p1, p2 where p0 == p2, which is a way of representing a full
circle.
GDAL interprets p1 as the symetrical point of p0 with respect to the center
(https://github.com/osgeo/gdal/blob/trunk/gdal/ogr/ogrcircularstring.cpp#L640),
that is p1 is on the perimeter of the circle, or said otherwise the center of
the circle is the midpoint of [p0,p1].
Whereas QGIS interprets p1 as the center of the circle (
https://github.com/qgis/QGIS/blob/master/src/core/geometry/qgsgeometryutils.cpp#L359
)
I'd think GDAL interpretation is the right one, since according to
http://jtc1sc32.org/doc/N1101-1150/32N1107-WD13249-3--spatial.pdf (ISO SQL MM
Part 3), paragraph 4.1.6 :
(let's call this sentence S1)
""" In the case where the segment is a circle, then the center is located
at the midpoint of the line connecting the start point with the intermediate
point. """
But if you look a bit above in the paragraph, there's a sentence (call it S2)
: """In the special case where a segment is a complete circle, that is, the
start and end points are coincident, then the intermediate point shall be the
midpoint of the segment. """, which looks confusing at first. I think this
sentence must be interpreted considering distances along the curve, in which
case the "midpoint of the segment" when doing a full walk along the circle
from p0 back to p0 is the symetrical point of p0 with respect to the center.
I think this interpretation is also more logical since, even in that
particular case, p0,p1,p2 are all on the arc, like in the general case.
I can also see that PostGIS (in https://github.com/postgis/postgis/blob/svn-
trunk/liblwgeom/lwalgorithm.c#L252 ) has the same interpretation as GDAL (*)
I'd be happy to read opinions regarding this.
Even
(*) Can also be shown with :
# SELECT
ST_AsText(ST_Envelope(ST_CurveToLine(ST_GeomFromText('CIRCULARSTRING(-1 0,1
0,-1 0)';
st_astext
--
POLYGON((-1 -1,-1 1,1 1,1 -1,-1 -1))
And http://postgis.net/docs/manual-2.2/using_postgis_dbmanagement.html says
"The exception to this is for a closed circle, where the start and end points
are the same. In this case the second point MUST be the center of the arc, ie
the opposite side of the circle.", which is another way to rephrase S2.
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Interpretation of a 3 point CircularString with p0 == p2 (circle)
Le jeudi 23 juin 2016 16:01:10, Marco Hugentobler a écrit :
> Hi Even
>
> I agree it will be good to follow the postgres / gdal interpretation.
> Reading S2, I somehow thought the segment midpoint would be the circle
> midpoint, but it's not the same.
Filed as https://hub.qgis.org/issues/15116
>
> Regards,
> Marco
>
> On 06/23/16 15:32, Even Rouault wrote:
> > Hi,
> >
> > I just came into a difference how QGIS and GDAL interpret a
> > CircularString made of a 3 points p0, p1, p2 where p0 == p2, which is a
> > way of representing a full circle.
> >
> > GDAL interprets p1 as the symetrical point of p0 with respect to the
> > center
> > (https://github.com/osgeo/gdal/blob/trunk/gdal/ogr/ogrcircularstring.cpp
> > #L640), that is p1 is on the perimeter of the circle, or said otherwise
> > the center of the circle is the midpoint of [p0,p1].
> > Whereas QGIS interprets p1 as the center of the circle (
> > https://github.com/qgis/QGIS/blob/master/src/core/geometry/qgsgeometryuti
> > ls.cpp#L359 )
> >
> > I'd think GDAL interpretation is the right one, since according to
> > http://jtc1sc32.org/doc/N1101-1150/32N1107-WD13249-3--spatial.pdf (ISO
> > SQL MM Part 3), paragraph 4.1.6 :
> > (let's call this sentence S1)
> > """ In the case where the segment is a circle, then the center is located
> > at the midpoint of the line connecting the start point with the
> > intermediate point. """
> >
> > But if you look a bit above in the paragraph, there's a sentence (call it
> > S2)
> >
> > : """In the special case where a segment is a complete circle, that is,
> > : the
> >
> > start and end points are coincident, then the intermediate point shall be
> > the midpoint of the segment. """, which looks confusing at first. I
> > think this sentence must be interpreted considering distances along the
> > curve, in which case the "midpoint of the segment" when doing a full
> > walk along the circle from p0 back to p0 is the symetrical point of p0
> > with respect to the center.
> >
> > I think this interpretation is also more logical since, even in that
> > particular case, p0,p1,p2 are all on the arc, like in the general case.
> >
> > I can also see that PostGIS (in
> > https://github.com/postgis/postgis/blob/svn-
> > trunk/liblwgeom/lwalgorithm.c#L252 ) has the same interpretation as GDAL
> > (*)
> >
> > I'd be happy to read opinions regarding this.
> >
> > Even
> >
> > (*) Can also be shown with :
> >
> > # SELECT
> > ST_AsText(ST_Envelope(ST_CurveToLine(ST_GeomFromText('CIRCULARSTRING(-1
> > 0,1 0,-1 0)';
> >
> >st_astext
> >
> > --
> >
> > POLYGON((-1 -1,-1 1,1 1,1 -1,-1 -1))
> >
> > And http://postgis.net/docs/manual-2.2/using_postgis_dbmanagement.html
> > says "The exception to this is for a closed circle, where the start and
> > end points are the same. In this case the second point MUST be the
> > center of the arc, ie the opposite side of the circle.", which is
> > another way to rephrase S2.
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: [Qgis-user] QGIS problem with GeoPackage database views
Le dimanche 26 juin 2016 21:15:24, Richard Duivenvoorde a écrit : > On 26-06-16 20:27, Matthias Kuhn wrote: > > Hi > > > > On 06/26/2016 08:23 PM, Richard Duivenvoorde wrote: > >> @Marcus: forwarding this to the Developers mailing list, as I think > >> there are more people there who maybe can help. > >> Good that you publish both data + problems! Even better maybe create > >> issues (with if possible more slimmed down dataset)... > > > > An issue report would certainly be good. > > > > My first wild guess reading this is that there is some trouble with the > > mapping the feature id to primary keys. > > One additional observation (fresh master of today): > > - I downloaded the dataset > - loaded the layer/view sa1_bo1_map_v into QGIS > - opened the attributetable and see all the same values in the cells > > But > - Open DB Manager (Plugin?), > - Create a connection to it > - Select this sa1_bo1_map_v node > - I see the correct(?) cell values (and very fast, compared to QGIS > itself?) > > When I open with browser, I get the same wrong result... The issue is that the OGR GeoPackage driver cannot derive an integer primary key from the view, and affects 0 as the fid for all features. In the case of the views of this particular dataset, the OBJECTID field could be used as the FID (given some logic to be implemented in the driver to analyze the structure of the view, the underlying tables and the unicity constraints on the join fields) Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: [Qgis-user] QGIS problem with GeoPackage database views
Le dimanche 26 juin 2016 21:50:38, Richard Duivenvoorde a écrit :
> On 26-06-16 21:22, Even Rouault wrote:
> > The issue is that the OGR GeoPackage driver cannot derive an integer
> > primary key from the view, and affects 0 as the fid for all features. In
> > the case of the views of this particular dataset, the OBJECTID field
> > could be used as the FID (given some logic to be implemented in the
> > driver to analyze the structure of the view, the underlying tables and
> > the unicity constraints on the join fields)
>
> Ok... so, is this a driver challenge?
Eh, I love driver challenges :-)
>
> Or is it more an explicit problem, because the view is created without
> explicit primary key?
>
> Because, instead of putting 'some logic' into the driver trying to guess
> a primary key, we can maybe create some kind of PK-constraint?
>
> Like: a view (just like an Oracle table?) should have some kind of
> primary key defined?
I'm not aware of a way of doing it :
Here's a failed attempt :
sqlite> create unique index foo on sa1_b01_map_v ( OBJECTID );
Error: views may not be indexed
I'd be curious if other databases have a way of doing it, but my feeling is
that I don't think it is possible for normal dynamic views. (Unless you are
using a materialized view as in Postgres for example)
> If not: ask for it, so it is defined into the view
> definition (uh... not sure IF that is possible at all in a view...).
> Or QGIS asks for it: showing the attributes, and letting the user choose
> the id('s) that the user (thinks) are unique and should be used as
> primary key...
That would be a possibility, although that would still require an enhancement
in the OGR side to accept the name of the PKID as an option.
Anyway as a fallback in the absence of a PKID a sequential numbering would
probably be desirable (with the caveat that it wouldn't be stable when
attribute or spatial filters are applied, which could cause some problems )
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: [Qgis-user] QGIS problem with GeoPackage database views
Le lundi 27 juin 2016 02:47:09, Marcus Blake a écrit : > @Richard: thanks for redirecting this question in to the correct people…and > apologises for the size of the file…lack of specification on my part to a > over enthusiastic team member ;-). I’ll reduce the size and put in a issue > report. > > I’m in total agreement with you on the tremendous potential of GeoPackage > to support the sharing of all types of data (statistical, geospatial, > metadata, imagery…). Certainly the statistical community (the UNGGIM), is > grappling with the issue of integrating statistical and geospatial data > models and I think GeoPackage can provide one important part of the > solution. > > As well as publishing 2016 Census data...One of my aspiration is to use > GeoPackage to publish the full data model that the ABS uses to internally > store our geographic classification. This would provide a point of truth > for all users…and they can tell us where we have gone wrong ;-) > > But to do both of these things well, views are very valuable and would > prevent a lot of data duplication. > > @Even Thanks for the quick reply…and all your important support of GDAL. > > One of my team (more knowledgable than I) thought that it was an ID > issue…so it good to have that confirmed. But it doesn’t look like there is > a easy solution. > > It interesting that the despite the lack of PKID (and therefore a correct > FID) both the classification and symbolisation for a choropleth maps and > the Identify Features Tool work as expected….thoughts? I didn't check in the code, but likely rendering "just" iterates over features and doesn't care about their FID. And for identification, it is a spatial query, which ends up being an iteration over all features too (since, with views, spatial indexes are not - at least currently - used. Could probably be improved too since the Spatialite driver can use the underlying table spatial index for Spatialite views. But Spatialite has an explicit declaration of which pkid to use and the geometry column of the base table in its views_geometry_columns table). On the contrary the attribute table works with a feature cache based on FID. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Shape repack issue
Andreas, I cannot confirm. But the bug has been reopened without specifying the operating system, the GDAL version and the exact procedure followed (possibly with the dataset in case it might make a difference), so it might hit some particular case. So here's my setup : - versions tried : up-to-date versions of QGIS master and 2.14 branch - OS: Linux - GDAL >= 2.1 Steps : 1) Download: http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shp http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shx http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.dbf 2) Open the shapefile in QGIS 3) Turn on edition mode 4) Select the feature with EAS_ID = 165 (the one roughly at the middle) 5) Delete it 6) Turn off edition mode and confirm saving the changes 7) Quit QGIS and do "ogrinfo -al poly.shp". You'll see "Feature Count: 9" and 9 features numeroted without hole from OGRFeature(poly):0 to OGRFeature(poly):8 Sure, a test could be added to simulate that (looking at test_provider_shapefile.py it doesn't seem there's one), but there's probably something we miss here w.r.t. the reporter setup. On the reverse, to see the effect of *no* repacking, if you do : 1) Download: http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shp http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shx http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.dbf 2) ogrinfo poly.shp -sql "delete from poly where eas_id = 165" -dialect sqlite 3) ogrinfo -al poly.shp. You'll see "Feature Count: 10" and features numbered from OGRFeature(poly):0 to OGRFeature(poly):9 with a hole (OGRFeature(poly):8 missing) --> the shapefile hasn't been repacked (as "expected" from current OGR behaviour) Even > Hi, > > There is (hopefully was) this annoying ESRI Shape Repack issue - see > http://hub.qgis.org/issues/11007 > > I see that this bug was re-opened - Antoine SIG claims that it worked in > 2.14.1 and 2.14.2 (Windows) but fails again in 2.14.3. Can someone > confirm? How can that happen? Can a test be added to ensure this doesn't > fail again? > > How about 2.16? Does it work there if it is built with GDAL 2.x? > > I can't reproduce, since I don't have another GIS besides QGIS to check. > > > Thanks, > > Andreas -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS for INSPIRE
Le mercredi 06 juillet 2016 16:35:03, Richard Duivenvoorde a écrit : > On 06-07-16 16:27, Patrick Valsecchi wrote: > > or is having recommendations/comments/questions, please tell us. > > Hi Patrick, > > just a note, that I hope that there is also work (funds) spend on OGR > maybe to make GeoPackage driver work (even) better in QGIS? There will be definitely a significant amount of work to do in OGR in that context to be able to read (and write) complex GML files such as found in Inspire datasets in a "lossless way", ie dealing with arbitrary nesting of elements based on the .xsd schemas and exposing them through relational tables when needed. GeoPackage work isn't in the scope though. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Perfs: a lot of WKB conversions
> I was a bit sceptical, so I did a quick computation. A 32 bit float allows > an accuracy of 3mm with WGS84 for coordinates around 180°: > 180 takes 8 bits out of the 23 bits of fraction. The remaining 15 bits can > split the earth circumference into chunks of 3mm (4/(2^15)). I'm maybe > off by +1 bit of precision (the fraction has an implicit 1 at MSB), so that > would be 1.5mm. I'm not sure to have followed your computation, but it is wrong somewhere (must be a km vs m confusion). For example, OpenStreetMap .pbf format uses int32 to store longitudes (in a scaled way), and that enables a ~1cm accuracy. Proof : 40e6 / 2^32 ~= 0.0093 m = 9.3 mm In practice, they multiply longitudes in deegrees by 10 000 000, which offers 40e6 / (2 * 180 * 10 000 000) = 1.1 cm accuracy So for float32 given that you have only 23 bit for the mantissa, the precision should be much less than that in average and would not be uniform anyway. But your conclusion that float32 cannot be used to store coordinates is right :-) -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QgsMapLayer.source() for a WFS now returns a different string
Le mercredi 20 juillet 2016 11:57:19, Tom Chadwin a écrit :
> I was retrieving the URL of a WFS layer, and formatting it for Leaflet as
> follows:
>
> layerSource = layer.source()
> layerSource += "&outputFormat=text%2Fjavascript&"
> layerSource += "format_options=callback%3AmyCallback"
> wfsVars += ('' % layerSource)
>
> This no longer works, because source() on a WFS layer now (2.16 Win7x64)
> returns a string of the format:
>
> retrictToRequestBBOX='1' srsname='EPSG:27700'
> typename='yorkshire_dales:ydnpa_route_accessibility'
> url='http://maps.nationalparks.gov.uk/geoserver/wfs' table="" sql=
>
> When did this change?
in 2.16
> And can I retrieve the URL as I did before, or am I
> going to have to hack this new string around to build the WFS URL?
You can use QgsDataSourceURI.param("url") to retrieve the url parameter. You
'll need to augment it with SERVICE, VERSION and REQUEST parameters to form a
valid GetFeature request.
>
> Thanks
>
> Tom
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/QgsMapLayer-source-for-a-WFS-now-retur
> ns-a-different-string-tp5277278.html Sent from the Quantum GIS - Developer
> mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QgsMapLayer.source() for a WFS now returns a different string
Le mercredi 20 juillet 2016 15:21:57, Tom Chadwin a écrit :
> Even Rouault-2 wrote
>
> > You can use QgsDataSourceURI.param("url") to retrieve the url parameter.
> > You
> > 'll need to augment it with SERVICE, VERSION and REQUEST parameters to
> > form a
> > valid GetFeature request.
>
> Many apologies, but how do I retrieve the QgsDataSourceURI of a layer? I'm
> not managing to get it to work.
Something like QgsDataSourceURI(layer.provider().dataSourceUri())
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/QgsMapLayer-source-for-a-WFS-now-retur
> ns-a-different-string-tp5277278p5277347.html Sent from the Quantum GIS -
> Developer mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WFS Provider Strategies
> In which case does that help? Isn't every cached feature downloaded > again (with potentially more up to date information) anyway? You get the feeling of a more responsive UI when you can reuse already downloaded features, but that's true that if the server content has changed in between, you won't get the new version. In which case you'll have to reload the layer with F5. > > >> Question: *is **there anybody using WFS with this option unchecked?* And > >> if yes, for what reason? > > > > Yes it is needed for some use cases. There are servers that have buggy > > behaviour with BBOX requests combined with other filters. Or the cost of > > solving a spatial request might be super high, making it more practical > > to issue a GetFeature without a BBOX. > > Ok, so it should be a super well hidden checkbox with a big warning sign > next to it? That really depend on servers. If the current default behaviour is OK for most, it might still be useful that the option is not too hidden if users have issues with some servers. They might have a better chance of trying to uncheck the option. Where would you hide it ? Note: this is not new to 2.16 as far as I remember. The option was already there. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WFS Provider Strategies
Hi, > > I am a bit confused by the WFS option *"Only request features > overlapping the view extent"*. > > In general, that's what every provider does by default and is a safe > strategy to use. If this option is unchecked, QGIS will just start > downloading features randomly until it hits a server limit (or not). Time to upgrade the servers to support WFS 2.0 paging :-) > > The only reason why one would possibly want to do that is to warm a > cache on a layer where he know he will be getting all the features (in a > reasonable time). In this case, the option should probably be renamed > (to something containing the word "cache"). The provider always cache (meaning keep in a temporary database the features retrieved), whatever you check or uncheck this option. For example with the default behaviour, zoom in in some region and wait for some or all features to be retrieved, and zoom out. The provider will use the already downloaded features first and then return the features coming from the background downloading of the new request (using gml:id/fid to make sure not to return already cached features). > > Question: *is **there anybody using WFS with this option unchecked?* And > if yes, for what reason? Yes it is needed for some use cases. There are servers that have buggy behaviour with BBOX requests combined with other filters. Or the cost of solving a spatial request might be super high, making it more practical to issue a GetFeature without a BBOX. > > Apart from this, Raymond noticed that cached features are not dismissed, > when they are re-downloaded so you end up with duplicated features after > multiple rendering cycles. Does that ring a bell for someone? That should be better explained to be sure. It might be an issue with the features returned by the server having not a stable gml:id (or even not a id at all). Richard raised a ticket about that. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WFS Provider Strategies
> True... Although we could replace the features in the cache instead of > dropping the new ones for a tiny improvement. That would indeed help for the next feature request > > Question: *is **there anybody using WFS with this option unchecked?* > And if yes, for what reason? > >>> > >>> Yes it is needed for some use cases. There are servers that have buggy > >>> behaviour with BBOX requests combined with other filters. Or the cost > >>> of solving a spatial request might be super high, making it more > >>> practical to issue a GetFeature without a BBOX. > >> > >> Ok, so it should be a super well hidden checkbox with a big warning sign > >> next to it? > > > > That really depend on servers. If the current default behaviour is OK for > > most, it might still be useful that the option is not too hidden if users > > have issues with some servers. They might have a better chance of trying > > to uncheck the option. Where would you hide it ? > > Note: this is not new to 2.16 as far as I remember. The option was > > already there. > > Well, I was confused and I know of others which are confused. > > At the moment it's really hard to tell which is the recommended option > and which one is the "try this if your sever is broken" option. We could > just add a warning if it's unchecked which says "only do this if there > are problems with the default" or put it into an advanced dialog or so. > Have you actually seen such servers? And if yes, can you name them? The issues were with multiple layer joins with GeoServer in some circumstances not very clearly understood ( I don't want to particularly point fingers at GeoServer, as server side joins is a pretty advanced feature rarely implemented by servers) You need to get an API key at https://data.linz.govt.nz/group/owner-data-controlled-access-group/ And then try the following SQL request SELECT DISTINCT par.id, par.status, own.owner_type, own.prime_surname, own.prime_other_names, own.corporate_name, par.shape FROM "layer-1571" AS par JOIN "table-1569" AS tpa ON par.id = tpa.par_id JOIN "table-1564" AS own ON tpa.title_no = own.title_no WHERE ST_Within(par.shape, ST_MakeEnvelope(174.806, -41.347, 174.846, -41.285, 'EPSG:4167’)) The server will not like the extra addition of the BBOX. There might be less complicated examples but this is the one I managed to find quickly in my mail box... Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Feedback for contrast enhancement ... enhancements ?
Hi, There has been interest expressed to improve the usability of the contrast enhancement function. Basically there are workflows where you want the min/max values used by contrast enhancement to be updated each time you pan or zoom the canvas. From what I've seen, here's what currently exists: - a long method (6 clicks): through the Style tab of the layer properties - a faster method (2 clicks): through the "Strech using current extent" of the contextual menu of the layer panel. When you have several rasters loaded, even the 2-click method is inconvenient, so there's a need for a 0-click solution (once the layers have been configured) Another shortcoming in the current implementation is that the settings of the "Load min/max values" foldable group are not persistant, which requires re- setting them if you're not happy with the default Cumlative count cut method. And if you use the "Strech using current extent" menu item, the genuine min/max values are used (not the 2-98% cumulative count cut) So I was thinking to something along the following lines: - make the min/max settings persistant - remove the "Load" button and "Clip extent to canvas" checkbox, and replace them by 3 radio buttons to determine the scope of statistics : "Whole raster", "Current canvas" and "Updated canvas". See the attached proposal_min_max.png. The function of the Load button would be replaced by the general Apply / OK buttons. - when the user manually enters the min/max values, the 2 groups of radio buttons (method to compute min/max and scope of statistics) would be unchecked so that is is clear that they don't come from computed statistics. I also think that when you select "Current canvas", once the Apply/OK buttons have been pushed, the checked state of Current canvas shouldn't be saved. This way when you display the layer properties you have a good idea of where the current min/max values come from. - make the "Strech using current extent" method honour the way min/max are computed in the min/max settings instead of using systematically the min/max. So when "Updated canvas" would be selected, it would have no (extra) effect as expected. Any opinions ? Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2.16.1-2 Crashing on Loading GeoTIFFs
Jürgen, I can reproduce the crash on a fresh new OSGeo4W 32 bit install just GDAL 2.1.1-1. After a few trial&errors by trying previous versions of gdal, libtiff and libgeotiff, I've determined that it is the recent update of libgeotiff 1.4.2-1 that seems to be the cause of the crashes. When manually reverting to libgeotiff-1.3.0-3 dll, I no longer get the crash on the sample .tif (although just substituting the libgeotiff dll is not recommended, as there might be some subtle ABI differences in 1.3.0 vs 1.4.2 that might cause later issues) Interestingly, when installing gdal-dev (2.2.0dev) and sourcing it, I don't get the crash, even with libgeotiff 1.4.2-1 I also tried a fresh new OSGeo4W 64 bit install but it fails when downloading ogdi. I'm not sure what is wrong exactly with gdal 2.1.1/libgeotiff 1.4.2 since when installing gisinternals binaries ( http://download.gisinternals.com/sdk/downloads/release-1600-gdal-2-1- mapserver-7-0.zip ), gdalinfo works on the provided GeoTIFF. One difference is that gisinternal binaries are compiled with the internal version of libgeotiff in GDAL, but the sources of that one are sync'ed from latest state of libgeotiff SVN, so ~ 1.4.2. One subtelty between internal and external libgeotiff regarding GDAL is how some CPL services (the ones parsing CSV files mostly) are hooked. Even Le vendredi 02 septembre 2016 18:25:12, C Hamilton a écrit : > I don't know if this crash information is helpful. > > Problem signature: > Problem Event Name:APPCRASH > Application Name:qgis-bin.exe > Application Version:0.0.0.0 > Application Timestamp:57c0c24e > Fault Module Name:ntdll.dll > Fault Module Version:6.1.7601.23418 > Fault Module Timestamp:5708a73e > Exception Code:c005 > Exception Offset:000346f3 > OS Version:6.1.7601.2.1.0.256.48 > Locale ID:1033 > Additional Information 1:1d0c > Additional Information 2:1d0c85114d5e995e150b85f0f1b98898 > Additional Information 3:5dac > Additional Information 4:5dacaa43bc2311a4ec5a6b7872b77a7a > > > On Fri, Sep 2, 2016 at 10:44 AM, Giovanni Manghi > > > wrote: > > Hi, > > > > > Has anyone encountered this yet? I am using the 32-bit Network > > > > Installer. I > > > > > think it started with the latest GDAL update. Loading a GeoTIFF fails > > > on both my machines. I had to go back to the long term release on my > > > machine that I use for actual work. > > > > any geotiff? could you eventually share one that does not work for you > > so we can test on 64bit and other platforms? > > > > cheers! > > > > -- g -- > > ___ > > Qgis-developer mailing list > > Qgis-developer@lists.osgeo.org > > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Error in WFS QgsDataProvider.dataSourceUri()?
Le vendredi 16 septembre 2016 13:58:39, Tom Chadwin a écrit : > It includes "retrictToRequestBBOX" (missing an 's'). Should be > "restrictToRequestBBOX". Don't know if this is internal to QGIS, or if it's > eg OGR. Also don't know what breakages would be caused by fixing it. Ah.. Purely a QGIS thing, but not completely internal in the meaning that it can be used by code building a connection string (eg in unit tests) and it is actually documented in http://qgis.org/api/classQgsVectorLayer.html#details So if we wanted to change that we should probably accept the old value as well. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Warning - shapefile corruption on 2.16/master and how to recover
Le vendredi 16 septembre 2016 20:27:05, Jeff McKenna a écrit : > I just tried to reproduce with QGIS 2.16.2 on Windows 10, I had no > problems using the "Split Features" tool on a shapefile, and saving. I > notice that the .dbf .shp .shx were modified properly. > > (I did have a brain lapse to remember that the Split Features tool lives > in the /edit menu ha) One of my hypothesis is some bad interaction with the "connection pool". Could you (or anyone) open the attribute table before doing the edits,and do the edits and commit them no more than 60 seconds afterwards ? I'm not sure but this might perhaps also require the shapefile to be big enough (several thousands of features). > > -jeff > > > Unfortunately a fairly nasty regression has slipped in to 2.16 and is > > still present on master. This results in shapefile corruption in > > certain circumstances. > > > > While I've hit this issue maybe 3 or 4 times in the last 2 months, I > > haven't been able to track down exactly what causes this. It seems > > related to using the split or reshape tool on a shapefile, then saving > > the changes and getting the errors "Cannot reopen datasource > > xxx.shp|layerid=0 in read-only mode" and "Data source is invalid > > (Unable to open xxx.shx or xxx.SHX.Try --config SHAPE_RESTORE_SHX true > > to restore or create it)" in the log. > > > > A full report is at http://hub.qgis.org/issues/15570 > > > > Hopefully we can resolve this before the next round of releases. In > > the meantime, there's a workaround for recovering data: > > > > In the same folder as the shapefile there'll be additional files > > "xxx_packed.shp" and "xxx_packed.shx". Renaming the "xxx_packed.shx" > > file to "xxx.shx" allows the original shapefile to be reopened. > > > > Nyall > > ___ > > Qgis-developer mailing list > > Qgis-developer@lists.osgeo.org > > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Warning - shapefile corruption on 2.16/master and how to recover
Le mardi 20 septembre 2016 13:11:36, Giovanni Manghi a écrit : > Hi all, > > > One of my hypothesis is some bad interaction with the "connection pool". > > Could you (or anyone) open the attribute table before doing the edits,and > > do the edits and commit them no more than 60 seconds afterwards ? > > this sounds familiar too... this is exactly how the editing workflow > of geopackage layers gets broken > > http://hub.qgis.org/issues/15351 > > is this just coincidence? I'm going to work soon on this GPKG issue. On surface, it looks similar to the shapefile issue, but technically file locking and sqlite database locking use different mechanisms so the solutions will be likely different. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [QGIS Server] Maintain it and create a team
> I know QGIS > depends on GDAL mostly in terms of I/O, so it really should be solved on > both GDAL and QGIS levels. But as far as I know GDAL dev community doesn’t > have any particular plans to implement MVT driver (or, perhaps, they > do?:). This is something I'd love to see in GDAL. As usual, plans are mostly driven by parties interested to make things happen and provide appropriate resources or funding. That said, on the writing side, MVT is a special beast that mixes traditional vector concepts, as well as rendering considerations for generalization, subselection of attributes for lower zoom levels, etc. But this goes a bit out of scope of the main topic of this thread ;-) Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Building on Ubuntu 14.04
Le samedi 24 septembre 2016 16:34:36, Sandro Santilli a écrit : > On Sat, Sep 24, 2016 at 04:31:23PM +0200, Sandro Santilli wrote: > > I'm trying to build the master branch on Ubuntu 14.04.5 > > > > but the build configuration fails with: > > CMake Error at cmake/FindQCA.cmake:60 (message): > > Could not find QCA > > > > Call Stack (most recent call first): > > CMakeLists.txt:296 (FIND_PACKAGE) > > > > I have libqca2-dev installed, and 2.14 branch builds just fine: > > -- Found QCA: /usr/lib/x86_64-linux-gnu/libqca.so (2.0.3) > > -- Found QCA OpenSSL plugin > > > > What changed between 2.14 and master wrt QCA ? > > This seems to have changed: > > diff qgis-2.14/cmake/FindQCA.cmake qgis/cmake/FindQCA.cmake > 23,27c23 > < if(ENABLE_QT5) > < set(QCA_LIBRARY_NAMES qca-qt5 qca2-qt5) > < else(ENABLE_QT5) > < set(QCA_LIBRARY_NAMES qca qca2) > < endif(ENABLE_QT5) > --- > > > set(QCA_LIBRARY_NAMES qca-qt5 qca2-qt5) > > 52c48 > < PATH_SUFFIXES QtCrypto qt4/QtCrypto Qca-qt5/QtCrypto > --- > > > PATH_SUFFIXES QtCrypto qt5/QtCrypto Qca-qt5/QtCrypto > > It looks like qca-qt5 is not packaged for ubuntu 14.04, > can I disable it ? Some time ago, I had rebuilt the whole stack of dependencies from sources. This was quite a pain for a few of them (one of the QT based lib. can't remember which one), especially to convince them to install to a custom prefix. You could take inspiration from Matthias' build recipees at https://github.com/opengisch/osgeo4travis/tree/master/docker/qt5 that are used to generate the https://github.com/opengisch/osgeo4travis/archive/qt5bin.tar.gz archive used on Travis-CI (but you can't probably directly use those binaries for 14.04 as they are targetted for 12.04). > > --strk; > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] MongoDB plugins - merge
Le vendredi 30 septembre 2016 08:26:02, Paolo Cavallini a écrit : > Il 29/09/2016 22:05, Vasilios Kalogirou ha scritto: > > My name is Vasilios Kalogirou and I have recently developed a plugin > > which allows users to store vector data in MongoDB > > (https://github.com/VasiliosKalogirou/Save-layer-in-MongoDB ). > > > > > > > > After trying to publish my plugin in QGIS Python Plugins Repository I > > got a response from Paolo Cavallini to consider merging my plugin with > > the other two MongoDB plugins, MongoConnector and Load MongoDB Layers. > > > > > > > > Please let me know of any future steps with regard to this. > > > > Also, please note that on my research I tried to evaluate the > > functionality of the other two plugins so I would be happy to discuss > > with the other authors about some key points of the plugins. > > Thanks Vasilios, > I think many would welcome the landing of a good and robust support of > MongoDB in QGIS; on the other hand, we're trying hard to reduce the > duplication of efforts and the confusion for the plugins end users, > hence my suggestion. > Moreover, the upcoming QGIS 3 will require some effort in porting the > plugins, so a smaller number of plugins with stronger dev teams will > have better chances. > Vasilios, could you please quickly recall here the strengths of each > plugin? And, to help us understanding, could you also point to a sample > DB so we can do some tests? > BTW, there is also http://plugins.qgis.org/plugins/mongo_memorizer/ > Are the other plugins authors listening here? If not, better to also > contact them directly. And there's also the OGR MongoDB driver since GDAL 2.1: http://gdal.org/drv_mongodb.html . Although I suspect it is rarely compiled by default due to the dependency to the MongoDB C++ driver client library -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Fwd: Re: [Geopackage] Geopackage on a shared network drive
FYI: An interesting finding to improve performance of large Geopackage on a shared network drive. -- Message transmis -- Sujet : Re: [Geopackage] Geopackage on a shared network drive Date : samedi 01 octobre 2016, 16:41:05 De : Árni Geirsson via Geopackage À : Even Rouault CC : geopack...@lists.opengeospatial.org Yes! It renders very quickly after I set the read-only flag in the file explorer. That goes a long way towards solving the problem for me because as I mentioned, the team would like to use this format to store geodata, not to edit it and certainly not to make edits by multiple concurrent users. Thank you so much for your help! Árni Árni Geirsson *Alta ehf* // +354 582 5000 // +354 897 9549 www.alta.is // Alta á Twitter <http://twitter.com/alta_ehf> // Alta á Facebook <http://www.facebook.com/pages/Alta/161795813838691?v=wall> Gæða- og umhverfisstefna Alta <http://alta.is/pdf/svonavinnumvid.pdf> On 1 October 2016 at 14:28, Even Rouault wrote: > Le samedi 01 octobre 2016 16:02:38, Árni Geirsson a écrit : > > Hello Even > > Thank you for your suggestion. I made the changes you suggested, adding > > set SQLITE_USE_OGR_VFS=YES > > after > > set VSI_CACHE=TRUE > > set VSI_CACHE_SIZE=100 > > but there was no difference. Was this perhaps not the right way to do it? > > Yes, that's correct. > > Hum actually reviewing the code, the cache mechanism is only enabled when > the > file is opened in read-only mode, whereas QGIS will open the file in > read-write > mode. > > You could perhaps try to make the GPKG read-only in the explorer?, at least > just to test if it is a promising optimization. I guess write support for > the > cache mechanism could be added. > > A drawback of a cache machnism is that it would defeat the updates in > SQLite > to deal with concurrent editing, but anyway such mechanisms don't work very > well on network shares. > > > Anyway, I would think that I am not alone in seeing this as a problem > but I > > find very little about it on the web. > > > > Árni > > > > > > > > Árni Geirsson > > *Alta ehf* // +354 582 5000 // +354 897 9549 > > www.alta.is // Alta á Twitter <http://twitter.com/alta_ehf> // Alta á > > Facebook <http://www.facebook.com/pages/Alta/161795813838691?v=wall> > > Gæða- og umhverfisstefna Alta <http://alta.is/pdf/svonavinnumvid.pdf> > > > > > > > > > > On 30 September 2016 at 19:52, Even Rouault > > > > wrote: > > > Le vendredi 30 septembre 2016 00:44:45, Árni Geirsson via Geopackage a > > > > > > écrit : > > > > Dear Geopackage developers! > > > > I look forward to the day when Geopackage replaces the old shapefiles > > > > > > and I > > > > > > > thank you for your efforts. As a user in a small team that uses QGIS > > > > and shares data on a NAS box, basically a Samba server for network > > > > shares, I notice that Geopackage data loads very slowly, much more > > > > slowly than a shapefile stored in exactly the same shared folder. I > > > > have noticed this with Spatialite, too, and suspect that the problem > > > > lies with Sqlite and some problem it has with the networking > protocol. > > > > Since Geopackage is intended (as I understand) as a storage and > > > > exchange format for geodata, rather than a general purpose database > > > > format like Spatialite, I was > > > > > > hoping > > > > > > > that this problem could be overcome and that the Geopackage data > would > > > > > > load > > > > > > > as fast as the shapefile data from the network share. When the > > > > Geopackage and shapefile data are both on a local drive, I see no > > > > difference in the loading speed. > > > > > > > > Do you think this will be solved? > > > > > > QGIS tweaks GDAL/OGR to use a large buffer size to speed up network > > > access to > > > shapefiles (or any format that uses the GDAL I/O layer, which is called > > > "VSI"). > > > > > > If you look at the qgis.bat in c:\osgeo4w\bin, you will see : > > > set VSI_CACHE=TRUE > > > set VSI_CACHE_SIZE=100 > > > > > > But by default, the OGR GPKG driver uses SQLite own I/O layer, which > > > probably > > > does access with a granualrity of a SQLite page size (4KBytes). You > could > > > tried to define the > > > SQLITE_USE_OGR_VFS=YES environmenet variable, restart Q
Re: [Qgis-developer] Fwd: Re: [Geopackage] Geopackage on a shared network drive
Le lundi 03 octobre 2016 10:33:25, Neumann, Andreas a écrit : > Hi Even, > > Thank you for sharing this finding! > > In that case I think that QGIS should offer a flag to open Geopackages > in read-only mode. I'm not sure we need an explicit flag for read-only mode (in the GUI I mean). This could bring some complications: for example should that be saved with the layer in a project file? But if so, then you'd be stuck to read-only later if you want to edit a layer, etc. Read-only mode could be the default mode for opening, and re-open in read- write mode when this is needed. This is something I've done recently, but limited to MapInfo .tab, since opening .tab files in read-write mode prevented concurrent opening of the file in QGIS & MapInfo. I didn't want to mess with other formats, but fundamentally I don't see any reason why this couldn't be generalized to other formats (I'm not sure why QGIS has historically opened in read-write mode as first try. Probably because this was easier to implement) For GPKG, there's just one subtelty though. I've fixed recently #15351 and to avoid deadlocks between readers&writers, the first to open a GPKG needs to turn on write ahead log (WAL) journalisation, so the workflow would be : - open in read only - check if journalisation is WAL - if so, done - if not, re-open in read-write, turn on WAL, re-open in read-only And similar on closing to revert to the default DELETE journalisation mode. Hum, with further thinking, I don't undertstand why my suggestion in the discussion thread on the geopackage ML of changing the file permission to read- only made things faster. Because, for feature iterators, QGIS uses a dedicated OGR connection in read-only mode and does not use the provider connection that might be in read-write mode. Unless the reporter still uses GDAL 1.11, which used to open in read-write mode regardless of what the user specified (was fixed in GDAL 2.0). That must be it. I'll check back with the reporter. So probably all the above is not needed after all... > > Even - since you are "Mr. Geopackage" in the QGIS project anyway - can > you please make sure that this can be covered in the upcoming Geopackage > improvements? Would a "read-only" mode also be useful for other data > formats? I opened a ticket at http://hub.qgis.org/issues/15652 and > assigned it to you. I have no idea how much effort this enhancement > would mean - can you please do an estimate and send me a quote for that? > Maybe we could still include it in the upcoming Geopackage improvements > financed by the Swiss QGIS user group. > > --- > > This also leads to a follow up question: many OGR data formats have > "open options". As far as I know, these options are not exposed to the > User in QGIS, other than the encoding - or did I miss something? Should > we introduce a "GUI" way in QGIS 3.x to expose these "open options" in > the "add vector layer" dialogue? Open options cannot be specified through QGIS currently indeed. There are not so many vector drivers that expose them, mostly those who are of the database type (with some redundancy with the way configuring the connection is already offered in the GUI). Some notable exceptions in the regular file category are CSV and GML. One downside of open options is that they can be rather esoteric and hard to understand for the average user, so I guess they should be presented in a expandable tab. GDAL offers the possibility to auto-discover which open options are available for a format, but that doesn't solve the issue with internationalization in QGIS. Although I think I discussed with someone about this and one possibility mentionned was to dump, at QGIS build time, the strings to translate from GDAL in a QGIS resource file. I didn't look how internationalization worked in QGIS. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Re: [Geopackage] Geopackage on a shared network drive
> There's the "read only" setting (hidden away) under Project Properties > -> Identify Layers which this could potentially hook into. Didn't know that one! I see this is done through the QgsVectorLayer::setReadOnly( bool readonly )" interface. So in case we would need that at the provider level (which is not so confirmed in this case) we could plug that there. Side note: on a quick try there's some oddity in the GUI. If I just change a layer to Read-Only the "Toggle editing" button is still enabled. It becomes disabled only after I choose the "Select features by id" mode and clicked on a feature. And symetrically when changing back to Read-Write. > > Nyall > > > --- > > > > This also leads to a follow up question: many OGR data formats have "open > > options". As far as I know, these options are not exposed to the User in > > QGIS, other than the encoding - or did I miss something? Should we > > introduce a "GUI" way in QGIS 3.x to expose these "open options" in the > > "add vector layer" dialogue? > > > > Thanks, > > Andreas > > > > On 2016-10-01 23:38, Even Rouault wrote: > > > > FYI: An interesting finding to improve performance of large Geopackage on > > a shared network drive. > > > > -- Message transmis -- > > > > Sujet : Re: [Geopackage] Geopackage on a shared network drive > > Date : samedi 01 octobre 2016, 16:41:05 > > De : Árni Geirsson via Geopackage > > À : Even Rouault > > CC : geopack...@lists.opengeospatial.org > > > > Yes! It renders very quickly after I set the read-only flag in the file > > explorer. > > That goes a long way towards solving the problem for me because as I > > mentioned, the team would like to use this format to store geodata, not > > to edit it and certainly not to make edits by multiple concurrent users. > > Thank you so much for your help! > > > > Árni > > > > > > Árni Geirsson > > *Alta ehf* // +354 582 5000 // +354 897 9549 > > www.alta.is // Alta á Twitter <http://twitter.com/alta_ehf> // Alta á > > Facebook <http://www.facebook.com/pages/Alta/161795813838691?v=wall> > > Gæða- og umhverfisstefna Alta <http://alta.is/pdf/svonavinnumvid.pdf> > > > > > > > > > > On 1 October 2016 at 14:28, Even Rouault > > wrote: > > > > Le samedi 01 octobre 2016 16:02:38, Árni Geirsson a écrit : > > > > Hello Even > > Thank you for your suggestion. I made the changes you suggested, adding > > set SQLITE_USE_OGR_VFS=YES > > after > > set VSI_CACHE=TRUE > > set VSI_CACHE_SIZE=100 > > but there was no difference. Was this perhaps not the right way to do it? > > > > > > Yes, that's correct. > > > > Hum actually reviewing the code, the cache mechanism is only enabled when > > the > > file is opened in read-only mode, whereas QGIS will open the file in > > read-write > > mode. > > > > You could perhaps try to make the GPKG read-only in the explorer?, at > > least just to test if it is a promising optimization. I guess write > > support for the > > cache mechanism could be added. > > > > A drawback of a cache machnism is that it would defeat the updates in > > SQLite > > to deal with concurrent editing, but anyway such mechanisms don't work > > very well on network shares. > > > > Anyway, I would think that I am not alone in seeing this as a problem > > > > but I > > > > find very little about it on the web. > > > > Árni > > > > > > > > Árni Geirsson > > *Alta ehf* // +354 582 5000 // +354 897 9549 > > www.alta.is // Alta á Twitter <http://twitter.com/alta_ehf> // Alta á > > Facebook <http://www.facebook.com/pages/Alta/161795813838691?v=wall> > > Gæða- og umhverfisstefna Alta <http://alta.is/pdf/svonavinnumvid.pdf> > > > > > > > > > > On 30 September 2016 at 19:52, Even Rouault > > > > wrote: > > > > Le vendredi 30 septembre 2016 00:44:45, Árni Geirsson via Geopackage a > > > > écrit : > > > > Dear Geopackage developers! > > I look forward to the day when Geopackage replaces the old shapefiles > > > > > > and I > > > > thank you for your efforts. As a user in a small team that uses QGIS > > and shares data on a NAS box, basically a Samba server for network > > shares, I notice that Geopackag
Re: [Qgis-developer] Fwd: Re: [Geopackage] Geopackage on a shared network drive
Le lundi 03 octobre 2016 11:49:52, Even Rouault a écrit : > Le lundi 03 octobre 2016 10:33:25, Neumann, Andreas a écrit : > > Hi Even, > > > > Thank you for sharing this finding! > > > > In that case I think that QGIS should offer a flag to open Geopackages > > in read-only mode. > > > I'm not sure we need an explicit flag for read-only mode (in the GUI I > mean). This could bring some complications: for example should that be > saved with the layer in a project file? But if so, then you'd be stuck to > read-only later if you want to edit a layer, etc. > > Read-only mode could be the default mode for opening, and re-open in read- > write mode when this is needed. This is something I've done recently, but > limited to MapInfo .tab, since opening .tab files in read-write mode > prevented concurrent opening of the file in QGIS & MapInfo. I didn't want > to mess with other formats, but fundamentally I don't see any reason why > this couldn't be generalized to other formats (I'm not sure why QGIS has > historically opened in read-write mode as first try. Probably because this > was easier to implement) > > For GPKG, there's just one subtelty though. I've fixed recently #15351 and > to avoid deadlocks between readers&writers, the first to open a GPKG needs > to turn on write ahead log (WAL) journalisation, so the workflow would be > : > > - open in read only > - check if journalisation is WAL >- if so, done >- if not, re-open in read-write, turn on WAL, re-open in read-only > > And similar on closing to revert to the default DELETE journalisation mode. > > > Hum, with further thinking, I don't undertstand why my suggestion in the > discussion thread on the geopackage ML of changing the file permission to > read- only made things faster. Because, for feature iterators, QGIS uses a > dedicated OGR connection in read-only mode and does not use the provider > connection that might be in read-write mode. Unless the reporter still > uses GDAL 1.11, which used to open in read-write mode regardless of what > the user specified (was fixed in GDAL 2.0). That must be it. I'll check > back with the reporter. So probably all the above is not needed after > all... I have had several follow-up exchanges with Árni Geirsson and the conclusions I drew from his test results are : - the apparent cause for performance degradation is that there exists a file handle opened in read/write mode on the GeoPackage. An existing file handle in read/write mode negatively impacts performance on read-only connections. And that is true when this R/W file handle is in the same process than the R/O file handle, or in other process (we tested ogr2ogr performance when reading a remote GPKG file, while QGIS opened on this GPKG) Does such behaviour of files on network shares on Windows ring a bell to someone ? I tried (quickly) to find if this was a documented behaviour but didn't manage to find. So my above suggested changes between would appear to be worth (except that I went a bit too fast in my explanations and you don't want to turn WAL on files on network shares, but this is something I had already implemented per #15351) - VSI_CACHE in the GeoPackage case (when enabled with SQLITE_USE_OGR_VFS=YES) does not seem to bring any performance improvement. And I'd wondering if this wouldn't be the case now for shapefile since (contrary to what I said above), both shapefile and mapinfo are now opened by default in read-only mode. Or perhaps VSI_CACHE has still effect since in sqlite case access are made on a sqlite page granularity (1024 bytes) whereas for shapefile that might be just a few bytes. But clearly there's something happening at Windows OS level when a R/W connection exists. ==> It would be cool if someone could test, with QGIS 2.16.3, shapefile performance on network share, by removing/commenting the set VSI_CACHE=YES environment variable of qgis.bat. > > > Even - since you are "Mr. Geopackage" in the QGIS project anyway - can > > you please make sure that this can be covered in the upcoming Geopackage > > improvements? Would a "read-only" mode also be useful for other data > > formats? I opened a ticket at http://hub.qgis.org/issues/15652 and > > assigned it to you. I have no idea how much effort this enhancement > > would mean - can you please do an estimate and send me a quote for that? > > Maybe we could still include it in the upcoming Geopackage improvements > > financed by the Swiss QGIS user group. > > > > --- > > > > This also leads to a follow up question: many OGR data formats have > > "open options". As far as I
Re: [Qgis-developer] Fwd: Re: [Geopackage] Geopackage on a shared network drive
Le mercredi 05 octobre 2016 21:51:03, vous avez écrit : > On 05-10-16 17:17, Even Rouault wrote: > > Does such behaviour of files on network shares on Windows ring a bell to > > someone ? I tried (quickly) to find if this was a documented behaviour > > but didn't manage to find. > > Hi Even, well this rang with me: > > https://hub.qgis.org/issues/6448 > > it's an old discussion about reading shapefiles over a Windows network... > > And it was also talking about VSI_CACHE, and I also (from the issue) had > a little chat with Frank W about it: > > http://irclogs.geoapt.com/gdal/%23gdal.2012-07-25.log > > HTH maybe Thanks for the pointers. Helpful indeed. The situation has changed since now QGIS opens the shapefile handle of the QgsOgrProvider object in read-only mode by default (used to be read-write before latest 1.16 and 1.14 point releases), hence I'm wondering if the VSI_CACHE mechanism has still some effect on the read-only handles owned by the QgsOgrFeatureIterator objects, which are the ones that matter for rendering operations. Seeing https://msdn.microsoft.com/en-us/library/windows/desktop/aa365433%28v=vs.85%29.aspx which is about opportunistic locks, I would think that a read-write file handle would defeat opportunistic locks, hence the slowness seen. That would also what Radim suggested in a comment : "OpLocks are broken for read only files, not for read write files if opened as read only, at least this was observed on Windows XP + Samba" -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Preparing the Changelog for 2.18
Le mercredi 05 octobre 2016 22:33:04, Tim Sutton a écrit : > Hi All > > I have started preparing the changelog for 2.18: > > http://changelog.qgis.org/en/qgis/version/2.18.0/ > > The usual caveat applies: Please do not publicize this link until the > changelog is completed and the release is ready. > > If anyone has worked on newsworthy features for 2.18 please add your > proposed entries there (I am still working back through the commit log > adding any obvious ones I can see there, I will finish that tomorrow > night). You should be able to sign in to the site and post new entries > using your GitHub user credentials. If that presents any problem for you, > please just email me directly with the text and ideally a screenshot, and > I will add it for you. Also if you can improve text and graphics for > existing entries, please feel free to submit your suggestions. > > I will be adding a few notes at the top of the changelog description of the > upcoming feature freeze breakage for 2.18.1 (to add DWG support) and > 2.18.2 GeoPackage provider improvements. @Even could you provide a little > detail about the planned GeoPackage improvements for 2.18.2? Tim, Hum, I'm not sure if this will go into 2.18. Was more intended to be for master and possibly backported in master_2 if feasible. But I guess if master_2 is doable, backport to 2.18.X could also be done (although there will be non trivial changes in DB manager to separate the spatialite code path and GPKG code path) Anyway, here are the topics: * Add, rename and remove columns, both in the "Fields tab" of QGIS, but also in the DB manager ( Note: this will require GDAL 2.2dev for rename and remove columns) * Add capability to save an existing layer in the project with "Save As" into an already existing geopackage (rather than overwriting it) * DB-Manager: rename existing tables in geopackage ( Note: this will require GDAL 2.2dev) * DB-Manager: delete tables from the geopackage. * DB-Manager: load non-geometry tables There will be other improvements, but probably master only. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Preparing the Changelog for 2.18
Le jeudi 06 octobre 2016 00:15:50, Nyall Dawson a écrit : > On 6 October 2016 at 06:54, Even Rouault wrote: > > Le mercredi 05 octobre 2016 22:33:04, Tim Sutton a écrit : > >> Hi All > >> > >> I have started preparing the changelog for 2.18: > >> > >> http://changelog.qgis.org/en/qgis/version/2.18.0/ > >> > >> The usual caveat applies: Please do not publicize this link until the > >> changelog is completed and the release is ready. > >> > >> If anyone has worked on newsworthy features for 2.18 please add your > >> proposed entries there (I am still working back through the commit log > >> adding any obvious ones I can see there, I will finish that tomorrow > >> night). You should be able to sign in to the site and post new entries > >> using your GitHub user credentials. If that presents any problem for > >> you, please just email me directly with the text and ideally a > >> screenshot, and I will add it for you. Also if you can improve text and > >> graphics for existing entries, please feel free to submit your > >> suggestions. > >> > >> I will be adding a few notes at the top of the changelog description of > >> the upcoming feature freeze breakage for 2.18.1 (to add DWG support) > >> and 2.18.2 GeoPackage provider improvements. @Even could you provide a > >> little detail about the planned GeoPackage improvements for 2.18.2? > > > > Tim, > > > > Hum, I'm not sure if this will go into 2.18. Was more intended to be for > > master and possibly backported in master_2 if feasible. But I guess if > > master_2 is doable, backport to 2.18.X could also be done (although there > > will be non trivial changes in DB manager to separate the spatialite > > code path and GPKG code path) > > > > Anyway, here are the topics: > > * Add, rename and remove columns, both in the "Fields tab" of QGIS, > > but > > > > also in the DB manager ( Note: this will require GDAL 2.2dev for rename > > and remove columns) > > Is this one public yet? I'd love to have a look over. I haven't started yet development of any of those items (in QGIS or in GDAL) for now. In the next days... -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Preparing the Changelog for 2.18
> Ok - was just wondering if you're planning on hooking into existing > methods like QgsVectorDataProvider::renameAttributes here or whether > it'll be something specific to this format. That will of course use QgsOgrProvider::renameAttributes() which already exists and calls OGR_L_AlterFieldDefn(), so it is a matter of implementing the AlterFieldDefn API in the OGR GPKG driver. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Warning - shapefile corruption on 2.16/master and how to recover
Le vendredi 16 septembre 2016 03:08:37, Nyall Dawson a écrit : > Unfortunately a fairly nasty regression has slipped in to 2.16 and is > still present on master. This results in shapefile corruption in > certain circumstances. I've commited in GDAL trunk and 2.1 branch a fix that revises the way repacking of shapefiles is done, so as to use in-place rewrite of the already opened file rather than trying to remove the temporary copies on top of them, which was prone to issues with files being locked elsewhere. From my tests this solve the issues I could reproduce in http://hub.qgis.org/issues/15570 and http://hub.qgis.org/issues/15393 and I'm reasonably confident this is a robust fix for other similar cases. Anyway, testing by others to confirm would be appreciated. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Error in WFS QgsDataProvider.dataSourceUri()?
Le vendredi 16 septembre 2016 14:19:22, Tom Chadwin a écrit : > OK, I'll not submit a PR, but let others decide if it's worth it. FYI, I've just noticed Jürgen fixed the typo in master and master_2 (while accepting a URI with the typo) : https://github.com/qgis/QGIS/commit/9ae12c811d7d8bcb1cba93f1ff14f46e747e3039 > > Thanks > > Tom > > > > - > Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/Error-in-WFS-QgsDataProvider-dataSourc > eUri-tp5286330p5286337.html Sent from the Quantum GIS - Developer mailing > list archive at Nabble.com. > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Warning - shapefile corruption on 2.16/master and how to recover
Le samedi 17 septembre 2016 00:00:55, Jeff McKenna a écrit : > On 2016-09-16 3:53 PM, Even Rouault wrote: > > One of my hypothesis is some bad interaction with the "connection pool". > > Could you (or anyone) open the attribute table before doing the edits,and > > do the edits and commit them no more than 60 seconds afterwards ? I'm > > not sure but this might perhaps also require the shapefile to be big > > enough (several thousands of features). > > Here was my next test: > > - download OSM land polygons for the world, unsplit: > http://data.openstreetmapdata.com/land-polygons-complete-4326.zip > 424MB 568,635 features <--- big test! > > - add shapefile to QGIS 2.16.2 view > > - open attribute table > > - start editing > > - after a while waiting for nodes to appear as QGIS works, message is > displayed of "qgis-bin.exe has stopped working" I've tried your file 2.16.3 in a Win7 VM with 4GB and trying to reproduce your actions but didn't get a crash. I managed painfully to move a node of the coastline of western part of France. Note that I used a 64 bit build, and I noticed that the memory consumption goes up to 3 GB when you enable the Node tool (goes down to 300 MB once you finish all editing actions), so if you use a 32 bit build, a crash is not surprising. All the actions are super slow, particularly making a node active and moving it. There are clearly issues, with algorithms, data structures and memory use, when dealing with huge polygons. I also noticed that there's apparently always a core busy until you finish editing. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] gdalwarp fails, Save as... reprojected works
Le dimanche 09 octobre 2016 23:27:04, Victor Olaya a écrit : > If the parameter is not needed, it should be optional. > > If anyone can confirm that, I will make it optional. From the doc http://gdal.org/gdalwarp.html, the only required parameters are the input and output files :-) > > Cheers > > 2016-10-09 23:05 GMT+02:00 Giovanni Manghi : > >> Hi all, > >> reprojecting a raster from 4326 to 3857 through Save as... menu works, > >> whereas the same through Processing does not: > >> > >> gdalwarp -ot Float32 -t_srs EPSG:3857 -r near -of GTiff -te -20.0 40.0 > >> 20.0 90.0 -te_srs EPSG:4326 -co COMPRESS=DEFLATE -co PREDICTOR=1 -co > >> ZLEVEL=6 -wo OPTIMIZE_SIZE=TRUE gt30w020n90.dem OUTPUT.tif > >> GDAL command output: > >> ERROR 1: tolerance condition error > >> ERROR 1: -te_srs ignored since coordinate transformation failed. > >> > >> With GDALTools it works. The CL in this case is: > >> > >> gdalwarp -overwrite -s_srs EPSG:4326 -t_srs EPSG:3857 -of GTiff > >> gt30w020n90.dem test_repro.tif > >> > >> So apparently Processing introduces unnecessary, damaging, params. > > > > I assume that your input is > > > > http://svn.simo-project.org/tools/trunk/txt2latlon/data/ > > > > A quick test from the cli would have shown you that the issue is in > > > > "20.0 40.0 20.0 90.0" > > > > for the "-te" parameter. If a smaller extent is defined the > > tool/command works (in fact the exact extent of the raster is not that > > one). Leaving the extent automatically defined/computed by Processing > > does not seems to be an issue for the majority of inputs. > > > > Regarding this tool my question is another: why the "te_srs" parameter > > (and by consequence also "te") has been made mandatory? > > > > -- G -- > > ___ > > Qgis-developer mailing list > > Qgis-developer@lists.osgeo.org > > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QgsField::length semantic
Le mardi 11 octobre 2016 11:42:12, Jürgen E. Fischer a écrit : > On Tue, 11. Oct 2016 at 10:45:18 +0200, Sandro Santilli wrote: > > Chasing a regression bug upon importing shapefile to postgresql [1] > > I've stumbled upon an unclear semantic of the "length" member of > > QgsField class [2]. > > Hm, I though that was following database semantics - at least that's what I > recall - maybe it was changed. > > Not sure OGR has a general semantic of it's own, maybe it follows the data > source and those are inconsistent. More or less. My analysis of the OGR situation at: http://hub.qgis.org/issues/15188#note-8 > > For what I know in shapes and postgres the semantics is different as the > decimal separator is considered part of the precision in one, but not the > other. > > > Jürgen -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QgsField::length semantic
> According to this: > http://devzone.advantagedatabase.com/dz/webhelp/advantage9.0/server1/dbf_fi > eld_types_and_specifications.htm > > A DBF field with extended data type "double" does not affect the > precision of the stored data, and the length information is simply > ignored. I had never seen such "double" type in use in .dbf, and it is certainly not handled by shapelib/OGR, and I have never seen reports that other shapefile producing software generate such field types. Might be a "Visual FoxPro" specific thing. > > After all, a "Double" in a DBF is just 8 bytes anyway, so why bother > attempting to go beyond that ? Qgis is storing values in a Double too, > and the only reason I see to support "numeric" is storing arbitrary > precision values, which don't seem to be supported by OGR: > http://www.gdal.org/ogr__core_8h.html#a787194bea637faf12d61643124a7c9fc True, OGR ends up storing numeric fields as C double. The width/precision is mostly informative (and occasionnaly indeed an annoyance when backends start using it...) > > --strk; > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QgsField::length semantic
Le mardi 11 octobre 2016 12:21:31, Sandro Santilli a écrit : > On Tue, Oct 11, 2016 at 12:11:06PM +0200, Even Rouault wrote: > > > According to this: > > > http://devzone.advantagedatabase.com/dz/webhelp/advantage9.0/server1/db > > > f_fi eld_types_and_specifications.htm > > > > > > A DBF field with extended data type "double" does not affect the > > > precision of the stored data, and the length information is simply > > > ignored. > > > > I had never seen such "double" type in use in .dbf, and it is certainly > > not handled by shapelib/OGR, and I have never seen reports that other > > shapefile producing software generate such field types. Might be a > > "Visual FoxPro" specific thing. > > So what are those OFTReal types coming from ? From DBF 'N'umeric or 'F'loat fields : https://github.com/OSGeo/gdal/blob/trunk/gdal/ogr/ogrsf_frmts/shape/dbfopen.c#L1273 which are mapped to Shapelib FTDouble which is then mapped to OGR OFTReal -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QgsField::length semantic
Le mardi 11 octobre 2016 12:17:44, Sandro Santilli a écrit : > On Tue, Oct 11, 2016 at 11:53:27AM +0200, Even Rouault wrote: > > Le mardi 11 octobre 2016 11:42:12, Jürgen E. Fischer a écrit : > > > On Tue, 11. Oct 2016 at 10:45:18 +0200, Sandro Santilli wrote: > > > > Chasing a regression bug upon importing shapefile to postgresql [1] > > > > I've stumbled upon an unclear semantic of the "length" member of > > > > QgsField class [2]. > > > > > > Hm, I though that was following database semantics - at least that's > > > what I recall - maybe it was changed. > > > > > > Not sure OGR has a general semantic of it's own, maybe it follows the > > > data source and those are inconsistent. > > > > More or less. My analysis of the OGR situation at: > > http://hub.qgis.org/issues/15188#note-8 > > Then I think the OGR provider should just avoid setting OFTReal fields > length/precision values, upon reading (but also upon writing, as long > as the QgsField length/precision for Double-typed fields would not be > defined). > > Does it make sense ? On reading, should be hopefully rather harmless. On writing, looking quickly at the provider, I couldn't see where OGR_Fld_SetWidth()/Precision would be called with a non-zero value on a OFTReal field if QgsField length/precision is not set > > --strk; -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Backport of master feature in QGIS 2.18
Hi, I'm currently working on improving geopackage support in QGIS and a first part of this is https://github.com/qgis/QGIS/pull/3597 (other part will be DBManager changes) It has been raised that this would be worth backporting in QGIS 2.18.x, hence a few questions: - this PR adds new strings to translate (the DBManager changes might also). Will translators do another round of translations for 2.18.x ? If not, this might not be material appropriate for 2.18.x - as we are in 2.18.0 feature freeze, must I wait for 2.18.0 to be released before backporting (depending on previous question) ? Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] run only one unit test?
Le jeudi 13 octobre 2016 19:31:08, Sandro Santilli a écrit : > On Thu, Oct 13, 2016 at 07:07:01PM +0200, Raymond Nijssen wrote: > > Can I run only one unit test, instead of all 244? > > > > Something like: > > > > make test QgsSymbolLayerCreateSld > > Something like this should work: > > ctest -R QgsSymbolLayerCreateSld > > See tests/README.md, and please help improving it > (for example: can I run just a *single* test inside a test unit?) I usually do something like this shortcircuiting ctest: QGIS_PREFIX_PATH=output PYTHONPATH=output/python:$PYTHONPATH \ python ../tests/src/python/test_qgsvectorfilewriter.py TestQgsVectorLayer.testOverwriteLayer > > --strk; > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] About my plugins ...
Le samedi 15 octobre 2016 15:32:42, Geo DrinX a écrit : > 2016-10-14 8:42 GMT+02:00 Nathan Woodrow : > > Hey, > > > > Have you raised this as a issue with us. Can't really fix anything if > > it's not raised. > > > > What you suggest we do to make it better? > > > > Regards, > > Nathan > > Well, good question. I thank you for making me the question. > > My opinion is : There is no need to have an approval process. What is it > for ? > Who judges the job, maybe months, another programmer, who is giving to the > community that has developed because of its usefulness ? > Maybe Richard Stallman ? By chance Gary Sherman ? > Probably would not do it even they. > > I think right now the approval of the plugin is only a manifestation of > power. > > It is nothing but this. > > Imagine Wikipedia and prior approval. It would be composed of only ten > pages. > Imagine OpenStreetMap. Only two roads. Other than free map of the world ! > > Make free plugins. As long as you are on time. There's an important difference. Neither contributing *data* to Wikipedia nor OpenStreetMap involves security risk for users of those databases. On the contrary contributing a plugin to QGIS is contributing *code* that will run with the privledges of the user running QGIS, so potentially thefting data / destroying data / installing malware / doing whatever nasty you can imagine. Making a plugin available in the default repository is like accepting a code contribution to QGIS core. That involves some form of trust in the contributor. > > > geodrinx > > > On Fri, Oct 14, 2016 at 4:35 PM, Geo DrinX wrote: > >> Good morning :) > >> > >> > >> I am here to inform you that I just removed from the repository the > >> latest plugin version 3.0.4 of GEarthView, and also other my plugins. > >> > >> I have taken this decision to draw your attention on the mechanism of > >> the plugin approval, which I think is totally insufficient and > >> inadequate. > >> > >> I recommend you review this procedure and pay more attention to whom is > >> dealing, which should be a technical, and not another. > >> > >> I am sorry for the difficulties that my decision will cause to > >> unsuspecting users of my plugin, but they can continue to download my > >> plugin from my official repository on github. > >> > >> I thank you for your attention > >> > >> > >> Best Regards > >> > >> Roberto (geodrinx) > >> > >> ___ > >> Qgis-developer mailing list > >> Qgis-developer@lists.osgeo.org > >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] About my plugins ...
Le dimanche 16 octobre 2016 15:00:21, Tim Sutton a écrit : > Hi > > In addition to Martin and Nathan's great replies I can add: > > On 16 Oct 2016, at 6:26 PM, Geo DrinX wrote: > > > > > > [Set up] an automatic procedure (antivirus, automatic control sources to > > figure out harmful instructions, etc.) that warns the existence of > > problems. > > This was the first option we looked in to. Do you know of some good tools > for detecting malicious code in python? It is a hard problem to solve and > simple things like preventing shell calls are not productive or effective. I wondered about the same recently for GDAL since I've introduced the possibility to write pixel functions in Python in a VRT file ( http://gdal.org/gdal_vrttut.html#gdal_vrttut_derived_python ) and wanted to have a way to know if they were safe enough or not to be executed by default. Sean Gillies pointed to me the following : """I found http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html to be a good intro to the risks of eval'ing untrusted Python code. Mentioned in there is a notable attempt to make a secure subset of Python called "pysandbox", but its developer has since declared it "broken by design": https://lwn.net/Articles/574215/."""; So the conclusion is that sandboxing Python is not believed to be possible, at least with the traditionnal CPython interpreter. It appears that PyPy has some sandboxing mechanism ( http://doc.pypy.org/en/latest/sandbox.html ) although that would probably very tricky to use in the QGIS context (not to mention the changes required to use PyPy!). You cannot even trust calls to the native C++ QGIS API to be safe in themselves. I'm pretty sure they could be abused to do evil things. > In the end we decided to take a social approach to peer review (which is a > completely different thing to censorship). By the way I am not averse to > some limited censorship of plugins if they go against our code of conduct > [1] and diversity statement [2] for example, I would support banning them. > I think any reasonable community would expect that of us > > [1] > https://www.qgis.org/en/site/getinvolved/governance/codeofconduct/codeofco > nduct.html [2] > https://www.qgis.org/en/site/getinvolved/governance/codeofconduct/diversit > ystatement.html > > > A case in point might be a plugin aimed at belittling a particular ethnic > group or gender identification or which otherwise promotes intolerance. > Thankfully such a situation has never arisen. Our friendly non-combative > community is something that makes the QGIS community a joy to participate > in. Lets try to keep that in mind whilst having this discussion too and > focus on practical, achievable solutions if you have concern Another thing to remember is the recent attempts at spamming OSGeo Trac instances. Opening the plugin catalog without control would lead to all sort of abuses. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Backport of master feature in QGIS 2.18
Any opinion ? > Hi, > > I'm currently working on improving geopackage support in QGIS and a first > part of this is https://github.com/qgis/QGIS/pull/3597 (other part will be > DBManager changes) > It has been raised that this would be worth backporting in QGIS 2.18.x, > hence a few questions: > - this PR adds new strings to translate (the DBManager changes might also). > Will translators do another round of translations for 2.18.x ? If not, this > might not be material appropriate for 2.18.x > - as we are in 2.18.0 feature freeze, must I wait for 2.18.0 to be released > before backporting (depending on previous question) ? > > Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] ogrLayerName in processing/tools/vector.py
Le mardi 18 octobre 2016 11:59:04, Sandro Santilli a écrit : > On Tue, Oct 18, 2016 at 11:55:21AM +0200, Mark Johnson wrote: > > > The problem, as Germán found out, is that the URI passed as parameter > > > is not necessarely an OGR provider URI, but a generic QGIS uri, from > > > any provider, so it cannot always be opened via ogr.Open. > > > > Yes, ogr-sysntax must be used. > > > > # -- Spatialite provider > > > > # dbname='/tmp/x.sqlite' table="t" (geometry) sql=' > > > > would need to call 'GetLayerByName' > > But the above is NOT an ogrDataSource > Please see with current master_2 branch if the test work for you > with both GDAL 1 and GDAL 2: > > Running the automated test is done via: > > ctest -V -R ProcessingToolsTest > > Manual tests imply importing layers to postgis (via processing). > > They pass here with GDAL 2 Sandro, Mark's point is for the particular case of layers with multiple geometry fields (as may be found in some spatialite DB for example). That's a different issue than the one you tackle. Even > > > --strk; > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Correction of QgsOgrProvider implementaion of GDAL 2.0
Mark, I unfortunately don't have time right now to review in detail your message & proposed changes, but a few suggestions though. > https://github.com/mj10777/QGIS/tree/master_2_ogrprovider > > (unfortunately I created this about 2 hours before 'master_2' died, so this > should be considered as a 'release-2_18' branch) I think you should target master only for your changes (and consider only GDAL >= 2 case). It is unlikely they are appropriate for backporting, or that should be considered in a later stage depending on the impact they have. You should try to create PR for each individual issue, otherwise it is super hard to deal with. > > --- > Main problems: > > Problem 01: > > The retrieval logic for Ogr-Layers changed between gdal 1.* and gdal 2.*. > This was reported on the 31.03.2015: > https://hub.qgis.org/issues/12479 > I didn't dig up into that but the issue here is with tables with multiple geometry columns, right ? In that case, the OGR uri should likely have a geometry= parameter so that the right column is selected. Similarly to what the spatialite or postgresql providers do. > > -- > Problem 02: > > Since 2015, new code has been added implementing gdal 2.* specific > functions, which will only be included when compiled/built against gdal > 2.*. > > Thus, when QGIS is complied against gdal 2.*, symbols/functions are added > - that doe not exist in gdal 1.*. To me, this is a non issue, or rather an issue we shouldn't try solving. In normal user environements this will not happen. This is just an issue for us developers that might play with multiple versions. What we might perhaps eventually want to ensure is that if QGIS is compiled with GDAL 2.X, it works reasonably well when running against GDAL 2.Y where Y >= X. And even that can be painful, because 2.Y can introduce for example new geometry types not handled in 2.X, so that would oblige to have runtime checks in addition to compile time checks. Binary distributions of QGIS are normally recompiled against a new major GDAL version if they will run against it. > > For QGIS 3.0: gdal 1.* support should be removed. This is probably reasonable. I guess that all target environments that will be able to run QGIS 3.0 will have at least GDAL 2.0. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] open vector data using specific GDAL driver
Le samedi 29 octobre 2016 12:30:38, Martin Landa a écrit :
> Hi all,
>
> I wonder whether it's possible to specify GDAL driver when creating
> QgsVectorLayer instance. The constructor allows passing uri, layer
> name and provider. Is there any way how to specify GDAL driver which
> will be used for opening datasource (let's say that we are working
> with datasource which can be open by two different GDAL drivers).
>
> composedURI = str(dbPath) + "|layername=" + dbTable
> layer = QgsVectorLayer(composedURI, layerName, 'ogr')
>
> Something like:
>
> sqliteDriver = ogr.GetDriverByName('SQLite')
> sqliteDataSource = sqliteDriver.Open(str(dbPath))
No, this is currently not possible this way
You could potentially achieve what you want by calling
blacklisted_driver = gdal.GetDriverByName('driver_you_dont_want')
blacklisted_driver.Deregister()
layer = QgsVectorLayer(composedURI, layerName, 'ogr')
do all the stuff you need with the layer
blacklisted_driver.Register()
>
> Thanks, Martin
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Compile QGIS master on Ubuntu 14.04 / missing packages
Le lundi 07 novembre 2016 11:53:44, Stefan Ziegler a écrit : > Hi > > I'm trying to compile QGIS master on Ubuntu 14.04. According to the INSTALL > [1] file I try to install the build depencies but I can't find some of > them: > > E: Unable to locate package libqca-qt5-2-dev > E: Unable to locate package libqca-qt5-2-plugins > E: Unable to locate package libqwt-qt5-dev > E: Unable to locate package pyqt5.qsci-dev > E: Couldn't find any package by regex 'pyqt5.qsci-dev' > E: Unable to locate package python3-future > > Any ideas? You need to self compile them, or use 16.04. > > [1]: https://github.com/qgis/QGIS/blob/master/INSTALL > > best regards > Stefan -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Changing ergonomy of the visibility of layers inside groups ?
Hi, I've been involved in discussions about improving/changing how visibility of layers (or groups) is handled when they are inside groups. Currently if you check/uncheck a group, this recursively checks/unchecks all its items (layers or sub-groups). There are workflows with large projects that include ~ 50 layers in several groups and where users need to quicly turn on/off the visibility of groups, but when they don't want to change the visible of items inside the group. For those use cases, the layer themes functionnality has been tested but doesn't solve the need to be able to quickly (1 click) turn on/off/on/off the visibility of a group to be able to detect changes between raster imagery (the human eye is sensitive to movements more than colors), and they don't really have predefined configurations (would require creating tens of them) Basically what is proposed is the following: [ ] Group [x] Layer 1 --> Layer checked but group is not --> invisible [ ] Layer 2 [x] Group [x] Layer 1 --> Layer checked and group too --> visible [ ] Layer 2 There's a ticket https://hub.qgis.org/issues/14547 about that. In the ticket it is suggested that the current behaviour might be preserved by using control-click. Control-click on a group would check/uncheck recursively all sub-items. One effect of this change is that there wouldn't be anymore a tri-state for a group. It is either checked or unchecked. One potential downside of the new behaviour would be that it might not be immediately obvious to determine the visibility of a layer if you have several levels of hiearchy : looking only at the layer item if it is checked isn't sufficient to tell about its visibility. Not sure if that's an issue though (and if so what could be ways of indicating the visibility state) At the API level, from what I can see, * Qt::CheckState QgsLayerTreeGroup::isVisible() would be renamed to bool isChecked() since it would be a binary state and not related to visibility. I'm not sure if there are users outside of the layer tree mechanism where we really need to want if a group is visible (ie all its subgroups and layers are visible ?). Wouldn't be hard to implement anyway * Qt::CheckState QgsLayerTreeLayer::isVisible() would be "split" into a bool isChecked() and a bool isVisible(). The later would inspect recursively its parents to figure out the final visibility state. Thoughts ? Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Changing ergonomy of the visibility of layers inside groups ?
> I think this would be a good improvement to the usability of the legend > groups. > > Does it make sense to add a right-click action to maintain the possibility > of hierarchical/recursive selection of the group items? Yes, users might not necessarily be aware of the Ctrl+click shortcut. For the contextual menu, I can imagine different variations: - one item whose label&action would change according to the context. For example if the child groups and layers have different check state, or all unchecked, then it would be "Check all subgroups and layers". And if they are all checked, it would be "Uncheck all subgroups and layers". Downside is that you need to do it twice to go from the state where subitems have different check state to the state where they are all unchecked. But that would be consistent with the behaviour of the Ctrl+click action. - have the 2 items "Check all subgroups and layers" and "Uncheck all subgroups and layers" always displayed (but potentially greyed if not available given the state of the subitems) - or variation of the above, show 0, 1 or 2 of the items according to the context (0 for a group no subgroup/layer, 1 if all subitems are checked/ unchecked, 2 if there are different check state) ==> This one is probably the best one as it seems our contextual menus are rather dynamic according to the context -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Changing ergonomy of the visibility of layers inside groups ?
> Grey out is already used to indicate that a checked layer is currently > out of its scale range of visibility (hence not visible). so it may be good > to keep greying layers when they "should" be visible but another option > makes them not rendered. > Good suggestion -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Changing ergonomy of the visibility of layers inside groups ?
> The visualisation could still be tri-state, I think > > * Unchecked > * Checked (All subitems checked) > * Semi-checked (Checked but some sub-items are invisible) > > Clicking would then switch between either Unchecked and Semi-Checked or > Unchecked and Checked depending on the subitems. > That might work indeed. It is just hard to imagine what is the more natural way of handling this. I couldn't find something similar in other applications Let me think out loud to a scenario :-) > The approach sounds good. What do you think about integrating on both > levels (group and layer) the methods isVisible() and > itemVisibilityChecked() methods? If we allow isVisible() for groups, it would need to be 3 state : TotallyVisible, PartiallyVisible, Invisible (probably better than using the Checked semantics directly, so we can decorrelate from how we render partial visibility) -- Spatialys - Geospatial professional services http://www.spatialys.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
