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
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:
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
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
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
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
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:
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:
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
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-d
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:
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
12 matches
Mail list logo
