Re: [Qgis-developer] Number of arguments for processing gdalogr:warpreproject

2016-07-20 Thread Victor Olaya 
2016-06-28 13:34 GMT+02:00 Tom Chadwin :
> I'm sorry to keep asking about this. I'm now getting this error on Travis,
> against nightly (http://qgis.org/debian-nightly):
>
> Traceback (most recent call last):
>   File "/home/travis/build/tomchadwin/qgis2web/olwriter.py", line 58, in
> writeOL
> optimize, usedFields, json)
>   File "/home/travis/build/tomchadwin/qgis2web/utils.py", line 293, in
> exportLayers
> processing.runalg("gdalogr:warpreproject", warpArgs)
>   File "/usr/share/qgis/python/plugins/processing/tools/general.py", line
> 75, in runalg
> alg = Processing.runAlgorithm(algOrName, None, *args, **kwargs)
>   File "/usr/share/qgis/python/plugins/processing/core/Processing.py", line
> 304, in runAlgorithm
> ret = runalg(alg, progress)
>   File "/usr/share/qgis/python/plugins/processing/gui/AlgorithmExecutor.py",
> line 52, in runalg
> progress.error(e.msg)
> AttributeError: 'NoneType' object has no attribute 'error'
>


Tom,

I just commited a change that should fix this issue

https://github.com/qgis/QGIS/commit/df2ca2e60798315d816966f25aa024b93835f776

Could you try again and see if now you dont get that error?

Thanks!
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] plugins.qgis.org star vote feeback

2016-07-20 Thread Tom Chadwin 
-1 for Disqus. How about an easy step in this direction: have a field for a
Twitter account. Authors could decide whether to populate with their own or
create an account dedicated to their plugin.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/plugins-qgis-org-star-vote-feeback-tp5277371p5277465.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Managing a future 2.18 or 3.0 documentation?

2016-07-20 Thread Richard Duivenvoorde 
On 20-07-16 09:29, Yves Jacolin wrote:
> Matthias, Harrissou,
> 
> On Wednesday, July 20, 2016 9:12:17 Matthias Kuhn wrote:
>> Hi Harrissou
>>
>> On 07/20/2016 08:47 AM, DelazJ wrote:
>> [..]
>>
>>> So questions:
>>> - Will we have a 2.18 (if ever) documentation?
>>
>> I think it would be good to plan 2.18 in general. Triggering the release
>> scripts should be trivial. Since some features end up in 2.18, I guess
>> it will happen.
>> Concerning docs and also pre-release fixing, I wonder if this effort
>> should be spent on the 3.0 migration instead?
> 
> So, either we can know which feature is in 2.18 and which in 3.0 and we can 
> target the ticket (in the doc repository) in the two milestone and without 
> much work, or we can't.
> 
> Anyway, as we are "still" working in the 2.16 release,  I guess we can aims 
> to 
> release it at the end of the year, not before.
> 
> Next, we should focus on 3.0 to get the doc ready for QGIS 3.0, at the 
> beginning of 2017.
> 
> So +1 for your proposition.
> 
>> [..]
>>> - Should the webhook set different milestions according to the branch
>>> used?
>>
>> Yes, master_2 => 2.18, master => 3.0.
> Are you sure? 2.18 milestone doesn't exist in the QGIS doc repository.
> 
>>
>> Has there ever been a documentation released for 2.10 and 2.12?
>> If non-LTR get no documentation, there's probably not much point in
>> doing one for 2.18 I think?
>> People can still refer to the "testing" doc from master instead which
>> should match in many points (and where not, some notes can be included).
> Indeed, but this is more a consequence than a cause. In the mid term I prefer 
> that we add new feature in the doc in the same time that the ticket is 
> created 
> and so get a documentation release for each QGIS release.

We tried in history, but the doc (and doc release-) team could just not
cope with all the releases. So we more or less decided to only build (at
least translated) the docs for LTR versions.

2.16 is non-ltr and 2.18 is a special case.. so I would also be OK to
concentrate on a docs build  for 3.0. So only pick features which will
be ported to 3.0 from 2.16 and 2.18 etcetc

But we can off course try to follow... currently '[FEATURE]' is
automatically labeled as 3.0 milestone...
IF we want to distinguish between those, we either have to fix the script:
https://github.com/qgis/QGIS-Sysadmin/blob/master/webhooks/github_feature_tracker.cgi
Or do it by hand...

Regards,

Richard
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] WFS Provider Strategies

2016-07-20 Thread Andrea Aime 
On Wed, Jul 20, 2016 at 6:17 PM, Even Rouault 
wrote:

> The issues were with multiple layer joins with GeoServer in some
> circumstances not very
> clearly understood ( I don't want to particularly point fingers at
> GeoServer, as server side joins is a pretty advanced feature rarely
> implemented by servers)
>

The WFS 2.0 joining implementation in GeoServer can certainly use some
love. Some fixes have been
made in the last year, but there is still a significant limitation, the
join has to be a "star" one,
with a central feature type joining with the others, while a list one
cannot be made, e.g.:
* ((T1 join T2) join T3) can always be made (by reshuffling thing so that
T2 is the center)
* ((T1 join T2) join T3) join T4) cannot be implemented without changing
the API down in GeoTools instead, that would be quite a bit of work
(sponsorship welcomed ;-) )

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] WFS Provider Strategies

2016-07-20 Thread Matthias Kuhn 
On 20/07/16 18:17, Even Rouault wrote:

>> True... Although we could replace the features in the cache instead of
>> dropping the new ones for a tiny improvement.
> That would indeed help for the next feature request
>
>> There might be less complicated examples but this is the one I managed to 
>> find quickly in my mail box...

Ok, so it's really required... But I think the labelling of the checkbox
should somehow better reflect the situation.

I think already inverting the question to "Do not send bounding box
filter to server" would help to raise awareness. And with a tooltip
explaining that this only is used for certain server scenarios it would
be enough information for everyone.

My thinking now was "Of course I only want only features in the bbox.
But wait, why would I even have to opt-in? Is there something wrong with
it? Will other features be missing from the attribute table if I put a
check there?"

Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] WFS Provider Strategies

2016-07-20 Thread Even Rouault 

> True... Although we could replace the features in the cache instead of
> dropping the new ones for a tiny improvement.

That would indeed help for the next feature request

> 
>  Question: *is **there anybody using WFS with this option unchecked?*
>  And if yes, for what reason?
> >>> 
> >>> Yes it is needed for some use cases. There are servers that have buggy
> >>> behaviour with BBOX requests combined with other filters. Or the cost
> >>> of solving a spatial request might be super high, making it more
> >>> practical to issue a GetFeature without a BBOX.
> >> 
> >> Ok, so it should be a super well hidden checkbox with a big warning sign
> >> next to it?
> > 
> > That really depend on servers. If the current default behaviour is OK for
> > most, it might still be useful that the option is not too hidden if users
> > have issues with some servers. They might have a better chance of trying
> > to uncheck the option. Where would you hide it ?
> > Note: this is not new to 2.16 as far as I remember. The option was
> > already there.
> 
> Well, I was confused and I know of others which are confused.
> 
> At the moment it's really hard to tell which is the recommended option
> and which one is the "try this if your sever is broken" option. We could
> just add a warning if it's unchecked which says "only do this if there
> are problems with the default" or put it into an advanced dialog or so.
> Have you actually seen such servers? And if yes, can you name them?

The issues were with multiple layer joins with GeoServer in some circumstances 
not very
clearly understood ( I don't want to particularly point fingers at
GeoServer, as server side joins is a pretty advanced feature rarely implemented 
by servers)

You need to get an API key at
 https://data.linz.govt.nz/group/owner-data-controlled-access-group/

And then try the following SQL request

 SELECT DISTINCT
   par.id,
   par.status,
   own.owner_type,
   own.prime_surname,
   own.prime_other_names,
   own.corporate_name,
par.shape
FROM
   "layer-1571" AS par
   JOIN "table-1569" AS tpa ON par.id = tpa.par_id
   JOIN "table-1564" AS own ON tpa.title_no = own.title_no
WHERE
   ST_Within(par.shape, ST_MakeEnvelope(174.806, -41.347, 174.846, -41.285, 
'EPSG:4167’))

The server will not like the extra addition of the BBOX.

There might be less complicated examples but this is the one I managed to find 
quickly in my mail box...

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] WFS Provider Strategies

2016-07-20 Thread Matthias Kuhn 


On 20/07/16 17:51, Even Rouault wrote:
>> In which case does that help? Isn't every cached feature downloaded
>> again (with potentially more up to date information) anyway?
> You get the feeling of a more responsive UI when you can reuse already 
> downloaded features, but that's true that if the server content has changed 
> in 
> between, you won't get the new version. In which case you'll have to reload 
> the layer with F5.
True... Although we could replace the features in the cache instead of
dropping the new ones for a tiny improvement.
 Question: *is **there anybody using WFS with this option unchecked?* And
 if yes, for what reason?
>>> Yes it is needed for some use cases. There are servers that have buggy
>>> behaviour with BBOX requests combined with other filters. Or the cost of
>>> solving a spatial request might be super high, making it more practical
>>> to issue a GetFeature without a BBOX.
>> Ok, so it should be a super well hidden checkbox with a big warning sign
>> next to it?
> That really depend on servers. If the current default behaviour is OK for 
> most, it might still be useful that the option is not too hidden if users 
> have 
> issues with some servers. They might have a better chance of trying to 
> uncheck 
> the option. Where would you hide it ?
> Note: this is not new to 2.16 as far as I remember. The option was already 
> there.
Well, I was confused and I know of others which are confused.

At the moment it's really hard to tell which is the recommended option
and which one is the "try this if your sever is broken" option. We could
just add a warning if it's unchecked which says "only do this if there
are problems with the default" or put it into an advanced dialog or so.
Have you actually seen such servers? And if yes, can you name them?
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] WFS Provider Strategies

2016-07-20 Thread Even Rouault 
Hi,

> 
> I am a bit confused by the WFS option *"Only request features
> overlapping the view extent"*.
> 
> In general, that's what every provider does by default and is a safe
> strategy to use. If this option is unchecked, QGIS will just start
> downloading features randomly until it hits a server limit (or not).

Time to upgrade the servers to support WFS 2.0 paging :-)

> 
> The only reason why one would possibly want to do that is to warm a
> cache on a layer where he know he will be getting all the features (in a
> reasonable time). In this case, the option should probably be renamed
> (to something containing the word "cache").

The provider always cache (meaning keep in a temporary database the features 
retrieved), whatever you check or uncheck this option. For example with the 
default behaviour, zoom in in some region and wait for some or all features to 
be retrieved, and zoom out. The provider will use the already downloaded 
features first and then return the features coming from the background 
downloading of the new request (using gml:id/fid to make sure not to return 
already cached features).

> 
> Question: *is **there anybody using WFS with this option unchecked?* And
> if yes, for what reason?

Yes it is needed for some use cases. There are servers that have buggy 
behaviour with BBOX requests combined with other filters. Or the cost of 
solving a spatial request might be super high, making it more practical to 
issue a GetFeature without a BBOX.

> 
> Apart from this, Raymond noticed that cached features are not dismissed,
> when they are re-downloaded so you end up with duplicated features after
> multiple rendering cycles. Does that ring a bell for someone?

That should be better explained to be sure. It might be an issue with the 
features returned by the server having not a stable gml:id (or even not a id 
at all). Richard raised a ticket about that.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] WFS Provider Strategies

2016-07-20 Thread Even Rouault 
> In which case does that help? Isn't every cached feature downloaded
> again (with potentially more up to date information) anyway?

You get the feeling of a more responsive UI when you can reuse already 
downloaded features, but that's true that if the server content has changed in 
between, you won't get the new version. In which case you'll have to reload 
the layer with F5.

> 
> >> Question: *is **there anybody using WFS with this option unchecked?* And
> >> if yes, for what reason?
> > 
> > Yes it is needed for some use cases. There are servers that have buggy
> > behaviour with BBOX requests combined with other filters. Or the cost of
> > solving a spatial request might be super high, making it more practical
> > to issue a GetFeature without a BBOX.
> 
> Ok, so it should be a super well hidden checkbox with a big warning sign
> next to it?

That really depend on servers. If the current default behaviour is OK for 
most, it might still be useful that the option is not too hidden if users have 
issues with some servers. They might have a better chance of trying to uncheck 
the option. Where would you hide it ?
Note: this is not new to 2.16 as far as I remember. The option was already 
there.


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] WFS Provider Strategies

2016-07-20 Thread Matthias Kuhn 
On 20/07/16 17:35, Even Rouault wrote:

> Hi,
>
>> I am a bit confused by the WFS option *"Only request features
>> overlapping the view extent"*.
>>
>> In general, that's what every provider does by default and is a safe
>> strategy to use. If this option is unchecked, QGIS will just start
>> downloading features randomly until it hits a server limit (or not).
> Time to upgrade the servers to support WFS 2.0 paging :-)
Who could object to that :-)
>
>> The only reason why one would possibly want to do that is to warm a
>> cache on a layer where he know he will be getting all the features (in a
>> reasonable time). In this case, the option should probably be renamed
>> (to something containing the word "cache").
> The provider always cache (meaning keep in a temporary database the features 
> retrieved), whatever you check or uncheck this option. For example with the 
> default behaviour, zoom in in some region and wait for some or all features 
> to 
> be retrieved, and zoom out. The provider will use the already downloaded 
> features first and then return the features coming from the background 
> downloading of the new request (using gml:id/fid to make sure not to return 
> already cached features).
In which case does that help? Isn't every cached feature downloaded
again (with potentially more up to date information) anyway?
>
>> Question: *is **there anybody using WFS with this option unchecked?* And
>> if yes, for what reason?
> Yes it is needed for some use cases. There are servers that have buggy 
> behaviour with BBOX requests combined with other filters. Or the cost of 
> solving a spatial request might be super high, making it more practical to 
> issue a GetFeature without a BBOX.
Ok, so it should be a super well hidden checkbox with a big warning sign
next to it?

Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] WFS Provider Strategies

2016-07-20 Thread Matthias Kuhn 
Hi,

I am a bit confused by the WFS option *"Only request features
overlapping the view extent"*.

In general, that's what every provider does by default and is a safe
strategy to use. If this option is unchecked, QGIS will just start
downloading features randomly until it hits a server limit (or not).

The only reason why one would possibly want to do that is to warm a
cache on a layer where he know he will be getting all the features (in a
reasonable time). In this case, the option should probably be renamed
(to something containing the word "cache").

Question: *is **there anybody using WFS with this option unchecked?* And
if yes, for what reason?

Apart from this, Raymond noticed that cached features are not dismissed,
when they are re-downloaded so you end up with duplicated features after
multiple rendering cycles. Does that ring a bell for someone?

Best Regards

Matthias

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] plugins.qgis.org star vote feeback

2016-07-20 Thread Akbar Gumbira 
There is a ticket related here https://hub.qgis.org/issues/6478. We had a
discussion whether we should have the feedbacks on our side or usea 3rd
party plugin such as disqus, but it did not go much further than that.

Cheers

On Wed, Jul 20, 2016 at 4:45 PM, Paolo Cavallini 
wrote:

> Il 20/07/2016 16:40, C Hamilton ha scritto:
> > I don't know if it is possible, but it would be really nice if there
> > were a way to get feedback on what a user likes or especially what the
> > user dislikes when they vote on a QGIS plugin. If they give it a 1, 2,
>
> Hi,
> agreed, this would be a very nice feature (even though we should be
> careful about the potential implication - remember we have a potential
> user base in the order of 100k users). Could you please open a feature
> req, or much better help us coding it?
> All the best.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer




-- 

*---*
*Akbar Gumbira *
*www.akbargumbira.com *
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] plugins.qgis.org star vote feeback

2016-07-20 Thread Paolo Cavallini 
Il 20/07/2016 16:40, C Hamilton ha scritto:
> I don't know if it is possible, but it would be really nice if there
> were a way to get feedback on what a user likes or especially what the
> user dislikes when they vote on a QGIS plugin. If they give it a 1, 2,

Hi,
agreed, this would be a very nice feature (even though we should be
careful about the potential implication - remember we have a potential
user base in the order of 100k users). Could you please open a feature
req, or much better help us coding it?
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] plugins.qgis.org star vote feeback

2016-07-20 Thread C Hamilton 
I don't know if it is possible, but it would be really nice if there were a
way to get feedback on what a user likes or especially what the user
dislikes when they vote on a QGIS plugin. If they give it a 1, 2, or 3 star
vote I would really like to know why. I would take the steps to try and fix
what they don't like. I know they could take the extra step of posting
something on the github page, but knowing that I am somewhat lazy I
wouldn't take that extra step unless I had a real compelling reason. Also I
think that unless a user is a developer they are not likely to post a
problem on github. I base this on the fact that I am new to github and
wouldn't have taken that step a year or more ago.

If there were a way to make giving feedback really easy as a part of the
clicking on the stars I think it would be quite beneficial to the
developers.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Will be submitting new QGIS D3 Chart plugin - experimental or not

2016-07-20 Thread Neumann, Andreas 
Hi, 

You can submit it as non-experimental right away, if you think it is
already mature enough. I think this flag is self-declared - up to the
developer to decide. Paolo, who checks new plugins may suggest to the
plugin author to mark it as experimental if he thinks it is not yet
mature enough. 

Reasons for experimental: 

- still under early development (initial version) 

- may fail in a lot of cases (unsuitable for production use) 

- no documentation at all - not obvious for the user how to use it 

It looks like a very nice plugin - thank you for developing and
submitting it! Definitely useful for people doing time analysis. I will
recommend it to my local police, who already is doing crime analysis
with QGIS. 

Greetings, 

Andreas 

On 2016-07-20 16:22, C Hamilton wrote:

> I am planning on submitting a new D3 plugin to the QGIS plugins repo. This 
> generates a circular heatmap D3 web page that has some similarities to the 
> ArcGIS data clock. This is the github link.
> 
> https://github.com/NationalSecurityAgency/qgis-d3datavis-plugin
> 
> I have done a write up that shows what it does. The question that I have is 
> when should a plugin be marked experimental? Are their advantages in marking 
> it experimental? I think what I have done so far is fairly solid and the only 
> changes will be to improve upon it and perhaps add some other charts.
> 
> I would appreciate your thoughts before I submit the plugin. 
> 
> Thanks,
> 
> Calvin 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Will be submitting new QGIS D3 Chart plugin - experimental or not

2016-07-20 Thread Paolo Cavallini 
Hi Calvin,

Il 20/07/2016 16:22, C Hamilton ha scritto:
> I am planning on submitting a new D3 plugin to the QGIS plugins repo.
> This generates a circular heatmap D3 web page that has some similarities
> to the ArcGIS data clock. This is the github link.
> 
> https://github.com/NationalSecurityAgency/qgis-d3datavis-plugin
> 
> I have done a write up that shows what it does. The question that I have
> is when should a plugin be marked experimental? Are their advantages in
> marking it experimental? I think what I have done so far is fairly solid
> and the only changes will be to improve upon it and perhaps add some
> other charts.
> 
> I would appreciate your thoughts before I submit the plugin.

Thanks for that. IMHO the experimental flag is useful if you want to
have a first test from a restricted community of, possibly more skilled,
users before submitting it to a worlwide audience of potentially
hundreds of thousands users. It is imperative if you suspect your plugin
might mess up user data or cause other inconveniences.
Please note that other efforts are underway to use graphical js libs
from within QGIS, so you may find convenient to join forces.
Looking forward to see your plugin, and publish it.
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Will be submitting new QGIS D3 Chart plugin - experimental or not

2016-07-20 Thread C Hamilton 
I am planning on submitting a new D3 plugin to the QGIS plugins repo. This
generates a circular heatmap D3 web page that has some similarities to the
ArcGIS data clock. This is the github link.

https://github.com/NationalSecurityAgency/qgis-d3datavis-plugin

I have done a write up that shows what it does. The question that I have is
when should a plugin be marked experimental? Are their advantages in
marking it experimental? I think what I have done so far is fairly solid
and the only changes will be to improve upon it and perhaps add some other
charts.

I would appreciate your thoughts before I submit the plugin.

Thanks,

Calvin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QgsMapLayer.source() for a WFS now returns a different string

2016-07-20 Thread Tom Chadwin 
Thanks again, Even:

QgsDataSourceURI(layer.dataProvider().dataSourceUri())

Tom



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/QgsMapLayer-source-for-a-WFS-now-returns-a-different-string-tp5277278p5277353.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QgsMapLayer.source() for a WFS now returns a different string

2016-07-20 Thread Tom Chadwin 
Even Rouault-2 wrote
> You can use QgsDataSourceURI.param("url") to retrieve the url parameter.
> You 
> 'll need to augment it with SERVICE, VERSION and REQUEST parameters to
> form a 
> valid GetFeature request.

Many apologies, but how do I retrieve the QgsDataSourceURI of a layer? I'm
not managing to get it to work.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/QgsMapLayer-source-for-a-WFS-now-returns-a-different-string-tp5277278p5277347.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QgsMapLayer.source() for a WFS now returns a different string

2016-07-20 Thread Even Rouault 
Le mercredi 20 juillet 2016 15:21:57, Tom Chadwin a écrit :
> Even Rouault-2 wrote
> 
> > You can use QgsDataSourceURI.param("url") to retrieve the url parameter.
> > You
> > 'll need to augment it with SERVICE, VERSION and REQUEST parameters to
> > form a
> > valid GetFeature request.
> 
> Many apologies, but how do I retrieve the QgsDataSourceURI of a layer? I'm
> not managing to get it to work.

Something like QgsDataSourceURI(layer.provider().dataSourceUri())

> 
> 
> 
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/QgsMapLayer-source-for-a-WFS-now-retur
> ns-a-different-string-tp5277278p5277347.html Sent from the Quantum GIS -
> Developer mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Add feature to QGIS LTR core plugins

2016-07-20 Thread Matthias Kuhn 
On 20/07/16 14:26, Nathan Woodrow wrote:
> Not sure we can?  2.14 is bug fix only.  Given it's Python though you
> could just patch their copy.
>
Same thinking here, in general a release should receive bugfixes, not
features.

In the past we played with shipping updates through the plugin manager
(see processing) but it turned out, that suddenly certain features were
shipped via plugin manager to old installations without required APIs
available. Or core plugin being newer but shadowed by the custom
installed (plugin manager). This road might be possible but would
require proper versioning of core plugins and properly setting min- and
max- version on it (and probably also some logic in the plugin manager
to decide which one to load).

In short: If it cannot be called a bugfix, I'd say just ship it in a
custom repository to your customers and make them aware it needs to be
uninstalled on next QGIS update.

Matthias

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QgsMapLayer.source() for a WFS now returns a different string

2016-07-20 Thread Tom Chadwin 
Perfect - thanks so much for the extremely thorough answer. I still don't
understand why my tests aren't failing with 2.16/master, but there we go...

Thanks again

Tom



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/QgsMapLayer-source-for-a-WFS-now-returns-a-different-string-tp5277278p5277331.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Add feature to QGIS LTR core plugins

2016-07-20 Thread Neumann, Andreas 
Hi René-Luc, 

There are no new features in past versions - only bug fixes. This also
applies to LT releases. 

Sometimes it is a bit of a discussion if something qualifies as bug fix
or a feature, e.g. if something really essential is missing. So if you
can sell it as a "bug fix" it may get in. 

But it is up to Jürgen to decide. 

Andreas 

On 2016-07-20 14:25, René-Luc Dhont wrote:

> Hi devs,
> 
> I just made a Pull-Request to add a feature to DB manager.
> https://github.com/qgis/QGIS/pull/3322
> Add the ability to update SQL Layer (to tweak the query)
> 
> I'd like to know what is the official ways adding features to QGIS LTR core 
> plugins ?
> My customer will be happy to see it in release-2_14.
> 
> Reagrds,
> René-Luc
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Add feature to QGIS LTR core plugins

2016-07-20 Thread Nathan Woodrow 
Not sure we can?  2.14 is bug fix only.  Given it's Python though you could
just patch their copy.

On Wed, Jul 20, 2016 at 10:25 PM, René-Luc Dhont  wrote:

> Hi devs,
>
> I just made a Pull-Request to add a feature to DB manager.
> https://github.com/qgis/QGIS/pull/3322
> Add the ability to update SQL Layer (to tweak the query)
>
> I'd like to know what is the official ways adding features to QGIS LTR
> core plugins ?
> My customer will be happy to see it in release-2_14.
>
> Reagrds,
> René-Luc
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Add feature to QGIS LTR core plugins

2016-07-20 Thread René-Luc Dhont 

Hi devs,

I just made a Pull-Request to add a feature to DB manager.
https://github.com/qgis/QGIS/pull/3322
Add the ability to update SQL Layer (to tweak the query)

I'd like to know what is the official ways adding features to QGIS LTR 
core plugins ?

My customer will be happy to see it in release-2_14.

Reagrds,
René-Luc
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QgsMapLayer.source() for a WFS now returns a different string

2016-07-20 Thread Even Rouault 
Le mercredi 20 juillet 2016 11:57:19, Tom Chadwin a écrit :
> I was retrieving the URL of a WFS layer, and formatting it for Leaflet as
> follows:
> 
> layerSource = layer.source()
> layerSource += "&outputFormat=text%2Fjavascript&"
> layerSource += "format_options=callback%3AmyCallback"
> wfsVars += ('' % layerSource)
> 
> This no longer works, because source() on a WFS layer now (2.16 Win7x64)
> returns a string of the format:
> 
> retrictToRequestBBOX='1' srsname='EPSG:27700'
> typename='yorkshire_dales:ydnpa_route_accessibility'
> url='http://maps.nationalparks.gov.uk/geoserver/wfs' table="" sql=
> 
> When did this change?

in 2.16

> And can I retrieve the URL as I did before, or am I
> going to have to hack this new string around to build the WFS URL?

You can use QgsDataSourceURI.param("url") to retrieve the url parameter. You 
'll need to augment it with SERVICE, VERSION and REQUEST parameters to form a 
valid GetFeature request.

> 
> Thanks
> 
> Tom
> 
> 
> 
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/QgsMapLayer-source-for-a-WFS-now-retur
> ns-a-different-string-tp5277278.html Sent from the Quantum GIS - Developer
> mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QgsMapLayer.source() for a WFS now returns a different string

2016-07-20 Thread Tom Chadwin 
I was retrieving the URL of a WFS layer, and formatting it for Leaflet as
follows:

layerSource = layer.source()
layerSource += "&outputFormat=text%2Fjavascript&"
layerSource += "format_options=callback%3AmyCallback"
wfsVars += ('' % layerSource)

This no longer works, because source() on a WFS layer now (2.16 Win7x64)
returns a string of the format:

retrictToRequestBBOX='1' srsname='EPSG:27700'
typename='yorkshire_dales:ydnpa_route_accessibility'
url='http://maps.nationalparks.gov.uk/geoserver/wfs' table="" sql=

When did this change? And can I retrieve the URL as I did before, or am I
going to have to hack this new string around to build the WFS URL?

Thanks

Tom



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/QgsMapLayer-source-for-a-WFS-now-returns-a-different-string-tp5277278.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] ubuntu 2.16 packages core dump

2016-07-20 Thread matteo 
Hi guys,
any news on this error?

tried to change the repo with those for the 2.14 and I'm not
experiencing the same error..

Thanks

Matteo
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PyQgsAppStartup failing with Timeout on OSX

2016-07-20 Thread Matthias Kuhn 
On 20/07/16 09:31, Radim Blazek wrote:

> On Tue, Jul 19, 2016 at 10:07 PM, Radim Blazek  wrote:
>> On Tue, Jul 19, 2016 at 7:11 PM, Radim Blazek  wrote:
>>> This is failing https://travis-ci.org/qgis/QGIS/jobs/145868490 with
>>> Timeout  60.05 sec.
>>>
>>> Any idea why? I have merged pull request with just GRASS config files
>>> (xml) and 2 python scripts which are not called from tests.
>> With the next commit the test on Mac is passing but PyQgsServerWFST
>> (which I certainly had not touched) failing on Linux / gcc. It looks
>> like random, but I see that it is not failing for others.
> Both tests passed when I had manually relaunched the tests on Travis.
> Do others also have to fiddle with Travis this way?

Unfortunately some tests do not run stable. E.g. PyQgsAppStartup seems
to freeze and runs into a 60 secods timeout every once in a while. But
it's some kind of race condition or other external factors triggering this.
Some tests have been disabled because they were unstable, but mainly the
ones depending on external services (e.g. osm). I don't really want to
do this with the app startup test because it often reveals python problems.

So in short, somebody needs to look into this (these?) issue(s). Until
then we are probably left with restarting or ignoring the tests if we
see it fail because of the timeout.

Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PyQgsAppStartup failing with Timeout on OSX

2016-07-20 Thread Radim Blazek 
On Tue, Jul 19, 2016 at 10:07 PM, Radim Blazek  wrote:
> On Tue, Jul 19, 2016 at 7:11 PM, Radim Blazek  wrote:
>> This is failing https://travis-ci.org/qgis/QGIS/jobs/145868490 with
>> Timeout  60.05 sec.
>>
>> Any idea why? I have merged pull request with just GRASS config files
>> (xml) and 2 python scripts which are not called from tests.
>
> With the next commit the test on Mac is passing but PyQgsServerWFST
> (which I certainly had not touched) failing on Linux / gcc. It looks
> like random, but I see that it is not failing for others.

Both tests passed when I had manually relaunched the tests on Travis.
Do others also have to fiddle with Travis this way?

Radim
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Managing a future 2.18 or 3.0 documentation?

2016-07-20 Thread Yves Jacolin 
Matthias, Harrissou,

On Wednesday, July 20, 2016 9:12:17 Matthias Kuhn wrote:
> Hi Harrissou
> 
> On 07/20/2016 08:47 AM, DelazJ wrote:
> [..]
> 
> > So questions:
> > - Will we have a 2.18 (if ever) documentation?
> 
> I think it would be good to plan 2.18 in general. Triggering the release
> scripts should be trivial. Since some features end up in 2.18, I guess
> it will happen.
> Concerning docs and also pre-release fixing, I wonder if this effort
> should be spent on the 3.0 migration instead?

So, either we can know which feature is in 2.18 and which in 3.0 and we can 
target the ticket (in the doc repository) in the two milestone and without 
much work, or we can't.

Anyway, as we are "still" working in the 2.16 release,  I guess we can aims to 
release it at the end of the year, not before.

Next, we should focus on 3.0 to get the doc ready for QGIS 3.0, at the 
beginning of 2017.

So +1 for your proposition.

> [..]
> > - Should the webhook set different milestions according to the branch
> > used?
> 
> Yes, master_2 => 2.18, master => 3.0.
Are you sure? 2.18 milestone doesn't exist in the QGIS doc repository.

> 
> Has there ever been a documentation released for 2.10 and 2.12?
> If non-LTR get no documentation, there's probably not much point in
> doing one for 2.18 I think?
> People can still refer to the "testing" doc from master instead which
> should match in many points (and where not, some notes can be included).
Indeed, but this is more a consequence than a cause. In the mid term I prefer 
that we add new feature in the doc in the same time that the ticket is created 
and so get a documentation release for each QGIS release.

Y.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Managing a future 2.18 or 3.0 documentation?

2016-07-20 Thread Matthias Kuhn 
Hi Harrissou

On 07/20/2016 08:47 AM, DelazJ wrote:
> Hi folks,
> (sorry for the cross-posting)

being sorry doesn't make it any better ;)
honestly, I think in 99% of the cases it's fine to just target one or
the other.

> A few days ago, 2.14 doc has been released and the issues for 2.16 are
> being addressed now.

Thanks a lot for all your work on that!!

> 
> So questions:
> - Will we have a 2.18 (if ever) documentation?

I think it would be good to plan 2.18 in general. Triggering the release
scripts should be trivial. Since some features end up in 2.18, I guess
it will happen.
Concerning docs and also pre-release fixing, I wonder if this effort
should be spent on the 3.0 migration instead?

> - Are all features added to 2.18 also in 3.0 (and vice-versa)?

master_2 features should all also end up in master.
master features are not necessarily ported to master_2.

> - Should the webhook set different milestions according to the branch used?

Yes, master_2 => 2.18, master => 3.0.

Has there ever been a documentation released for 2.10 and 2.12?
If non-LTR get no documentation, there's probably not much point in
doing one for 2.18 I think?
People can still refer to the "testing" doc from master instead which
should match in many points (and where not, some notes can be included).

Matthias

> 
> [0] https://github.com/qgis/QGIS-Documentation/issues/1198
> [1] https://github.com/qgis/QGIS-Documentation/issues/1204
> 
> Regards,
> Harrissou
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Managing a future 2.18 or 3.0 documentation?

2016-07-20 Thread Neumann, Andreas 
Hi Harrissou, 

I would say 99% of the new features in the 2.x branch should also land
in the 3.x branch - otherwise it would be a waste ... in the opposite
direction it will be less, since new features that depend on an API
break can't be present in the 2.x. branch. 

It is also very likely that a 2.18 release will happen - we are still
waiting for Jürgens DXF/DWG import, which should land in 2.18 and 3.x 

If there will be a 2.18 documentation? This question I can't answer. If
2.18 is really the latest 2.x version (noone really knows exactly until
we have proper progress in the 3.x branch) it would make sense to have
documentation and also treat it as a LT version with extended bug
fixing. That's just my personal opinion and may not be the position of
PSC or other project members. 

Thanks and greetings, 

Andreas 

On 2016-07-20 08:47, DelazJ wrote:

> Hi folks, 
> (sorry for the cross-posting)
> 
> A few days ago, 2.14 doc has been released and the issues for 2.16 are being 
> addressed now. Thanks to the automatic [feature] webhook, we are able to 
> build the list of changes in doc as soon as features land. BUT but... 
> Currently, the webhook is set to tag newcoming issues as 3.0 milestone. And I 
> remarked there are some issues that are from master [0] or master_2 branch 
> [1] (I must confess I didn't check if these features were cherry-picked from 
> master and vice-versa) but if I'm not wrong: master --> 3.0 master_2 --> a 
> probable 2.18
> 
> So questions: - Will we have a 2.18 (if ever) documentation? - Are all 
> features added to 2.18 also in 3.0 (and vice-versa)? - Should the webhook set 
> different milestions according to the branch used?
> 
> [0] https://github.com/qgis/QGIS-Documentation/issues/1198
> [1] https://github.com/qgis/QGIS-Documentation/issues/1204
> 
> Regards, Harrissou 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer