[Qgis-developer] Plugin [998] Standard Deviational Ellipse approval notification.

[noreply]

Plugin Standard Deviational Ellipse approval by pcav.
The plugin version "[998] Standard Deviational Ellipse 1.2" is now approved
Link: http://plugins.qgis.org/plugins/SDEllipse/
___
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] QGIS Default Style

[Akbar Gumbira]

Hi All,

I realized that there are some Qt components in QGIS that their style are
not changed after changing the UI theme (in Settings), for example the grey
background QListWidget. Is there API to apply these default style to be
used in Python Plugin?

Cheers

-- 

*---*
*Akbar Gumbira *
*www.akbargumbira.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] (Yet again) SAGA support badly broken in QGIS

[Victor Olaya]

>
> SAGA already can use OGR instead of just shapefiles. By using the
> module io_gdal you can load a file through OGR into memory, do your
> analysis and save using the same module to any ogr file.
> It does not have to be a shape file. In the gui, try dragging and
> dropping an OGR supported file on saga or go through
> geoprocessing>file>gdal/ogr import.

I might be wrong but...how do you use that in the command line? We
already use io_gdal for converting formats (a step we would like to
avoid...), but the call to an actual module that does analysis can
only be made (correct me if I'm wrong) with a shapefile as input (in
the case of vector layers).

can you, for instance, call an algorithm passing a geojson file as input?

Thanks!
___
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

[Richard Duivenvoorde]

Off course I do not want to be to harsh for your users, but this is one
ot the troubles of closed source servers/software: it takes time to get
something fixed (well that is not new...) but also it is impossible to
fix/find stuff yourself too, making you totally dependent on the
company, selling you stuff.

And in name of the 'standards', I would not encourage a client (like
QGIS) to be too tolerant about the standards. Even less if it makes
our/QGIS code more complex to maintain because of all the ifs and
options to handle this.

The plan to ditch Geomedia Web Mapserver in favour of QGIS-server is off
course the preferred solution, I don't like the parallel plan too much
either. :-)

Regards,

Richard


On 01-06-16 11:10, Neumann, Andreas wrote:
> Hi Even,
> 
> Thank you for your time to analyze the problem.
> 
> Unfortunately, while we can try to influence Geomedia Web Map server to
> become more standard compliant (which we probably should do), it means
> that we have to wait at minimum 1.5-2 years until these fixes would
> become available to us - if they even accept our demand for the fixes.
> 
> If you are willing to work on making QGIS "more tolerant" to read
> such WFS, we would probably be interested in funding this work. Probably
> cheaper and faster for us than trying to fix Geomedia Web Map server. On
> the other hand there is an internal effort at our organization to
> establish a parallel open source web map server (most likely QGIS
> server) next to Geomedia or potentially replace it over time.
> 
> I will discuss offlist with you and my colleagues to see what makes
> sense in our case.
> 
> Thanks,
> 
> Andreas
> 
> On 2016-05-31 18:53, Even Rouault wrote:
> 
>> 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
> 
>  
> 
>  
> 
> 
> ___
> 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

Re: [Qgis-developer] (Yet again) SAGA support badly broken in QGIS

[Bas Couwenberg]

I notice a distinct lack of consideration for the SAGA LTR effort.

That removes the need to incorporate SAGA into QGIS, and provides a 
stable API for 3rd parties to work with.


I suggest to support the LTR effort by Johan van de Wauw, and only 
consider incorporating SAGA into QGIS if the LTR effort proves to not 
resolve the integration issues.


Kind Regards,

Bas
___
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] (Yet again) SAGA support badly broken in QGIS

[Johan Van de Wauw]

> On Wed, Jun 1, 2016 at 2:16 PM, Neumann, Andreas 
> wrote:
>>
>> If you guys think about integrating SAGA closer into QGIS, could we also fix
>> the issue that SAGA is currently limited to reading Shapefiles for vector
>> input? Probably a lot of work - but would this be feasible?
>
> After last year's hackfest in Nodebo just out of curiosity I was
> looking at the feasibility of replacing SAGA's native shapefile
> support by OGR. IMHO it is feasible - not something for a rainy
> afternoon, but maybe a project for 2-3 weeks of developer time. All
> work with shapefiles is done by API calls to saga core, so it would be
> a matter of reimplementing a part of the API. Similarly, raster access
> could be adapted to use GDAL. We could even use directly QGIS API for
> vector/raster access if we chose even tighter integration.

SAGA already can use OGR instead of just shapefiles. By using the
module io_gdal you can load a file through OGR into memory, do your
analysis and save using the same module to any ogr file.
It does not have to be a shape file. In the gui, try dragging and
dropping an OGR supported file on saga or go through
geoprocessing>file>gdal/ogr import.

The same thing is true for raster files. There is not much error
handling if you try exotic formats, but when used correctly it works.

It will still load everything in memory again. Directly using the QGIS
api will be harder (especially when changes are made), but there are
not too many things you can do with vector/raster data. I guess most
of the required methods are probably implemented.

>
> I think integrating SAGA tightly into QGIS would be very beneficial
> for both projects:
> - QGIS would finally have a native analysis engine, ending the long
> time struggle with changing parameter names, data conversions, CRS
> issues, algorithm naming (e.g. raster vs grid), duplication of
> algorithms etc.
> - SAGA source code would get more eyes of developers (increasing
> quality and bringing in new algorithms) and users. SAGA devs could
> focus more on algorithms as GUI side would be handled by QGIS.

Best first step would be including saga-gis-developer list in this thread.

Kind Regards,
Johan
___
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] (Yet again) SAGA support badly broken in QGIS

[Luigi Pirelli]

+1

if SAGA devs are not interested to merge in QGIS, I strongly suggest
to just fork a stable version shipped with qgis (as proposed in this
thread), but NOT to integrate the algs in qgis. I prefer to fix API
changes with fixed time frame (on demand) than maintaining a large
bunch of code.

cheers
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 1 June 2016 at 15:05, Martin Dobias  wrote:
> Hi
>
> On Wed, Jun 1, 2016 at 2:16 PM, Neumann, Andreas  wrote:
>>
>> If you guys think about integrating SAGA closer into QGIS, could we also fix
>> the issue that SAGA is currently limited to reading Shapefiles for vector
>> input? Probably a lot of work - but would this be feasible?
>
> After last year's hackfest in Nodebo just out of curiosity I was
> looking at the feasibility of replacing SAGA's native shapefile
> support by OGR. IMHO it is feasible - not something for a rainy
> afternoon, but maybe a project for 2-3 weeks of developer time. All
> work with shapefiles is done by API calls to saga core, so it would be
> a matter of reimplementing a part of the API. Similarly, raster access
> could be adapted to use GDAL. We could even use directly QGIS API for
> vector/raster access if we chose even tighter integration.
>
> I think integrating SAGA tightly into QGIS would be very beneficial
> for both projects:
> - QGIS would finally have a native analysis engine, ending the long
> time struggle with changing parameter names, data conversions, CRS
> issues, algorithm naming (e.g. raster vs grid), duplication of
> algorithms etc.
> - SAGA source code would get more eyes of developers (increasing
> quality and bringing in new algorithms) and users. SAGA devs could
> focus more on algorithms as GUI side would be handled by QGIS.
>
> This would be however best done with consent from SAGA developers, so
> we do not end up with two competing projects.
>
> Cheers
> Martin
> ___
> 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

[Qgis-developer] Plugin [728] STEM approval notification.

[noreply]

Plugin STEM approval by pcav.
The plugin version "[728] STEM 0.8.9 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/stem/
___
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] Plugin [999] Qgeric approval notification.

[noreply]

Plugin Qgeric approval by pcav.
The plugin version "[999] Qgeric 1.2 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/qgeric/
___
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] Plugin [1012] Cartographic Line Generalization approval notification.

[noreply]

Plugin Cartographic Line Generalization approval by pcav.
The plugin version "[1012] Cartographic Line Generalization 0.2" is now approved
Link: http://plugins.qgis.org/plugins/CartoLineGen-master/
___
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