[QGIS-Developer] Plugin [1268] Walking Papers approval notification.

[noreply]

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/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Nathan Woodrow]

> 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 open,
I guess having it open in two QGIS instances is the same issue.  But I get
the same thing if I open the same word doc twice one of the applications
will take a write lock on the file.

On Wed, Jul 5, 2017 at 9:29 AM, Nyall Dawson  wrote:

> 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 operations like a delete have been performed since the last
> repack
> > and if yes repack or write it to a new file), but there were also other
> > situations where people just have been working on the same file in
> different
> > GIS applications side-by-side.
> >
> >
> > This raises the question.  Should we support that?  A lot of file types
> are
> > just not meant to be opened by many applications at the same, e.g MapInfo
> > wants a full exclusive read/write lock on tab files.  My gut has always
> been
> > if it's file based you shouldn't be using it in other applications at the
> > same time.
>
>
> 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
>
> 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/OGR: FeatureIds reassigned on write to data provider?

[Nyall Dawson]

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 operations like a delete have been performed since the last repack
> and if yes repack or write it to a new file), but there were also other
> situations where people just have been working on the same file in different
> GIS applications side-by-side.
>
>
> This raises the question.  Should we support that?  A lot of file types are
> just not meant to be opened by many applications at the same, e.g MapInfo
> wants a full exclusive read/write lock on tab files.  My gut has always been
> if it's file based you shouldn't be using it in other applications at the
> same time.


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

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/OGR: FeatureIds reassigned on write to data provider?

[Nathan Woodrow]

>
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 repack and if yes repack or write it to a new file), but there
were also other situations where people just have been working on the same
file in different GIS applications side-by-side.


This raises the question.  Should we support that?  A lot of file types are
just not meant to be opened by many applications at the same, e.g MapInfo
wants a full exclusive read/write lock on tab files.  My gut has always
been if it's file based you shouldn't be using it in other applications at
the same time.

- Nathan

On Wed, Jul 5, 2017 at 6:47 AM, Matthias Kuhn  wrote:

> 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 ?
>
>
> IIRC, in situations where the layer has not been closed and was still used
> by other software at the same time, issues arose.
>
> In particular features flagged as deleted by OGR (and no longer reported
> as existing features by OGR) were still detected as existing features by
> other applications. Often, this was surprising in situations when people
> were working on shapefiles, deleted some features and then used this file
> in a different application while it was still open in QGIS.
>
> 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 repack and if yes repack or write it to a new file), but there
> were also other situations where people just have been working on the same
> file in different GIS applications side-by-side.
>
> From the lack of reported issues regarding this in the last two years
> (compared to the time before) I suspect the current approach suits many
> use-cases quite well. At the same time, I am very surprised that this is
> the very first issue that I am aware of which is related to 7d7cdcd3.
>
> Matthias
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.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
>
___
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 Server 2.x: issue with @map_scale variable vs. $scale

[Nyall Dawson]

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 fails - the font-size (defined in map units) is constant and
> doesn't react to my scale dependent rule. The interesting thing, is, that
> the same rule works fine in GetPrint requests.
>
> If I change my rule to use $scale instead of @map_scale, my label rule works
> fine.
>
> Could it be that the @map_scale variable doesn't work in QGIS server GetMap
> requests?

Exactly - it's a consequence of QGIS 2.x server using the really old
map renderer, which means it doesn't have access to any variables
relating to the current map scale/extent/etc. This is also why 2.5d
renderer is quite broken on server under 2.x.

The good news is that it's all fixed with 3.0.

Nyall



>
> Here is my expression:
>
> CASE
>WHEN @map_scale <= 251 THEN 1
>WHEN @map_scale > 251 AND @map_scale <= 501 THEN 2
>WHEN @map_scale > 501 AND @map_scale <= 1001 THEN 3
>WHEN @map_scale > 1001 AND @map_scale <= 2001 THEN 4
>WHEN @map_scale > 2001 AND @map_scale <= 3001 THEN 6
>WHEN @map_scale > 3001 AND @map_scale <= 4001 THEN 7
>WHEN @map_scale > 4001  THEN 8
> END
>
> Thanks for your ideas.
>
> Andreas
>
>
> ___
> 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] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Matthias Kuhn]

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 ?
>

IIRC, in situations where the layer has not been closed and was still
used by other software at the same time, issues arose.

In particular features flagged as deleted by OGR (and no longer reported
as existing features by OGR) were still detected as existing features by
other applications. Often, this was surprising in situations when people
were working on shapefiles, deleted some features and then used this
file in a different application while it was still open in QGIS.

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 repack and if yes repack or write it to a new file), but
there were also other situations where people just have been working on
the same file in different GIS applications side-by-side.

From the lack of reported issues regarding this in the last two years
(compared to the time before) I suspect the current approach suits many
use-cases quite well. At the same time, I am very surprised that this is
the very first issue that I am aware of which is related to 7d7cdcd3.

Matthias

>  
>
> Even
>
>  
>
> -- 
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.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/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

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 ?



That would be a nice solution!

Sandro
___
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/OGR: FeatureIds reassigned on write to data provider?

[Even Rouault]

> 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 such a mechanism.

One could imagine to create such a map inside the shapefile driver itself 
(could be RAM 
costly though) But I guess that after a repack people expect OGR to return 
features and 
feature ids as they would appear after a fresh new open ? And I anticipate that 
this game 
with remapping feature ids could cause issues. For example the feature iterator 
operates on 
a OGR dataset handle which is not the one of the QgsOGRProvider object, so you 
would get 
different ids for the same feature depending on which handle is used. That 
would be a 
mess...

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 ?

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.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/OGR: FeatureIds reassigned on write to data provider?

[Matthias Kuhn]

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 be found here, where this
behavior with changing feature ids is also pointed out (sorry, the
thread is really long).

https://issues.qgis.org/issues/11007

To alleviate the impact, the signal `QgsVectorLayer::dataChanged()` was
introduced. As soon as this signal is emitted, any cached feature id
should be discarded. It might help to let the geometry checker reload
the data when feature ids are bogus.

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 such a mechanism.

Regards
Matthias

On 7/4/17 5:51 PM, Sandro Mani wrote:
>
> 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 since the plugin will essentially behave randomly.
>
> In any event, so I suppose other than manually introducing a UUID
> attribute to the features and identifying them by a attribute filter
> expression, there is no way to reliably identify a feature over the
> lifetime of the layer being loaded in QGIS?
>
> I'm kinda inclined to think that I'm not the only one relying on
> feature ids to identify features?
>
> Sandro
>
> On 04.07.2017 17:36, Even Rouault wrote:
>>
>> 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 other software that don't like holes in SHP and DBF files.
>>
>>  
>>
>> There have been changes in that area to rebustify shapefile
>> recompaction that used
>>
>> to work not so well on Windows (although most of them were in OGR
>> itself),
>>
>> but my understanding of
>>
>> https://github.com/qgis/QGIS/blob/release-2_12/src/providers/ogr/qgsogrprovider.cpp
>>
>> is that even in 2.12, feature deletion should cause a repack of the
>> shapefile, so
>>
>> I'm not sure why the issue would be new
>>
>>  
>>
>> Even
>>
>>  
>>
>> > 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 by the feature id (and other parameters). So if the
>>
>> > FeatureIds change, the geometry checker errors may suddenly reference
>>
>> > the wrong feature, causing general mayhem.
>>
>> >
>>
>> > Can anyone confirm that indeed FeatureIds are being purposefully
>>
>> > reassigned, and whether there is a rationale behind this change (I
>> never
>>
>> > observed this before in QGIS 2.x)? And if so, what other options exist
>>
>> > to reliably reference a feature over the entire lifetime of the layer
>>
>> > being loaded in QGIS?
>>
>> >
>>
>> > Note that in the geometry checker, I don't use the edit buffer, but
>>
>> > write each change directly to the data provider. This to avoid that
>>
>> > situations where, after fixing multiple errors, the final result cannot
>>
>> > be committed due to a particular geometry still being invalid and the
>>
>> > provider refusing to accept the change.
>>
>> >
>>
>> > Thanks
>>
>> > Sandro
>>
>> >
>>
>> > ___
>>
>> > 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
>>
>>  
>>
>>  
>>
>> -- 
>>
>> Spatialys - Geospatial professional services
>>
>> http://www.spatialys.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

___
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/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

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 since the plugin will essentially behave randomly.


In any event, so I suppose other than manually introducing a UUID 
attribute to the features and identifying them by a attribute filter 
expression, there is no way to reliably identify a feature over the 
lifetime of the layer being loaded in QGIS?


I'm kinda inclined to think that I'm not the only one relying on feature 
ids to identify features?


Sandro

On 04.07.2017 17:36, Even Rouault wrote:


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 other software that don't like holes in SHP and DBF files.

There have been changes in that area to rebustify shapefile 
recompaction that used


to work not so well on Windows (although most of them were in OGR itself),

but my understanding of

https://github.com/qgis/QGIS/blob/release-2_12/src/providers/ogr/qgsogrprovider.cpp

is that even in 2.12, feature deletion should cause a repack of the 
shapefile, so


I'm not sure why the issue would be new

Even

> 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 by the feature id (and other parameters). So if the

> FeatureIds change, the geometry checker errors may suddenly reference

> the wrong feature, causing general mayhem.

>

> Can anyone confirm that indeed FeatureIds are being purposefully

> reassigned, and whether there is a rationale behind this change (I never

> observed this before in QGIS 2.x)? And if so, what other options exist

> to reliably reference a feature over the entire lifetime of the layer

> being loaded in QGIS?

>

> Note that in the geometry checker, I don't use the edit buffer, but

> write each change directly to the data provider. This to avoid that

> situations where, after fixing multiple errors, the final result cannot

> be committed due to a particular geometry still being invalid and the

> provider refusing to accept the change.

>

> Thanks

> Sandro

>

> ___

> 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

--

Spatialys - Geospatial professional services

http://www.spatialys.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/OGR: FeatureIds reassigned on write to data provider?

[Even Rouault]

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 other software that don't like holes in SHP and DBF files.

There have been changes in that area to rebustify shapefile recompaction that 
used
to work not so well on Windows (although most of them were in OGR itself),
but my understanding of 
https://github.com/qgis/QGIS/blob/release-2_12/src/providers/ogr/qgsogrprovider.cpp
is that even in 2.12, feature deletion should cause a repack of the shapefile, 
so
I'm not sure why the issue would be new

Even

> 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 by the feature id (and other parameters). So if the
> FeatureIds change, the geometry checker errors may suddenly reference
> the wrong feature, causing general mayhem.
> 
> Can anyone confirm that indeed FeatureIds are being purposefully
> reassigned, and whether there is a rationale behind this change (I never
> observed this before in QGIS 2.x)? And if so, what other options exist
> to reliably reference a feature over the entire lifetime of the layer
> being loaded in QGIS?
> 
> Note that in the geometry checker, I don't use the edit buffer, but
> write each change directly to the data provider. This to avoid that
> situations where, after fixing multiple errors, the final result cannot
> be committed due to a particular geometry still being invalid and the
> provider refusing to accept the change.
> 
> Thanks
> Sandro
> 
> ___
> 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


-- 
Spatialys - Geospatial professional services
http://www.spatialys.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

[QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

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 by the feature id (and other parameters). So if the 
FeatureIds change, the geometry checker errors may suddenly reference 
the wrong feature, causing general mayhem.


Can anyone confirm that indeed FeatureIds are being purposefully 
reassigned, and whether there is a rationale behind this change (I never 
observed this before in QGIS 2.x)? And if so, what other options exist 
to reliably reference a feature over the entire lifetime of the layer 
being loaded in QGIS?


Note that in the geometry checker, I don't use the edit buffer, but 
write each change directly to the data provider. This to avoid that 
situations where, after fixing multiple errors, the final result cannot 
be committed due to a particular geometry still being invalid and the 
provider refusing to accept the change.


Thanks
Sandro

___
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] [Processing] Split vector layer problem

[matteo]

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 input seems to be not taken into account.

Thanks!

Matteo
___
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] Regular points in Processing freezes

[matteo]

> 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: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Regular points in Processing freezes

[Nyall Dawson]

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

>
> Thanks
>
> Matteo
> ___
> 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] QGIS 3 > Processing: some test

[Paolo Cavallini]

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 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

Re: [QGIS-Developer] QGIS 3 > Processing: some test

[matteo]

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 outputs, the
result viewer is empty and one can get the result just by saving the
output as local html in a folder.

Can I help to solve this problem?

Thanks!

Matteo
___
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 [1264] kNN approval notification.

[noreply]

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/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] GeoPackage and styling

[Ian Turton]

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, so it may be very difficult to
> standardize it. Falling back to a more limited set is IMHO not a very
> viable option.
>

I think the best chance for standardisation is to allow programs to fall
back to "easier" options if unable to support the more complex styles
another program is generating, other wise there is no incentive to bother
reading the style if you can't implement all possible style options and
then standardisation falls by the way side for another 10 years.

Ian
___
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 [1268] Walking Papers approval notification.

[noreply]

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/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] GeoPackage and styling

[Paolo Cavallini]

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 to a more limited set is IMHO not a very
viable option.
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=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