[QGIS-Developer] QGIS on mobile Linux?

[Stefan Blumentrath]

Dear all,

While I am very fond of mobile QGIS versions like QField and Input, I am 
wondering if anyone in the QGIS community is having an eye on emerging mobile 
Linux solutions using Phosh, Lomiri, Plasma mobile on devices like 
PinePhone[1], PineTab[2] or Librem5[3]? Anyone who tried it out or even 
developed in that direction?

Though maybe still not fully production ready yet, this looks very interesting 
...

Happy new year.

Cheers
Stefan

1: PINEPHONE | PINE64
2: PINETAB | PINE64
3: Purism- Librem 5

___
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] [GRASS-dev] Access to GRASS GIS addons

[Stefan Blumentrath]

Dear Nikos,

Approaches are a bit different for Processing and the GRASS plugin, though both 
do not allow usage of GRASS addons out-of-the-box.
Assuming you are aiming at integration in Processing have a look here:
https://gis.stackexchange.com/questions/150100/how-to-add-my-own-grass-algorithms-to-processing
and
https://github.com/qgis/QGIS/blob/b3d2619976a69d7fb67b884492da491dfaba287c/python/plugins/processing/algs/grass7/description/r.horizon.height.txt
on how you would have to tweak local GRASS and QGIS installation.

For less experienced users that are supposed to use the addon, you would 
probably want to write a little installation routine for your addon, that puts 
txt files into right places in the installation and also installs the GRASS 
addon systemwide...

Cheers
Stefan

-Original Message-
From: grass-dev  On Behalf Of Nikos 
Alexandris
Sent: onsdag 10. oktober 2018 17:45
To: qgis-developer@lists.osgeo.org
Cc: grass-...@lists.osgeo.org
Subject: [GRASS-dev] Access to GRASS GIS addons

Dear QGIS developers,

I'd much appreciate some response in the following questions.

I rarely use Windows, yet I would like to learn about the latest status in 
accessing GRASS GIS addons (not only regular modules) through QGIS under 
Windows.

If I write an addon for GRASS GIS, can I then provide/ensure access to it for 
Windows users of QGIS?

Thank you, Nikos
___
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-user] New Features in Shape Tools 3.2.0

[Stefan Blumentrath]

Hi,

Even if the discussion already moved on, for the record below some more numbers 
from other OSGeo tools:
PostGIS (in UTM 33N): 14727443738.0 m2
GRASS 7.4 (in WGS84): 14707741818.0911
GRASS 7.4 (in UTM33): between 14707741818.0911 m2 and 14727443738.0262 m2 
(depending on how much one densifies vertices on the boundaries during 
reprojection, the latter value measured without boundary vertex densification)

Please see also: https://issues.qgis.org/issues/12057 for earlier discussion of 
area calculations in QGIS...
And https://trac.osgeo.org/grass/ticket/3356 for recent changes in area 
calculations in GRASS.

Cheers
Stefan

-Original Message-
From: QGIS-Developer  On Behalf Of 
Kristian Evers
Sent: tirsdag 25. september 2018 15:32
To: Kristian Evers ; Nyall Dawson 
Cc: qgis-developer 
Subject: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0

Right, here are the calculated areas as returned by a number of different GIS 
applications and the planimeter app of GeographicLib for reference:

Caris LOTS: 14.737 km^2
ArcMap: 14.727,446 km^2
MapInfo:14.727,352 km^2
GeoMedia:   14.726,443 km^2
Planimeter: 14.722,522 km^2
QGIS 3.2:   14.652,181 km^2
QGIS 2.8:   14.652,181 km^2

The polygon that I have used to get the numbers above can be found here: 
https://gist.github.com/kbevers/207b5bcb9be20e7554abe5f56742ec2c

I am quite confident that GeographicLib delivers the most accurate result (if 
you have doubts, this reference [0] should convince you). As can be seen from 
the table above all but QGIS come fairly close. I expect some variation in the 
results as these are numerical approximations, although I think QGIS is too far 
of the mark. My suspicion is that the geodesic algorithm used by QGIS (and 
apparently GRASS) is to blame here.

/Kristian

[0] https://arxiv.org/pdf/1102.1215.pdf 

-Oprindelig meddelelse-
Fra: QGIS-Developer  På vegne af 
Kristian Evers
Sendt: 25. september 2018 09:15
Til: Nyall Dawson 
Cc: qgis-developer 
Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0

It's not a small area, that's why I have been nitpicking ellipsoid area 
calculation algorithms!
I did end up doing the calculations with geographiblib to get a reference to 
judge various other calculations by. It's a pain in the butt to extract the 
data from a polygon shapefile (or whatever) and format it to suit the 
planimeter app of geographiclib. It would be so much cooler if I could get the 
same results by clicking info on a polygon in QGIS :-)

/Kristian


-Oprindelig meddelelse-
Fra: Nyall Dawson 
Sendt: 25. september 2018 09:07
Til: Kristian Evers 
Cc: Paolo Cavallini ; qgis-developer 

Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 3.2.0

On Tue, 25 Sep 2018 at 16:59, Kristian Evers  wrote:
>
> Hi Paolo,
>
> I have some rought notes that I can try to polish up a bit and share here.
> I'll see if I can find the time for that today. I didn't get to the 
> bottom of the problem but I am leaning towards the issue being that 
> QGIS uses an inferior algorithm to determine geodesics. Unfortunately 
> I couldn't find out from either the source code or the documentation which 
> algorithm is used.
> As far as I remember it differs from the otherwise popular algorithm 
> by Vincenty. That may be because a different algorithm is used or the 
> Implementation is wrong.
>
> I'll get back with a better write-up later and some test data and results.

We use a direct port from GRASS:

https://github.com/qgis/QGIS/blob/master/src/core/qgsdistancearea.cpp#L690

vs GRASS upstream:

https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/area_poly1.c?rev=71260

It's not very stable for very small areas -- better to use cartesian 
calculations there. Or bring in geographiclib and punt the responsibility 
elsewhere ;)

Nyall



>
> /Kristian
>
> -Oprindelig meddelelse-
> Fra: QGIS-Developer  På vegne 
> af Paolo Cavallini
> Sendt: 25. september 2018 08:23
> Til: qgis-developer@lists.osgeo.org
> Emne: Re: [QGIS-Developer] [Qgis-user] New Features in Shape Tools 
> 3.2.0
>
> Hi Kristian,
>
>
> Il 09/25/2018 07:24 AM, Kristian Evers ha scritto:
> >
> >
> > On a related note, I have been meaning to raise a similar issue 
> > based on QGIS’s not so accurate polygon-area-on-the-ellipsoid calculations.
> > A colleague of mine came across some differences between QGIS and 
> > CARIS LOTS while doing area calculations in relation to a border 
> > dispute at sea. After that I tested several popular closed source 
> > GIS apps and they all performed better than QGIS.
> this is worth exploring in detail. could you please be more specific? 
> do you have a test case? could you share the results, or give us a way 
> to replicate them?
> Thanks.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>
> ___
> QGIS-Developer mailing list
> 

Re: [QGIS-Developer] Running grass algorithms in threads

[Stefan Blumentrath]

Dear Rudi, Nyall,

GRASS is being used on HPC systems for heavily parallelisation. So, in 
principle, the answer is yes, you can for sure run GRASS algorithms in parallel.
On Linux, I often run several commands in parallel using xargs. So it works 
just fine in many cases. GRASS also has some specific python functions for 
parallel processing. See also:
https://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs
https://grasswiki.osgeo.org/wiki/Parallelizing_Scripts

However, if GRASS algorithms can be run in parallel in this particular case 
depends.

E.g., if the algorithm in question temporarily modifies the computational 
region, parallel processes can get in the way for each other.
Also, with SQLite as DB backend writing several vector maps (and attribute 
tables) in parallel will be a problem (due to SQLite locks).

In addition, if GRASS commands can be executed in parallel in the QGIS 
Processing framework is probably yet another question, depending on how e.g. 
QGIS handles data management (locations and mapsets) esp. in more complex 
workflows / models...

CCing also grass-dev list for more qualified answers...

Cheers
Stefan


-Original Message-
From: QGIS-Developer  On Behalf Of 
Nyall Dawson
Sent: onsdag 15. august 2018 01:10
To: Rudi von Staden 
Cc: qgis-developer 
Subject: Re: [QGIS-Developer] Running grass algorithms in threads

On Tue, 14 Aug 2018 at 21:43, Rudi von Staden  wrote:
>
> Hi all,
>
> The bottleneck in my script at the moment is the calculation of zonal stats 
> using 'grass7:r.stats.zonal'. I thought I might speed things up by using 
> QgsTask.fromFunction() or QgsProcessingAlgRunnerTask() to run these 
> calculations in parallel. In my tests of both approaches the tasks seem to 
> complete (task.status() == QgsTask.Complete), but the output file is only 
> generated for 1 of 4 parallel tasks (the task that finishes first).
>
> I'm assuming this is because grass algorithms are not thread safe? Or am I 
> missing something in my implementation that could make this work?

I strongly suspect that grass algorithms cannot be run in parallel.
This is why they cannot run in the background in QGIS like the native/GDAL 
algorithms can. But I'd love for confirmation about this and whether there's 
any way to make GRASS multi-thread safe.

Because this is grass related (and not QGIS specific) I'd suggest asking on the 
grass mailing list, and relaying any responses back here.

Nyall

>
> Thanks,
> Rudi
>
>
>
> My code for the QgsTask approach is as below:
>
> def getZonal(task, habitatModelFile, cover):
> tempFile = QgsProcessingUtils.generateTempFilename("output.tif")
> processing.run("grass7:r.stats.zonal", {
> 'base':habitatModelFile,
> 'cover':cover,
> 'method':5,
> '-c':False,
> '-r':False,
> 'output':tempFile,
> 'GRASS_REGION_PARAMETER':None,
> 'GRASS_REGION_CELLSIZE_PARAMETER':0,
> 'GRASS_RASTER_FORMAT_OPT':'',
> 
> 'GRASS_RASTER_FORMAT_META':''},context=context,feedback=algFeedback)
>
> if task.isCanceled():
> deleteFile(tempFile)
> return
>
> return tempFile
>
> ls90Task = QgsTask.fromFunction('LS90', getZonal, 
> habitatModelFile=hm1, cover=ls90Layer)
> QgsApplication.taskManager().addTask(ls90Task)
> feedback.pushInfo("Calculating LS14 mean...") ls14Task = 
> QgsTask.fromFunction('LS14 ', getZonal, habitatModelFile=hm2, 
> cover=ls14Layer)
> QgsApplication.taskManager().addTask(ls14Task)
> hs90Task = QgsTask.fromFunction('HS90 ', getZonal, 
> habitatModelFile=hm3, cover=hs90Layer)
> QgsApplication.taskManager().addTask(hs90Task)
> hs14Task = QgsTask.fromFunction('HS14 ', getZonal, 
> habitatModelFile=hm4, cover=hs14Layer)
> QgsApplication.taskManager().addTask(hs14Task)
>
> while (len([t for t in [ls90Task.status(), ls14Task.status(), 
> hs90Task.status(),
> hs14Task.status()] if t in [QgsTask.Running, QgsTask.Queued]]) > 
> 0)
> and not feedback.isCanceled():
> sleep(1)
>
> if feedback.isCanceled():
> # some cleanup code (send task.cancel() and wait for tasks to terminate)
> break
>
> ls90Result = ls90Task.returned_values
> ls14Result = ls14Task.returned_values
> hs90Result = hs90Task.returned_values   # only this file exists
> hs14Result = hs14Task.returned_values
>
>
> ___
> 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
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Can I refresh PostGIS DB connection in pyqgis

[Stefan Blumentrath]

Dear devs,

When I try to load a layer from a PostGIS data source where the connection has 
timed out, is there a way in pyqgis (2.18) to refresh the connection 
programmatically like in DBmanager before loading the layer?

psycopg2 connections are no problem...

The following however:

# Add new layer
uri = QgsDataSourceURI()
uri.setConnection(host, port, db_name, user, password)
uri.setDataSource('', query, 'geom','', 'ID')
lyr = QgsVectorLayer(uri.uri(), layer_name, 'postgres')

gives me "No result buffer" error in PostGIS...

Thanks for any hint in advance.

Kind regards,
Stefan
___
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] [GRASS-dev] External providers in QGIS

[Stefan Blumentrath]

Hi,

Regarding the negative effect of algorithms getting lost I fully agree with you 
Paolo.

However, it might simplify the discussion if we try separate user experience 
and development (and packaging) solutions as well as means and ends...

Aim should be to have the different back-ends available for user in a way that 
is as straight forward as possible. From my point of view that includes that 
possibly available providers are not hidden from users who just install bare 
QGIS. If they want to activate them, but don`t have the backends installed (and 
possibly a plugin) then they should get a notice that they have to install them 
(and I don`t see a problem with installing provider + plugin compared to just 
provider).

And if that sort of user experience is guaranteed I - as a user - would not 
care about where the code is maintained (in QGIS core, in the provider core, or 
in a separate plugin). My impression is that Victors arguments for an 
out-of-core solution are very valid, esp. given effects of the independent 
release cycles of the backends and QGIS on packaging needs (at least for the 
GRASS plugin).
The only difference I see is that additional packages would be needed for a 
plugin solution. But that is probably not too bad or even an advantage...

Finally, if there is interest in keeping the processing integration alive (and 
it obviously is) having it in an independent repo should not be a show stopper. 
Only negative effect I can see is that this produces additional repos, where 
access rights have to be managed. But that should not be a major issue either...

Cheers
Stefan

P.S.: Just a pity that this discussion starts after medspx just put down all 
this work:
https://github.com/qgis/QGIS/pull/5603
https://github.com/qgis/QGIS/pull/5968
https://github.com/qgis/QGIS/pull/5426

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paolo 
Cavallini
Sent: torsdag 8. februar 2018 09.04
To: G. Allegri 
Cc: qgis-developer ; 
saga-gis-develo...@lists.sourceforge.net; grass-dev 
; Victor Olaya 
Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS

Hi all,
I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable for 
serious, comprehensive GIS analysis work. Full stop.
Missing one specific alg, even if not used daily, means having to switch to 
other software.
We have already removed R provider: even if used by a tiny minority, and 
certainly not perfect, the previous situation was better than the current one, 
without the option of using R from QGIS.
I think we have to be extra cautious on this ground.
All the best.

Il 07/02/2018 19:07, G. Allegri ha scritto:

> - from my experience - comprising years of feedbacks from the courses 
> I teach - the most frequently used algs are available within the GDAL 
> and QGIS algs list
> 
> - a few generic and widely used algs are from GRASS and SAGA. We would 
> miss them - out of the box - but it could also be an opportunity to 
> port them. For examples v.to.points, transects, profiles.
> Anyway we would have the plugins for GRASS and SAGA, in case...
> 
> - specific algs are for specialized users. Here I think plugins are 
> best suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added 
> to the list, consistently with the others approach.
> 
> I appreciate a lot the work from Richard, I hope this discussion is 
> not understood as to belittle its effort!

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-dev mailing list
grass-...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
___
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] Exporting GDB files?

[Stefan Blumentrath]

Hi Paolo,

Only the GDAL driver with (proprietary) ESRI SDK has writing capability for 
FGDB (and is vector only).

Cheers,
Stefan

-Original Message-
From: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Paolo Cavallini
Sent: søndag 14. januar 2018 14.51
To: qgis-developer 
Subject: [QGIS-Developer] Exporting GDB files?

Hi all,
GDB seems supported by GDAL (trough two drivers, one proprietary and one not), 
but it does not seem possible from QGIS to export in this format.
Does anybody know what is the reason for this, and if there is a workaround? Or 
is this just yet something more to be done, for which I can open a feature req?
All the best, and thanks.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=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 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] Python error in processing on 2.99 startup

[Stefan Blumentrath]

Hi Tim,

While your at GRASS provider in Processing: I noticed that it (still) uses 
linked OGR data (v.external).
However, that does not work for all algorithms and particularly not for all 
data types. Points are less of a problem, but areas are often. See:
https://lists.osgeo.org/pipermail/grass-dev/2017-November/086601.html
and
https://lists.osgeo.org/pipermail/grass-dev/2017-November/086505.html

v.external.out (https://grass.osgeo.org/grass72/manuals/v.external.out.html) 
might be used though instead of v.our.ogr. But there might be drawbacks too.
For raster data and algorithms r.external.out would speed-up the algorithms 
significantly…

Cheers
Stefan

From: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Tim Sutton
Sent: onsdag 29. november 2017 18.49
To: Larry Shaffer 
Cc: QGIS Developer 
Subject: Re: [QGIS-Developer] Python error in processing on 2.99 startup

Hi

Thanks for your quick reply Larry. Confirmed that your fix addresses the 
startup issue. When I try to run a grass processing alg on Mac I get a similar 
error in the log window now:

g.proj -c proj4="+proj=longlat +datum=WGS84 +no_defs"
v.external input="/Users/timlinux/gisdata/InaSAFE/Agung/Agung.shp" 
output="a5a1ef289ca1062" --overwrite -o
g.region n=-8.3419928 s=-8.3419928 e=115.508004 
w=115.508004
v.buffer input=a5a1ef289ca1062 distance=100 tolerance=0.01 
output=output0bddfa66df874fd7bb9e9d52a9c84228 --overwrite
v.out.ogr -c type=auto input="output0bddfa66df874fd7bb9e9d52a9c84228" 
output="/var/folders/g6/fnh1vyx13q728xq52nw7yx40gn/T/processing_9b123312434544668360822a2b4cf6f0/0af610f60d9f465f9b2959fbc5442af5/output.shp"
 format=ESRI_Shapefile --overwrite
Traceback (most recent call last): File 
"/Users/timlinux/dev/cpp/QGIS-QtCreator-Build/output/python/plugins/processing/algs/grass7/Grass7Algorithm.py",
 line 375, in processAlgorithm Grass7Utils.executeGrass(self.commands, 
feedback, self.outputCommands) File 
"/Users/timlinux/dev/cpp/QGIS-QtCreator-Build/output/python/plugins/processing/algs/grass7/Grass7Utils.py",
 line 368, in executeGrass startupinfo=si if isWindows() else None File 
"/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/subprocess.py",
 line 707, in __init__ restore_signals, start_new_session) File 
"/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/subprocess.py",
 line 1333, in _execute_child raise child_exception_type(errno_num, err_msg) 
PermissionError: [Errno 13] Permission denied
Execution failed after 0.08 seconds

Loading resulting layers
Algorithm 'v.buffer.distance - Creates a buffer around features of given type.’ 
finished


I guess we are going to need to search and replace all shell=False parameters 
and set them to True if we are on Mac….

Regards

Tim



On 29 Nov 2017, at 19:40, Larry Shaffer 
> wrote:

Hi Tim,

Ran into the same thing today, but with more output on the error:

PermissionError: [Errno 13] Permission denied: 
'/usr/local/opt/grass7/grass-base/etc/colors/grass'

Changing line # 108 in:
python/plugins/processing/algs/grass7/Grass7Utils.py

from:
shell=False,

to:
shell=True if isMac() else False,

fixes the issue for me. Processing loads and GRASS algs open. (Not sure if True 
is needed for other platforms; untested.)

Fix not pushed. Please verify on your setup first (mine is macOS 10.11.6). 
Thanks!

Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota
--
Boundless Desktop and QGIS Support/Development
Boundless Spatial - http://boundlessgeo.com
lshaf...@boundlessgeo.com

On Wed, Nov 29, 2017 at 7:39 AM, Tim Sutton 
> wrote:
Hi All

Its been a few days since I pulled from master - now I am getting the error 
below on startup. Does anyone else get it? (Building on MacOS here):

Couldn't load plugin 'processing' due to an error when calling its initGui() 
method
PermissionError: [Errno 13] Permission denied

Traceback (most recent call last):
  File 
"/Users/timlinux/dev/cpp/QGIS-QtCreator-Build/output/python/qgis/utils.py", 
line 345, in startPlugin
plugins[packageName].initGui()
  File 
"/Users/timlinux/dev/cpp/QGIS-QtCreator-Build/output/python/plugins/processing/ProcessingPlugin.py",
 line 178, in initGui
self.toolbox = ProcessingToolbox()
  File 
"/Users/timlinux/dev/cpp/QGIS-QtCreator-Build/output/python/plugins/processing/gui/ProcessingToolbox.py",
 line 93, in __init__
self.fillTree()
  File 
"/Users/timlinux/dev/cpp/QGIS-QtCreator-Build/output/python/plugins/processing/gui/ProcessingToolbox.py",
 line 317, in fillTree
self.fillTreeUsingProviders()
  File 
"/Users/timlinux/dev/cpp/QGIS-QtCreator-Build/output/python/plugins/processing/gui/ProcessingToolbox.py",
 line 382, in 

Re: [QGIS-Developer] Windows QGIS Installer builds

[Stefan Blumentrath]

Hi Richard,

We/I have done so earlier from OSGeo4W binaries, using creatnsis.pl (meaning 
without compiling stuff ourselfs) while injecting use of --configpath option in 
the startup batch scripts). That was a quite OK solution until the number of 
relevant packages grew beyond the size limit of nsis installers.
In consequence, we moved to a command-line installation based on OSGeo4W that 
our IT can put into Windows SoftwareCenter and only kept  some customizations 
of the QGIS startup batch-files.

Now with the global options in QGIS 3 
(https://connect.boundlessgeo.com/docs/desktop/1.1.0/system_admins/globalsettings.html)
 and having all configurations in a .qgis directory, modification of the batch 
scripts becomes even less needed.

I can share our general recipe if that should be of interest...

Cheers
Stefan


-Original Message-
From: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Richard Duivenvoorde
Sent: torsdag 16. november 2017 12.55
To: qgis-developer 
Subject: [QGIS-Developer] Windows QGIS Installer builds


Hi Devs,

I see (and personally get) more and more questions about individuals or 
businesses who want to create their own QGIS windows installers.
Sometimes to do some branding, sometimes to create a 'suite' with some plugins 
etc etc.

Myself I do not do this, but I see people struggling.

I often point them to the INSTALL.txt but looking into that I see:
"Consider this section as example.  It tends to outdate, when OSGeo4W and SDKs 
move on"

I was wondering: should we help these people by maybe let an experienced 
Windows developer write a build manual (or update the INSTALL.txt?
Or do we conclude: if you are not able to build a msi with the information in 
the ms-windows dir and INSTALL.txt you just should not try?

Regards,

Richard Duivenvoorde

PS: Today I received such email again, and will ask this company if they have 
budget to sponsor writing such docs...
___
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] Settings migration from QGIS 2 to 3

[Stefan Blumentrath]

Thanks so much Alessandro!

Having read some documentation:
https://connect.boundlessgeo.com/docs/desktop/1.1.0/system_admins/globalsettings.html
I am sure that this will be a cool new feature in QGIS 3 that will be very much 
appreciated by organisations!!!

Thanks again for the hint!

Cheers
Stefan

From: Alessandro Pasotti [mailto:apaso...@gmail.com]
Sent: onsdag 1. november 2017 09.30
To: Stefan Blumentrath <stefan.blumentr...@nina.no>
Cc: Nathan Woodrow <madman...@gmail.com>; Borys Jurgiel 
<li...@borysjurgiel.pl>; Richard Duivenvoorde <rich...@duif.net>; 
qgis-developer@lists.osgeo.org
Subject: Re: [QGIS-Developer] Settings migration from QGIS 2 to 3


Stefan, you may try to use global settings for shared user settings, you can 
specify the global settings file path in several ways (and it could even be a 
shared network folder).
See:
https://github.com/qgis/QGIS/blob/master/src/app/main.cpp#L131
and:
https://github.com/qgis/QGIS/blob/master/src/app/main.cpp#L831
the global settings format is exactly the same of the user settings file: INI.
Hope this helps.


On Tue, Oct 31, 2017 at 11:19 PM, Stefan Blumentrath 
<stefan.blumentr...@nina.no<mailto:stefan.blumentr...@nina.no>> wrote:
Dear all,

I am really looking forward to seeing all QGIS configuration in ini-files and 
that registry will be abandoned on Windows in QGIS 3!
That will be a great improvement, esp. from a sys-admin perspective!

In this consolidation context I was wondering I would be possible to prepare 
for:

-  Use of relative path (https://issues.qgis.org/issues/12623)

-  Usage of variables in the ini file

I have been earlier thinking about “versioning” of ini files, so that updates 
(e.g. changes in OWS URLs) can be passed to all users as a sort of “diff/merge” 
without damaging individual adjustments they might have made.
Background is that the Norwegian mapping authority provides a “Service feed” 
(https://register.geonorge.no/register/tjenestevarsler) where all OWS changes 
are announced… I would love to be able to just apply those changes to all our 
users…

No idea if such a thing could be fostered by the way settings are stored in the 
ini files?

Cheers
Stefan

From: QGIS-Developer 
[mailto:qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>]
 On Behalf Of Nathan Woodrow
Sent: mandag 30. oktober 2017 15.27
To: Borys Jurgiel <li...@borysjurgiel.pl<mailto:li...@borysjurgiel.pl>>
Cc: Richard Duivenvoorde <rich...@duif.net<mailto:rich...@duif.net>>; 
qgis-developer@lists.osgeo.org<mailto:qgis-developer@lists.osgeo.org>
Subject: Re: [QGIS-Developer] Settings migration from QGIS 2 to 3

Ah right.  I'm happy with whatever there.

On Tue, Oct 31, 2017 at 12:25 AM, Borys Jurgiel 
<li...@borysjurgiel.pl<mailto:li...@borysjurgiel.pl>> wrote:
Dnia wtorek, 31 października 2017 00:19:49 Nathan Woodrow pisze:
> Hey,
>
> > There are over 100 keys there, are we going to migrate them all from
>
> Windows
> to windows, like we did with Qgis -> qgis?
>
> No I don't think we need to do anything for those subgroups, dropping the
> Windows placement between version isn't a big deal.  The main core things
> to migrate is stuff that is a pain to setup again.

Sorry I was unclear. I didn't mean migrating the values, just changing the
section for all these keys.

Regards,
Borys


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org<mailto:QGIS-Developer@lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



--
Alessandro Pasotti
w3:   www.itopen.it<http://www.itopen.it>
___
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] Settings migration from QGIS 2 to 3

[Stefan Blumentrath]

Dear all,

I am really looking forward to seeing all QGIS configuration in ini-files and 
that registry will be abandoned on Windows in QGIS 3!
That will be a great improvement, esp. from a sys-admin perspective!

In this consolidation context I was wondering I would be possible to prepare 
for:

-  Use of relative path (https://issues.qgis.org/issues/12623)

-  Usage of variables in the ini file

I have been earlier thinking about “versioning” of ini files, so that updates 
(e.g. changes in OWS URLs) can be passed to all users as a sort of “diff/merge” 
without damaging individual adjustments they might have made.
Background is that the Norwegian mapping authority provides a “Service feed” 
(https://register.geonorge.no/register/tjenestevarsler) where all OWS changes 
are announced… I would love to be able to just apply those changes to all our 
users…

No idea if such a thing could be fostered by the way settings are stored in the 
ini files?

Cheers
Stefan

From: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Nathan Woodrow
Sent: mandag 30. oktober 2017 15.27
To: Borys Jurgiel 
Cc: Richard Duivenvoorde ; qgis-developer@lists.osgeo.org
Subject: Re: [QGIS-Developer] Settings migration from QGIS 2 to 3

Ah right.  I'm happy with whatever there.

On Tue, Oct 31, 2017 at 12:25 AM, Borys Jurgiel 
> wrote:
Dnia wtorek, 31 października 2017 00:19:49 Nathan Woodrow pisze:
> Hey,
>
> > There are over 100 keys there, are we going to migrate them all from
>
> Windows
> to windows, like we did with Qgis -> qgis?
>
> No I don't think we need to do anything for those subgroups, dropping the
> Windows placement between version isn't a big deal.  The main core things
> to migrate is stuff that is a pain to setup again.

Sorry I was unclear. I didn't mean migrating the values, just changing the
section for all these keys.

Regards,
Borys

___
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] [WIP] GRASS Processing port to new API

[Stefan Blumentrath]

Yes, thank you very much, Médéric!
Maybe you can have a look at / incorporate this one:
https://issues.qgis.org/issues/14856 ?

Using r.external.out could speed-up GRASS raster algorithms significantly…

Cheers
Stefan


From: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Pedro Venâncio
Sent: lørdag 16. september 2017 12.04
To: Médéric Ribreux 
Cc: qgis-developer 
Subject: Re: [QGIS-Developer] [WIP] GRASS Processing port to new API

Excellent work Médéric!
Thank you very much!
Best regards,
Pedro Venâncio


2017-09-16 8:35 GMT+01:00 Médéric Ribreux 
>:
Hello devs,

just a simple mail to tell you that I am currently working on QGIS3 Processing 
port of GRASS plugin.
You can read the code in my forked QGIS git repository:
https://github.com/medspx/QGIS/tree/ProcessingPortGrass72

For the moment, about 50% of the job is done:
- I have used the new QgsProcessing framework for parameters (I have used 
modifications of processing/parameters.py made by Nyall in the SAGA port).
- I have modified description files according to this new framework.
- I can launch most of the algorithms for rasters and vectors (and some 
imagery).
- I have also worked on improving layers management (importing/exporting 
into/from temporary GRASS DB).

I still need to work on the following points:
- Adapt and factorize ext/ scripts to the new framework.
- Multiformat support for vector and rasters.
- A better support for OutputFiles (HTML and text files).
- Add new GRASS7.2 algorithms (less than a dozen).
- Verify all description files to support the new parameters introduced into 
GRASS7.2.
- Port and improve unit tests.
- Try to fix all bugs linked to unicode support under MS-Windows.

I am going offline for the next 3 weeks and I think I'll be able to make a 
(decent) PR at the end of this period of time.

I really hope that QGIS3 will have GRASS Processing in its first release...

Cheers!
--
Médéric RIBREUX
https://medspx.fr
___
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