Re: [QGIS-Developer] FOSS4G CFP proposals around QGIS

[Alessandro Pasotti]

Hi

I submitted a workshop proposal about QGIS Server and Python.

Basically the same I did in La Coruña.


On Mon, Apr 15, 2019 at 12:17 PM Andreas Neumann 
wrote:

> Hi,
>
> Today is the last day submitting workshop and presentation proposals.
>
> I wonder who/what was already submitted, so I could potentially help to
> fill in gaps?
>
> I could submit something around "tips with layouts/atlas/reports"
> (including usage of variables and expressions).
>
> How about
>
>- QGIS server improvements (OGC validation, etc.)
>- Behind the scenes of QGIS.ORG (it was presented in Dresden at
>FOSSGIS by Anita and in A Coruna by myself; but I think not yet at a FOSS4G
>conf)
>- QGIS 3D (Lutra-guys - are you participating?)
>
> How about doing a workshop around 3D and mesh rendering?
>
> Thanks for your replies and greetings,
>
> 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



-- 
Alessandro Pasotti
w3:   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] GetFeatureInfo: sensitivity on rendered geometry vs original geometry.

[Alessandro Pasotti]

On Fri, Apr 12, 2019 at 3:53 PM René-Luc Dhont  wrote:

> Hi Andreas,
>
> I think QGIS Server has to use the rendered geometries to identify Feature.
>

Hi René,

Yeah, I also though that's the only solution, what scares me is the
performances cost, because we would need to render and check each layer
individually.



> Is it possible to get the  point layer to polygon rendred layer ?
>

I don't follow you, can you explain what's in your mind?



>
> Regards,
> René-Luc
>
> Le 12/04/2019 à 15:43, Andreas Neumann a écrit :
>
> Hi,
>
> I'd like to discuss an issue with GetFeatureInfo that we have with point
> symbols.
>
> (Point) symbols can have different sizes (sometimes rather large),
> different anchor points and sometimes even with offset away from the
> original feature geometry. Often, the rendering of the point symbol differs
> substantially from the original point geometry.
>
> Now, our issue is that GetFeatureInfo often fails miserably in such cases.
> People try to click on the visible symbol, which doesn't correspond to the
> original geometry.
>
> One such example WMS:
>
> https://services.geo.zg.ch/ows/Abfallsammelstellen
>
> The symbols are rather large, but the anchor point is at the bottom of the
> symbol. Users now think that they can click anywhere on the symbol, but in
> fact they can only click on the original geometry at the very bottom of the
> symbol, taking into account the FI_POINT_TOLERANCE parameter.
>
> Things get even worse when one wants to identify points that are displayed
> using the point displacement renderer. There, GetFeatureInfo is only
> sensitive on the center point, and not at all at the rendered points at a
> completely different position.
>
> Now my question: could we improve QGIS server that GetFeatureInfo responds
> to the bounding boxes of the rendered geometries (as opposed to the raw
> geometries), taking into account sizes, offsets, etc.
>
> Would this be technically possible?
>
> Would others also think that this is useful to have?
>
> Or would this even contradict OGC standards?
>
> Do other WMS servers implement such behaviors (Geoserver, UMN)?
>
> Thanks for the discussion,
>
> Andreas
>
> ___
> QGIS-Developer mailing listqgis-develo...@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



-- 
Alessandro Pasotti
w3:   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] loading attribute table with a lot of fields

[Alessandro Pasotti]

On Thu, Apr 11, 2019 at 2:51 PM Martin Landa  wrote:

> Hi,
>
> čt 11. 4. 2019 v 10:00 odesílatel Alessandro Pasotti
>  napsal:
> > Yes, something similar I thought it was fixed
> >
> > https://issues.qgis.org/issues/21303
>
> thanks, it seems to be PG-only related, right? My data is stored in
> SQLite DB. Ma
>
>
Hi Martin,

yes, that was PG specific.


-- 
Alessandro Pasotti
w3:   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] QGIS Server layer metadata

[Alessandro Pasotti]

On Thu, Apr 11, 2019 at 2:08 PM Etienne Trimaille <
etienne.trimai...@gmail.com> wrote:

> Le jeu. 11 avr. 2019 à 07:46, Alessandro Pasotti  a
> écrit :
>
>> If I'm not wrong, in getcapabilities you will get metadata from OWS tab,
>> in expressions you get metadata from Metadata tab and there is no fallback.
>>
>
> Correct, but there is a fallback. The expression will use the QGIS Server
> metadata if the corresponding layer metadata is empty.
>

The fallback I'm talking about is in server metadata, not the expressions.

If "Title" is empty in server metadata tab, getcapabilities will not use
the metadata from the metadata tab.

But in general, the question is: now that we have the metata tab for both
project and layers, do we still need a separate UI server metadata?

Maybe yes: it's just a question.

But if the answer is yes, we should think about inheriting defaults in a
consistent (and documented) way.





>
> According to https://github.com/qgis/QGIS-Enhancement-Proposals/issues/50
> and some discussions 2 years ago, I think that all items of the QGIS Server
> tab can fit into the new schema. But I agree, the UI is not the best about
> links for instance. (metadata URL, data URL, legend URL)
>
>
>>
>>
>>
>>> Le jeu. 11 avr. 2019 à 05:23, Alessandro Pasotti  a
>>> écrit :
>>>
>>>>
>>>> On Thu, Apr 11, 2019 at 11:17 AM René-Luc Dhont 
>>>> wrote:
>>>>
>>>>> Hi ALessandro,
>>>>>
>>>>> Which metadata can be reused ?
>>>>>
>>>>
>>>> For example: Title, Abstract, Keywords, Attribution 
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> René-Luc D'Hont
>>>>>
>>>>> Le 11/04/2019 à 11:12, Alessandro Pasotti a écrit :
>>>>>
>>>>> Hi,
>>>>>
>>>>> Shouldn't we drop some of the QGIS Server that are now available in
>>>>> the more general "Metadata" tab or at least fallback on those values?
>>>>>
>>>>> Or maybe provide a button to copy values from the "Metadata" tab.
>>>>>
>>>>>
>>>>> --
>>>>> Alessandro Pasotti
>>>>> w3:   www.itopen.it
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Alessandro Pasotti
>>>> w3:   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
>>>
>>>
>>
>> --
>> Alessandro Pasotti
>> w3:   www.itopen.it
>>
>

-- 
Alessandro Pasotti
w3:   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] QGIS Server layer metadata

[Alessandro Pasotti]

On Thu, Apr 11, 2019 at 1:30 PM Etienne Trimaille <
etienne.trimai...@gmail.com> wrote:

> Nyall has already made a PR for this:
> https://github.com/qgis/QGIS/pull/9197
> To use layer metadata instead of QGIS Server metadata when using an
> expression.
>
> I think we can replace a few of them already.
>

That's a bit different, and now the confusion is complete :)

If I'm not wrong, in getcapabilities you will get metadata from OWS tab, in
expressions you get metadata from Metadata tab and there is no fallback.



> Le jeu. 11 avr. 2019 à 05:23, Alessandro Pasotti  a
> écrit :
>
>>
>> On Thu, Apr 11, 2019 at 11:17 AM René-Luc Dhont 
>> wrote:
>>
>>> Hi ALessandro,
>>>
>>> Which metadata can be reused ?
>>>
>>
>> For example: Title, Abstract, Keywords, Attribution 
>>
>>
>>
>>
>>>
>>> René-Luc D'Hont
>>>
>>> Le 11/04/2019 à 11:12, Alessandro Pasotti a écrit :
>>>
>>> Hi,
>>>
>>> Shouldn't we drop some of the QGIS Server that are now available in the
>>> more general "Metadata" tab or at least fallback on those values?
>>>
>>> Or maybe provide a button to copy values from the "Metadata" tab.
>>>
>>>
>>> --
>>> Alessandro Pasotti
>>> w3:   www.itopen.it
>>>
>>>
>>>
>>
>> --
>> Alessandro Pasotti
>> w3:   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
>
>

-- 
Alessandro Pasotti
w3:   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] QGIS Server layer metadata

[Alessandro Pasotti]

On Thu, Apr 11, 2019 at 11:17 AM René-Luc Dhont  wrote:

> Hi ALessandro,
>
> Which metadata can be reused ?
>

For example: Title, Abstract, Keywords, Attribution 




>
> René-Luc D'Hont
>
> Le 11/04/2019 à 11:12, Alessandro Pasotti a écrit :
>
> Hi,
>
> Shouldn't we drop some of the QGIS Server that are now available in the
> more general "Metadata" tab or at least fallback on those values?
>
> Or maybe provide a button to copy values from the "Metadata" tab.
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>
>
>

-- 
Alessandro Pasotti
w3:   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

[QGIS-Developer] QGIS Server layer metadata

[Alessandro Pasotti]

Hi,

Shouldn't we drop some of the QGIS Server that are now available in the
more general "Metadata" tab or at least fallback on those values?

Or maybe provide a button to copy values from the "Metadata" tab.


-- 
Alessandro Pasotti
w3:   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] loading attribute table with a lot of fields

[Alessandro Pasotti]

On Wed, Apr 10, 2019 at 5:13 PM Martin Landa  wrote:

> Hi,
>
> I got a strange experience with QGIS (3.4) when opening attribute
> table with larger number of fields (here 512 fields). Attribute table
> opens very quickly, but then QGIS freeze for dozens of seconds (not
> able to scroll attribute table).
>
> Do you have similar experience? Known issue? Thanks! Ma
>

Yes, something similar I thought it was fixed

https://issues.qgis.org/issues/21303


-- 
Alessandro Pasotti
w3:   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] Inconsistency in QgsServerRequest parameter handling ?

[Alessandro Pasotti]

On Wed, Apr 10, 2019 at 11:37 PM David Marteau  wrote:

>
> > Le 10 avr. 2019 à 23:21, pblottiere  a
> écrit :
> >
> > Hi David,
> >
> >
> >> If you try:
> >>
> >> request.setParameter('FOOBAR','foobar')
> >>
> >> then
> >>
> >> request.parameter('FOOBAR')
> >>
> >> then you get an empty string,
> >>> Even if I add  an 'allowed' parameter by hand:
> >>>
> >>>> request.setParameter('FI_POINT_TOLERANCE','25')
> >
> > Actually, QgsServerRequest and QgsServerParameters are high level
> > classes which are not aware of valid parameters defined in services. For
> > example, FI_POINT_TOLERANCE is a valid parameter in WMS service, and
> > defined within the WMS module. But it's totally encapsulated within the
> > module (a shared library so), and considered as unknown from
> > QgsServerParameters. The only valid parameters from the
> > QgsServerParameters point of view are those which are common for all
> > services (WMS, WFS, and so on) like SERVICE, VERSION, REQUEST, ...
> >
> > If you want to retrieve the full query from the request without any
> > filter on valid parameters, you may use request.url(). However, I think
> > we could probably add a fallback on the `parameter()` method to return
> > invalid parameters too. I'll do a PR tomorrow and I'll ping you to check
> > if the behaviour suits you.
> >
> >
>
> Yes, this is what I was thinking about Looking at the code: maybe adding a
> lookup to the 'unmanaged' parameters if the code is not found should
> restore the symmetry setParameter/parameter.
>
> I'm standing from the python plugin's point of view - services and
> filters: plugins are expecting some behavior when setting/getting
> parameters. If a plugin override a parameter it can only doing it using the
> requestHandler which is aware
> only of the  base QgsServerParameters owned by the  QgsServerRequest
> instance, so they should be able to set/get parameters in a transparent way.
>
> Regards
>
> David.
>
>
Hi David,

that makes sense, I agree completely, it's odd I didn't catch this issue
before during one of my tests with plugins, I often use parameters to pass
information around within plugins.

May I suggest that we add a test case to protect the changes when done?

Thanks!



> > Regards,
> >
> > Paul
> >
> >
> > On 4/10/19 10:37 PM, David Marteau wrote:
> >> To add some precision:
> >>
> >> Even if I add  an 'allowed' parameter by hand:
> >>
> >>> request.setParameter('FI_POINT_TOLERANCE','25')
> >> then
> >>
> >>> request.parameter('FI_POINT_TOLERANCE')
> >> return an empty string
> >>
> >>> Le 10 avr. 2019 à 19:46, David Marteau  a écrit :
> >>>
> >>>
> >>> Hi devs,
> >>>
> >>> I found a strange and seemingly inconsistent behavior when accessing
> QgsServerRequest parameters:
> >>>
> >>> If you try:
> >>>
> >>> request.setParameter('FOOBAR','foobar')
> >>>
> >>> then
> >>>
> >>> request.parameter('FOOBAR')
> >>>
> >>> then you get an empty string,
> >>>
> >>> If you call
> >>>
> >>> request.parameters()
> >>>
> >>> Then your get a dictionary with all the values previously set.
> >>>
> >>> At first glance it seems that request.setParameter enforce use of a
> limited set of keys (SERVICE…..
> >>>
> >>> This does not seem very consistent with the fact parameter() should
> return any value previously set with setParameter and also the fact that
> >>> request.parameters()  return all previously defined  parameters
> key/values .
> >>>
> >>> Furthemore this may be  problematic with plugins that define services
> in python and thus may define any other set of allowed parameters.
> >>>
> >>> Should I open an issue ?
> >>>
> >>> David
> >
>
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Crashes on closing QGIS

[Alessandro Pasotti]

 


@thomas : there are already dozen of issue reports with your stacktrace,
which is very different from Andrea's.


On Wed, Apr 10, 2019 at 3:50 PM Thomas Baumann 
wrote:

> Hi there,
>
> same situation here: QGIS 3.6 crashed several times when trying to close
> it.
>
> regards,
> Thomas
>
> PS: attached is one crash report:
> 
>
> h2. User Feedback
>
> QGIS Crashed when I tried to close QGIS
>
> h2. Report Details
>
> *Crash ID*: 62f1fcd2045780cb9f127836e6b579b8665f3e63
>
>
> *Stack Trace*
> 
> proj_lpz_dist :
> proj_lpz_dist :
> QgsCoordinateTransform::transformPolygon :
> QgsCoordinateTransform::transformPolygon :
> QgsCoordinateTransform::QgsCoordinateTransform :
> QHashData::free_helper :
> QgsCoordinateTransform::addToCache :
> QgsCoordinateTransform::invalidateCache :
> QgsApplication::exitQgis :
> QgisApp::~QgisApp :
> CPLStringList::operator[] :
> main :
> BaseThreadInitThunk :
> RtlUserThreadStart :
> 
>
>
> *QGIS Info*
> QGIS Version: 3.6.0-Noosa
> QGIS code revision: commit:58734527ab
> Compiled against Qt: 5.11.2
> Running against Qt: 5.11.2
> Compiled against GDAL: 2.4.0
> Running against GDAL: 2.4.0
>
>
>
> *System Info*
> CPU Type: x86_64
> Kernel Type: winnt
> Kernel Version: 10.0.14393
>
>
> Am Mo., 8. Apr. 2019 um 11:22 Uhr schrieb Andreas Neumann <
> a.neum...@carto.net>:
>
>> Hi,
>>
>> We always have crashes on closing QGIS (on Windows) - regardless of
>> version - it happens on 3.4, 3.6 and master.
>>
>> Seems to be related to the authentication manager. Is this a known issue?
>> Are there ideas how to fix the issue?
>>
>> Here is the crashlog:
>>
>> Crash ID: 0f25782d491a42462ec5c96af91c45b3e9859bd3
>>
>> Stack Trace
>>
>>
>> QMutex::lock :
>> QMutexLocker::QMutexLocker :
>> ::operator() qgsauthmanager.cpp:145
>> QtPrivate::FunctorCall,QtPrivate::List,void, >::call qobjectdefs_impl.h:128
>> QtPrivate::Functor,0>::call,void> qobjectdefs_impl.h:239
>> QtPrivate::QFunctorSlotObject,0,QtPrivate::List,void>::impl 
>> qobjectdefs_impl.h:427
>> QMetaObject::activate :
>> QThread::finished :
>> QThread::currentThreadId :
>> QThread::start :
>> BaseThreadInitThunk :
>> RtlUserThreadStart :
>>
>>
>>
>>
>> QGIS Info
>> QGIS Version: 3.7.0-Master
>> QGIS code revision: 5a85e206f6
>> Compiled against Qt: 5.11.2
>> Running against Qt: 5.11.2
>> Compiled against GDAL: 2.4.1
>> Running against GDAL: 2.4.1
>>
>>
>>
>> System Info
>> CPU Type: x86_64
>> Kernel Type: winnt
>> Kernel Version: 6.1.7601
>> ___
>> 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



-- 
Alessandro Pasotti
w3:   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] Bug #21460?

[Alessandro Pasotti]

ng revealed
> to me that I need: "CREATE EXTENSION IF NOT EXISTS "uuid-ossp";" to use
> the uuid_generate_v4() function you use?
>
> Also make sure it is actually a QGIS problem, looking into it, it is.
> But it is also a data-schema issue, as you define the problematic
> columns as:
> predecessors uuid[] DEFAULT ARRAY[]::uuid[],
> And the "uuid[]" is not a very common type in the gis world.
>
> If I'm correct '{""}' (what QGIS now uses for NULL values if the column
> has an array type) is a textual representation of an array with one
> string in it. Would it be better to do '{null}' or even '{}' instead?
> Can you try to create an update query with '{null}' and '{}' values in
> the empty array fields?
> And add these queriies to the bug report?
>
> Regards,
>
> Richard Duivenvoorde
>
>
>
>
>
>
>
>
>
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] No LTR on SUSE repos

[Alessandro Pasotti]

On Mon, Apr 8, 2019 at 10:25 AM Paolo Cavallini 
wrote:

> Hi Yann,
>
> On 08/04/19 10:01, Yann POUFFARIX wrote:
> > Back in time.
> >
> > No answer from maintener and of course nothing listed here
> >
> > https://software.opensuse.org/package/qgis-ltr
> >
> > what to do x)
>
> I think you are left with the choice of either doing the package
> yourself, or hire someone to do it. Of course you can always compile
> qgis yourself, it shouldn't be too hard if the dependencies are properly
> packaged.
> Cheers.
>
>
Just curious: why should we invest money for Apple packaging and not for
SuSE packaging?

I think we should be inclusive and supportive for all users on all
platforms.



-- 
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Can't import GeoPackage generated by QGIS into PostGIS

[Alessandro Pasotti]

My pleasure!

On Thu, Apr 4, 2019 at 1:53 PM Anita Graser  wrote:

>
>
> On Sun, Mar 31, 2019 at 1:46 PM Anita Graser  wrote:
>
>> Here it is: https://issues.qgis.org/issues/21714
>>
>
> Thanks for fixing, Alessandro!
>
> Anita
>
>
>


-- 
Alessandro Pasotti
w3:   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] Can't import GeoPackage generated by QGIS into PostGIS

[Alessandro Pasotti]

On Sat, Mar 30, 2019, 21:55 Anita Graser  wrote:

> Hi,
>
> I have a CSV with multiple columns including some WKT columns containing
> polygon definitions. I've exported the layer as GeoPackage. Later, I wanted
> to import the GeoPackage content to PostGIS but the import fails because
> the WKT strings are longer than the fields DB Manager creates. The layer
> properties state that the WKT columns are text(255) but the strings are
> considerably longer.
>
> (If I directly import the CSV to PostGIS, all is well.)
>
> I'm not sure what kind of ticket I should open ...
> - Option #1: DB Manager should be more fault tolerant and create less
> restrictive columns
> - Option #2: QGIS shouldn't create GeoPackages that store long strings in
> field defined as text(255)
>
> What do you recommend?
>


Hi Anita,

I think 2 looks like a bug.

I didn't look at it but from your description seems like DB manager
correctly follows the (wrong) information from the provider.



> Regards,
> Anita
>
>
> ___
> 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.6.0 fail to read shapefile with python on buster

[Alessandro Pasotti]

On Tue, Mar 26, 2019 at 5:45 PM David Marteau  wrote:

>
> The situation seems to be worst: it seems that no layers can be read from
> python whatever the format.
>
>
> Le 26 mars 2019 à 17:38, David Marteau  a écrit :
>
> Hi devs,
>
> We use to build docker images of the latest qgis releases and we have a
> regression  affecting version 3.6.0 official release on buster
>
> Qgis: 3.6.0 on Debian
>
> If we read a layer with python:
>
> layer = QgsVectorLayer('./mydata.shp')
>
>
> Then the layer is invalid (no warning, no errors)
>
> Doing the same thing on stretch + Qgis 3.4.5 (ltr) with same data work
> flawlessly and lead to a valid layer.
>
> This was not affecting previous build 24 h ago (release end
> nightly-release)
>
> The tests were based with shapefiles from testdata in qgis sources.
>
> We are not sure it that come from Qgis itself or from a change on the
> distribution.
>
> David,
>
>
>
Hi David,

anything in the logs?

I would check QGIS_PREFIX_PATH env var, and make sure the provider
libraries are found and loaded.


-- 
Alessandro Pasotti
w3:   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] Get rid of 'Manage Layers Toolbar', or not?

[Alessandro Pasotti]

Hi Andreas,

IIRC the removal was discussed in the original plan, your proposal looks
good.

I think the data source manager dialog icon should outshine the others but
I have no idea how to do that.

On Sat, Mar 16, 2019, 16:53 Andreas Neumann  wrote:

> Hi Richard,
>
> I wouldn't mind removing it - but we could also do it in two steps: first
> disabling it by default for new users and then later remove it completely.
>
> Andreas
> Am 16.03.19 um 13:58 schrieb Richard Duivenvoorde:
>
> Porting some Documentation about Mesh layers, written by Rosa during the
> Hackfest, I happened to note that there is no 'Add Mesh Layer' icon on
> the 'Manage Layers Toolbar' (see screenie).
>
> So now I wonder: do I create a Feature Request to add 'Add Mesh Layer'
> to it (so it opens the DataSource Manager window)?
>
> OR
>
> are we planning to get rid of the 'Manage Layers Toolbar' because we
> have the new DataSource Manager dialog now?
>
> Regards,
>
> Richard Duivenvoorde
>
>
> ___
> QGIS-Developer mailing listqgis-develo...@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
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Flaky tests and Travis

[Alessandro Pasotti]

I understand we haven't much of a choice: +1 for disabling.

I wonder if there is a way to make it more evident for developers that they
need to run disabled tests locally by hand before making a PR.

It happened to me once or twice that I made a change that I knew was
covered by a test case, let travis run, all green, merge!

And then I discovered that the test I was relying on wasn't running on
Travis and that there was a test failure when running the test locally.



On Tue, Mar 12, 2019 at 9:28 AM Matthias Kuhn  wrote:

> On 3/12/19 12:28 AM, Nyall Dawson wrote:
>
> On Tue, 12 Mar 2019 at 07:59, Denis Rouzaud  
>  wrote:
>
> I am also in favor of disabling them but maybe keep them running and have 
> them as expected failure?
>
> That sounds preferable -- but I'm not (personally) sure if it's
> possible. You know the CI setup better than I do, can you see a way to
> do this?
>
> I'm not sure this works.
>
> Expected failure "expects" the tests to fail and will error if it
> succeeds, since we are dealing with flaky tests here, that will still lead
> to unstable behavior.
>
> If not I'd still be in favor of disabling them.
>
> I honestly believe the harm in leaving these enabled (short term) is
> outweighing the risk of disabling them. We are very likely pushing new
> contributors away from our project with the current difficulties just
> getting a PR to green.
>
> I agree with the proposal, these tests do more harm than good currently.
>
> Matthias
>
> Nyall
>
>
>
> Cheers
> Denis
>
> On Mon, 11 Mar 2019, 22:47 Nyall Dawson,  
>  wrote:
>
> Hi all,
>
> For a long time now we've been plagued by intermittently failing tests
> on Travis, which are making the whole QGIS development experience
> quite painful.
>
> I propose that we take an absolute hard line approach from now and
> disable all tests which are causing false positive failures. I've
> started here: https://github.com/qgis/QGIS/pull/9483
>
> This is obviously not ideal, as the failures may be revealing real
> bugs (and in the case of the two disabled above I believe they are
> symptoms of the same underlying bug), but I think now we've passed the
> point where leaving these tests enabled causes more damage then
> skipping them.
>
> Ideally someone would investigate these and fix either the tests or
> the underlying bugs... but it hasn't happened in 6+ months, so I don't
> expect that to happen shortly**. I did spend some time around a month
> ago to see if the fix for these two was trivial, but could not find it
> quickly.
>
> Is anyone opposed to a hard-line "disable if flaky" stance?
>
> Nyall
>
> ** For full disclosure: next round of QGIS grants I plan on filing for
> a grant to investigate all tests disabled on Travis in depth and
> either fix underlying bugs or make the tests more stable. But that's
> grant dependant, and not a short term solution.
> ___
> QGIS-Developer mailing listqgis-develo...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
>
> Denis rouzaudde...@opengis.ch
> +41 76 370 21 22
>
>
>
> ___
> QGIS-Developer mailing listqgis-develo...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
> Matthias Kuhn
> matth...@opengis.ch
> +41 (0)76 435 67 63 <+41764356763>
> [image: OPENGIS.ch Logo] <http://www.opengis.ch>
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Improvement to the plugin manager's upgradeable plugins details

[Alessandro Pasotti]

I like the idea, I'm just worried about the increased size of the XML on
option A: we don't have any control over the changelog size (well, we could
truncate the changelog if it's too long but I don't know if that makes much
sense).



On Sat, Mar 9, 2019 at 11:38 AM Mathieu Pellerin 
wrote:

> Greetings,
>
> While applying a couple of commits to QGIS' plugin manager, I would like
> to fix a long-standing UX issue with it, namely that plugins that show a
> newer version available do _not_ show the latest changelog but rather the
> changelog of the currently installed plugin version.
>
> It'd much nicer, and exciting for users, to show what's new _prior to_
> hitting the [ update plugin ] button.
>
> For that to happen, we'd need either: a/ add the changelog information in
> the repository XML file fetched (i.e.
> https://plugins.qgis.org/plugins/plugins.xml?qgis=3.6), or b/ add a
> method to fetch changelog strings from the repository site (for e.g.,
> https://plugins.qgis.org/plugins/changelog.xml?names=plugin1,plugin2,plugin3
> ).
>
> Unless adding the short changelog to the repository XML adds too many MBs,
> I'd vote for option A.
>
> Thoughts?
>
> Mathieu
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Plugin site down

[Alessandro Pasotti]

I wonder if spinning up an AWS for the heavy duty tasks (and switch it off
when done) would be the right thing to do here.


On Wed, Feb 27, 2019 at 4:32 PM Richard Duivenvoorde 
wrote:

> On 27/02/2019 15.25, Paolo Cavallini wrote:
> > 504 Gateway Time-out
> >
> > is it my impression, or this is happening rather often recently?
> > any way to fix it more permanently?
>
> We use the qgis2 server for several purposes. So IF a lot of people are
> viewing/using plugins or qgis site, and we are building
> docs/website/packages it get's crowded.
>
> To fix this we could rent another server, or move the plugins dir to
> another existing server (like the issue tracker (qgis3) or test server
> (qgis4)) Another server is another 600 dollar per year
>
> 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



-- 
Alessandro Pasotti
w3:   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] Error building QGIS server withouth GUI

[Alessandro Pasotti]

Please file a ticket on the issue tracker.

On Sun, Feb 24, 2019, 09:56 Tom Palan  wrote:

> Hello everybody,
>
> we are using QGIS server on our servers, without any GUI. For this I
> built a single Debian package without the desktop components and
> deployed on the servers. We are using currently version 2.18, but want
> to make the switch to 3.4 in the next few weeks, also for participating
> more in the dev process.
>
> My problem is with building QGIS 3.4.4:
> when I specify the cmake paramters like this:
> cmake -G Ninja \
>   -DCMAKE_VERBOSE_MAKEFILE=1 \
> -DCMAKE_INSTALL_PREFIX=/usr \
> -DBINDINGS_GLOBAL_INSTALL=TRUE \
> -DPEDANTIC=TRUE \
> -DSERVER_SKIP_ECW=TRUE \
> -DQGIS_CGIBIN_SUBDIR=/usr/lib/cgi-bin \
> -DWITH_APIDOC=TRUE \
> -DGENERATE_QHP=TRUE \
> -DWITH_CUSTOM_WIDGETS=FALSE \
> -DWITH_GLOBE=FALSE \
> -DWITH_SERVER=TRUE \
> -DWITH_SERVER_PLUGINS=TRUE \
> -DWITH_QWTPOLAR=FALSE \
> -DWITH_DESKTOP=FALSE \
> -DWITH_GUI=TRUE \
> -DDOXYGEN_ON_DEMAND=TRUE ..
>
> everything builds correctly.
> But with WITH_GUI=FALSE the build fails with the following error:
> ninja: error:
> '../python/plugins/db_manager/db_plugins/postgis/plugins/versioning/pyg
> ui', needed by
> 'python/plugins/db_manager/db_plugins/postgis/plugins/versioning/ui_Dlg
> Versioning.py', missing and no known rule to make it
>
> I am not sure what WITH_GUI does in the end, but as I want to remove
> any unnecessary components (and therefore install dependencies), please
> could somebody point me in the right direction? Thanks!
>
> Tom Palan
> ___
> 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] Request for Change of UserAgent

[Alessandro Pasotti]

Hi Richard,

Sounds fair to me, you can put the user agent string setting (
/qgis/networkAndProxy/userAgent ) in global_settings.ini, no need to
rebuild.

https://github.com/qgis/QGIS/blob/master/resources/qgis_global_settings.ini



On Wed, Feb 20, 2019 at 5:30 PM Richard Duivenvoorde 
wrote:

> Hi Devs, PSC,
>
> I had a short talk on IRC to 'Firefishy' the person who runs
> tile.openstreetmap.org CDN
> (in bcc, and see: http://irclogs.geoapt.com/qgis/%23qgis.2019-02-20.log)
>
> In short: he/osm has an issue with QGIS using 'Mozilla/5.0 ' as
> User-Agent header, but QGIS NOT behaving as a true browser.
>
> He explains that the tricks to create their abuse filters do not work on
> QGIS because (for example) we do not honor cookies.
>
> I asked this earlier:
>
>
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Do-we-have-a-User-Agent-string-for-QGIS-td5360740.html
>
> But in my opinion now is time to change our default UserAgent.
>
> In the email thread above people were afraid that certain wms proxies
> would block us, but I think we should just try.
>
> IF we have proxy troubles, we can change the UserAgent per service? For
> example change the UserAgent only for OSM related services.
> Mmm, is it possible to do that via Python...
>
> I think that we should honor requests from a colleague-FOSS-service. He
> notes that they are exceeding 17000 tile requests per second at peaks...
>
> Regards,
>
> Richard Duivenvoorde
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] QGIS Server WMSRequestDefinedDataSources configuration option

[Alessandro Pasotti]

Hi Marco,

thank you for the clarifications, I think that if that option is not
implemented in the current server version we should drop it, I'll take care
of it.



On Fri, Feb 8, 2019 at 11:00 AM Marco Hugentobler <
marco.hugentob...@sourcepole.ch> wrote:

> Hi Alessandro
> Am 08.02.19 um 08:33 schrieb Alessandro Pasotti:
>
> Hi all,
>
> I've found this WMSRequestDefinedDataSources option in the code (exposed
> in the Server GUI settings as "Allow defining datasources in server
> requests"), it is apparently unused.
>
> First question: what was it for?
>
> It was possible to request dynamically created vector and raster layers by
> giving path/datasource information to the server (tags RemoteRDS /
> RemoveVDS as SLD extension). To avoid potential security risks, the option
> 'Allow defining datasources in server requests' is off by default.
>
>
> Second question: ok to remove it or is anybody willing to add an
> implementation in a reasonable time?
>
>
> We don't use it in the current projects, so I don't have a strong opinion
> here.
>
>
> Regards,
>
> Marco
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>
> ___
> QGIS-Developer mailing listqgis-develo...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Weberstrasse 5, CH-8004 Zürich, switzerlandmarco.hugentob...@sourcepole.ch 
> http://www.sourcepole.ch
>
> ___
> 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



-- 
Alessandro Pasotti
w3:   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

[QGIS-Developer] QGIS Server WMSRequestDefinedDataSources configuration option

[Alessandro Pasotti]

Hi all,

I've found this WMSRequestDefinedDataSources option in the code (exposed in
the Server GUI settings as "Allow defining datasources in server
requests"), it is apparently unused.

First question: what was it for?

Second question: ok to remove it or is anybody willing to add an
implementation in a reasonable time?

-- 
Alessandro Pasotti
w3:   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] Windows only version of a QGIS 2.18x plugin

[Alessandro Pasotti]

On Thu, Feb 7, 2019 at 8:29 AM  wrote:

> Hi All,
>
>
>
> Thank you for the lively debate.
>
>
>
> Just to answer the concerns regarding the VESPER exe.
>
>
>
> I am *not* distributing the VESPER exe with the plugin.
>
>
>
> There are instructions in the provided manual and on the github page on
> where to download VESPER and how to configure it for PAT on Windows. It is
> up to the user to do this.  If VESPER is not installed the user will get a
> warning message and won’t be able to run the kriging part of the tool.
> There is currently only one tool from a group of around 13 which relies on
> VESPER. The kriging functionality already provided in QGIS is not suitable
> for our needs hence we are using VESPER.
>
>
>
That makes me think that perhaps the best win-win solution would have been
to fix/improve QGIS's Kriging implementation instead of relying on a
windows-only binary.


-- 
Alessandro Pasotti
w3:   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] Windows only version of a QGIS 2.18x plugin

[Alessandro Pasotti]

On Wed, Feb 6, 2019 at 1:59 PM Axel Andersson 
wrote:

> On the subject, is there any possibility to test a plugin at another
> platform?
>
> I'm developing my plugin on Windows machine and I have a Linux server,
> which I can test the plugin on but when it comes to OSX I have no machine
> to test it on. Does anyone have experience/good cookbooks how to set up a
> OSX virtual box or something similar to test a plugin in?
>
>
>
I'm not a lawyer but I believe that you are breaking the law if you do not
run Apple software on Apple hardware.


-- 
Alessandro Pasotti
w3:   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] Windows only version of a QGIS 2.18x plugin

[Alessandro Pasotti]

On Wed, Feb 6, 2019 at 7:28 AM  wrote:

> Hi QGIS dev list,
>
> I have just uploaded a new QGIS 2.18.x plugin called PAT - Precision
> Agriculture Tools.  It relies on VESPER,  a Windows only bit of software so
> therefore I went ahead writing a Windows only plugin using QGIS 2.18.x and
> the non-QGIS Python dependencies of rasterio, Fiona, geopandas and our
> pyprecag package.
>
> The majority of our users are Windows users and are the likes of Farmers
> and Ag consultants with no programming experience and very little QGIS
> experience which also led to the decision of making PAT a Windows only
> plugin. I have developed a series of dependency checks based on the Windows
> environment and create a Windows batchfile that the user can launch to
> install the Python dependencies correctly for use with QGIS.
>
> On uploading to the QGIS repository I have been advised by @pcav (see
> https://github.com/CSIRO-Precision-Agriculture/PAT_QGIS_Plugin/issues/7 )
> that PAT must support Linux and OSX operating environments. I have had a
> look on https://plugins.qgis.org/ and I cannot find where this is listed
> in bullet points under *how to add your plugin to this repository* as a
> requirement for the approval of plugins. @pcav advised that I email this
> list regarding this issue.
>
> Is it acceptable to add a line in the metadata.txt file clearly pointing
> out that this plugin is to be used in Windows only and will it still be
> approved for the QGIS plugin repository?
>
> If not what are my options?
> Are there any guides on how to best setup and test QGIS plugins for Linux
> and OSX environments? I only have access to Windows at the moment and I am
> a novice at Python programming in these other environments.
>
>


Hi Christina,

I'm not sure if I get your questions right, but one of the best things of
Python is that is very portable across different operating systems, if you
want to set up a testing environment for your plugins you could start with
a Linux Ubuntu 18.04 virtual machine and install QGIS inside it.



-- 
Alessandro Pasotti
w3:   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] Jupyter Console Plugin for QGIS?

[Alessandro Pasotti]

Stefan,

this is actually a very good idea, I've started something similar a few
years ago, but its scope was limited to embedding the IPython console
inside QGIS, the plugin is available here:
https://plugins.qgis.org/plugins/IPyConsole/

It is based on QtConsole.

Perhaps it could be a starting point, IIRC Luigi also explored this
possibility while we were working together in Boundless.




On Thu, Jan 31, 2019 at 8:11 PM Stefan Keller  wrote:

> Hi,
>
> August 2017 Tim S. blogged about "Plotting the future of QGIS" [1] and
> mentioned as no. 1. "We need to beef up the analytical capabilities in
> QGIS". There he asked "why not provide both a Jupyter Notebook"
> embedded into QGIS and pointed to options to integrate the Jupyter Qt
> console [2]. QGIS/Jupyter integration has been mentioned 2017 as
> possible GSoC but then can't see other activities.
>
> So what is your opinion about writing a QGIS Python Plugin which
> allows to run Python notebooks an accesses the QGIS processing power
> (e.g. using Qt's  RichJupyterWidget).
>
> Any developments or thoughts on this?
>
> :Stefan
>
> [1] https://blog.qgis.org/2017/08/25/plotting-the-future-of-qgis/
> [2]
> https://qtconsole.readthedocs.io/en/stable/#embedding-the-qtconsole-in-a-qt-application
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] stronger minor version parsing is required inside GeoNode request

[Alessandro Pasotti]

We are not using  trac anymore, here is the current issues website:
https://issues.qgis.org/

You need an OSGEO id to log in.



On Fri, Jan 25, 2019 at 11:13 AM G. Allegri  wrote:

> I would like but my trac account is not allowed to open tickets anymore.
> Don't know why and I don't know who I should ask :)
>
> Giovanni
>
> Il giorno ven 25 gen 2019 alle ore 11:10 Alessandro Pasotti <
> apaso...@gmail.com> ha scritto:
>
>> Giovanni,
>>
>> can you please file a ticket?
>>
>> On Fri, Jan 25, 2019 at 11:06 AM G. Allegri  wrote:
>>
>>> Currently QGIS parses GeoNode's version with a simple .toInt():
>>> https://github.com/qgis/QGIS/blob/master/src/core/geocms/geonode/qgsgeonoderequest.cpp#L275
>>> but GeoNode adds more informations to the minor version, for instance
>>> "rc" for a release candidate. This makes the parsing fail and thus layers
>>> are not fetched.
>>>
>>> As an example look at the "geonode_version" field on the master demo
>>> instance: http://master.demo.geonode.org/api/layers/
>>>
>>> Probably a regex should be used to extract only the first numbers from
>>> the minor version part.
>>>
>>> Best,
>>> Giovanni
>>> ___
>>> 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
>>
>>
>>
>> --
>> Alessandro Pasotti
>> w3:   www.itopen.it
>>
>

-- 
Alessandro Pasotti
w3:   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] stronger minor version parsing is required inside GeoNode request

[Alessandro Pasotti]

Giovanni,

can you please file a ticket?

On Fri, Jan 25, 2019 at 11:06 AM G. Allegri  wrote:

> Currently QGIS parses GeoNode's version with a simple .toInt():
> https://github.com/qgis/QGIS/blob/master/src/core/geocms/geonode/qgsgeonoderequest.cpp#L275
> but GeoNode adds more informations to the minor version, for instance "rc"
> for a release candidate. This makes the parsing fail and thus layers are
> not fetched.
>
> As an example look at the "geonode_version" field on the master demo
> instance: http://master.demo.geonode.org/api/layers/
>
> Probably a regex should be used to extract only the first numbers from the
> minor version part.
>
> Best,
> Giovanni
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] WFS and NULL values

[Alessandro Pasotti]

Correct,  thanks for pointing that out!

On Wed, Jan 23, 2019 at 11:45 AM Even Rouault 
wrote:

> On mercredi 23 janvier 2019 11:42:19 CET Alessandro Pasotti wrote:
> > Thanks for all the comments!
> >
> > I understand that it depends on the schema, what confuses me is the
> > assertion by Andrea in the (quite old) cited email that  "GML and WFS
> > explicitly avoid the use of "xs:nil", I could not find any authoritative
> > support for that claim.
> >
> > So, if that is not the case, we should probably fix QGIS Server's
> > DescribeFeatureType to return something like this (for a nillable
> element):
> >
> > 
> >
> > And for the getFeature response, in case the value is NULL:
> >
> > 
>
> If you want to be able to set xsi:nil="true", the XSD element declaration
> must
> have the nillable="true" attribute.
> minOccurs="0" is to allow the element to be completely absent.
>
> >
> > How does it sounds?
> >
> >
> > On Wed, Jan 23, 2019 at 11:02 AM Even Rouault <
> even.roua...@spatialys.com>
> >
> > wrote:
> > > Recent versions of OGR make a difference between :
> > >
> > > - a missing XML element, that will be represented in OGR as a "unset
> > > field")
> > > (allowed if the schema has minOccurs="0")
> > > - and a XML element set to , that will be
> represented
> > > in
> > > OGR as a NULL field value (allowed if the schema has nillable="true")
> > >
> > > ( see https://trac.osgeo.org/gdal/wiki/rfc67_nullfieldvalues )
> > >
> > > The same for JSon actually, between a property that doesn't appear at
> all,
> > > or
> > > which is set to null.
> > >
> > > Example, given foo.json with
> > >
> > > { "type": "FeatureCollection",
> > >
> > >   "features": [
> > >
> > > { "type": "Feature", "properties": { "a": 1, "null_prop": null },
> > >
> > > "geometry": null },
> > >
> > > { "type": "Feature", "properties": { "b": 2 }, "geometry": null }
> > >
> > >   ]
> > >
> > > }
> > >
> > > $ ogr2ogr foo.gml foo.json -f gml
> > >
> > > $ cat foo.gml
> > > 
> > >  > >
> > >  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> > >  xsi:schemaLocation="http://ogr.maptools.org/ foo.xsd"
> > >  xmlns:ogr="http://ogr.maptools.org/;
> > >  xmlns:gml="http://www.opengis.net/gml;>
> > >
> > >   missing
> > >
> > >   
> > >
> > > 
> > >
> > >   1
> > >   
> > >
> > > 
> > >
> > >   
> > >   
> > >
> > > 
> > >
> > >   2
> > >
> > > 
> > >
> > >   
> > >
> > > 
> > >
> > > $ ogr2ogr out.json foo.gml
> > >
> > > $ ogrinfo foo.gml -al
> > > INFO: Open of `foo.gml'
> > >
> > >   using driver `GML' successful.
> > >
> > > Layer name: foo
> > > Geometry: Unknown (any)
> > > Feature Count: 2
> > > Layer SRS WKT:
> > > (unknown)
> > > Geometry Column = geometryProperty
> > > fid: String (0.0) NOT NULL
> > > a: Integer (16.0)
> > > null_prop: String (0.0)
> > > b: Integer (16.0)
> > > OGRFeature(foo):0
> > >
> > >   fid (String) = foo.0
> > >   a (Integer) = 1
> > >   null_prop (String) = (null)
> > >
> > > OGRFeature(foo):1
> > >
> > >   fid (String) = foo.1
> > >   b (Integer) = 2
> > >
> > > And yes this is not WFS or GML specific, but XML + XML-Schema generic.
> > >
> > > --
> > > Spatialys - Geospatial professional services
> > > http://www.spatialys.com
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>


-- 
Alessandro Pasotti
w3:   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] WFS and NULL values

[Alessandro Pasotti]

Thanks for all the comments!

I understand that it depends on the schema, what confuses me is the
assertion by Andrea in the (quite old) cited email that  "GML and WFS
explicitly avoid the use of "xs:nil", I could not find any authoritative
support for that claim.

So, if that is not the case, we should probably fix QGIS Server's
DescribeFeatureType to return something like this (for a nillable element):



And for the getFeature response, in case the value is NULL:



How does it sounds?


On Wed, Jan 23, 2019 at 11:02 AM Even Rouault 
wrote:

> Recent versions of OGR make a difference between :
>
> - a missing XML element, that will be represented in OGR as a "unset
> field")
> (allowed if the schema has minOccurs="0")
> - and a XML element set to , that will be represented
> in
> OGR as a NULL field value (allowed if the schema has nillable="true")
>
> ( see https://trac.osgeo.org/gdal/wiki/rfc67_nullfieldvalues )
>
> The same for JSon actually, between a property that doesn't appear at all,
> or
> which is set to null.
>
> Example, given foo.json with
>
> { "type": "FeatureCollection",
>   "features": [
> { "type": "Feature", "properties": { "a": 1, "null_prop": null },
> "geometry": null },
> { "type": "Feature", "properties": { "b": 2 }, "geometry": null }
>   ]
> }
>
> $ ogr2ogr foo.gml foo.json -f gml
>
> $ cat foo.gml
> 
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://ogr.maptools.org/ foo.xsd"
>  xmlns:ogr="http://ogr.maptools.org/;
>  xmlns:gml="http://www.opengis.net/gml;>
>   missing
>
>   
> 
>   1
>   
> 
>   
>   
> 
>   2
> 
>   
> 
>
> $ ogr2ogr out.json foo.gml
>
> $ ogrinfo foo.gml -al
> INFO: Open of `foo.gml'
>   using driver `GML' successful.
>
> Layer name: foo
> Geometry: Unknown (any)
> Feature Count: 2
> Layer SRS WKT:
> (unknown)
> Geometry Column = geometryProperty
> fid: String (0.0) NOT NULL
> a: Integer (16.0)
> null_prop: String (0.0)
> b: Integer (16.0)
> OGRFeature(foo):0
>   fid (String) = foo.0
>   a (Integer) = 1
>   null_prop (String) = (null)
>
> OGRFeature(foo):1
>   fid (String) = foo.1
>   b (Integer) = 2
>
>
> And yes this is not WFS or GML specific, but XML + XML-Schema generic.
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>


-- 
Alessandro Pasotti
w3:   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] WFS and NULL values

[Alessandro Pasotti]

On Wed, Jan 23, 2019 at 9:31 AM René-Luc Dhont  wrote:

> Hi Allessandro,
>
> Do you speak about these PR:
> * https://github.com/qgis/QGIS/pull/8536 [Server] Null field value in GML
> has to be empty string 2.18
> * https://github.com/qgis/QGIS/pull/8537 [Server][WFS] Null field value
> in GML has to be empty string 3.4
>
> I don't think it is a GML specific issue, but something about XSD and XML.
>

Hi René-Luc,

thank you for you reply,

no, I'm talking about this:

image you have a field named "typ" with a NULL value, the XML should not
contain that value at all, currently we get this:

22Oebisfelder
Straße

while I think that we should get that:

22Oebisfelder Straße

In other words: if a field is NULL it should not be empty but completely
omitted from the resulting GML (I suppose this is to make a difference
between empty and null in case of not-numeric fields).



>
> Regards,
> René-Luc
>
> Le 23/01/2019 à 09:14, Paul Blottiere a écrit :
>
> Hi Alessandro,
>
> > If it is a bug I can work on the fix, but maybe I'm missing something.
>
> Have you taken a look to the compliance OGC tests for WFS 1.X? If there's
> tests about this particular point, we'll know for sure if it's something to
> fix.
>
> Regards.
>
> Paul
>
> Le mar. 22 janv. 2019 à 17:51, Alessandro Pasotti  a
> écrit :
>
>> Hi all,
>>
>> while working on QGIS server I noticed that WFS GetFeature returns NULL
>> values as empty tags while according to the majority of the sources I've
>> found it should not include it in the XML response (GML2 at least, I'm not
>> sure about GML3 yet).
>>
>> If it is a bug I can work on the fix, but maybe I'm missing something.
>>
>> See:
>> http://osgeo-org.1560.x6.nabble.com/Why-the-WFS-does-not-return-the-NULL-value-field-td3802398.html
>>
>> apparently this is also what geoserver does.
>>
>> Any opinion?
>>
>> --
>> Alessandro Pasotti
>> w3:   www.itopen.it
>>
>
>

-- 
Alessandro Pasotti
w3:   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] WFS and NULL values

[Alessandro Pasotti]

No, I haven't, thanks for pointing that out

I'm looking now at http://test.qgis.org/ogc_cite/wfs_110/latest/report.html
but I can't find the test about NULL values, do you remember exactly where
it is?


On Wed, Jan 23, 2019 at 9:15 AM Paul Blottiere 
wrote:

> Hi Alessandro,
>
> > If it is a bug I can work on the fix, but maybe I'm missing something.
>
> Have you taken a look to the compliance OGC tests for WFS 1.X? If there's
> tests about this particular point, we'll know for sure if it's something to
> fix.
>
> Regards.
>
> Paul
>
> Le mar. 22 janv. 2019 à 17:51, Alessandro Pasotti  a
> écrit :
>
>> Hi all,
>>
>> while working on QGIS server I noticed that WFS GetFeature returns NULL
>> values as empty tags while according to the majority of the sources I've
>> found it should not include it in the XML response (GML2 at least, I'm not
>> sure about GML3 yet).
>>
>> If it is a bug I can work on the fix, but maybe I'm missing something.
>>
>> See:
>> http://osgeo-org.1560.x6.nabble.com/Why-the-WFS-does-not-return-the-NULL-value-field-td3802398.html
>>
>> apparently this is also what geoserver does.
>>
>> Any opinion?
>>
>> --
>> Alessandro Pasotti
>> w3:   www.itopen.it
>>
>

-- 
Alessandro Pasotti
w3:   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

[QGIS-Developer] WFS and NULL values

[Alessandro Pasotti]

Hi all,

while working on QGIS server I noticed that WFS GetFeature returns NULL
values as empty tags while according to the majority of the sources I've
found it should not include it in the XML response (GML2 at least, I'm not
sure about GML3 yet).

If it is a bug I can work on the fix, but maybe I'm missing something.

See:
http://osgeo-org.1560.x6.nabble.com/Why-the-WFS-does-not-return-the-NULL-value-field-td3802398.html

apparently this is also what geoserver does.

Any opinion?

-- 
Alessandro Pasotti
w3:   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] connecting to QgsNetworkAccessManagers signals

[Alessandro Pasotti]

Nice plugin though!

Try this: https://termbin.com/3y60

On Sat, Jan 19, 2019 at 3:51 PM Richard Duivenvoorde 
wrote:

> On 1/18/19 10:56 PM, Nyall Dawson wrote:
> > On Fri, 18 Jan 2019 at 21:19, Richard Duivenvoorde 
> wrote:
> >>
> >> On 1/18/19 12:13 PM, Alessandro Pasotti wrote:
> >>
> >>> I didn't look at the code but maybe it's because the NAM instance is
> >>> per-thread and WMS/WFS downloaders run within threads.
> >>
> >> Yeah, that is what I'm afraid of...
> >> I just do QgsNetworkAccessManager.instance() which get's it from current
> >> thread.
> >>
> >> And (from what I understand) most providers do not keep an handle to
> >> some NAM :-(
> >>
> >> There is no way to QgsNetworkAccessManager what instances are running in
> >> different threads?
> >
> > It'd need to be a change made in the core code -- the signals from the
> > background threads would need to be "bubbled up" to the main thread
> > instance of the manager.
>
> Meaning (?), that wherever now a signal of the nam
> (NetworkAccessManager) is connected to some local method, it is also to
> be connected to the nam of the parent/application thread?
>
> I had a look into some providers, but do not understand where this
> connection between signals is to be made?
>
> Is it in the application main thread when you create some
> downloader-class that you add some extra 'connect'-calls?
>
> Or is it in the downloader-class that you can fetch the
> parent/application thread and then get the nam-instance from there and
> do the connection?
>
> Or should I not even try :-)
>
> Regards,
>
> Richard Duivenvoorde
>
> _______
> 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



-- 
Alessandro Pasotti
w3:   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] documentation rules (was [qgis/QGIS-Enhancement-Proposals] Translation of .qgs project files (#90))

[Alessandro Pasotti]

On Fri, Jan 18, 2019 at 10:58 PM Nyall Dawson 
wrote:

> On Thu, 17 Jan 2019 at 17:15, Paolo Cavallini 
> wrote:
> >
> > Hi all
> >
> > On 16/01/19 23:42, Nyall Dawson wrote:
> >
> > > So again, I'm +1 to the policy, but only if it's enforced
> > > automatically on Travis by an appropriate meta unit test.
> >
> > agreed
> >
> > > I think we could do this by some rules like:
> > > - if a commit message has [feature] or [needs-docs], then the body of
> > > the message must contain at least 200(?) characters OR contain a link
> > > to a PR on the documentation repo (detected via regex)
> > > - feature commits must also contain a link to an image/video/blogpost
> > > illustrating the feature (the test would just check to ensure that
> > > there's at least one http(s):// link in the commit body). We can add a
> > > specific [no-pic] tag for features which explicitly DON'T need a
> > > picture (e.g. API feature additions, server specific features which
> > > don't have any user-facing UI changes)
> > I'd prefer having all the material in the manual. external links can
> > break anytime, and after a while we'll end up with lots of dead links.
>
> But we aren't requiring that the code PR comes with a documentation
> PR, are we? I was thinking more that if the original code commit has a
> link to a blog post, the documentation team would have a detailed
> write up (likely with pictures) which they could use as a basis for
> the actual QGIS documentation to be written from.
>
> Nyall
>
>

Yes, I think we developer should provide the documentation in any form
(text in the code PRs, blog posts, links to emails, QEP, whatever works
best).

The important part is that the source material for the documentation
writers must be easily available somewhere.


-- 
Alessandro Pasotti
w3:   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] connecting to QgsNetworkAccessManagers signals

[Alessandro Pasotti]

On Fri, Jan 18, 2019 at 12:10 PM Richard Duivenvoorde 
wrote:

> Hi Devs,
>
> I'm doing a simple small proof of concept of a minimal plugin which
> connects to the QgsNetworkAccesManager.instance()'s signals to log the
> requests that are fired and show them in de message panel.
>
> https://github.com/rduivenvoorde/qgisnetworklogger
>
> This is going fine for wms and wfs requests or python stuff which uses
> the same instance.
>
> But other parts of QGIS apparently use another instances?
> Or can there another reason I do not connect to their signals?
>

> Eg for a WMS I see the GetCapabilities en GetLegendGraphic, but not the
> actual WMS requests, while you can see them in the debug messages if you
> have debug enabled.
>
> Same with WFS and WMTS tile requests.
>

I didn't look at the code but maybe it's because the NAM instance is
per-thread and WMS/WFS downloaders run within threads.

-- 
Alessandro Pasotti
w3:   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] confirmation message after plugin upload

[Alessandro Pasotti]

Did you check if a plugin with the same name already exists?


On Wed, Jan 16, 2019 at 11:21 PM Alessandro Cristofori 
wrote:

> Hello,
> I have just uploaded to the QGIS plugin repository my first plug-in.
>
> After having read all the documentation, provided a LICENSE a README and
> having filled the metadata.txt file I zipped it and uploaded via the upload
> page.
>
> As a confirmation I get a white page that says "You cannot modify this
> plugin". White page with just a just this message on top.
>
> Does this mean that the upload was successful or not? And if not, what
> could I do to upload a plugin correctly?
>
> Thanks
>
> Alessandro
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Fwd: [qgis/QGIS-Enhancement-Proposals] Translation of .qgs project files (#90)

[Alessandro Pasotti]

My 2 quick cents:

1 - new features or significant changes to existing features *must* provide
a description of the feature/changes or a link to it in some form (a QEP,
the PR text, a blog post an extensive commit message etc., suitable for
copy-paste into the documentation)
2 - little documentation is better than no documentation at all. I suggest
that the documentation team be less strict in accepting PRs and lower the
bar: we/they can always make it better later
3 - (speaking about the server) consider the audience: we do not need/want
to document the standard apache/nginx/fcgi/mod_rewrite/whatever web-server
setup, but we may provide pointers to upstream documentation



On Wed, Jan 16, 2019 at 5:48 PM Matteo Ghetta 
wrote:

> Fully agreed with all the comments.
>
> What are devs thoughts? ;)
>
> Cheers
>
> 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



-- 
Alessandro Pasotti
w3:   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] Is it just me, or is sip totally broken?

[Alessandro Pasotti]

It's not just you, this is what I see when running your code:


WTFFF!!!



Found PyQt5 version: 5.11.2

Found SIP version: 4.19.13




On Thu, Jan 3, 2019 at 8:19 AM Nyall Dawson  wrote:

> Hi list,
>
> I'm at my wits end here, fighting with a sip issue I can't solve. And
> honestly, I'm starting to think maybe there's something completely
> broken in sip. (Or at least, in the version 4.19.7 provided by my
> distro).
>
> Here's what I'm currently hitting:
>
> The validity check registry added this week has a method "addCheck",
> which transfers ownership of the check to c++:
>
> void addCheck( QgsAbstractValidityCheck *check SIP_TRANSFER );
>
> https://github.com/qgis/QGIS/blob/master/src/core/validity/qgsvaliditycheckregistry.h#L65
>
> But if I make a Python subclass of QgsAbstractValidityCheck, and add
> it to the registry, it's immediately garbage collected by Python!
>
> My test code looks like this:
>
> class LayoutMapCrsCheck(QgsAbstractValidityCheck):
>
> def __del__(self):
> print('WTFFF!!!')
>
> def id(self):
> return 'map_crs_check'
>
> def checkType(self):
> return QgsAbstractValidityCheck.TypeLayoutCheck
>
> def prepareCheck(self,context, feedback):
> return True
>
> def runCheck(self,context, feedback):
> return []
>
> def add_check():
> QgsApplication.validityCheckRegistry().addCheck(LayoutMapCrsCheck())
>
> add_check()
>
>
> So I create a Python subclass of the interface, and then add it to the
> registry. And boom - it's immediately deleted.
>
> If I make a global copy of the check, and then add to the registry,
> everything works -- the check isn't garbage collected.
>
> check_instance = LayoutMapCrsCheck()
> QgsApplication.validityCheckRegistry().addCheck(check_instance)
>
> But this leads me to believe that sip is broken somewhere, and is
> ignoring the /Transfer/ annotation.
>
> Indeed - I've also seen this in other classes. Specifically
> QgsTaskManager.addTask() -- Python tasks must be stored globally in
> order to avoid them being immediately deleted too.
>
> Can anyone else reproduce using my above code? Does anyone have any
> ideas what's happening here?
>
> 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



-- 
Alessandro Pasotti
w3:   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] QGIS Plugin download information

[Alessandro Pasotti]

No, sorry but there's no such information.

There are of course raw server logs but they aren't public.

On Mon, Dec 24, 2018, 10:23 shiva reddy  Dear QGIS Developers,
>
> As a plugin developer, one may be curious to understand at what places
> his/her plugin is being used/downloaded.
>
> Does QGIS have any such tool or site where such information can be seen?
> If not directly, how to access by using API (if available)?
>
> I hope I made my requirement clear.
>
> Thanks & Regards
> Shiva Reddy K.
> Scientist/Engineer 'SD'
> Indian Institute of Remote Sensing,
> Indian Space Research Organisation
> Department of Space
> 4-Kalidas Road
> Dehradun
> mobile: 0135-2524126
> ___
> 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] debug build - DPI assertion fails in qgsmaprenderercustompainterjob.cpp

[Alessandro Pasotti]

What about rounding and comparing integers?

On Thu, Dec 20, 2018 at 2:38 PM Jonas  wrote:

> Hi,
>
> leaving this here, because it happens just in Debug builds:
>
> the assertion in qgsmaprenderercustompainterjob.cpp/line 73 fails on my
> non-retina Mac Book Air when i change the magnification by locking the
> scale and using the trackpad to zoom. changing magnification via the
> spinner-box is just fine.
>
> the assertion check is only enabled in debug builds ( #ifndef QT_NO_DEBUG
> ) so i didn’t want to file a bug report, just FYI.
>
> log output is:
> src/gui/qgsmapcanvas.cpp: 1588: (wheelEvent) [3ms] Wheel event delta 2
> src/core/qgsmapsettings.cpp: 63: (setMagnificationFactor) [0ms]
> Magnification factor: 1.52486 dpi: 109.79 ratio: 0.983607
> src/gui/qgsmapcanvas.cpp: 514: (refresh) [0ms] CANVAS refresh scheduling
> src/gui/qgsmapcanvas.cpp: 732: (stopRendering) [11ms] CANVAS stop
> rendering!
> src/core/qgsmaprendererparalleljob.cpp: 115: (cancelWithoutBlocking) [0ms]
> PARALLEL cancel at status 1
> src/core/qgsvectorlayerrenderer.cpp: 270: (drawRenderer) [0ms]
> [thread:0x7fe3ab038820] Drawing of vector layer
> Ortsteile_Berlin_3808bce3_0433_4bd1_ab94_24c1a4c2b617 canceled.
> src/core/qgsmaprendererparalleljob.cpp: 64: (start) [2ms] QThreadPool max
> thread count is 4
> src/core/qgsmaprendererparalleljob.cpp: 222: (renderingFinished) [0ms]
> PARALLEL finished
> src/gui/qgsmapcanvas.cpp: 1588: (wheelEvent) [18ms] Wheel event delta 2
> src/core/qgsmapsettings.cpp: 63: (setMagnificationFactor) [0ms]
> Magnification factor: 1.55027 dpi: 111.62 ratio: 0.983607
> src/gui/qgsmapcanvas.cpp: 514: (refresh) [0ms] CANVAS refresh scheduling
> src/gui/qgsmapcanvas.cpp: 732: (stopRendering) [2ms] CANVAS stop rendering!
> src/core/qgsmaprendererparalleljob.cpp: 115: (cancelWithoutBlocking) [0ms]
> PARALLEL cancel at status 1
> src/core/qgsvectorlayerrenderer.cpp: 270: (drawRenderer) [0ms]
> [thread:0x7fe3ab22a850] Drawing of vector layer
> Ortsteile_Berlin_3808bce3_0433_4bd1_ab94_24c1a4c2b617 canceled.
> src/core/qgsmaprendererparalleljob.cpp: 64: (start) [3ms] QThreadPool max
> thread count is 4
> src/core/qgsmaprendererparalleljob.cpp: 222: (renderingFinished) [0ms]
> PARALLEL finished
> src/core/qgsmaprendererparalleljob.cpp: 201: (renderLayersFinished) [67ms]
> PARALLEL layers finished
> src/core/qgsmaprenderercustompainterjob.cpp: 345: (drawLabeling) [1ms]
> [thread:0x7fe3ab263850] Draw labeling took (seconds): 0
> src/core/qgsmaprendererparalleljob.cpp: 222: (renderingFinished) [2ms]
> PARALLEL finished
> src/core/qgsmaprendererjob.cpp: 439: (cleanupLabelJob) [0ms] caching label
> result image
> src/gui/qgsmapcanvas.cpp: 600: (rendererJobFinished) [0ms] CANVAS finish! 1
> src/gui/qgsmapcanvas.cpp: 1588: (wheelEvent) [30ms] Wheel event delta 2
> src/gui/qgsmapcanvas.cpp: 1588: (wheelEvent) [8ms] Wheel event delta 0
> src/gui/qgsmapcanvas.cpp: 1588: (wheelEvent) [0ms] Wheel event delta 0
> Fatal: ASSERT failure in Job::startRender(): "pre-set DPI not equal to
> painter's DPI (112 vs 111.62)", file
> src/core/qgsmaprenderercustompainterjob.cpp, line 73
> 14:24:25: The program has unexpectedly finished.
>
>
> thanks
> Jonas
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Sometimes qgz files opens just as a completely blank project

[Alessandro Pasotti]

The file opens without issues on QGIS master (Linux).

Please try to rename the project using only ASCII characters and see if
that helps.

In any event, please file a ticket attaching the project files (after
checking for duplicate tickets).

Kind regards.

On Fri, Dec 14, 2018 at 8:07 PM magerlin  wrote:

> I have several times encountered that when I reopen a QGIS3 project
> previously stored as a QGZ file it just shows a completely blank project
> (and no kind of error messages).
>
> I can then use 7zip to unzip the qgz file and extract a fully functional
> qgs
> file showing my whole project as it should look  :-)
>
> An example of a qgz files showing a blank project is here:
>
> Knudepunkter_ogt_påstigere_v3.qgz
> <
> http://osgeo-org.1560.x6.nabble.com/file/t202356/Knudepunkter_ogt_p%C3%A5stigere_v3.qgz>
>
>
> and when I unzip it with 7zip I get this fully functional qgs file:
>
> Knudepunkter_ogt_påstigere_v3.qgs
> <
> http://osgeo-org.1560.x6.nabble.com/file/t202356/Knudepunkter_ogt_p%C3%A5stigere_v3.qgs>
>
>
>
>
> -
> Regards Morten
>
> Currently using Qgis 2.18.23 (OSGeo4) and Qgis 3.4.2 in parallel
> Windows 7, 64bit
> --
> Sent from:
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Plugins website

[Alessandro Pasotti]

On Thu, Dec 13, 2018 at 11:10 AM Richard Duivenvoorde 
wrote:

> On 12/13/18 10:56 AM, Michel Stuyts wrote:
> > The plugins website https://plugins.qgis.org/ can’t find the Bootstrap
> > files (bootsrap.min.css, bootstrap-responsive.min.css,
> > bootstrap.min.js).  It makes some parts of the webpage show up on wrong
> > places. The same happens on all subpages.
>
> Seems ok to me, as in I do not see missing resources in webdeveloper
> console?
>
>

It's not ok, this gives 404 for me too:
https://plugins.qgis.org/static/bootstrap/js/bootstrap.min.js


-- 
Alessandro Pasotti
w3:   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] unable to build MacOS master (OpenCL)

[Alessandro Pasotti]

On Mon, Dec 3, 2018 at 9:43 AM Peter Petrik <
peter.pet...@lutraconsulting.co.uk> wrote:

> Looks like 1.2 (compiled
> https://github.com/yohanesgultom/parallel-programming-assignment/blob/master/PR2/opencl/device_query.c
> )
>


So, please try to #ifdef for mac and set

#define CL_HPP_MINIMUM_OPENCL_VERSION 120
#define CL_HPP_TARGET_OPENCL_VERSION 120
#define CL_TARGET_OPENCL_VERSION 120

if that doesn't work, try with 110 instead of 120.

You can run an OpenCL smoke test by enabling it in the
options->acceleration and by using the hillshade renderer on a DEM raster
(also enable rendering debug log in options->rendering and you'll see in
the log is the hillshade is really using opencl).


Please let me know if this works for you.



>
> Platform - 1
>
>   1.1 CL_PLATFORM_NAME: Apple
>
>   1.2 CL_PLATFORM_VENDOR: Apple
>
>   1.3 CL_PLATFORM_VERSION: OpenCL 1.2 (Oct 11 2018 21:04:03)
>
>   1.4 CL_PLATFORM_PROFILE: FULL_PROFILE
>
>   1.5 CL_PLATFORM_EXTENSIONS: cl_APPLE_SetMemObjectDestructor
> cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names
> cl_APPLE_gl_sharing cl_khr_gl_event
>
>   Device - 1:
>
> CL_DEVICE_NAME: Intel(R) UHD Graphics 630
>
> CL_DEVICE_VENDOR: Intel Inc.
>
> CL_DRIVER_VERSION: 1.2(Oct 11 2018 20:55:51)
>
> CL_DEVICE_VERSION: OpenCL 1.2
>
> CL_DEVICE_MAX_COMPUTE_UNITS: 24
>
>   Device - 2:
>
> CL_DEVICE_NAME: AMD Radeon Pro 560X Compute Engine
>
> CL_DEVICE_VENDOR: AMD
>
> CL_DRIVER_VERSION: 1.2 (Oct 16 2018 21:18:14)
>
> CL_DEVICE_VERSION: OpenCL 1.2
>
> CL_DEVICE_MAX_COMPUTE_UNITS: 16
>
>
>
> On Mon, Dec 3, 2018 at 9:19 AM Alessandro Pasotti 
> wrote:
>
>> Hi Peter,
>>
>> the only change that come up to my mind is that we are now supporting
>> also opencl versions > 1.1,
>> can you please check what is the opencl version implemented on mac?
>>
>> It might be necessary to add a ifdef for mac to set
>>
>>
>> #define CL_HPP_MINIMUM_OPENCL_VERSION 110
>> #define CL_HPP_TARGET_OPENCL_VERSION 110
>> #define CL_TARGET_OPENCL_VERSION 110
>>
>> as it was before the changes.
>>
>>
>>
>> On Mon, Dec 3, 2018 at 9:02 AM Peter Petrik <
>> peter.pet...@lutraconsulting.co.uk> wrote:
>>
>>> Hi,
>>>
>>> I am unable to build QGIS master after Friday's changes in opencl
>>> header. Any idea if I can still use official MACOS CL headers or how to
>>> proceed?
>>>
>>> Thanks.
>>> Peter
>>>
>>> [ 19%] Building CXX object
>>> src/core/CMakeFiles/qgis_core.dir/geometry/qgsabstractgeometry.cpp.o
>>>
>>> In file included from
>>> /Users/peter/Projects/qgis1/QGIS/src/core/raster/qgshillshaderenderer.cpp:33:
>>>
>>> In file included from
>>> /Users/peter/Projects/qgis1/QGIS/src/core/qgsopenclutils.h:25:
>>>
>>> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
>>> error: use of undeclared identifier 'CL_DEVICE_QUEUE_ON_HOST_PROPERTIES'
>>>
>>> CL_HPP_PARAM_NAME_INFO_2_0_(CL_HPP_DECLARE_PARAM_TRAITS_)
>>>
>>> ^
>>>
>>> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1277:23:
>>> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>>>
>>> F(cl_device_info, CL_DEVICE_QUEUE_ON_HOST_PROPERTIES,
>>> cl_command_queue_properties) \
>>>
>>>   ^
>>>
>>> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
>>> error: use of undeclared identifier 'CL_DEVICE_QUEUE_ON_DEVICE_PROPERTIES'
>>>
>>> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1278:23:
>>> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>>>
>>> F(cl_device_info, CL_DEVICE_QUEUE_ON_DEVICE_PROPERTIES,
>>> cl_command_queue_properties) \
>>>
>>>   ^
>>>
>>> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
>>> error: use of undeclared identifier
>>> 'CL_DEVICE_QUEUE_ON_DEVICE_PREFERRED_SIZE'
>>>
>>> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1279:23:
>>> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>>>
>>> F(cl_device_info, CL_DEVICE_QUEUE_ON_DEVICE_PREFERRED_SIZE, cl_uint)
>>> \
>>>
>>>   ^
>>>
>>> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp

Re: [QGIS-Developer] unable to build MacOS master (OpenCL)

[Alessandro Pasotti]

fo, CL_DEVICE_PIPE_MAX_PACKET_SIZE, cl_uint) \
>
>   ^
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
> error: use of undeclared identifier 'CL_DEVICE_SVM_CAPABILITIES'
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1286:23:
> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>
> F(cl_device_info, CL_DEVICE_SVM_CAPABILITIES,
> cl_device_svm_capabilities) \
>
>   ^
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
> error: use of undeclared identifier
> 'CL_DEVICE_PREFERRED_PLATFORM_ATOMIC_ALIGNMENT'
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1287:23:
> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>
> F(cl_device_info, CL_DEVICE_PREFERRED_PLATFORM_ATOMIC_ALIGNMENT,
> cl_uint) \
>
>   ^
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
> error: use of undeclared identifier
> 'CL_DEVICE_PREFERRED_GLOBAL_ATOMIC_ALIGNMENT'
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1288:23:
> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>
> F(cl_device_info, CL_DEVICE_PREFERRED_GLOBAL_ATOMIC_ALIGNMENT,
> cl_uint) \
>
>   ^
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
> error: use of undeclared identifier
> 'CL_DEVICE_PREFERRED_LOCAL_ATOMIC_ALIGNMENT'
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1289:23:
> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>
> F(cl_device_info, CL_DEVICE_PREFERRED_LOCAL_ATOMIC_ALIGNMENT, cl_uint)
> \
>
>   ^
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
> error: use of undeclared identifier 'CL_QUEUE_SIZE'
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1290:30:
> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>
> F(cl_command_queue_info, CL_QUEUE_SIZE, cl_uint) \
>
>  ^
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
> error: use of undeclared identifier 'CL_MEM_USES_SVM_POINTER'
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1291:20:
> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>
> F(cl_mem_info, CL_MEM_USES_SVM_POINTER, cl_bool) \
>
>^
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
> error: use of undeclared identifier
> 'CL_PROGRAM_BUILD_GLOBAL_VARIABLE_TOTAL_SIZE'
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1292:30:
> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>
> F(cl_program_build_info, CL_PROGRAM_BUILD_GLOBAL_VARIABLE_TOTAL_SIZE,
> size_type) \
>
>  ^
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
> error: use of undeclared identifier 'CL_PIPE_PACKET_SIZE'
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1293:21:
> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>
> F(cl_pipe_info, CL_PIPE_PACKET_SIZE, cl_uint) \
>
> ^
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1323:1:
> error: use of undeclared identifier 'CL_PIPE_MAX_PACKETS'
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:1294:21:
> note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
>
> F(cl_pipe_info, CL_PIPE_MAX_PACKETS, cl_uint)
>
> ^
>
> /Users/peter/Projects/qgis1/QGIS/external/opencl-clhpp/include/CL/cl2.hpp:3293:16:
> error: unknown type name 'cl_svm_mem_flags'; did you mean 'cl_mem_flags'?
>
> static cl_svm_mem_flags getSVMMemFlags()
>
>^
>
> /System/Library/Frameworks/OpenCL.framework/Headers/cl.h:67:29: note:
> 'cl_mem_flags' declared here
>
> typedef cl_bitfield cl_mem_flags;
>
> ^
>
> fatal error: too many errors emitted, stopping now [-ferror-limit=]
>
> 20 errors generated.
>
> make[2]: ***
> [src/core/CMakeFiles/qgis_core.dir/raster/qgshillshaderenderer.cpp.o] Error
> 1
>
> make[2]: *** Waiting for unfinished jobs
>
> make[1]: *** [src/core/CMakeFiles/qgis_core.dir/all] Error 2
>
> make: *** [all] Error 2
> ___
> 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



-- 
Alessandro Pasotti
w3:   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

[QGIS-Developer] Fwd: Running QGIS Python tests inside a real QGIS application in Travis CI

[Alessandro Pasotti]

Re-sending, because apparently this email was not delivered, sorry if you
have got it already.


-- Forwarded message -
From: Alessandro Pasotti 
Date: Thu, Nov 22, 2018 at 9:09 AM
Subject: Running QGIS Python tests inside a real QGIS application in Travis
CI
To: QGIS Developer Mailing List 
Cc: , Larry Shaffer ,
Alex Neto , Victor Olaya 


Hi,

since all the pieces are now in place, I made a little experiment for
running Python tests inside QGIS on Travis and it seem to work well [1]

I don't think that we need to run **all** tests this way, but I believe
that for some tests that require the real iface and a real QGIS
application, this could be very useful.

I'm still waiting to hear from Boundless if they are willing to fund the
additional work required to fully integrate this new possibility in the
current testing workflow but I'd like to know your thoughts on this topic
before proceeding further.

I'm not sure what is the best way to integrate this in the current CMake
configuration, for example: should we create a CMake macro to add these
tests?

[1] https://travis-ci.org/qgis/QGIS/jobs/458107282#L1815

-- 
Alessandro Pasotti
w3:   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

[QGIS-Developer] Running QGIS Python tests inside a real QGIS application in Travis CI

[Alessandro Pasotti]

Hi,

since all the pieces are now in place, I made a little experiment for
running Python tests inside QGIS on Travis and it seem to work well [1]

I don't think that we need to run **all** tests this way, but I believe
that for some tests that require the real iface and a real QGIS
application, this could be very useful.

I'm still waiting to hear from Boundless if they are willing to fund the
additional work required to fully integrate this new possibility in the
current testing workflow but I'd like to know your thoughts on this topic
before proceeding further.

I'm not sure what is the best way to integrate this in the current CMake
configuration, for example: should we create a CMake macro to add these
tests?

[1] https://travis-ci.org/qgis/QGIS/jobs/458107282#L1815

-- 
Alessandro Pasotti
w3:   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] docker, PyQGIS, Travis failing on PR

[Alessandro Pasotti]

On Mon, Nov 19, 2018 at 11:20 AM Denis Rouzaud 
wrote:

>
> * PyQGIS
> The good part is that PyQGIS 3.4 is out https://qgis.org/pyqgis/3.4/ and
> that the build of the API is now fully working on Travis/Docker.
>
>
Hi Denis,

can you point me to the scripts that build the Python API documentation?

-- 
Alessandro Pasotti
w3:   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] docker, PyQGIS, Travis failing on PR

[Alessandro Pasotti]

Thank you for your great work Denis!

Would you please tell me when I can rebase and merge the backport for
https://github.com/qgis/QGIS/pull/8500 ?



On Mon, Nov 19, 2018 at 11:20 AM Denis Rouzaud 
wrote:

> Hi all,
>
> I have been working on small improvements on our CI lately. There have
> been some nice things coming, but also a few things failing this monday
> morning.
>
> * New docker images
> Since building the PyQGIS API docs requires very recent versions of libs,
> two docker images are now built. One based on Ubuntu Bionic where the tests
> run fine, and one on Ubuntu Cosmic where we can properly build the API docs.
> Added to this, Alessandro also modified the image built (master only for
> now) which now integrate QGIS itself. The idea behind this is to test
> plugin with a full QGIS running (and not only core libs as before).
>
> * Travis changes
> To achieve this, some builds were duplicated. I have reformatted a bit the
> files and this is hopefully a tiny bit clearer now (Docker images builds
> are explicitly declared in .travis.yml)
> The Docker credentials were saved in the Travis online config which
> apparently got overwritten by the new "env: global:" in the Travis file. I
> have now integrated the credentials in the file. PR were not supposed to
> push the base dependencies image to Docker hub this has been fixed.
>
> * PR failing
> You should now be able to retrigger the builds on your PR, this should not
> require a rebase.
>
> * PyQGIS
> The good part is that PyQGIS 3.4 is out https://qgis.org/pyqgis/3.4/ and
> that the build of the API is now fully working on Travis/Docker.
>
> Sorry for the mess this morning. I'll try to followup if there is any
> issue (not sure the login is fixed) but I will be offline often in the next
> 3 days.
>
> Thanks for your understanding!
> Denis
> --
>
> Denis Rouzaud
> de...@opengis.ch  
> +41 76 370 21 22
>
>
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Cannot load QGIS source code in QTCreator

[Alessandro Pasotti]

Hi Andrea,


sorry, I totally forgot about this:
https://github.com/elpaso/qgis-dev-vagrant

I did not use it after I created it, so YMMV.




On Wed, Nov 14, 2018 at 12:26 PM Andrea Aime 
wrote:

> Hi,
> I'm trying to load the master branch of QGIS into QTCreator following the
> instructions at
> https://www.qgis.org/it/site/getinvolved/development/qgisdevelopersguide/qtcreator.html
> Trying to load the CMakeLists.txt file fails immediately, and I get this
> in the console:
>
> Running "/usr/bin/cmake -E server --pipe=/tmp/cmake-TWdPXn/socket
> --experimental" in /home/aaime/tmp/qgis-build.
>
> CMake Project parsing failed.
>
> Parsing of CMake project failed: Connection to CMake server lost.
>
>
> I've only found this ticket searching the internet, unfortunately, it
> contains no workaround:
>
> https://bugreports.qt.io/browse/QTCREATORBUG-20972
>
>
> My environment is a Linux Mint 19, which should be based on Ubuntu Bionic
> (I've setup the dependencies as per docs on bionic distros).
>
>
> Does anyone know of workarounds to use QTCreator?
>
> Or, should I look at setting up using a different IDE?
>
>
> Cheers
>
> Andrea
>
>
> == GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Cannot load QGIS source code in QTCreator

[Alessandro Pasotti]

On Thu, Nov 15, 2018 at 10:09 AM Andrea Aime 
wrote:

> Thanks everybody for the followup! I'm answering this mail but I'll
> integrate comments about the others too.
>
> On Thu, Nov 15, 2018 at 8:26 AM Alessandro Pasotti 
> wrote:
>
>> Hi Andrea,
>>
>> I've never seen that particular error, I'd look into cmake installation
>> and/or version.
>>
>
> See below
>
>
>> The vast majority of QGIS C++ developers uses Qt Creator on a daily basis
>> on different platforms, what work for me here is:
>>
>> Ubuntu xenial
>>
>> QtCreator: 4.7.2 installed from https://www.qt.io/download
>> cmake version 3.10.2 self-built from sources
>> Qt 10.0.1 self-built from sources
>>
>> Notice that none of the above was installed with apt, the main reason is
>> that xenial is a little bit old, but IIRC that was also to avoid some
>> problems in the integration of the different components.
>>
>
> I see... on my machine I have everything installed from apt instead,
> versions are:
>
>- QT Creator 4.5.2
>- cmake 3.10.2
>- QT is 5.9.5 (you have QT 10 instead??)
>
>
You should be good with 5.9, I have several kits with different QT versions
in release or debug mode, this is the script I use to build them:
http://termbin.com/froy



>  In other comments I've been invited to build from sources using cmake,
> which I did, worked, but then trying to start qgis as built results in this:
>
> aaime@colossus ~/devel/qgis/build-master (master) $ export
> LD_LIBRARY_PATH=/home/aaime/apps/lib
>
>
[...]

You might need some more env vars, here is an example of a run script of
mines: http://termbin.com/us9x note that I never run make/ninja install but
I run everything directly from the output dir under the build dir.


> I'm starting to think I'd be better of using a virtual machine where one
> can do any custom setup required.
> Someone was hinting at a video showing how to do that, using a vagrant
> setup. Is the same also documented anywhere, like,
> in text form?
>
>
Not that I'm aware of, but depending on your needs, you might find it
useful a docker recipe to build qgis from sources:
https://github.com/qgis/QGIS/blob/master/.docker/qgis.dockerfile

Btw, a Vagrant recipe to build a QGIS development environment ready to go
would be IMO very welcome and would low barriers for new developers.

Cheers

--
Alessandro Pasotti
w3:   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] iOS prototyping

[Alessandro Pasotti]

On Fri, Nov 16, 2018 at 2:21 PM Matthias Kuhn  wrote:

> Am I too late for the party? Probably.
>
>
> An example: it should be possible to provide QGIS as a service via a
> remote desktop like cloud platform and change whatever you want without
> being forced to publish the source code with the current license (Note:
> I'm not a lawyer). At the same time it's really hard to distribute QGIS
> based public code to Apple tablets with the current license (Note: I'm
> not a lawyer). Personally I'd prefer things to be vice versa.
>

I'm not a lawyer either, but the GPL does not prevent SAAS, AGPL does.

-- 
Alessandro Pasotti
w3:   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] Cannot load QGIS source code in QTCreator

[Alessandro Pasotti]

On Wed, Nov 14, 2018 at 12:26 PM Andrea Aime 
wrote:

> Hi,
> I'm trying to load the master branch of QGIS into QTCreator following the
> instructions at
> https://www.qgis.org/it/site/getinvolved/development/qgisdevelopersguide/qtcreator.html
> Trying to load the CMakeLists.txt file fails immediately, and I get this
> in the console:
>
> Running "/usr/bin/cmake -E server --pipe=/tmp/cmake-TWdPXn/socket
> --experimental" in /home/aaime/tmp/qgis-build.
>
> CMake Project parsing failed.
>
> Parsing of CMake project failed: Connection to CMake server lost.
>
>
> I've only found this ticket searching the internet, unfortunately, it
> contains no workaround:
>
> https://bugreports.qt.io/browse/QTCREATORBUG-20972
>
>
> My environment is a Linux Mint 19, which should be based on Ubuntu Bionic
> (I've setup the dependencies as per docs on bionic distros).
>
>
> Does anyone know of workarounds to use QTCreator?
>
> Or, should I look at setting up using a different IDE?
>
>
> Cheers
>
> Andrea
>
>
> == GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead
>

Hi Andrea,

I've never seen that particular error, I'd look into cmake installation
and/or version.

The vast majority of QGIS C++ developers uses Qt Creator on a daily basis
on different platforms, what work for me here is:

Ubuntu xenial

QtCreator: 4.7.2 installed from https://www.qt.io/download
cmake version 3.10.2 self-built from sources
Qt 10.0.1 self-built from sources

Notice that none of the above was installed with apt, the main reason is
that xenial is a little bit old, but IIRC that was also to avoid some
problems in the integration of the different components.

I hope this helps.


Cheers

-- 
Alessandro Pasotti
w3:   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] QGIS Server WFS 2.18 unreliable?

[Alessandro Pasotti]

On Wed, Nov 14, 2018 at 5:15 PM Andreas Neumann  wrote:

> Hi,
>
> Just tried exporting the Postgis table with ogr2ogr to GML. It works fine
> without any issue. All characters and geom seem fine.
>
> Any ideas?
>
> Thanks,
>
> Andreas
>

Hi Andreas,

I would suggest to test with QGIS 3, if the issue remains, please file a
ticket attaching a sample of the failing data, if that's a crash (as I
think it is) it should be easy to debug.


-- 
Alessandro Pasotti
w3:   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] OpenCL support

[Alessandro Pasotti]

Hi Paolo,

this is enough for building with OpenCL support on Ubuntu (debian should be
the same):
apt-get install -y opencl-headers ocl-icd-libopencl1 ocl-icd-opencl-dev

To actually run OpenCL applications  you'll need also the runtime for your
graphic card or for your CPU (or for both), there are packages for Nvidia,
ATI/AMD and Intel.



On Sat, Nov 10, 2018 at 8:27 PM Daniele Viganò  wrote:

> Ciao Paolo,
>
> On Sat, Nov 10, 2018 at 7:22 PM Paolo Cavallini 
> wrote:
>
>>
>> I have installed:
>>
>> beignet-opencl-icd/testing,now 1.3.2-4 amd64 [installato]
>> ocl-icd-libopencl1/testing,now 2.2.12-1 amd64 [installato]
>> opencl-c-headers/testing,now 2.2~2018.05.14-gde26592-1 all [installato,
>> automatico]
>> opencl-clhpp-headers/testing,now 2.0.10+git12-g5dd8bb9-1 all
>> [installato, automatico]
>> opencl-headers/testing,now 2.2~2018.05.14-gde26592-1 all [installato]
>>
>
> I'm not a Debian/Ubuntu user, but I guess you are missing
> the *ocl-icd-opencl-dev* package.
>
> Cheers,
> Daniele
>
> --
> *Daniele Viganò*
> http://daniele.vigano.me
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] iOS prototyping

[Alessandro Pasotti]

On Fri, Nov 9, 2018 at 8:52 AM Nyall Dawson  wrote:

>
>
> Your concerns are very valid, but could we defer this to a different
> discussion? I really want to avoid this becoming an us-vs-apple/debate
> about the merit of specific licenses, and instead allow it to focus
> solely on the question: "should the qgis org, with all the checks and
> balances it has in place, have the power to relicense the QGIS
> codebase (or not)"?.
>
> Nyall
>
>
I'm -1 on this proposal, it's not that I don't trust the PSC (that have
always done an amazing job!),  but perhaps because I'm Italian, I never
fully trust the "government", to me the GPL license is like the
constitution and it's there to protect from the possible abuses from the
"government".

Also, I particularly didn't like the "(8. Replace existing code from any
non-signing contributors)", it sounds like "you don't like that? We don't
need you".

-- 
Alessandro Pasotti
w3:   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] is QGIS Server 3.4 working?

[Alessandro Pasotti]

On Fri, Nov 2, 2018 at 2:06 PM Andreas Neumann  wrote:

> Hi Giovanni,
>
> Glad it works on a new machine.
>
> But it shows, that to find out what is wrong with QGIS server, is often a
> difficult challenge.
>
> The error message
>
> error 500 ("End of script output before headers:
> qgis_mapserv.fcgi" in the Apache log)
>
tells you absolutely nothing what might be wrong with QGIS Server.
>
> Even experienced QGIS server users struggle with finding problems in QGIS
> server.
>
> If we could improve this situation about more meaningful error messages
> from QGIS server, it would be a big, big plus!
>
> Greetings,
>
> Andreas
>

This message does not come from QGIS but from the web server and it usually
means that QGIS crashed, there is no possibility to set an error message
from QGIS in that case.

-- 
Alessandro Pasotti
w3:   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] Early 3.4 point release?

[Alessandro Pasotti]

On Wed, Oct 31, 2018 at 11:48 AM Giovanni Manghi 
wrote:

> Hi Matthias,
>
> > > The problem here is the "known" part: if we had more testers on the
> > > nightlies during the two weeks before the release date, we would
> > > probably have catched some of these regression in time to fix them.
> >
> > Agreed, the more testing the better.
>
> serious manual/semi-automated testing (of most functionalities, on the
> 3 major platforms, using multiple type/versions of QGIS and endpoints,
> etc.) is a full time job, I know because  I was lucky enough to have
> done it for a year and half. Without this type of effort we will
> always rely on reports sent in by people that find issues here and
> there while doing their normal workflow, which is ok but also has a
> good chance of not finding a number of serious bugs.
>
> cheers!
>
> -- g --
>


Giovanni,

I'm not talking about the test cycles a company could run, but if we did a
call for testers and prepared a page with instructions, we may have had a
dedicated group of people (users) who is willing to help the QGIS project
running test cyles, and as I said, going through the current
lessons/tutorial may be sufficient.

So, the plan would be:
1. prepare a page about how to run tests (based on the lessons/tutorials)
2. ask the community via email, twitter, whatever, to join the effort of
running test cycles when the code freezes
3. before any new release GOTO 2

I don't know if that will work, but worth trying.

-- 
Alessandro Pasotti
w3:   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] Early 3.4 point release?

[Alessandro Pasotti]

On Wed, Oct 31, 2018 at 10:41 AM Giovanni Manghi 
wrote:

> > This code freeze period will need to be associated with a strict
> definition of "blocker issues" that really need to by adressed immediatly.
> This issue here is a great example of a valid blocker.
>
> big fan of the "no known regressions admitted", at least for LTR releases.
>

The problem here is the "known" part: if we had more testers on the
nightlies during the two weeks before the release date, we would probably
have catched some of these regression in time to fix them.

I think that it would be a good idea to create a group of volunteer
testers, like we have for translators, that can regularly run test cycles
(for example going through the tutorials that we already have).

We might want to introduce the concept of release candidate, in order to
have a stricter code freeze, and give the testers and translators some
amount of time for testing and translations, during this time only "real"
bug fixes should be allowed.

That said, I think that "release early release often" is still the best way
we can handle release cycles.

-- 
Alessandro Pasotti
w3:   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] MacOS packaging

[Alessandro Pasotti]

Hi Peter,

this is great news for Mac users!

I suggest you to get in touch with Larry Shaffer, if I'm not wrong he has
been doing some work on QGIS for conda recently, perhaps you could join
efforts.



On Fri, Oct 26, 2018 at 5:26 PM Peter Petrik <
peter.pet...@lutraconsulting.co.uk> wrote:

> Hello,
>
> we have been asked to create standalone QGIS package for MacOS. By
> standalone I mean that there will be a single package (.pkg) file that will
> be extracted to /Application folder and will contain all dependencies
> (GDAL, Python3, PyQT, Qt libraries, ...) and will be working without any
> additional installation steps (similar to any application you install via
> App Store).
>
> As there is no such open-sourced solution I could use or enhance, I
> started some prototyping here:
> https://github.com/lutraconsulting/qgis-mac-packager . I hope I can wrap
> the last bits next week and be able to produce QGIS 3.4 release and QGIS
> master nightlies on some Mac Cloud server. I used osgeo4mac homebrew for
> dependencies, since it looks like it is the most maintained package manager
> with osgeo libraries for MacOS. Usage of Conda packages could be better,
> but the number of downloads and the activity in any available repositories
> is not convincing.
>
> The aim is to eventually have QGIS bundled and shipped similar to Linux
> and Windows. Once we finish the work, we will send an email to the PSC and
> see if this is something they'd be happy to bring it under their umbrella.
>
> I am open to any suggestions or cooperation for either packaging or
> distribution. Feel free to
> write me PM or reply here. Thanks
>
> Now its time to celebrate new QGIS release during weekend!
>
> Cheers,
> Peter
>
> Note: CMAKE scripts try to achieve similar tasks (qgis/mac/cmake/*.in).
> But it seems to me that only bundling of Qt libraries is actively
> maintained [QGIS_MACAPP_BUNDLE=1]and bundling of rest of libs (gdal,
> libzip, geos, etc.. ) [QGIS_MACAPP_BUNDLE=2 and 3] is not
> implemented/maintained. Also I am not convinced that CMake scripting
> language is best tool for such task. (due to reconfiguration on change,
> syntax/readability compared to python, tools available for path handling,
> ...)
>
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] QGIS Server plugins and thread safety

[Alessandro Pasotti]

I would go for multiprocess and stick to a single thread per-process.

But David may have a better advice.

Btw, it's nice to see a use case for Python Vector data providers :)




On Thu, Oct 25, 2018 at 1:02 PM Radim Blazek  wrote:

> If we narrow down the environment to uWSGI (with multiple threads
> enabled) running a Python application, which means that more instances
> of the same application may run in threads but never at the same time
> due to Python GIL (if I understand it well), is it still a problem? If
> we ensure that there are no static variables and singletons used by
> QGIS server? Is it then a problem to create/delete QObject on a non
> main thread?
>
> Radim
> On Sun, Nov 19, 2017 at 5:39 PM Martin Dobias  wrote:
> >
> > Hi Alessandro
> >
> > On Sun, Nov 19, 2017 at 10:34 AM, Alessandro Pasotti 
> wrote:
> > > Hi,
> > >
> > > mi recent experiments with multi-threaded python wrappers for QGIS
> server
> > > showed a critical flaw in my original implementation of the server
> plugins.
> > >
> > > First, I want to stress that this is not a problem in FCGI server
> > > implementation but only if the server is used directly from python in a
> > > multi threaded server implementation.
> > >
> > > The problem is that the server interface that exposes the request
> handler is
> > > a static property of the interface, that is changed on every request.
> > > This means that there is a race condition in setting/accessing the
> handler
> > > from a plugin filter, and that a plugin filter might access to the
> handler
> > > for a wrong request.
> >
> > I think this is probably just the tip of the iceberg: most of the
> > classes in qgis_core are not thread-safe, and I believe the
> > implementation of server's services is not expected to be run in
> > multiple threads at once either. So even though things in theory could
> > work if requests are handled in multiple threads, most likely there
> > will be crashes. Even though map rendering was made to run safe in
> > multiple worker threads, there is still the assumption that the map
> > rendering is started from the main thread where all the objects live
> > (I'm talking about the QObject-based classes). Dealing with objects
> > like map layers or project in non-main thread is likely to end up
> > badly.
> >
> > I would say for now we should simply stick with handling only one
> > request per server process at a time - just like how it is done with
> > the FastCGI implementation.
> >
> > Cheers
> > Martin
> > ___
> > 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
>


-- 
Alessandro Pasotti
w3:   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] Python support still broken

[Alessandro Pasotti]

Sorry, I didn't notice the version of SIP, maybe you want to check this
too:
https://github.com/qgis/QGIS/commit/0fad3e5731b32680acab9a43b146c73f4e1dab6a#commitcomment-31023279

On Wed, Oct 24, 2018 at 12:44 PM Borys Jurgiel 
wrote:

> Hi,
>
> I can't run Python after recent changes with sip:
>
> Traceback (most recent call last):
>   File "", line 1, in
>   File
> "/home/borys/sources/qgis/build/output/python/qgis/core/__init__.py",
> line 27, in
> from qgis._core import *
> ModuleNotFoundError: No module named 'PyQt5.sip'
>
> For sure python/PyQt/PyQt5/sip.py is executed, the exception there is
> handled
> properly and the error occurs later. Honestly I'm a bit lost in the paths
> ;)
>
> Debian Buster
> sip 4.19.13
> python-pyqt5 5.11.3
>
> and Borys
>
>
>
>

-- 
Alessandro Pasotti
w3:   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] Python support still broken

[Alessandro Pasotti]

See: https://github.com/qgis/QGIS/pull/8301

On Wed, Oct 24, 2018 at 12:44 PM Borys Jurgiel 
wrote:

> Hi,
>
> I can't run Python after recent changes with sip:
>
> Traceback (most recent call last):
>   File "", line 1, in
>   File
> "/home/borys/sources/qgis/build/output/python/qgis/core/__init__.py",
> line 27, in
> from qgis._core import *
> ModuleNotFoundError: No module named 'PyQt5.sip'
>
> For sure python/PyQt/PyQt5/sip.py is executed, the exception there is
> handled
> properly and the error occurs later. Honestly I'm a bit lost in the paths
> ;)
>
> Debian Buster
> sip 4.19.13
> python-pyqt5 5.11.3
>
> and Borys
>
>
>
>

-- 
Alessandro Pasotti
w3:   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] Woohoo! Interactive Travis debugging

[Alessandro Pasotti]

Hi Nyall,

thanks for this useful information!

Do we have a place to store it? Developer docs maybe?



On Fri, Oct 12, 2018 at 1:20 AM Nyall Dawson  wrote:

> On Tue, 9 Oct 2018 at 19:18, Nyall Dawson  wrote:
> >
> > Hey all,
>
> >
> > #! /usr/bin/env bash
> >   curl -s -X POST \
> >-H "Content-Type: application/json" \
> >-H "Accept: application/json" \
> >-H "Travis-API-Version: 3" \
> >-H "Authorization: token " \
> >-d '{ "quiet": true }' \
> >https://api.travis-ci.org/job//debug
> >
>
>
> Just a follow up here. Turns out the default configuration (shown
> above) is limited to a 30 minute timeout, which isn't enough to get
> all the dependencies installed and QGIS built, let alone leaving time
> for debugging ;)
>
> After some discussion with Travis staff (who have been fantastic, I've
> got to say!), there's a workaround. By changing "quiet": true to
> "quiet": false, the interactive session is subject to the normal 90(+)
> minute timeout. The side effect is that all the commands entered are
> visible to anyone looking at the Travis log, so be careful not to do
> this with any sensitive information.
>
> The command is full is:
>
> #! /usr/bin/env bash
>   curl -s -X POST \
>-H "Content-Type: application/json" \
>-H "Accept: application/json" \
>-H "Travis-API-Version: 3" \
>-H "Authorization: token " \
>-d '{ "quiet": false }' \
>https://api.travis-ci.org/job//debug
>
>
> Nyall
>
>
> > The Job ID is displayed in the build log after expanding "Build system
> > information".
> >
> > 2. Head back to the web UI and in the log of your job. There you
> > should see the following lines to connect to the VM:
> >
> > Setting up debug tools.
> > Preparing debug sessions.
> > Use the following SSH command to access the interactive debugging
> environment:
> > ssh ukjiucekxbbnrae32y8xch...@ny2.tmate.io
> >
> > 3. Connect from your computer using SSH into the interactive session,
> > and once you're done, just type exit and your build will terminate.
> >
> > Once in the SSH session, these bash functions will come in handy to
> > run the different phases in your build:
> >
> https://docs.travis-ci.com/user/running-build-in-debug-mode/#Things-to-do-once-you-are-inside-the-debug-VM
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Python API for 3D

[Alessandro Pasotti]

On Fri, Sep 28, 2018 at 4:21 PM Martin Dobias  wrote:

> Hi all
>
> I have been thinking it would be good to finally have Python API also
> for qgis_3d library. Until now I have kept the 3D library
> intentionally without Python bindings so that it is possible to move
> the code around without being blocked by the API stability
> requirement.
>
> I think for the time being we should still treat the 3D library as
> having unstable API - so I wanted to check how others would feel about
> having Python API for qgis_3d that would be marked as unstable, i.e.
> there may be changes between 3.x releases? I think with big warnings
> in the docs that the API may change we can get others to experiment
> with 3D functionality while not offending anyone too much if we break
> it later. The idea is that the API would get frozen at some point
> later in 3.x release cycle or for QGIS 4.
>
> Cheers
> Martin
>


Hi Martin,

I think it's a good idea!

... if the warning is big enough and not light gray over a white background
;)


-- 
Alessandro Pasotti
w3:   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] Has QgsLayout.itemById() changed?

[Alessandro Pasotti]

Do you have any clue about why this issue is not always reproducible?


On Sun, Sep 23, 2018, 11:27 Nyall Dawson  wrote:

> On Fri, 21 Sep 2018 at 23:20, Raymond Nijssen 
> wrote:
>
> > which doesn't work anymore, because there is no setText() function on a
> > QgsLayoutItem. Has anything changed recently? Does any one know a
> solution?
>
> Nothing has changed recently -- this has always been fragile, and the
> bug lies deep within the library used to create the Python bindings.
>
> See e.g.
>
>
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-QgsLayout-itemById-returns-wrong-object-td5350947.html
>
> for a workaround
>
> Nyall
>
> Nyall
>
> >
> > Regards,
> > Raymond
> > ___
> > 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
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Has QgsLayout.itemById() changed?

[Alessandro Pasotti]

On Fri, Sep 21, 2018 at 8:36 PM Raymond Nijssen 
wrote:

> Not working for me. I just built todays master (e85c09254c) and get the
> same result. What version did you build?
>

Same as yours.

Btw, please file a ticket, I just re-tested it now and got the issue again,
this is my workflow:

- Open a project that has no layouts
- Create a new layout through the manager
- Add a label and set id = "my_label"
- Save and close the layout and the manager
- Run python code and:


In [1]: p = QgsProject.instance()

   ...: lom = p.layoutManager()

   ...: lo = lom.layoutByName('Layout 1')

   ...:




In [2]: lo

Out[2]: 

In [4]: lo.itemById('my_label')

Out[4]: 


In [5]: lo.items()

Out[5]:

[,

,

,

,

,

,

,

]


In [6]: lo.items()

Out[6]:

[,

,

,

,

,

,

,

,

,

,

,

,

]


In [7]: lo.items()

Out[7]:

[,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

]


Now, there is  another (possibly unrelated) issue: if I open the layout
again and do nothing but hit "save" and close the layout, when re-running
the code I get a brand new set of QGraphicsLineItem each time I save it.

This looks like a bug to me.




>
>
> On 21-09-18 16:29, Alessandro Pasotti wrote:
> >
> > Hi Raymond,
> >
> > You know what? I've just rebased and rebuilt current master and I cannot
> > reproduce it anymore :(
> > I checked the bindings code and it looks fine, can you check latest
> master?
> >
> >
> > On Fri, Sep 21, 2018 at 3:47 PM Raymond Nijssen  > <mailto:r.nijs...@terglobo.nl>> wrote:
> >
> > Will do so. Thank you Alessandro!
> >
> >
> >
> > On 21-09-18 15:32, Alessandro Pasotti wrote:
> >  > Hi Raymond,
> >  >
> >  > confirmed, there is probably something broken in the bindings,
> > please
> >  > file a ticket.
> >  >
> >  > On Fri, Sep 21, 2018 at 3:20 PM Raymond Nijssen
> > mailto:r.nijs...@terglobo.nl>
> >  > <mailto:r.nijs...@terglobo.nl <mailto:r.nijs...@terglobo.nl>>>
> wrote:
> >  >
> >  > Running this python script (in qgis 3.3):
> >  >
> >  > p = QgsProject.instance()
> >  > lom = p.layoutManager()
> >  > lo = lom.layoutByName('a4')
> >  > item = lo.itemById('label_title')
> >  > print(item)
> >  >
> >  >
> >  > a few weeks ago, it outputed this:
> >  > 
> >  >
> >  >
> >  > but today it outputs:
> >  > 
> >  >
> >  >
> >  >
> >  > My next line is:
> >  >
> >  > item.setText('hello')
> >  >
> >  > which doesn't work anymore, because there is no setText()
> > function on a
> >  > QgsLayoutItem. Has anything changed recently? Does any one
> know a
> >  > solution?
> >  >
> >  > Regards,
> >  > Raymond
> >  > _______
> >  > QGIS-Developer mailing list
> >  > QGIS-Developer@lists.osgeo.org
> > <mailto:QGIS-Developer@lists.osgeo.org>
> > <mailto: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> <http://www.itopen.it>
> >
> > --
> > Terglobo
> > Fahrenheitstraat 1
> > 5223 BJ 's-Hertogenbosch
> > The Netherlands
> > +31 (0) 6 25 31 49 83
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org  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>
>
> --
> Terglobo
> Fahrenheitstraat 1
> 5223 BJ 's-Hertogenbosch
> The Netherlands
> +31 (0) 6 25 31 49 83
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Has QgsLayout.itemById() changed?

[Alessandro Pasotti]

Hi Raymond,

You know what? I've just rebased and rebuilt current master and I cannot
reproduce it anymore :(
I checked the bindings code and it looks fine, can you check latest master?


On Fri, Sep 21, 2018 at 3:47 PM Raymond Nijssen 
wrote:

> Will do so. Thank you Alessandro!
>
>
>
> On 21-09-18 15:32, Alessandro Pasotti wrote:
> > Hi Raymond,
> >
> > confirmed, there is probably something broken in the bindings, please
> > file a ticket.
> >
> > On Fri, Sep 21, 2018 at 3:20 PM Raymond Nijssen  > <mailto:r.nijs...@terglobo.nl>> wrote:
> >
> > Running this python script (in qgis 3.3):
> >
> > p = QgsProject.instance()
> > lom = p.layoutManager()
> > lo = lom.layoutByName('a4')
> > item = lo.itemById('label_title')
> > print(item)
> >
> >
> > a few weeks ago, it outputed this:
> > 
> >
> >
> > but today it outputs:
> > 
> >
> >
> >
> > My next line is:
> >
> > item.setText('hello')
> >
> > which doesn't work anymore, because there is no setText() function
> on a
> > QgsLayoutItem. Has anything changed recently? Does any one know a
> > solution?
> >
> > Regards,
> > Raymond
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org  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>
>
> --
> Terglobo
> Fahrenheitstraat 1
> 5223 BJ 's-Hertogenbosch
> The Netherlands
> +31 (0) 6 25 31 49 83
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Has QgsLayout.itemById() changed?

[Alessandro Pasotti]

Hi Raymond,

confirmed, there is probably something broken in the bindings, please file
a ticket.

On Fri, Sep 21, 2018 at 3:20 PM Raymond Nijssen 
wrote:

> Running this python script (in qgis 3.3):
>
> p = QgsProject.instance()
> lom = p.layoutManager()
> lo = lom.layoutByName('a4')
> item = lo.itemById('label_title')
> print(item)
>
>
> a few weeks ago, it outputed this:
> 
>
>
> but today it outputs:
> 
>
>
>
> My next line is:
>
> item.setText('hello')
>
> which doesn't work anymore, because there is no setText() function on a
> QgsLayoutItem. Has anything changed recently? Does any one know a solution?
>
> Regards,
> Raymond
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Unable to get QGIS interface in another laguage than the system's - broken feature?

[Alessandro Pasotti]

On Wed, Sep 19, 2018 at 11:26 AM Jürgen E. Fischer  wrote:

> Hi Alessandro,
>
> On Wed, 19. Sep 2018 at 10:46:05 +0200, Alessandro Pasotti wrote:
> > See https://issues.qgis.org/issues/19879
>
> > I didn't have time yet to look into it but I've been able to reproduce on
> > Windows, it looks more like a CMake/installation issue, maybe Juergen
> would
> > be the best candidate for a quick fix.
>
> Um, I started, but rolled back my work once I noticed that you already
> assigned
> it to you - and just linked #19853 with which's fix I probably introduced
> the
> problem.
>

Thanks Jürgen! I'm more than happy to leave it to you :)

I thought it might be related with my recent changes with QLocale, that's
why I started looking at that bug but I run out of time yesterday and I was
just able to confirm it on windows.

-- 
Alessandro Pasotti
w3:   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] Unable to get QGIS interface in another laguage than the system's - broken feature?

[Alessandro Pasotti]

See https://issues.qgis.org/issues/19879

I didn't have time yet to look into it but I've been able to reproduce on
Windows, it looks more like a CMake/installation issue, maybe Juergen would
be the best candidate for a quick fix.




On Wed, Sep 19, 2018 at 10:42 AM DelazJ  wrote:

> Hi,
>
> I don't know if it's a local issue nor how I can get it sorted but I'm
> unable to change the language in which QGIS interface is displayed. I can
> get access to the Options --> General but whatever language I choose,
> reopening QGIS results in the same French interface. Creating new profile,
> changing the language and reopening QGIS changes nothing. All my profiles
> use the same language. The menu "User Interface Translation" still shows
> the language I select in the combobox but that language is applied nowhere.
>
> Regards,
> Harrissou
>
> ___
> 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



-- 
Alessandro Pasotti
w3:   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] Anyone using QGIS with high resolution screen?

[Alessandro Pasotti]

On Thu, Sep 6, 2018 at 5:28 PM Denis Rouzaud 
wrote:

> Thank you for replies.
> Alessandro, on Mac, how did you installed/compiled QGIS? Homebrew,
> MacPorts or KyngChaos ?
>
>
>
Hi Denis,

Sorry if I wasn't clear: I wiped out the hard disk completely, put a QGIS
sticker on the Apple logo and I'm happily running Ubuntu on my MacBook Pro
15'' :)

-- 
Alessandro Pasotti
w3:   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] Anyone using QGIS with high resolution screen?

[Alessandro Pasotti]

On Wed, Sep 5, 2018 at 11:52 PM Nyall Dawson  wrote:

> On Thu, 6 Sep 2018 at 03:39, Denis Rouzaud 
> wrote:
> >
> > Hi list,
> >
> > There is a persistent issue of slowness of QGIS on Mac.
> > https://issues.qgis.org/issues/19546
> >
> > The last comments led to think that this comes from high resolution.
> Starting from 2560x1440, it starts to be less and less usable. And
> completly unsuable at 5120x2880.
>
> 3840x2160 here, on Linux/Win, and perfectly usable. That's the highest
> res I've got available to test with.
>


Me too: I've been using a 4k 3840x2160 screen on Linux for 3 years now
without any slowness problem.
MacBook Pro 15'' retina with Ubuntu Xenial also works very well.


-- 
Alessandro Pasotti
w3:   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] Some initial OpenCL feedback

[Alessandro Pasotti]

On Tue, Sep 4, 2018 at 4:57 PM Andreas Neumann  wrote:

> Hi Alessandro,
>
> Thanks for the clarification that only the change of the OpenCL-device
> needs a restart.
>
> I tried both - acceleration in CPU and in GPU. I had the impression that
> the acceleration in the CPU was slightly faster than in the CPU - but not a
> lot faster. Maybe the GPU (Intel HD Graphics 4600) is not too powerful. It
> is a ThinkPad notebook, not a desktop.
>

Thanks for the info!

Yes, maybe that the lower I/O (there is no need to transfer data to/from
the graphic card) compensates the slower processing on the CPU

Cheers

Greetings,
>
> Andreas
>
> On 2018-09-04 15:56, Alessandro Pasotti wrote:
>
>
> On Tue, Sep 4, 2018 at 2:21 PM Andreas Neumann 
> wrote:
>
>> Hi Alessandro,
>>
>> I just tested if the hardware acceleration (OpenCL) helps in the live
>> hillshade renderer.
>>
>
>
> Hi Andreas,
>
> thanks a lot for your feedback, I honestly am a little worried about the
> possible problems on different platforms, graphic cards and driver
> versions, I choose to stay on the safe side and there is a safeguard that
> disables the OpenCL support at the first issue in the renderer.
>
> The processing algs looks generally more stable (never got a single crash
> myself).
>
>
>
>> The good news is that it works stable so far and substantially improves
>> rendering time of the live hillshade renderer. My notebook on my workplace
>> is rather slow. Without hardware acceleration it renders the hillshade in
>> approx 8 seconds (large window on two screens). With OpenCL acceleration
>> set to on, it renders in about 1 second or even less. I assume quite some
>> time is also spent on reading the file. This with resampling on (average
>> for zooming out and bilinear for zooming in beyond native resolution).
>>
>
> Yes some time is spent on reading the file and some time is spend on I/O
> tranferring data to/from the graphic card, this means that the performance
> gain is usually higher on larger images than on smaller images.
>
>
>> Hardware is an Intel HD Graphics 4600. The CPU is also listed as
>> supported.
>>
>
> Can you also try the CPU? I'm curious about the performances.
>
>
>> Visually, with or without HW accelation on, there still are some
>> rectangular artefacts in both versions.
>>
>
> Yes: that does not change, the algorithm is pretty much the same in both
> implementations.
>
>
>
>> Tested on Windows.
>>
>> --
>>
>> One more thing: on my machine there is no restart of QGIS necessary for
>> the changes (HW acceleration on of off) to be applied. This is contrary to
>> the statement in the settings dialogue, which says, that a restart of QGIS
>> is necessary.
>>
>
> The text can probably be improved: what needs a restart is if you change
> the device, enabling and disabling OpenCL support does not require a
> restart.
>
>
>> ---
>>
>> Thanks a lot for your work!
>>
>
>
> Thank you for the feedback!
>
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>
>
>

-- 
Alessandro Pasotti
w3:   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] Some initial OpenCL feedback

[Alessandro Pasotti]

On Tue, Sep 4, 2018 at 2:21 PM Andreas Neumann  wrote:

> Hi Alessandro,
>
> I just tested if the hardware acceleration (OpenCL) helps in the live
> hillshade renderer.
>


Hi Andreas,

thanks a lot for your feedback, I honestly am a little worried about the
possible problems on different platforms, graphic cards and driver
versions, I choose to stay on the safe side and there is a safeguard that
disables the OpenCL support at the first issue in the renderer.

The processing algs looks generally more stable (never got a single crash
myself).


The good news is that it works stable so far and substantially improves
> rendering time of the live hillshade renderer. My notebook on my workplace
> is rather slow. Without hardware acceleration it renders the hillshade in
> approx 8 seconds (large window on two screens). With OpenCL acceleration
> set to on, it renders in about 1 second or even less. I assume quite some
> time is also spent on reading the file. This with resampling on (average
> for zooming out and bilinear for zooming in beyond native resolution).
>

Yes some time is spent on reading the file and some time is spend on I/O
tranferring data to/from the graphic card, this means that the performance
gain is usually higher on larger images than on smaller images.

Hardware is an Intel HD Graphics 4600. The CPU is also listed as supported.
>

Can you also try the CPU? I'm curious about the performances.


> Visually, with or without HW accelation on, there still are some
> rectangular artefacts in both versions.
>

Yes: that does not change, the algorithm is pretty much the same in both
implementations.



> Tested on Windows.
>
> --
>
> One more thing: on my machine there is no restart of QGIS necessary for
> the changes (HW acceleration on of off) to be applied. This is contrary to
> the statement in the settings dialogue, which says, that a restart of QGIS
> is necessary.
>

The text can probably be improved: what needs a restart is if you change
the device, enabling and disabling OpenCL support does not require a
restart.


> ---
>
> Thanks a lot for your work!
>


Thank you for the feedback!




-- 
Alessandro Pasotti
w3:   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] What to do about WFS test failures?

[Alessandro Pasotti]

On Sat, Sep 1, 2018 at 12:37 PM Richard Duivenvoorde 
wrote:

> On 09/01/2018 11:56 AM, Nyall Dawson wrote:
> > Hi devs,
> >
> > Just raising the question of what we should do about the constant WFS
> > test failures we get on Travis. I'd estimate 1 in 3 builds fails
> > because of WFS related tests hanging.
> >
> > I'm very reluctant to disable all these tests, because:
> >
> > 1. WFS is super important.
> > 2. I think there may be a real issue here - I've got at least one
> > customer who is having WFS issues with 3.2 and master. BUT: on the
> > other hand Travis has always been flaky with any test which uses
> > threads, regardless of which area of code it's from. So it could just
> > be Travis playing up again, in which case we'd need to disable these
> > tests like we do most of the other thread-related tests...
> >
> > The current situation is basically unworkable. So ideas?
>
> To add: QGIS recently has some issues and list messages concerning wfs
> too. I searched some:
>
> https://issues.qgis.org/issues/19702
>
> https://lists.osgeo.org/pipermail/qgis-user/2018-August/043237.html
>
> https://lists.osgeo.org/pipermail/qgis-user/2018-August/043241.html
>
> And myself I also have the feeling that WFS is less stable/usable then
> in 2.18 (I release a list of national WFS/WMS/WCS's in one of my plugins).
>
> So I think it is not only CI that has problems, it looks like changes in
> WFS made it more tricky to use?
>


Richard, please let's focus on Travis in this thread.

WFS UX issues on 3.x are a complete different topic.


-- 
Alessandro Pasotti
w3:   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] What to do about WFS test failures?

[Alessandro Pasotti]

On Sat, Sep 1, 2018 at 11:56 AM Nyall Dawson  wrote:

> Hi devs,
>
> Just raising the question of what we should do about the constant WFS
> test failures we get on Travis. I'd estimate 1 in 3 builds fails
> because of WFS related tests hanging.
>
> I'm very reluctant to disable all these tests, because:
>
> 1. WFS is super important.
> 2. I think there may be a real issue here - I've got at least one
> customer who is having WFS issues with 3.2 and master. BUT: on the
> other hand Travis has always been flaky with any test which uses
> threads, regardless of which area of code it's from. So it could just
> be Travis playing up again, in which case we'd need to disable these
> tests like we do most of the other thread-related tests...
>
> The current situation is basically unworkable. So ideas?
>
> Nyall
>


Sorry I do not have any solution,  the only consideration that comes up to
my mind is that if sum up all the time wasted by developers by
unrelated/random Travis failures we would probably be very badly surprised
(as I usually say Travis is basically a very slow binary entropy generator).

Talking about the tests, WFS tests, and (even for different reasons)
http-based integration tests (some auth tests, qgsfiledownloader, many
server OWS tests) are apparently more fragile than others, mainly because
they depend on (sometimes external) http services, but they have proven in
the past to be very effective in spotting out regressions on very important
feature likes WMS, WFS etc., some of them are also important because they
ensure that QGIS client can talk to its server component.

The very bad things about disabling tests are:

- their development costed a lot of time and efforts and disabling them is
not an incentive for the developers to write more tests [1]
- the tests are obviously important to prevent regressions
- before disabling a test we should make 100% sure that we are not
overlooking a real bug (or what are the tests written for in the first
place?)


So, my recommendation - not very useful in the short term I'm afraid -
would be to start exploring other more reliable options for our CI, even if
they are more expensive.

For the time being, as a temporary solution, there are no other options
than disabling though.

Maybe a good idea would be to allocate some money specifically for the
tests (a dedicated grant, a dedicated hackfest?) just an idea...

[1] of course sometimes it would just mean to write "better" and more
robust tests, but I suspect that this is not generally the case.

-- 
Alessandro Pasotti
w3:   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] How long before closing an issue on "lack of feedback"?

[Alessandro Pasotti]

I would suggest 30 days, people might be so lucky to have their holidays
last longer than two weeks.

On Mon, Aug 13, 2018 at 2:23 AM, Nyall Dawson 
wrote:

> Quick question re closing issues on redmine:
>
> What's an "acceptable" amount of time between adding a question to a
> ticket/marking as "feedback" before closing that issue as "Closed due
> to lack of feedback"?
>
> Is 14 days sufficient?
>
> 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




-- 
Alessandro Pasotti
w3:   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] OpenCL and macOS

[Alessandro Pasotti]

On Thu, Aug 9, 2018 at 5:05 PM, Tom Elwertowski 
wrote:

> The directory found by CMake 
> (/System/Library/Frameworks/OpenCL.framework/Headers/)
> contains only .h files.
>
> The khronos site mentioned by Denis offers cl.hpp for v1 and cl2.hpp for
> v2. qgsopenclutils.h includes cl2.hpp.
>
> Should I download and try cl.hpp on my mac?


Sorry but I don't know if that will work (I'm not a mac user), what I know
is that you need cl2.hpp (note that this header supports 1.1 and 1.0) in
order to build QGIS with opencl support and you also need the opencl
library to link to.

Once you've built it, to actually run opencl stuff you need (one or more)
other runtime library that is hardware (intel, AMD, NVidia etc.) and system
dependent and it is dynamically loaded by opencl library.



> If it compiles, how can I test running it.
>


There are tests in the tests folder that you can build and run,
specifically: qgsninecellsfiltertest.cpp and qgsopenclutilstest.cpp

You can also open the QGIS options dialog and check under "Acceleration":
see
https://user-images.githubusercontent.com/142164/43066104-08b6880e-8e64-11e8-8a46-103e368119e5.png

As you can see in the picture OpenCL supported version of that particular
library is 1.1


Let me know how it goes!




>
> Tom
>
>
> On 8/9/18 10:12 AM, Denis Rouzaud wrote:
>
>> I think the issue is that there is no header installed on mac
>> https://stackoverflow.com/a/23079478/1548052
>>
>> Le jeu. 9 août 2018 à 16:06, Alessandro Pasotti > <mailto:apaso...@gmail.com>> a écrit :
>>
>> On Thu, Aug 9, 2018 at 3:54 PM, Tom Elwertowski
>> mailto:telwertow...@comcast.net>> wrote:
>>
>> Hi all,
>>
>> A recent change added OpenCL. Compilation fails on macOS because
>> Apple provides v1.2 (macOS 10.13) while QGIS seems to require v2.
>>
>>
>> That's wierd: 1.1 is what should be required can you file a ticket
>> and provide full logs?
>>
>> Adding a version to FIND_PACKAGE will fix the macOS compile and
>> not use OpenCL.
>>
>> Apple has deprecated OpenCL in favor of its own Metal
>> technology. OpenCL will remain for macOS 10.14 (Mojave, fall
>> 2018) but may be removed after fall 2019.
>>
>> For the future, either OpenCL must remain an optional QGIS
>> feature in order to support macOS or the API needs to be
>> abstracted so that macOS can use Metal while other OSs use OpenCL.
>>
>>
>>
>> OpenCL is an optional feature and there is no plan to change that.
>>
>>
>>
>> Tom
>> LinkedIn: https://www.linkedin.com/in/thomas-elwertowski-a0886032
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> <mailto:QGIS-Developer@lists.osgeo.org>
>> List info: https://lists.osgeo.org/mailma
>> n/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailma
>> n/listinfo/qgis-developer
>>
>>
>>
>>
>> -- Alessandro Pasotti
>> w3: www.itopen.it <http://www.itopen.it>
>> _______
>> 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
>>
>> --
>>
>> Denis Rouzaud
>> de...@opengis.ch <mailto:de...@opengis.ch>
>> +41 76 370 21 22
>>
>>
>>


-- 
Alessandro Pasotti
w3:   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] OpenCL and macOS

[Alessandro Pasotti]

On Thu, Aug 9, 2018 at 3:54 PM, Tom Elwertowski 
wrote:

> Hi all,
>
> A recent change added OpenCL. Compilation fails on macOS because Apple
> provides v1.2 (macOS 10.13) while QGIS seems to require v2.



That's wierd: 1.1 is what should be required can you file a ticket and
provide full logs?



> Adding a version to FIND_PACKAGE will fix the macOS compile and not use
> OpenCL.
>
> Apple has deprecated OpenCL in favor of its own Metal technology. OpenCL
> will remain for macOS 10.14 (Mojave, fall 2018) but may be removed after
> fall 2019.
>
> For the future, either OpenCL must remain an optional QGIS feature in
> order to support macOS or the API needs to be abstracted so that macOS can
> use Metal while other OSs use OpenCL.
>


OpenCL is an optional feature and there is no plan to change that.




>
> Tom
> LinkedIn: https://www.linkedin.com/in/thomas-elwertowski-a0886032
> ___
> 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




-- 
Alessandro Pasotti
w3:   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] Gentle request: please be careful with 2.18 backports

[Alessandro Pasotti]

On Mon, Jul 16, 2018 at 12:20 AM, Nyall Dawson 
wrote:

> Hi all,
>
> This is a gentle request to please please pay very special attention
> when backporting fixes to 2.18, and assess carefully whether those
> fixes are REALLY necessary in the stable LTR branch. Unfortunately the
> last couple of 2.18 patch releases have seen some serious regressions
> introduced as a result of backported fixes, which really harms the
> reputation of QGIS' stability.
>
> It's no-ones fault, because we ALL make mistakes and create
> regressions... but I think at this stage we should tighten up 2.18 now
> to only mission critical, very clearly safe bug fixes, and leave all
> "minor" fixes for 3.x only.
>
> (Possibly we should consider switching on github branch protection
> here, blocking direct commits and requiring a minimum of 2 or 3
> 'acceptable' reviews from core devs on PRs?)
>
> Nyall
>


+1

As a side note, I believe we should try to involve more community members
(I mean users: not developers) in regularly testing development builds
between feature freeze and release.


-- 
Alessandro Pasotti
w3:   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] QGIS 3 "GPS Information Panel" not fully functional

[Alessandro Pasotti]

Hi Nyall,

if you want to have a receiver "without having a receiver" you could use
this recipe: https://www.itopen.it/use-your-android-phones-gps-in-qgis/


On Tue, Jul 10, 2018 at 5:50 AM, Nyall Dawson 
wrote:

> On Tue, 10 Jul 2018 at 00:37, C Hamilton  wrote:
> >
> > Thanks for that explanation. I guess the satellite tab is more for
> curiosity than actual value.
> >
> > The "Signal" tab is there but apparently does not work. That one is
> useful. Are there any comments about it?
> >
>
> Not sure what's happening with this one -- I don't have a receiver
> which reports the information required for this graph, so can't
> diagnose what's happening here or if it's working as expected.
>
> 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
>



-- 
Alessandro Pasotti
w3:   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] QgsAuthConfigSelect use

[Alessandro Pasotti]

On Tue, Jun 5, 2018 at 2:46 PM, Richard Duivenvoorde 
wrote:

> Hi Devs,
>
> I'm using the QgsAuthConfigSelect-widget, to create 'configs' (with url,
> id, username, password (basic auth)) etc.
>
> It works great!! I could even incorporate it in my dialog!
>


that's exactly what it was designed for :)



> Two comments, of which I like to have some input of others if possible:
>
> 1) (see screenshot) currently the 'type' is always added in the dropdown
> (in my case you always see (Basic)). If a user wants to see this, it is
> possible to add it themselves (see (mytype)).
> So Question: would there be troubles if I remove that?
>

I'm not sure I understand what you are asking: the ("Basic") string is the
authentication type (that comes to the authentication plugin that the
configuration is using)  and it is a useful piece of information, but of
course it is not required.


>
> 2) the first item is ALWAYS: 'No authentication'.
> In my case that does not make sense. If you did not create a 'profile',
> there is not an url, no nothing, so I would prefer to see either:
> - nothing (no item)
> - 'Please create an authorisation profile'
> - 'Please configure first'
> or something like that.
>
>
I think you should handle that in your particular dialog logic, the widget
does what it was designed for, that is allow the users to choose and
existing authentication configuration AND/OR to create a new one, editing
and deletion of existing configs is also available.



> Any comments?
>
> I'm aware that this is build for governmental use, so if this is cast in
> stone, then... we leave it like this?
>


Nothing is carved in stone, but still I would leave like it is now.


-- 
Alessandro Pasotti
w3:   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] expression variable for rendering with QGIS server

[Alessandro Pasotti]

Hi Otto,

no need to be sorry, it is actually always good to know that something
works as expected ;)

On Wed, May 23, 2018 at 4:35 PM, Otto Dassau <das...@gbd-consult.de> wrote:

> Hi,
>
> after a second try, it seems that QGIS server version 3 supports expression
> variables within the rule based renderer - sorry for the noise.
>
> Thanks,
> Otto
>
> Am Wed, 23 May 2018 16:16:58 +0200
> schrieb Otto Dassau <das...@gbd-consult.de>:
>
> > Dear developers,
> >
> > I use expression variables within the rule based renderer. For example:
> >
> > CASE WHEN @project_title LIKE '%adult' THEN "fclass" = 'school' ELSE
> > "fclass" = 'kindergarten' END
> >
> > This works in QGIS desktop but not with QGIS Server Version 2 and 3. Does
> > QGIS server not support this feature at all? Or do I miss something?
> >
> > Thanks for any hint
> >
> > Otto
> > ___
> > 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
>



-- 
Alessandro Pasotti
w3:   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] "Actions" menu in feature forms

[Alessandro Pasotti]

On Thu, May 17, 2018 at 7:05 PM, Andreas Neumann <a.neum...@carto.net>
wrote:

> Hi Alessandro,
>
> Originally, there was the idea to introduce a menu that lists more than
> just actions. See https://issues.qgis.org/issues/10288
>
> e.g. also to list derived information based on a feature (same information
> that is also available in the panel of the info tool.
>
> I am sure that other people would find other ideas to extend this menu.
>
> But I agree with you, that an empty menu is not so nice. Would you suggest
> hiding the menu if nothing is in there?
>

Yes, I suppose it's better to hide it when it's empty.

Anyway - i don't think it is a major problem - either way. We have other
> more ugly things ... UI-wise.
>


Not  a good reason to add another one ;-)


Andreas
>
> On 2018-05-17 18:55, Alessandro Pasotti wrote:
>
> On Thu, May 17, 2018 at 6:49 PM, Andreas Neumann <a.neum...@carto.net>
> wrote:
>
>> Hi Alessandro,
>>
>> If you had any "Actions" defined on the layer, this menu would list all
>> assigned actions and you could start them from there.
>>
>
> Thanks for your answer Andreas!
>
> This is a nice feature, but I don't think it's a good UX/UI to have a menu
> which is empty by default.
>
> What do you think?
>
>
>
>> Andreas
>>
>> On 2018-05-17 18:43, Alessandro Pasotti wrote:
>>
>> In current master there is an empty "Actions" menu in the forms.
>>
>> What is it?
>>
>>
>>
>>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>
>
>


-- 
Alessandro Pasotti
w3:   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

[QGIS-Developer] "Actions" menu in feature forms

[Alessandro Pasotti]

In current master there is an empty "Actions" menu in the forms.

What is it?

-- 
Alessandro Pasotti
w3:   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] Compositions/Layouts - Subsitution map in QGIS 3

[Alessandro Pasotti]

In qgis3 you must use string search and replace, that is what the qgis2
implementation was doing.


On Wed, May 16, 2018, 17:30 Adam Borczyk 
wrote:

> Hi everyone,
>
> In QGIS 2 there was this handy function to load a Python dict with string
> mapping into a QgsComposition object, so each string (not only label, also
> eg. HTML) inside a given .qpt project was substituted accordingly ->
> https://qgis.org/api/2.18/classQgsComposition.html#ac147dd9e3ee689a7fdfdca58743e7be8
>
> I know Composition stuff was moved to QgsLayout in Q 3. In the
> documentation I found only this one:
> https://qgis.org/api/classQgsLayout.html#ad84ff95e98598ed3c29eef973d7b4bff
> but it doesn't seem to support the substitution map. What is the way to
> substitute string in Q 3?
>
> Best regards
>
> * Adam Borczyk*
>
> *-GIS Support Sp. z o.o.Dobrzańskiego 3,
> Lublin 20-262
> tel.
> +48 81 451 14 90, NIP: 9462641761*
> ___
> 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] Crash with Style Dock Layer Panel

[Alessandro Pasotti]

https://github.com/qgis/QGIS/commit/0e57b887d6bd222d57afd4a5edd33fa1c4accc3e


If this doesn't fix it then I really need some sleep ;-)



On Wed, May 16, 2018 at 8:49 PM, Alessandro Pasotti <apaso...@gmail.com>
wrote:

> I see, that's a different path than the one in Harrisou's comment.
>
> I'll have a look to that too.
>
>
> On Wed, May 16, 2018 at 8:35 PM, matteo <matteo.ghe...@gmail.com> wrote:
>
>> Hi Ale,
>>
>> nope, I just pulled from upstream and rebuild QGIS but same error is there
>>
>> matteo@debian:~/lavori/QGIS/QGIS$ git log --oneline
>> 40499ee392 (HEAD -> master, upstream/master) Fix crash on
>> categorized/graduated symbol styling dock
>> e56ff6838d Merge pull request #7004 from alexbruy/select-atribute
>> 15a5d91770 [processing] improve polar plot algorithm help (fix #16679)
>>
>> Thanks
>>
>> Matteo
>>
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>



-- 
Alessandro Pasotti
w3:   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] Crash with Style Dock Layer Panel

[Alessandro Pasotti]

I see, that's a different path than the one in Harrisou's comment.

I'll have a look to that too.


On Wed, May 16, 2018 at 8:35 PM, matteo <matteo.ghe...@gmail.com> wrote:

> Hi Ale,
>
> nope, I just pulled from upstream and rebuild QGIS but same error is there
>
> matteo@debian:~/lavori/QGIS/QGIS$ git log --oneline
> 40499ee392 (HEAD -> master, upstream/master) Fix crash on
> categorized/graduated symbol styling dock
> e56ff6838d Merge pull request #7004 from alexbruy/select-atribute
> 15a5d91770 [processing] improve polar plot algorithm help (fix #16679)
>
> Thanks
>
> Matteo
>



-- 
Alessandro Pasotti
w3:   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] Crash with Style Dock Layer Panel

[Alessandro Pasotti]

Can you please check latest master?

I think I fixed it.


On Wed, May 16, 2018 at 5:04 PM, DelazJ <del...@gmail.com> wrote:

> Hi,
> Yes, I confirm. I forgot to report in the issue tracker but see
> https://github.com/qgis/QGIS/pull/6952#issuecomment-388315309
>
> regards,
> Harrissou
>
>
> 2018-05-16 16:52 GMT+02:00 matteo <matteo.ghe...@gmail.com>:
>
>> Hi guys,
>>
>> I have a fresh compiled QGIS master and no matter which data I load, but
>> opening the style dock panel - > categorized style once I click on the
>> Change ... button to change the symbol type QGIS dies. No stack traces,
>> just:
>>
>> QGIS died on signal 11Aborted
>>
>> the same button in the Layer Properties works fine.
>>
>> Someone confirm?
>>
>> Cheers
>>
>> 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
>



-- 
Alessandro Pasotti
w3:   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] QGIS Server - SSL handshake failed for cascading WMS

[Alessandro Pasotti]

And this:

https://issues.qgis.org/issues/17951

and this too:

https://issues.qgis.org/issues/16462



On Mon, May 14, 2018 at 4:58 PM, Régis Haubourg <regis.haubo...@gmail.com>
wrote:

> Hi Anne,
> did you test QGIS 3.0 also?
> Could you create an issue in issue.qgis.org tracker?
>
> I found that one, that seemed related https://issues.qgis.org/issues/18634
>
> Regards,
> Régis
>
> 2018-05-14 16:25 GMT+02:00 Anne Blankert <anne.blank...@geodan.nl>:
>
>> Hello List,
>>
>> This question was already asked in Jan 2017, but no solution was posted.
>> http://osgeo-org.1560.x6.nabble.com/QGIS-Server-SSL-handshak
>> e-failed-for-cascading-WMS-td5305094.html
>>
>> The problem: if QGIS uses an HTTPS (SSL) WMS service, the WMS works
>> nicely in QGIS desktop. However, if you use the same .qgs project file on
>> QGIS Server, all requests to the HTTPS (SSL) WMS server result in an  SSL
>> handshake error.
>>
>> This (still) happens on:
>> Ubuntu 16.04
>> QGIS server 2.18
>> An example WMS https server showing the problem is:
>> https://geodata.nationaalgeoregister.nl/bag/ows
>>
>> A workaround could be to use the HTTP version of the WMS instead of the
>> HTTPS version. However, the capabilities of many HTTP services advertise
>> the HTTPS version for the GETMAP, GETFEATUREINFO and GETLEGENDGRAPHIC
>> endpoints.
>>
>> The SSL problem also arises when trying to use WFS services over HTTPS
>> from QGIS Server.
>>
>> Is this a known problem? Is there a workaround? Should I file a bug
>> report?
>>
>> Thanks,
>>
>> Anne
>>
>> ___
>> 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
>



-- 
Alessandro Pasotti
w3:   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] 32 by 3.2?

[Alessandro Pasotti]

On Tue, May 8, 2018 at 1:15 AM, Nyall Dawson <nyall.daw...@gmail.com> wrote:

> Hi all,
>
> It's no surprise to anyone familiar with the QGIS project that we've
> got an issue with the Pull Request queue. It's been slowly growing
> over time, recently hitting over 150 open requests! It's a bit of an
> embarrassment to the project (some of these PRs have been open for
> years!), and is likely causing us to lose new contributors and code.
>
> The usual magic QGIS coding pixies did some work lately and squashed
> the queue back below 100 requests. But the remaining ones are all the
> difficult, unfinished or orphaned PRs...
>
> PR reviewing is hard. Not everyone can review every open PR due to
> different familiarity with areas of the codebase. (Which is why I
> don't think a funding grant to cover this will ever work
> successfully). And no-one wants to be the 'bad guy" who closes an
> unmerged PR representing someone else's hard work.
>
> So I propose a "32 by 3.2" sprint, where we ALL collaboratively aim to
> reduce the PR queue to <32 open requests before 3.2 release.
>
> I think we could achieve this by:
>
> 1. Adopting a hard-line approach to the older, orphaned PRs. Even if
> they have some value or reflect real issues, if no-one is interested
> in cleaning up the request to get it merge ready then we close it.
>
> 2. Adopt a "open-one, close-one" guideline for core committers. Heck,
> I think every core committer has at least 1 or 2 open PRs representing
> various experiments and WIP in unfinished states. These should either
> be finished off, or closed and re-opened when the work is actually
> ready to go. And for test PRs which are "for comment only" I'd suggest
> a QEP is more likely to get better feedback and is the more
> appropriate place for this discussion of this nature.
>
> 3. Closing orphaned or risky PRs which are targeted to 2.18 and which
> have been fixed in master branch.
>
> 4. Sharing the hard work so that the magic pixies don't lose their
> magic powers :)
>
> Thoughts?
>


These are all good ideas!

I'd expecially go for 1, 3 and 4.


-- 
Alessandro Pasotti
w3:   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] Compiling QGIS3 on Ubuntu problems

[Alessandro Pasotti]

This looks like Qt4 and not Qt5:

#3  0x7fae50101b3f in QReadWriteLock::QReadWriteLock() () at
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x7fae4fe659ac in  () at /usr/lib/x86_64-linux-gnu/libQtDBus.so.4
#5  0x7fae4fe65e75 in QDBusMetaType::registerMarshallOperators(int,
void (*)(QDBusArgument&, void const*), void (*)(QDBusArgument const&,
void*)) () at /usr/lib/x86_64-linux-gnu/libQtDBus.so.4




On Fri, May 4, 2018 at 10:47 PM, Paulo van Breugel <p.vanbreu...@gmail.com>
wrote:

> Hi Etienne
>
> Thanks for the reply. I does (I should have seen that). However, next, I
> am getting (with ptrace_scope set to 0):
>
> QGIS died on signal 11[New LWP 26618]
> [New LWP 26619]
> [New LWP 26620]
> [New LWP 26621]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 0x7fae644126c2 in __GI___waitpid (pid=26622, stat_loc=0x7ffcb53cd7e4,
> options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
> 30../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> [Current thread is 1 (Thread 0x7fae687ec3c0 (LWP 26617))]
> #0  0x7fae644126c2 in __GI___waitpid (pid=26622,
> stat_loc=0x7ffcb53cd7e4, options=0) at ../sysdeps/unix/sysv/linux/
> waitpid.c:30
> resultvar = 18446744073709551104
> sc_cancel_oldtype = 0
> #1  0x56377281a8ec in qgisCrash(int) ()
> #2  0x7fae6436cf20 in  () at
> /lib/x86_64-linux-gnu/libc.so.6
> #3  0x7fae50101b3f in QReadWriteLock::QReadWriteLock() () at
> /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> #4  0x7fae4fe659ac in  () at /usr/lib/x86_64-linux-gnu/libQtDBus.so.4
> #5  0x7fae4fe65e75 in QDBusMetaType::registerMarshallOperators(int,
> void (*)(QDBusArgument&, void const*), void (*)(QDBusArgument const&,
> void*)) () at /usr/lib/x86_64-linux-gnu/libQtDBus.so.4
> #6  0x7fae2b7abeb6 in  () at /usr/lib/x86_64-linux-gnu/qt5/
> plugins/platforminputcontexts/libibusplatforminputcontextplugin.so
> #7  0x7fae654f3ff0 in QPlatformInputContextFactory::create(QString
> const&) () at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
> #8  0x7fae3d96aa60 in QXcbIntegration::initialize() () at
> /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
> #9  0x7fae6550b449 in QGuiApplicationPrivate::eventDispatcherReady()
> () at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
> #10 0x7fae64f56575 in QCoreApplicationPrivate::init() () at
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> #11 0x7fae6550ceaf in QGuiApplicationPrivate::init() () at
> /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
> #12 0x7fae65cd2649 in QApplicationPrivate::init() () at
> /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> #13 0x7fae66a319c0 in QgsApplication::QgsApplication(int&, char**,
> bool, QString const&, QString const&) () at /usr/local/qgis/lib/libqgis_
> core.so.3.0.2
> #14 0x56377281d99a in main ()
> gdb returned 0
> Aborted (core dumped)
>
> This seems something totally different. Any idea what the problem could
> be, and how to solve this?
>
> Best wishes,
>
> Paulo
>
>
>
>
>
> On 04-05-18 21:15, Etienne Trimaille wrote:
>
> Have a look on https://github.com/qgis/QGIS/blob/master/INSTALL and
> search "error while loading shared libraries". Does it help?
>
> 2018-05-04 15:11 GMT-04:00 Paulo van Breugel <p.vanbreu...@gmail.com>:
>
>>
>> Dear devs,
>>
>>
>> I am trying to compile QGIS3 (release_3-0) on a freshly install Ubuntu
>> 18.04 (bionic). All seems to go well, no error messages during
>> configuration or running make and make install.
>>
>> When trying to run QGIS, however, I am getting the following error:
>>
>> ./qgis: error while loading shared libraries: libqgis_app.so.3.0.2:
>> cannot open shared object file: No such file or directory
>>
>> Any idea what went wrong here, and how to solve this?
>>
>> Best wishes,
>>
>> Paulo
>>
>>
>>
>>
>> ___
>> 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
>



-- 
Alessandro Pasotti
w3:   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] Profile Tool's new owner

[Alessandro Pasotti]

Hi Borys,

the maintaner can be changed in the control panel and she is the user who
created the plugin record in the DB.


Owners are zero or more additional user that have admin privileges over the
plugin.




On Fri, May 4, 2018 at 3:22 PM, Borys Jurgiel <li...@borysjurgiel.pl> wrote:

> Hi List,
>
> Just wanted to let you know I've changed the Profile Tool plugin owner to
> Javier, who is the real developer for some time (Etienne and Patrice, who
> was
> taking care about the plugin last years are no longer acitive, and users
> was
> forced to use Javier's fork).
>
> Btw. what is the difference between owner and maintainer? I can't change
> the
> latter (although it's not necessary if owners can upload new versions).
>
> Regards,
> Borys
>
>
>
>
>


-- 
Alessandro Pasotti
w3:   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] [Qgis-user] New WEB Suite for QGIS - G3W-SUITE

[Alessandro Pasotti]

Great job!!

Thanks for sharing

On Wed, May 2, 2018 at 12:09 PM, Walter Lorenzetti <lorenze...@gis3w.it>
wrote:

> Hi users, hi developers,
>
> I am pleasure to introduce you a new suite to publish QGIS projects on web
> by QGIS-Server  that we developed in past 2-3 years at GIS3W.
>
> G3W-SUITE is a modular client-server application developed with Django and
> Vue.js.
>
> Main github repositoryies is https://github.com/g3w-suite
>
> Main Django application (G3W-ADMIN) is https://github.com/g3w-suite/
> g3w-admin and main webmap client applications are
>
> https://github.com/g3w-suite/g3w-client-sdk,
>
> https://github.com/g3w-suite/g3w-client-template-lte ,
>
> https://github.com/g3w-suite/g3w-client
>
> In normal developing workflow, client application is compiled and put
> inside main server Django application.
>
> To run the suite is enough deploy main Django application G3W-ADMIN.
>
> If you want to try it and/or (if you like it :)) partecipate to the
> project you are Welcome!
>
> Comments and suggestions are welcome!
>
> We are a small company, so is possibile we reply to your question with a
> slight delay :)
> Bye
> W
>
> --
>
> Walter Lorenzetti phD
> email: lorenze...@gis3w.it
> skype: aiki74
> twitter:w_lorenzetti <https://twitter.com/w_lorenzetti>
> g+:aiki74 <https://plus.google.com/117055903318462447104/>
> Tel/Cell: (+39) 347-6597931
> Viale Verdi 24 - 51016 Montecatini Terme (PT)
> Nuovi corsi QGIS e GFOSS
> <http://gis3w.it/it/calendario-corsi-software-geografici>
>
> ___
> Qgis-user mailing list
> qgis-u...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>



-- 
Alessandro Pasotti
w3:   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

[QGIS-Developer] QEP 122 - Python vector data providers

[Alessandro Pasotti]

Hi everyone,

Here is a new proposal to add support for Python vector data providers

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/122

Any comments would be highly appreciated!

PS: A QEP a day keeps the doctor away ;-)

-- 
Alessandro Pasotti
w3:   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] Drill-down (cascading) forms in QGIS Value Relation Widgets crowdfunding

[Alessandro Pasotti]

Hi,

I'll try to address all concerns in a single mail (what a challenge!)

First I would like to say that everybody has access to a different set of
"average/typical users" and I cannot claim any statistical relevance to the
group of users I've been in touch with.

But the user's feedback that I've got so far is that the Value-Relation
widget (V-RW) is easier to use and to understand: its scope it's limited to
how data are entered and viewed and does not depend on a
model-project-level constraint (the Relation-Reference R-RW does).

Those (statistically insignificant) users were quite emotional and ready to
fight to keep V-RW live and healthy :)

Code-wise I totally agree that the two widgets could share more logic and
options, but given the intricacies of the attr-table and widgets-forms
logic this is not trivial at all, and it's not in scope with this QEP 116
enhancement.

Coming to the new functionalities introduced by QEP 116, the way they will
be implemented will make them easily reusable in the context of the R-RW:

- form scope context with geometry and attributes
- form scope available in both the form and the attribute table

Of course existing bugs and glitches in the V-RW workflow will be fixed on
the way when they not imply rewriting the whole QGIS core ;)


What could be considered here, is to add a second goal to the campaign for
making the new features available to the R-RW too, what do you think?

But even without this additional goal, I still think that this QEP (which
is not a complete refactoring of the whole form/attr-table *-R widgets) is
a step forward and in the direction of a future better integration of the
existing *-R-widgets.


That's why I'm joining Nyall's call to contribute and make this a reality.


Also note that some of Règis requirements, like a geographical dynamic
filter will be possible with an expression like:

... AND contains(buffer( $current_form_geometry, 10), $geometry)

note that this expression is the one used to filter the values in the
related layer, and it will have access to the geometry of the feature
currently being edited/added in the form (or table row) as well as to the
form (row) values, so:

- $current_form_geometry = the geometry of the feature currently being
edited in the form
- $geometry = the geometry of the related layer that is being filtered to
get the list of values for the combo/search/etc...

Also note that the V-RW is already used in the identify results panel (and
form of course).


Cheers

-- 
Alessandro Pasotti
w3:   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] About merging a commit to fix the bug #18132 in QGIS 2.18

[Alessandro Pasotti]

On Thu, Apr 12, 2018 at 10:56 AM, andreaerdna <andreaer...@libero.it> wrote:

> Dear Alessandro,
> thanks for the tips.
>
> The strange thing is that my original pull request (#6524) passed all the
> tests so it would have been possible to merge it, but it was later closed
> by
> Nyall Dawson that slightly modified my commit and submitted a new pull
> request (#6620) that doesn't pass the tests.
>
> Do you think it would be appropriate to submit again the original pull
> request in order to circumvent this "impasse"?
>
> Best regards.
>
>
No: I think that what you need to do is to check the failure (which appears
to be a minor difference of 1 pixel in the size of the generate image) and
replace the reference image in order to make the test pass.


-- 
Alessandro Pasotti
w3:   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

[QGIS-Developer] QEP: Add OpenCL support for processing core algs (and possibly other parts of the core)

[Alessandro Pasotti]

Hi everyone

Here is a new proposal to add support for OpenCL to processing core algs
(and possibly other parts of the core in the future):

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/121

Any comments would be highly appreciated!

-- 
Alessandro Pasotti
w3:   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