Hi,
>>
> A common workflow that leads to this situation is when working on
> shapefiles and then using them in a processing algorithm that involves an
> external process. The processing situation could be avoided (detect if
> potentially dangerous operations like a delete have been performed sinc
Hi Nyall,
Thanks for explaining this. Makes sense and glad that it will be fixed
in QGIS 3.
So my follow-up question is: can I rely on $scale to work in future
version of QGIS or will it be deprecated?
Andreas
On 05.07.2017 00:52, Nyall Dawson wrote:
On 4 July 2017 at 01:46, Neumann, Andr
Plugin Walking Papers approval by pcav.
The plugin version "[1268] Walking Papers 0.2" is now approved
Link: http://plugins.qgis.org/plugins/walking_papers/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org
> I'd say we definitely do in the processing case. It'd be a significant
shortcoming to have to manually unload layers from projects before you
can run analysis on them.
> Not sure about totally external applications though
My comments only relate to external applications using files we have
On 5 July 2017 at 09:10, Nathan Woodrow wrote:
>>
> A common workflow that leads to this situation is when working on shapefiles
> and then using them in a processing algorithm that involves an external
> process. The processing situation could be avoided (detect if potentially
> dangerous operati
>
A common workflow that leads to this situation is when working on
shapefiles and then using them in a processing algorithm that involves an
external process. The processing situation could be avoided (detect if
potentially dangerous operations like a delete have been performed since
the last repa
On 4 July 2017 at 01:46, Neumann, Andreas wrote:
> Hi,
>
> In a QGIS project that should be published with QGIS Server, I used the
> @map_scale variable to define the font size with an expression, depending on
> the map scale. It works fine on QGIS Desktop, but on QGIS server GetMap
> requests it
On 7/4/17 6:46 PM, Even Rouault wrote:
> Another solution would be to defere the compaction only at layer
> closing (that's actually the new behaviour of the OGR Shapefile driver
> in recent GDAL versions to force a repack at closing). I'm not sure
> why QGIS currently repacks it every time ?
>
I
On 04.07.2017 18:46, Even Rouault wrote:
Another solution would be to defere the compaction only at layer
closing (that's actually the new behaviour of the OGR Shapefile driver
in recent GDAL versions to force a repack at closing). I'm not sure
why QGIS currently repacks it every time ?
T
> I don't know if it would be possible for OGR - in case of a repack() -
> to create an internal map of new ids to original ids (or if it would be
> possible for people to stop using shp :P). But I really don't know the
> internals of ogr (or people) good enough to comment on the feasibility
> of s
Hi Sandro,
The commit that introduced this behavior was done around 2 years back.
The reason for this was mainly interoperability with other applications
as Even mentioned.
https://github.com/qgis/QGIS/commit/7d7cdcd376c0d3fa60af1403a91e1e611b210174
Most relevant discussion around the issue can
Hi Even
Thanks for the reply. Yes I am indeed testing with shapefiles.
Not sure why I never observed this behaviour previously, but indeed I
have up to now never observed this myself, nor have received bug reports
concerned with this kind breakage - and this is a pretty hard to miss
issue sin
Sandro,
I guess this might depend on the actual OGR driver used. Somehow I assume you
use shapefiles here ?
This is probably linked to shapefiles being repacked after the end of various
operations
such as addFeatures(), changeGeometryValues(), deleteFeatures(), so as to avoid
issues
with othe
Hi
I'm doing work on the geometry checker in QGIS master and noticed that,
when deleting features from an ogr vector layer, FeatureIds appear to be
reassigned to fill up the gap in the ids. This is a pretty serious
blocker for the geometry checker since geometry checker errors are
identified
Hi all,
I get another (small) issue with "Split vector layer" in Processing.
By choosing a local folder where to store all the layers created from
the splitting, all the layers are saved in the /tmp/ folder anyways.
So algorithm works fine (output in /tmp/ are correct), only the
directory path i
> Is this on master?
yes, fresh compiled.. and sorry for the text, it's regular points and
not random point
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: htt
On 4 July 2017 at 02:08, matteo wrote:
> Hi all,
>
> I've some trouble with the simple "Random points" algorithm in
> Processing. No matter which parameters are selected, the algorithms does
> not return any output and "freezes" at 0%
>
> Should I open a ticket?
Is this on master?
Nyall
>
> Tha
Il 04/07/2017 09:57, matteo ha scritto:
> I notice that with all the algorithm that return html outputs, the
> result viewer is empty and one can get the result just by saving the
> output as local html in a folder.
confirmed
all the best
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS cour
Hi Nyall,
* barplot does not return a result (result viewer is empty)
>>>
>>> Looks like this happens when you don't pick a destination file. Can
>>> you re-test and explicitly choose an output file.
>>
>> tried, still empty wpanel
I notice that with all the algorithm that return html outpu
Plugin kNN approval by pcav.
The plugin version "[1264] kNN 0.1 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/kNN/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qg
On 4 July 2017 at 08:43, Paolo Cavallini wrote:
> Il 03/07/2017 21:15, Richard Duivenvoorde ha scritto:
>
> > Dreaming?
>
> If it is, it's a long standing one, and many of us have shard the same.
> It proved very elusive, and now I think QGIS has the richest set of
> styles, and rapidly improving
Plugin Walking Papers approval by pcav.
The plugin version "[1268] Walking Papers 0.1" is now approved
Link: http://plugins.qgis.org/plugins/walking_papers/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org
Il 03/07/2017 21:15, Richard Duivenvoorde ha scritto:
> Dreaming?
If it is, it's a long standing one, and many of us have shard the same.
It proved very elusive, and now I think QGIS has the richest set of
styles, and rapidly improving, so it may be very difficult to
standardize it. Falling back
23 matches
Mail list logo
