Re: [QGIS-Developer] QGIS 3 > Processing: some test
Hi Nyall, On Sat, Jun 10, 2017 at 12:25 AM, Nyall Dawson wrote: > On 10 June 2017 at 06:46, Giovanni Manghi wrote: >>> * Aspect throws an error: >> >> >> is this GDAL's aspect? > > No - native QGIS one. None of the GDAL/OGR provider is ported to the > new API yet and is not available in nightly builds. ok > >> is expected that -for example- all the tools, even not QGIS native >> ones to be somehow fixed in processing/QGIS3 because of the overhaul >> that is going on? > > Native, GDAL, grass and saga will be ported. It's low on my priority > list right now though, so if anyone wants to step forward and port > these now then it'd be much appreciated. My priorities are: > I could help with gdal/ogr ones >> If yes this is also true for Processing plugins that >> make uses of external programs like ogr2ogr, circuitscape and many >> other examples? > > No - processing plugin maintainers are responsible for porting their > own code to 3.0, just like all other plugin maintainers. sure, that wasn't my question, but never mind I got it. > - we have had some algs which were available in 2.x removed. This > breaks existing models which used those algorithms. there is a list? > We have a lot of > duplicate functionality spread across the QGIS algs, which would be > good to address for 3.0 true, is also true that some redundancy has helped a lot in the past. For example the geoprocessing tools based on ogr2ogr and spatial queries (that I plan to expand since a long time now), in several cases have been proven faster and more reliable than native ones. If they are not welcome in QGIS3 no problem, I can make a Processing plugin out of them, I'm sure it will be anyway preferred to native tools that frequently just return the wrong result (see several tickets on unions, intersections, differences and the alike). cheers! -- G -- ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] QGIS 3 > Processing: some test
On 10 June 2017 at 06:46, Giovanni Manghi wrote: >> * Aspect throws an error: > > > is this GDAL's aspect? No - native QGIS one. None of the GDAL/OGR provider is ported to the new API yet and is not available in nightly builds. > is expected that -for example- all the tools, even not QGIS native > ones to be somehow fixed in processing/QGIS3 because of the overhaul > that is going on? Native, GDAL, grass and saga will be ported. It's low on my priority list right now though, so if anyone wants to step forward and port these now then it'd be much appreciated. My priorities are: 1. bringing back complete functionality in the run alg dialog 2. batch mode 3. scripts 4. modeler 5. resurrecting remaining algs 6. adding new stuff to existing algs (dynamic parameters, porting to c++, etc) > If yes this is also true for Processing plugins that > make uses of external programs like ogr2ogr, circuitscape and many > other examples? No - processing plugin maintainers are responsible for porting their own code to 3.0, just like all other plugin maintainers. We probably need to bring up a discussion sometime about how to handle user's migrations to processing 3.0. As I see the situation: - we have had some algs which were available in 2.x removed. This breaks existing models which used those algorithms. - we have a bunch of "duplicate" native algs, some of which have been "deprecated" in 3.0. Deprecation just hides them from the toolbox - it doesn't break existing models. This is a HUGE amount of baggage to carry around and maintain, for little benefit. - user scripts will be broken, because they use the old API - the remaining algs still need a lot of cleanup. We have a lot of duplicate functionality spread across the QGIS algs, which would be good to address for 3.0 I'd like to raise the possibility that we break compatibility with 2.x models in 3.0, and require that users re-create their models using the new set of available algorithms. I personally think this is acceptable to do, given that: - 3.0 is a major release. Some changes to user workflows and existing projects are expected. Better to make the break now then in 3.2/other future 3.x releases. - It can be installed side-by-side with 2.x, allowing users to open existing models in 2.x and step by step recreate their models in 3.0 world. - Any scripts inside models will be broken and need to be updated anyway (due to new PyQGIS API in 3.0 + python3 + Qt5 - there's no way to automatically port these) Nyall ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] QGIS 3 > Processing: some test
> * Aspect throws an error: is this GDAL's aspect? is expected that -for example- all the tools, even not QGIS native ones to be somehow fixed in processing/QGIS3 because of the overhaul that is going on? If yes this is also true for Processing plugins that make uses of external programs like ogr2ogr, circuitscape and many other examples? cheers -- G -- ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] QGIS 3 > Processing: some test
Hi all,
I did some testing of new Processing commands, on a freshly compiled QGIS.
* Aspect throws an error:
{'INPUT_LAYER': ,
'OUTPUT_LAYER': , 'Z_FACTOR': 1.0}
Traceback (most recent call last):
File
"/usr/local/src/qgis/QGIS/build_qgis3/output/python/plugins/processing/gui/Postprocessing.py",
line 70, in handleAlgorithmResults
dataobjects.load(l, name, alg.crs,
AttributeError: 'Aspect' object has no attribute 'crs'
the same raster works fine with 2.x
* barplot does not return a result (result viewer is empty)
{'INPUT': , 'OUTPUT':
, 'VALUE_FIELD': 'POP1961', 'NAME_FIELD': 'PROVINCIA'}
* both frequency analysis and Number of unique values in classes return:
This algorithm cannot be run :-(
This script has a syntax errors. Problem with line: ##Fields=Field Input
* keep n biggest parts:
This script has a syntax errors. Problem with line: ##To_keep=number 1
* basic statistics for fields:
Traceback (most recent call last):
File
"/usr/local/src/qgis/QGIS/build_qgis3/output/python/plugins/processing/algs/qgis/BasicStatistics.py",
line 152, in processAlgorithm
self.createHTML(output_file, data)
File
"/usr/local/src/qgis/QGIS/build_qgis3/output/python/plugins/processing/algs/qgis/BasicStatistics.py",
line 265, in createHTML
with codecs.open(outputFile, 'w', encoding='utf-8') as f:
File "/usr/lib/python3.5/codecs.py", line 895, in open
file = builtins.open(filename, mode, buffering)
FileNotFoundError: [Errno 2] File o directory non esistente: ''
* buffer:
* rasters appear in the list of layers, but no result nor error is
given when chosen
* for vector polygons, a new layer is created, but geometries are
unchanged (no buffer)
* there are two QGIS entries (I imagine one Py and one C++), confusing
for the user
* clip, check validity, polygon extent, boundary, bounding boxes,
centroids, add field, add autoincremental field, delete field seem to be
all working fine.
I know it's very early, please let me know if I better stop testing.
All the best.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Geodesic Measure Tool With Bearing Information
Several weeks ago I had proposed a geodesic measure tool that also includes the bearing from point A to B and bearing from B to A. Nyall suggested that this capability be added to the QGIS measure tool. The question is would you want this with the QGIS measure tool or should it be a separate plugin? The changes would be as follows: 1. Where the current measure tool has 'Segments' there would be two more columns with 'Bearing to' and 'Bearing from'. 2. I would like to see a check box or selection widget of some sort that chooses between using Geodesic math or the current method of calculating the distances which I am still unsure on how it is doing its calculations. Right now it could use the Vincinty algorithms in QGIS to calculate the distances, but eventually I would like to see the geographiclib algorithms used. If this is of interest then I will attempt to get a QGIS development environment running to help make the changes to the core measure tool; otherwise, I will just create a plugin to do this. If I create a plugin I will use the geographiclib python library to do the calculations. Thoughts? Thanks, Calvin ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Plugin [1193] Shape Tools approval notification.
Plugin Shape Tools approval by pcav. The plugin version "[1193] Shape Tools 0.4.1" is now approved Link: http://plugins.qgis.org/plugins/shapetools/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Parallell processing, OpenCL
Where does QGIS stand on supporting parallel processing/OpenCL/CUDA? About a year ago, I opened a ticket about using OpenCL/CUDA in QGIS, https://issues.qgis.org/issues/14680, but it was closed almost immediately. The suggestion was to solve this outside of QGIS. Is that really all there is to it? Is there nothing that can be done in QGIS to improve the situation? Running on a single CPU core for most cases is starting to seem a bit out of date. In this example, QGIS seems to be many hours slower than Manifold Radian, http://www.georeference.org/forum/t136609.41 and https://www.mapd.com/ promises “leverages the parallelism of GPUs to achieve orders-of-magnitude speedups over CPU solutions, powering exploration of big datasets with near zero-latency”. That speed would be a great addition to QGIS. If I see a funding request or a grant proposal in this direction, I will definitely support it. Regards, Magnus -- View this message in context: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Parallell-processing-OpenCL-tp5323644.html Sent from the QGIS - Developer mailing list archive at Nabble.com. ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] QGIS Grant "Add consistency to UI controls" complete
Thanks a lot ! No more confusion with N or 1/N scales definition ! 2017-06-09 9:42 GMT+02:00 Tim Sutton : > Thanks for the report back and the great work Nyall! > > Regards > > Tim > > On Fri, Jun 9, 2017 at 9:18 AM, Paolo Cavallini > wrote: > >> Il 09/06/2017 08:54, Nyall Dawson ha scritto: >> >> > Just a quick notice to advise that the work sponsored by the QGIS >> > grant program on "adding consistency to UI controls" is now complete >> > and merged into master. The following tasks were done as part of this >> > work: >> >> Great stuff, thaks heaps! >> >> -- >> Paolo Cavallini - www.faunalia.eu >> QGIS & PostGIS courses: http://www.faunalia.eu/training.html >> https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis >> ___ >> QGIS-Developer mailing list >> QGIS-Developer@lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > > > -- > > -- > > > Tim Sutton > Visit http://kartoza.com to find out about open source: > * Desktop GIS programming services > * Geospatial web development > * GIS Training > * Consulting Services > Skype: timlinux Irc: timlinux on #qgis at freenode.net > Tim is a member of the QGIS Project Steering Committee > > --- > Kartoza is a merger between Linfiniti and Afrispatial > > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Exploring the new node tool: questions and bugs(?)
2017-06-09 8:31 GMT+02:00 Paolo Cavallini : > > > BTW, wouldn't this be the right time to change the colour scheme? To me > the old one (red for normal, blue for selected, green for errors, pink > for snapped) is non standard and counter-intuitive. > The normal semaphore schema (green for normal, yellow for selected, red > for errors, plus probably orange for snapped) seems better. > Hi, green for normal and red for errors seem good to me. Yellow for selected won't play nicely with underlying selected yellow features. ArcGIS is set to blue, I would stick to blue. pink for snapped works for me, and orange is probably too close to red for colorblind people, but this might not be a problem if we use different symbol types. Régis ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Exploring the new node tool: questions and bugs(?)
On 09-06-17 03:42, Nyall Dawson wrote: > Instead of a toggle, could we use some logic like: > > - no selection: edit all clicked features > - selection, but no selected features exist where clicked: edit all > clicked features > - selection, where selected features exist where clicked: edit ONLY > these selected features > > This way the "only edit selected features" behavior will only kick in > when a selection is in the area being edited. It should avoid the > annoying behavior where a selected feature on the other side of the > map becomes the editing target (move tool should probably use this > approach too!). I'm not a digitizer guy, so I'm ok with this idea, although also a little afraid it is a little too much 'magic' going on. Would it be a lot of work to implement and test it in the wild? What do other tools do (looking at users of Illustrator, Esri, AutoCAD etc). As said earlier I think we should conform somewhat to known ways of working... Regards, Richard ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] [otb-developers] qgis-otb-plugin repository moved to OTB's github
Hi Rashad, let's move this discussion to QGIS dev list. 2017-06-08 20:00 GMT+03:00 Rashad Kanavath : > With new improvements in OTB plugin there is no need to update stuff for > each release. It work same like GRASS GIS. > the descriptor files will be generated depending on user's OTB version. IT > will not be inside algs/otb/descriptor/ Seems there is a misunderstanding here. Description files is a pure-Processing thing, GRASS does not ship any description files, they were created by Processing devs and users and updated when necessary. As I understand, your idea is to move description files to the OTB disctribution and have some settings in the Processing to point to these description files. Right? > BTW, When you said adding new functionality and/or bugfixing will be > problematic, you mean issues in OTB or the plugin? I was talking about OTB plugin. For example, if you may found and fix a bug in the plugin or implemented new feature to support new OTB functionality. If plugin integrated into QGIS you will be tied to QGIS release cycle. > The way I see otb plugin is a part of processing plugin and it expect data > (descriptor file) in a specific format from OTB. > The correct job of otb is give those data so that processing can use it. > > Like GRASS and others, it reads a list of descriptor file and these will be > provided by OTB not QGIS. When user install a new otb version, descriptor is > automatically changed with it! > I hope that takes all the maintenance troubles from QGIS side. > > Finally, if we were able to remove the descriptor folder and gives a plugin > code (OTBAlgorithm, OTBAlgorithmProvider, OTBUtils) > which allows users to use any version of OTB package, that will be > acceptable right? > > And OTB devs will be able to test OTB for compatibility with QGIS. > Do you know about next QGIS release date and version? Next QGIS version will be 3.0 and according to the current roadmap [0] it is expected in the end of September [0] http://qgis.osgeo.org/en/site/getinvolved/development/roadmap.html -- Alexander Bruy ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] QGIS Grant "Add consistency to UI controls" complete
Thanks for the report back and the great work Nyall! Regards Tim On Fri, Jun 9, 2017 at 9:18 AM, Paolo Cavallini wrote: > Il 09/06/2017 08:54, Nyall Dawson ha scritto: > > > Just a quick notice to advise that the work sponsored by the QGIS > > grant program on "adding consistency to UI controls" is now complete > > and merged into master. The following tasks were done as part of this > > work: > > Great stuff, thaks heaps! > > -- > Paolo Cavallini - www.faunalia.eu > QGIS & PostGIS courses: http://www.faunalia.eu/training.html > https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- -- Tim Sutton Visit http://kartoza.com to find out about open source: * Desktop GIS programming services * Geospatial web development * GIS Training * Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net Tim is a member of the QGIS Project Steering Committee --- Kartoza is a merger between Linfiniti and Afrispatial ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] QGIS Grant "Add consistency to UI controls" complete
Il 09/06/2017 08:54, Nyall Dawson ha scritto: > Just a quick notice to advise that the work sponsored by the QGIS > grant program on "adding consistency to UI controls" is now complete > and merged into master. The following tasks were done as part of this > work: Great stuff, thaks heaps! -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
