Re: [Qgis-developer] SSL error on QGIS startup
On Fri, Oct 02, 2015 at 08:21:19AM +0200, Luca Delucchi wrote: > On 2 October 2015 at 08:08, Alessandro Pasotti wrote: > > > > Same here, even if I choose to save the certificate it pops up every time I > > start QGIS. > > Same here, it is really annoying Same here. Can it be an opt-in, to be annoying ? :) --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SSL error on QGIS startup
On 2 October 2015 at 08:08, Alessandro Pasotti wrote: > > Same here, even if I choose to save the certificate it pops up every time I > start QGIS. > Same here, it is really annoying -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SSL error on QGIS startup
To add some more information: this is on Ubuntu 15.04 64bit. I also tried starting QGIS without plugins, because I thought that maybe a Python Plugin may want to load something from the web, but the error message still appears. Thanks, Andreas On 02.10.2015 08:07, Andreas Neumann wrote: Hi, Since the integration of the new authentication system from Larry I am now getting an SSL error on Startup. See http://www.carto.net/neumann/temp/qgis_startup_ssl_error.png I have no idea what it means and what I can do in order to get rid of this error message. Does it mean that the connection to https://www.google.com/jsapi is not secure? Is QGIS now contacting a Google server at each startup? Thank you for any hint about this error message. Andreas ___ 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] SSL error on QGIS startup
Same here, even if I choose to save the certificate it pops up every time I start QGIS. 2015-10-02 8:07 GMT+02:00 Andreas Neumann : > Hi, > > Since the integration of the new authentication system from Larry I am now > getting an SSL error on Startup. See > http://www.carto.net/neumann/temp/qgis_startup_ssl_error.png > > I have no idea what it means and what I can do in order to get rid of this > error message. > > Does it mean that the connection to https://www.google.com/jsapi is not > secure? Is QGIS now contacting a Google server at each startup? > > Thank you for any hint about this error message. > > Andreas > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] SSL error on QGIS startup
Hi, Since the integration of the new authentication system from Larry I am now getting an SSL error on Startup. See http://www.carto.net/neumann/temp/qgis_startup_ssl_error.png I have no idea what it means and what I can do in order to get rid of this error message. Does it mean that the connection to https://www.google.com/jsapi is not secure? Is QGIS now contacting a Google server at each startup? Thank you for any hint about this error message. Andreas ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new dependency on GEOS C++ library
On Thu, Oct 01, 2015 at 05:41:58PM +0200, Sandro Mani wrote: > > > On 01.10.2015 17:26, Sandro Santilli wrote: > >So while the discussion on geos-dev started, I'm thinking that > >for GEOS you might prefer to have a solution that also works > >with older GEOS version ? Note that doing that by keeping the > >dependency on the C++ interface might be a puzzle for packagers > >because every version of GEOS is intentionally marked as being > >binary incompatible with the previous. > > > >Would it make sense to just do the gridding internally (dropping > >the geosc++ dep) for now and postpone the proper precision model > >implementation to only be available with the newer GEOS release ? > > > >The idea is to ship a 3.6 version of GEOS capable of the PrecisionModel > >control before February. > > > I suppose I could replace the incomplete precision reduction > implementation with a hand-rolled snap-to-grid for now and wait for > GEOS 3.6. If there are no objections, I'll move on with this this > weekend. Sounds good to me. I'd still love to gather your comments on geos-dev list for the new interface. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new dependency on GEOS C++ library
On 01.10.2015 17:26, Sandro Santilli wrote: So while the discussion on geos-dev started, I'm thinking that for GEOS you might prefer to have a solution that also works with older GEOS version ? Note that doing that by keeping the dependency on the C++ interface might be a puzzle for packagers because every version of GEOS is intentionally marked as being binary incompatible with the previous. Would it make sense to just do the gridding internally (dropping the geosc++ dep) for now and postpone the proper precision model implementation to only be available with the newer GEOS release ? The idea is to ship a 3.6 version of GEOS capable of the PrecisionModel control before February. I suppose I could replace the incomplete precision reduction implementation with a hand-rolled snap-to-grid for now and wait for GEOS 3.6. If there are no objections, I'll move on with this this weekend. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new dependency on GEOS C++ library
On Thu, Oct 01, 2015 at 04:38:53PM +0200, Sandro Santilli wrote: > On Thu, Oct 01, 2015 at 04:31:31PM +0200, Sandro Santilli wrote: > > On Thu, Oct 01, 2015 at 02:17:15PM +0200, Sandro Santilli wrote: > > > > > As known from the beginning, the challenge here is dealing with > > > management of the many GeometryFactory objects that would result > > > from the possibility of expressing them freely, and I start thinking > > > there's no way out of this than adding refcounting to the > > > GeometryFactory object so that it self-manages. > > > > I've stubbed this mechanism here: > > https://github.com/libgeos/libgeos/pull/52 > > > > Basically, once you don't need an explicit handle on your > > GeometryFactory you can call its "autoDestroy()" method and > > it will be destroyed once all the geometries referencing it > > are also deleted. > > > > Could be a key to what we're trying to do here. > > Note that with such feature, there would only need to be a single > new interface in the C-API, namely requesting reduction of the > precision of a geometry and optional scaling of coordinates. > There would be no need at all to expose PrecisionModel or > GeometryFactory to the outside world. Internally, the C-API might > still try to optimize the memory by re-using existing factories > with the same PrecisionModel. > > I guess this discussion would be better conducted on geos-dev > though... So while the discussion on geos-dev started, I'm thinking that for GEOS you might prefer to have a solution that also works with older GEOS version ? Note that doing that by keeping the dependency on the C++ interface might be a puzzle for packagers because every version of GEOS is intentionally marked as being binary incompatible with the previous. Would it make sense to just do the gridding internally (dropping the geosc++ dep) for now and postpone the proper precision model implementation to only be available with the newer GEOS release ? The idea is to ship a 3.6 version of GEOS capable of the PrecisionModel control before February. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Dev/test/bug fixing ratio for next LT release
Hi Jürgen, Have you given it some thoughts whether we should have a longer testing and bug fixing period before the LT release? E.g. 2.5 months development and 1.5 months testing/bug fixing? Or 2 months dev and 2 months testing/bug fixing? Would be good to know early on, esp. for the devs and organizations hiring devs. Thanks, Andreas ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new dependency on GEOS C++ library
On Thu, Oct 01, 2015 at 04:31:31PM +0200, Sandro Santilli wrote: > On Thu, Oct 01, 2015 at 02:17:15PM +0200, Sandro Santilli wrote: > > > As known from the beginning, the challenge here is dealing with > > management of the many GeometryFactory objects that would result > > from the possibility of expressing them freely, and I start thinking > > there's no way out of this than adding refcounting to the > > GeometryFactory object so that it self-manages. > > I've stubbed this mechanism here: > https://github.com/libgeos/libgeos/pull/52 > > Basically, once you don't need an explicit handle on your > GeometryFactory you can call its "autoDestroy()" method and > it will be destroyed once all the geometries referencing it > are also deleted. > > Could be a key to what we're trying to do here. Note that with such feature, there would only need to be a single new interface in the C-API, namely requesting reduction of the precision of a geometry and optional scaling of coordinates. There would be no need at all to expose PrecisionModel or GeometryFactory to the outside world. Internally, the C-API might still try to optimize the memory by re-using existing factories with the same PrecisionModel. I guess this discussion would be better conducted on geos-dev though... --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new dependency on GEOS C++ library
On Thu, Oct 01, 2015 at 02:17:15PM +0200, Sandro Santilli wrote: > As known from the beginning, the challenge here is dealing with > management of the many GeometryFactory objects that would result > from the possibility of expressing them freely, and I start thinking > there's no way out of this than adding refcounting to the > GeometryFactory object so that it self-manages. I've stubbed this mechanism here: https://github.com/libgeos/libgeos/pull/52 Basically, once you don't need an explicit handle on your GeometryFactory you can call its "autoDestroy()" method and it will be destroyed once all the geometries referencing it are also deleted. Could be a key to what we're trying to do here. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] TypeError: C++ type 'QgsFeatureIds' is not supported as a signal argument type
Hi, No Mac user able to reproduce the error? Am i the only one? m431m 25. Sep 2015 13:50 de m4...@tutanota.com: > > Hi QGIS developers! > > I got strange error with the 'commitedFeaturesRemoved' signal. > See: > > http://www.qgis.org/api/classQgsVectorLayer.html#a520550b45603ed20d593b1050768bd97 > > I try on python console (with any active layer on editing mode): > >>> layer = iface.activeLayer() > >>> def listener(s, l): > >>> print s, l > >>> layer.committedFeaturesRemoved.connect(listener) > > It returns `TypeError: C++ type 'QgsFeatureIds' is not supported as a > signal argument type` > > Now replace `layer.commitedFeaturesRemoved.connect(listener)`by: > >>> from PyQt4.QtCore import QObject > >>> from PyQt4.QtCore import SIGNAL > >>> QObject.disconnect(layer, SIGNAL(r"committedFeaturesRemoved()"), > listener) > > No error, but it returns `False`. > > If I delete some features and switch off editing mode, it returns nothing! > No print! The signal doesn't work(?) > > After exchanging a few message with some people on irc #qgis, the error > only appears with latest QGIS version on OSX10.10.5. (it works well with > 2.8.2). > > Maybe someone that has approached the same problem... and solved it? > > m431m___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Problem with GRASS 7 and Processing
On Thu, Oct 1, 2015 at 3:59 AM, Victor Olaya wrote: > Not sure what's the rationale for that line, since I am no GRASS > expert, There is no need to have GISBASE variable set (path to directory where GRASS binaries live) when GRASS GIS is started explicitly as a 'grass' command later on. If you have GISBASE, grass command will end with error as GISBASE says that you are already in GRASS session. Why GISBASE is set, or if deleting it is just a precaution, I have no idea. Best, Vaclav but this commit should fix it > > > https://github.com/qgis/QGIS/commit/87d8a12e79a4c889d72245fb2b3ba22100aab59f > > Please, try and confirm that it fixes the issue > > Regards > > 2015-10-01 9:36 GMT+02:00 matteo : > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > HI all, > > QGIS fresh compiled and Grass7 installed (works as standalone). > > I'm not able to run any of GRASS7 algorithm with Processing, this is > > the error: > > > > 2015-10-01T09:34:21 2 Could not load model model_PCA.model > > Error in algorithm name: r:acpcercle > > 2015-10-01T09:34:30 2 Uncaught error while executing algorithm > > Traceback (most recent call last): > > Traceback (most recent call last):| File > > "/home/ma7730/.qgis2/python/plugins/processing/core/GeoAlgorithm.py", > > line 227, in execute|self.processAlgorithm(progress)| File > > "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Algorit > > hm.py", > > line 425, in processAlgorithm|Grass7Utils.executeGrass7(commands, > > progress, outputCommands)| File > > "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Utils.p > > y", > > line 270, in executeGrass7|command, grassenv = > > Grass7Utils.prepareGrass7Execution(commands)| File > > "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Utils.p > > y", > > line 252, in prepareGrass7Execution|del env['GISBASE']|KeyError: > > 'GISBASE'| > > 2015-10-01T09:34:30 1 There were errors executing the > algorithm. > > > > > > Any idea? > > > > Thanks! > > > > Matteo > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2 > > > > iQEcBAEBCAAGBQJWDOKYAAoJEBy7UYf0gaEO9NcH/imnsNoRR9cgRIysh5tu5QWX > > HiOQIbAJcDjehJRr3+yDYLs7dMYPbaRkI4LlptuPsr+oB3p67KQkcXaFV2CKyNP5 > > x6QhKSHjrY7QTRXOnvGXgHfjeliQuLiB9G62j1JclbLy/o2XIZ9Rmq8D8yq9jB3W > > j6WwS22+78GKQUpDiK3dUfCEpQCTL3UoqpcxRPs39vwq2+WGO3D7NpW/tL623jNr > > G5oLNL6f6zl9L5R1zzXRjlS6cW9O+JhuwDiIot6q53nD9qyyCACz6GackdTLmbDB > > emRJNeU7Xor1ej1YzxMKH78jryZ9XHyWH4lpKQq6sOI7Nnanzy+YwSUSxyGsQro= > > =loCw > > -END PGP SIGNATURE- > > ___ > > 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 > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] OpenlayersPlugin QGIS
starting by saying that I never experienced problems with Openlayers plugin behind proxy, anyway I resolved all my proxy issues (user, passwords, subnet exclusions ...) using Qgis own network manager instead of creating a new one so you can try to remove the lines from 48 to 51 of openlayers_layer.py file and replace the row 52: self.setNetworkAccessManager(self.__manager) with the following: self.setNetworkAccessManager(QgsNetworkAccessManager.instance()) I just try and it goes but I don't know if it resolvs your issue. Regards Enrico Ferreguti 2015-10-01 12:32 GMT+02:00 Marica Landini : > Sorry, > I have this problem with 2.8 and 2.10.1 QGIS version (64bit) > I have not tried other versions > and I use Win7. > > I really appreciate any help you can provide. > Marica > > > On Thu, Oct 1, 2015 at 12:24 PM, Marica Landini > wrote: > >> Hi, >> I need to use OpenlayersPlugin QGIS behind proxy network. >> But I need to use defaultproxy settings configuration. >> >> QGIS works fine with this defaultproxy settings >> (also connection to wms/etc... >> reading plugin list and download it). >> >> But (with the defaultproxy settings) I can not work with OpenlayersPlugin >> QGIS >> that return: >> TypeError: unable to convert a QVariant of type 10 to a QMetaType of type >> 2 >> >> I can instead use this plugin with http proxy and setting manually the >> configuration (Settings->Options->Network) >> >> I have tryed to modify OpenlayersPlugin tool_network.py >> commenting setHostName/setPort/setUser/setPassword >> and using >> >> QNetworkProxy.setApplicationProxy(QNetworkProxy(QNetworkProxy.DefaultProxy)) >> obvious I do not get TypeError, >> but the plugin not work properly (e.g. I do not get OSM layer). >> >> How can I resolve this problem? >> There is another plugin that works with default (machine) proxy settings? >> (apologies for my english)... >> >> Cheers, >> Marica >> >> -- >> Ti prego di cercare di non inviarmi files .doc, .xls, .ppt, .dwg >> Preferisco formati liberi. >> Please try to avoid to send me .doc, .xls, .ppt, .dwg files. >> I prefer free formats. >> http://it.wikipedia.org/wiki/Formato_aperto >> http://en.wikipedia.org/wiki/Open_format >> >> Marica Landini >> > > > > -- > Ti prego di cercare di non inviarmi files .doc, .xls, .ppt, .dwg > Preferisco formati liberi. > Please try to avoid to send me .doc, .xls, .ppt, .dwg files. > I prefer free formats. > http://it.wikipedia.org/wiki/Formato_aperto > http://en.wikipedia.org/wiki/Open_format > > Marica Landini > > ___ > 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] new dependency on GEOS C++ library
On Thu, Oct 01, 2015 at 02:01:53PM +0200, Sandro Mani wrote: > On 01.10.2015 13:55, Sandro Santilli wrote: > > GEOSGeometry* GEOSGeometry_setFactory( GEOSGeometryFactory* factory, int > > roundCoordinates ); > > >But note that for such a call, the "factory" parameter would need > >to be alive for the whole lifetime of the returned GEOSGeometry > >_and_ for any further product from it (operation involving it as an input). > > > >These GeometryFactory links are sticky, that's what makes it hard to > >deal with them. > > If one sets the reduced precision factories on the geometries, does > one still need to explicitly reduce those geometries prior to > performing the analysis operation, or are they reduced implicitly > while performing the operation? Operation never pre-reduce inputs. That's why I added the second parameter. The only reason to pass "false" would be an optimization in case you know in advance your geometry is already constrained to the grid registered in the factory (that'd be case 1 in my mail from https://lists.osgeo.org/pipermail/geos-devel/2015-January/007097.html) The only way to construct geometries with the GEOS C-API right now is via WKB or WKT or passing a CoordinateSequence to any GEOSGeom_create* function. None of them applies any rounding and attached a singleton-like GeometryFactory to the result. So right now all geometries out of the C-API contain a reference to the very same GeometryFactory. Exposing function like: GEOSIntersection_reducedPrecision Would pose the question of whether or not the coordinates of input should be reduced. If we do reduce them, then chained operations would keep rounding the same coordinates again and again, while by storing the precision info inside each Geometry we are defining what is already rounded and to which grid. As known from the beginning, the challenge here is dealing with management of the many GeometryFactory objects that would result from the possibility of expressing them freely, and I start thinking there's no way out of this than adding refcounting to the GeometryFactory object so that it self-manages. I'll be trying something to that extent for the time being. As for QGIS, I guess you could have a function to "reduce" and a function to "register" a factory. So chained operations would: 0. reduce 1. register reduced factory 2. perform operation 1 3. perform operation 2 4. ... 5. register original factory In this case the "reduced factory" would just have a short living, and at the end of the operation chain there would still be a single factory alive. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new dependency on GEOS C++ library
On 01.10.2015 13:55, Sandro Santilli wrote: On Thu, Oct 01, 2015 at 01:39:37PM +0200, Sandro Mani wrote: As resulted from the discussion in the geos ticket: the goal is having the operations run in reduced precision, not just merely snap to grid. The discussion revealed however that snap to grid is basically what ends up being done with the current implementation, due to a mis-understanding of mine of the geos internals. As suggested in the geos ticket, I'd like to fix this to work as initially intended, and keep geosextra in QGIS until a new release of GEOS comes out which implements needed changes in the C-API. That's fine by me. I'm wondering if the easiest way to do it would be something like this: GEOSGeometry* GEOSGeometry_setFactory( GEOSGeometryFactory* factory, int roundCoordinates ); But note that for such a call, the "factory" parameter would need to be alive for the whole lifetime of the returned GEOSGeometry _and_ for any further product from it (operation involving it as an input). These GeometryFactory links are sticky, that's what makes it hard to deal with them. If one sets the reduced precision factories on the geometries, does one still need to explicitly reduce those geometries prior to performing the analysis operation, or are they reduced implicitly while performing the operation? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new dependency on GEOS C++ library
On Thu, Oct 01, 2015 at 01:39:37PM +0200, Sandro Mani wrote: > As resulted from the discussion in the geos ticket: the goal is > having the operations run in reduced precision, not just merely snap > to grid. The discussion revealed however that snap to grid is > basically what ends up being done with the current implementation, > due to a mis-understanding of mine of the geos internals. As > suggested in the geos ticket, I'd like to fix this to work as > initially intended, and keep geosextra in QGIS until a new release > of GEOS comes out which implements needed changes in the C-API. That's fine by me. I'm wondering if the easiest way to do it would be something like this: GEOSGeometry* GEOSGeometry_setFactory( GEOSGeometryFactory* factory, int roundCoordinates ); But note that for such a call, the "factory" parameter would need to be alive for the whole lifetime of the returned GEOSGeometry _and_ for any further product from it (operation involving it as an input). These GeometryFactory links are sticky, that's what makes it hard to deal with them. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGis and Socrata
Is it possible to access tabular data, without geometry field, (format json) from Socrata OpenData in QGis, in order to link them to other geodata? I found python code that does writing data in an existing table, but this is not a "live" connection. Cheers Francesca -- View this message in context: http://osgeo-org.1560.x6.nabble.com/QGis-and-Socrata-tp5227327.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new dependency on GEOS C++ library
Hi Sandro, In https://trac.osgeo.org/geos/ticket/713#comment:17, Sandro Mani wrote: > First thing to decide IMO is how to proceed for QGIS 2.12: I can fix my > geos_extra to construct the precision reducer correctly, get the fix > commited, and then as far as QGIS 2.12 is concerned things are ok and then we > can take the time to design a proper C API for GEOS. If this is okay with > you, I'll do that and then yes, we can continue where we left of on the > mailing list. We now depend on something that is not even in the latest GEOS and we also build on platforms/distributions that would be behind even if the latest GEOS supported this. So the geosextra stuff and the geos C++ dependency will have to stay for those. In OSGeo4W I'll just update the patch in the GEOS package - as we don't ship the C++ API there anyway - to avoid trouble with the compiler abi zoo on windows. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) GermanyIRC: jef on FreeNode signature.asc Description: Digital signature ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new dependency on GEOS C++ library
On 01.10.2015 11:47, Sandro Santilli wrote: I've found that qgis is now dependent on the C++ GEOS API, due to the new src/core/geosextra. It seems to me that the "geosextra" code in its current incarnation only exposes a function to basically round coordinates to a precision grid, but in no way changes the precision of operations performed by further GEOS functions on the resulting geometries. This is discussed in detail in https://trac.osgeo.org/geos/ticket/713 So my question is: if grid-snapping is enough for QGIS use, is adding a new dependency on GEOS really needed, or isn't there other internal code for doing coordinates editing work (would seem easy with Qt standard library?). As resulted from the discussion in the geos ticket: the goal is having the operations run in reduced precision, not just merely snap to grid. The discussion revealed however that snap to grid is basically what ends up being done with the current implementation, due to a mis-understanding of mine of the geos internals. As suggested in the geos ticket, I'd like to fix this to work as initially intended, and keep geosextra in QGIS until a new release of GEOS comes out which implements needed changes in the C-API. As I've been asked to help with getting the code in place for what I've understood are good new functionalities I'm here to better understsand the issue, why the new code is needed and how to best have it available, considering also that latest GEOS release was published on August 15, 2015. See also https://github.com/qgis/qgis/pull/2302 --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] OpenlayersPlugin QGIS
Sorry, I have this problem with 2.8 and 2.10.1 QGIS version (64bit) I have not tried other versions and I use Win7. I really appreciate any help you can provide. Marica On Thu, Oct 1, 2015 at 12:24 PM, Marica Landini wrote: > Hi, > I need to use OpenlayersPlugin QGIS behind proxy network. > But I need to use defaultproxy settings configuration. > > QGIS works fine with this defaultproxy settings > (also connection to wms/etc... > reading plugin list and download it). > > But (with the defaultproxy settings) I can not work with OpenlayersPlugin > QGIS > that return: > TypeError: unable to convert a QVariant of type 10 to a QMetaType of type 2 > > I can instead use this plugin with http proxy and setting manually the > configuration (Settings->Options->Network) > > I have tryed to modify OpenlayersPlugin tool_network.py > commenting setHostName/setPort/setUser/setPassword > and using > > QNetworkProxy.setApplicationProxy(QNetworkProxy(QNetworkProxy.DefaultProxy)) > obvious I do not get TypeError, > but the plugin not work properly (e.g. I do not get OSM layer). > > How can I resolve this problem? > There is another plugin that works with default (machine) proxy settings? > (apologies for my english)... > > Cheers, > Marica > > -- > Ti prego di cercare di non inviarmi files .doc, .xls, .ppt, .dwg > Preferisco formati liberi. > Please try to avoid to send me .doc, .xls, .ppt, .dwg files. > I prefer free formats. > http://it.wikipedia.org/wiki/Formato_aperto > http://en.wikipedia.org/wiki/Open_format > > Marica Landini > -- Ti prego di cercare di non inviarmi files .doc, .xls, .ppt, .dwg Preferisco formati liberi. Please try to avoid to send me .doc, .xls, .ppt, .dwg files. I prefer free formats. http://it.wikipedia.org/wiki/Formato_aperto http://en.wikipedia.org/wiki/Open_format Marica Landini ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] OpenlayersPlugin QGIS
Hi, I need to use OpenlayersPlugin QGIS behind proxy network. But I need to use defaultproxy settings configuration. QGIS works fine with this defaultproxy settings (also connection to wms/etc... reading plugin list and download it). But (with the defaultproxy settings) I can not work with OpenlayersPlugin QGIS that return: TypeError: unable to convert a QVariant of type 10 to a QMetaType of type 2 I can instead use this plugin with http proxy and setting manually the configuration (Settings->Options->Network) I have tryed to modify OpenlayersPlugin tool_network.py commenting setHostName/setPort/setUser/setPassword and using QNetworkProxy.setApplicationProxy(QNetworkProxy(QNetworkProxy.DefaultProxy)) obvious I do not get TypeError, but the plugin not work properly (e.g. I do not get OSM layer). How can I resolve this problem? There is another plugin that works with default (machine) proxy settings? (apologies for my english)... Cheers, Marica -- Ti prego di cercare di non inviarmi files .doc, .xls, .ppt, .dwg Preferisco formati liberi. Please try to avoid to send me .doc, .xls, .ppt, .dwg files. I prefer free formats. http://it.wikipedia.org/wiki/Formato_aperto http://en.wikipedia.org/wiki/Open_format Marica Landini ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS allows to create tables with invalid field names?
Il 01/10/2015 12:22, Sandro Santilli ha scritto: > Are you referring to PostgreSQL tables ? > IMHO the identifiers should just be quoted: not tested with pg, noticed with shp. thanks. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS allows to create tables with invalid field names?
On Thu, Oct 01, 2015 at 12:07:36PM +0200, Paolo Cavallini wrote:
> Hi all,
> I just discovered that QGIS allows you to create a tabel with invalid
> column names (e.g. "1"). As a consequence, further commands may
> obviously fail. IMHO we shouldn't allow invalid names.
> Opinions?
Are you referring to PostgreSQL tables ?
IMHO the identifiers should just be quoted:
strk=# create table test ("1" int);
CREATE TABLE
--strk;
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGIS allows to create tables with invalid field names?
Hi all, I just discovered that QGIS allows you to create a tabel with invalid column names (e.g. "1"). As a consequence, further commands may obviously fail. IMHO we shouldn't allow invalid names. Opinions? Thanks. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] new dependency on GEOS C++ library
I've found that qgis is now dependent on the C++ GEOS API, due to the new src/core/geosextra. It seems to me that the "geosextra" code in its current incarnation only exposes a function to basically round coordinates to a precision grid, but in no way changes the precision of operations performed by further GEOS functions on the resulting geometries. This is discussed in detail in https://trac.osgeo.org/geos/ticket/713 So my question is: if grid-snapping is enough for QGIS use, is adding a new dependency on GEOS really needed, or isn't there other internal code for doing coordinates editing work (would seem easy with Qt standard library?). As I've been asked to help with getting the code in place for what I've understood are good new functionalities I'm here to better understsand the issue, why the new code is needed and how to best have it available, considering also that latest GEOS release was published on August 15, 2015. See also https://github.com/qgis/qgis/pull/2302 --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Inverted polygon renderer and shapeburst fill in qgis server tiles
Hugo Mercier wrote > The solution proposed by Nyall (adding the possibility to have an > infinite distance if I understood correctly) is better I think. Hi Hugo, you're right. If someone has sufficient math skills to avoid a dirty workaround, I'd be pleased to have him work on it ;-). Cheers Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Inverted-polygon-renderer-and-shapeburst-fill-in-qgis-server-tiles-tp5224645p5227264.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Pending PRs
Hi Hugo On 10/01/2015 09:44 AM, Hugo Mercier wrote: > Hi, > > I've submitted two Pull Requests : > https://github.com/qgis/QGIS/pull/2189 and > https://github.com/qgis/QGIS/pull/2322 that stay in a undetermined state ... > > The first one (2189) is of particular interest here. It has been opened > in the beginning of July and I've been fixing issues spotted by others > (mostly Nyall), unfortunately at a lower pace than I would have liked, > busy on other projects. > > But agreement from other devs seemed needed to accept it. And ... this > agreement never came before the beginning of the feature freeze ... > So can you confirm this is now out of the scope of the 2.12 ? Or is > there a chance this would be an exception ? > > I guess this happened because everyone is busy, but it is not an easy > situation for me. > It becomes hard to target a particular release version when selling the > integration of new features and then it does not enforce confidence of > funders, I think. > > Do you see solutions to that for the future ? Probably the problem is > that integration of paid development depends on decisions made by > third-party developers that do their best to review PRs, but without > guarantee (i.e. are not paid specifically for that). What do you think ? > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer I deliberately did not set the milestone version to 2.14 on https://github.com/qgis/QGIS/pull/2322 but I did not feel comfortable enough myself to merge it (not due to lack of quality of the PR but due to lack of expertise). +1 from my side to have this merged IF sombody can step in and give it an additional review. In general, I try to filter and roughly review PR's and delegate them wherever possible. I agree that they need more attention and a stance on this problem by the PSC is highly appreciated. Best Matthias signature.asc Description: OpenPGP digital signature ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Tips & news
Hi, It would be nice to have the possibility to get back to this page, but as Kari said, it takes away screen real estate. What do you think about bringing the page back when somebody clicks "open project" and embed a file browser window next to the previous projects? We could also have a menu entry in the "Help" menu or "Project" Menu to bring back the start screen? Or we could have a "Close" project which would bring back the start screen. Andreas ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Tips & news
On 10/01/2015 09:37 AM, Paolo Cavallini wrote: > Il 01/10/2015 07:59, Nathan Woodrow ha scritto: >> Hi, >> >> I was planning on moving the tips to a new tab so consider this done >> once we are out of freeze. We can also split up the news tab to add >> extra info not just the blog feed. Have it pull from different places >> for different info. > sweet! Nathan, would you like me to open a feature req, to better > document the process? Alternatively I had the idea of showing it at the bottom of the recent project page with a close button (and a don't show again checkbox), similar to the message bar. > BTW, maybe the tabs could stick, so one could preview previous projects > also during normal work. Opinions? It would be nice to have the possibility to get back to this page, but as Kari said, it takes away screen real estate. What do you think about bringing the page back when somebody clicks "open project" and embed a file browser window next to the previous projects? > All the best. > Best ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Problem with GRASS 7 and Processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yep! Thanks Victor! Matteo -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWDOyaAAoJEBy7UYf0gaEOn4kH/2QDJq3G8CH16a7IHXEHigWw AbNZ5DwhF5uN1a3/FXJLtdj9xQvmY5A8IyTboLu7c847E+kKEI1kFJeO8WAu4YH5 fzdRIeKtLDsb0ASLCEAwOsKs7kuQN2E0sh9uEcPBRhDEOa0L+xyv4ywz3fx+4rSZ LFUU05p/0ob2rebvJWDCp9Lh9hEa+apVJ2hCxLz51o1XCDnN7RMUwNrPkMGDbMKe w5JgQ0Fxul9Uw5s5f/pwETKYEkiBMTjkvoTqfD1eGe/YnLQYR/AQkk/r8GF2L5lP aJEVh6wDYrvE0aDVG56RVxH6ja88Nael7JzYzEJAC8rI940sPZg/2/C3ZMvRrfs= =OXPC -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Inverted polygon renderer and shapeburst fill in qgis server tiles
Hi Régis, On 30/09/2015 09:03, Régis Haubourg wrote: > Hi Nyall, > thanks very much for the pointer, we know now where to look for a solution. > Another hypothesis, couldn't that be the inverted polygon renderer that is > sending a polygon clipped by map extent + a margin ? If this is the case, we > could simply put a greater margin value. Maybe Hugo at oslandia knows that. > I am not sure to understand the problem, i.e. what happens with qgis server that does not with the regular map canvas ? But to answer your question, there is already a margin taken around the map extent : https://github.com/qgis/QGIS/blob/master/src/core/symbology-ng/qgsinvertedpolygonrenderer.cpp#L95 This is completely arbitrary (x5), but this is just to cheat the concept of an "inverted" geometry that does not really exist in QGIS. So we can bump up the factor to say x10 ... and it will just translate the problem a bit further ... The solution proposed by Nyall (adding the possibility to have an infinite distance if I understood correctly) is better I think. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Problem with GRASS 7 and Processing
Not sure what's the rationale for that line, since I am no GRASS expert, but this commit should fix it https://github.com/qgis/QGIS/commit/87d8a12e79a4c889d72245fb2b3ba22100aab59f Please, try and confirm that it fixes the issue Regards 2015-10-01 9:36 GMT+02:00 matteo : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > HI all, > QGIS fresh compiled and Grass7 installed (works as standalone). > I'm not able to run any of GRASS7 algorithm with Processing, this is > the error: > > 2015-10-01T09:34:21 2 Could not load model model_PCA.model > Error in algorithm name: r:acpcercle > 2015-10-01T09:34:30 2 Uncaught error while executing algorithm > Traceback (most recent call last): > Traceback (most recent call last):| File > "/home/ma7730/.qgis2/python/plugins/processing/core/GeoAlgorithm.py", > line 227, in execute|self.processAlgorithm(progress)| File > "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Algorit > hm.py", > line 425, in processAlgorithm|Grass7Utils.executeGrass7(commands, > progress, outputCommands)| File > "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Utils.p > y", > line 270, in executeGrass7|command, grassenv = > Grass7Utils.prepareGrass7Execution(commands)| File > "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Utils.p > y", > line 252, in prepareGrass7Execution|del env['GISBASE']|KeyError: > 'GISBASE'| > 2015-10-01T09:34:30 1 There were errors executing the algorithm. > > > Any idea? > > Thanks! > > Matteo > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJWDOKYAAoJEBy7UYf0gaEO9NcH/imnsNoRR9cgRIysh5tu5QWX > HiOQIbAJcDjehJRr3+yDYLs7dMYPbaRkI4LlptuPsr+oB3p67KQkcXaFV2CKyNP5 > x6QhKSHjrY7QTRXOnvGXgHfjeliQuLiB9G62j1JclbLy/o2XIZ9Rmq8D8yq9jB3W > j6WwS22+78GKQUpDiK3dUfCEpQCTL3UoqpcxRPs39vwq2+WGO3D7NpW/tL623jNr > G5oLNL6f6zl9L5R1zzXRjlS6cW9O+JhuwDiIot6q53nD9qyyCACz6GackdTLmbDB > emRJNeU7Xor1ej1YzxMKH78jryZ9XHyWH4lpKQq6sOI7Nnanzy+YwSUSxyGsQro= > =loCw > -END PGP SIGNATURE- > ___ > 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] Pending PRs
2015-10-01 9:44 GMT+02:00 Hugo Mercier : > Hi, > > I've submitted two Pull Requests : > https://github.com/qgis/QGIS/pull/2189 and > https://github.com/qgis/QGIS/pull/2322 that stay in a undetermined state > ... > > The first one (2189) is of particular interest here. It has been opened > in the beginning of July and I've been fixing issues spotted by others > (mostly Nyall), unfortunately at a lower pace than I would have liked, > busy on other projects. > > But agreement from other devs seemed needed to accept it. And ... this > agreement never came before the beginning of the feature freeze ... > So can you confirm this is now out of the scope of the 2.12 ? Or is > there a chance this would be an exception ? > > I guess this happened because everyone is busy, but it is not an easy > situation for me. > It becomes hard to target a particular release version when selling the > integration of new features and then it does not enforce confidence of > funders, I think. > > Do you see solutions to that for the future ? Probably the problem is > that integration of paid development depends on decisions made by > third-party developers that do their best to review PRs, but without > guarantee (i.e. are not paid specifically for that). What do you think ? > > Hello Hugo, I don't know the details of your PRs but generally speaking I fully agree with your concerns about paid developments and uncertainty of PRs acceptance. Hopefully the new commitments of the PSC about the PRs queue handling will solve this problem in the long run. -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Pending PRs
+1 to merge if other devs agree On Thu, 1 Oct 2015 5:45 pm Hugo Mercier wrote: > Hi, > > I've submitted two Pull Requests : > https://github.com/qgis/QGIS/pull/2189 and > https://github.com/qgis/QGIS/pull/2322 that stay in a undetermined state > ... > > The first one (2189) is of particular interest here. It has been opened > in the beginning of July and I've been fixing issues spotted by others > (mostly Nyall), unfortunately at a lower pace than I would have liked, > busy on other projects. > > But agreement from other devs seemed needed to accept it. And ... this > agreement never came before the beginning of the feature freeze ... > So can you confirm this is now out of the scope of the 2.12 ? Or is > there a chance this would be an exception ? > > I guess this happened because everyone is busy, but it is not an easy > situation for me. > It becomes hard to target a particular release version when selling the > integration of new features and then it does not enforce confidence of > funders, I think. > > Do you see solutions to that for the future ? Probably the problem is > that integration of paid development depends on decisions made by > third-party developers that do their best to review PRs, but without > guarantee (i.e. are not paid specifically for that). What do you think ? > > ___ > 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
[Qgis-developer] Pending PRs
Hi, I've submitted two Pull Requests : https://github.com/qgis/QGIS/pull/2189 and https://github.com/qgis/QGIS/pull/2322 that stay in a undetermined state ... The first one (2189) is of particular interest here. It has been opened in the beginning of July and I've been fixing issues spotted by others (mostly Nyall), unfortunately at a lower pace than I would have liked, busy on other projects. But agreement from other devs seemed needed to accept it. And ... this agreement never came before the beginning of the feature freeze ... So can you confirm this is now out of the scope of the 2.12 ? Or is there a chance this would be an exception ? I guess this happened because everyone is busy, but it is not an easy situation for me. It becomes hard to target a particular release version when selling the integration of new features and then it does not enforce confidence of funders, I think. Do you see solutions to that for the future ? Probably the problem is that integration of paid development depends on decisions made by third-party developers that do their best to review PRs, but without guarantee (i.e. are not paid specifically for that). What do you think ? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Tips & news
Il 01/10/2015 07:59, Nathan Woodrow ha scritto: > Hi, > > I was planning on moving the tips to a new tab so consider this done > once we are out of freeze. We can also split up the news tab to add > extra info not just the blog feed. Have it pull from different places > for different info. sweet! Nathan, would you like me to open a feature req, to better document the process? BTW, maybe the tabs could stick, so one could preview previous projects also during normal work. Opinions? 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 http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Problem with GRASS 7 and Processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 HI all, QGIS fresh compiled and Grass7 installed (works as standalone). I'm not able to run any of GRASS7 algorithm with Processing, this is the error: 2015-10-01T09:34:21 2 Could not load model model_PCA.model Error in algorithm name: r:acpcercle 2015-10-01T09:34:30 2 Uncaught error while executing algorithm Traceback (most recent call last): Traceback (most recent call last):| File "/home/ma7730/.qgis2/python/plugins/processing/core/GeoAlgorithm.py", line 227, in execute|self.processAlgorithm(progress)| File "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Algorit hm.py", line 425, in processAlgorithm|Grass7Utils.executeGrass7(commands, progress, outputCommands)| File "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Utils.p y", line 270, in executeGrass7|command, grassenv = Grass7Utils.prepareGrass7Execution(commands)| File "/home/ma7730/.qgis2/python/plugins/processing/algs/grass7/Grass7Utils.p y", line 252, in prepareGrass7Execution|del env['GISBASE']|KeyError: 'GISBASE'| 2015-10-01T09:34:30 1 There were errors executing the algorithm. Any idea? Thanks! Matteo -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWDOKYAAoJEBy7UYf0gaEO9NcH/imnsNoRR9cgRIysh5tu5QWX HiOQIbAJcDjehJRr3+yDYLs7dMYPbaRkI4LlptuPsr+oB3p67KQkcXaFV2CKyNP5 x6QhKSHjrY7QTRXOnvGXgHfjeliQuLiB9G62j1JclbLy/o2XIZ9Rmq8D8yq9jB3W j6WwS22+78GKQUpDiK3dUfCEpQCTL3UoqpcxRPs39vwq2+WGO3D7NpW/tL623jNr G5oLNL6f6zl9L5R1zzXRjlS6cW9O+JhuwDiIot6q53nD9qyyCACz6GackdTLmbDB emRJNeU7Xor1ej1YzxMKH78jryZ9XHyWH4lpKQq6sOI7Nnanzy+YwSUSxyGsQro= =loCw -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] saga commands missing?
Il 01/10/2015 07:46, Victor Olaya ha scritto: > Should be fixed in here > > https://github.com/qgis/QGIS/commit/a9dab06a6ada0595802e2dcacbe5835f3d957a37 confirmed, saga is back with its 235 algs. Checked a random one, it works. Thanks a lot! -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] saga commands missing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Confirmed, it works now. Thanks Victor -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWDN7wAAoJEBy7UYf0gaEOYtoH/3hxJJLj75Ar5aRXsHAurCUb 4XAZIPA73000YuAdhj50DUskT40vbXukkHaHQ68mhtspHjFb6ecOCxu7+QFE/anB nv3xAW0o4+B2gkD/d/2LZOfOuB66R2wm8ANDuBGAzxgHfFntl7AZR/Qn2UXNr4IB YK+6h88XgWgL51mBW9Z8vkH4DR0dWcjhJC7DPoqGOCcd/ki3VrRDc5FshgpN2pIn u0gwzdyTZKH5wUcuQGgCOJVB9yapVIX1AbHYu7GKL8USBnHbtVoap+kWZBJmeGfn fswwOaApCFEvZsYBqAhp04iYzHujxW+nZ1vWPJyy8phaQCg+2JDe1pahYjdMcF4= =n+6i -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
