Re: [QGIS-Developer] [Qgis-user] Bug with GeoPackage and Expressions?

[Jonathan Moules]

Hi Calvin,

This definitely sounds like the sort of thing you want to be doing in 
the data provider and not in QGIS!


Maybe Fast Text Search would be of use. Problem is that I'm not sure if 
it's included in the GeoPackage spec or QGIS' SQLite install, but it's 
in the default pre-compiled SQLite. https://www.sqlite.org/fts5.html


Using that for textual searches and more conventional Operators for 
numerical should get you the speed of SQLite with the flexibility you 
desire.


Cheers,

Jonathan

On 29/07/2021 14:23, C Hamilton wrote:
Ultimately what I am trying to do is to revamp the Search Layers 
plugin (https://plugins.qgis.org/plugins/searchlayers/) to allow 
searching using two different strings with NOT, AND, OR operators, 
case dependent or independent, with qualifiers where the strings are 
an exact match, within the string, begins with, and ends with. The 
plugin allows for searching across all layers and all attributes, or 
optionally a particular layer and attribute. The two strings may be 
required to match within each attribute or match in any of the 
attributes within the feature. I am trying to make it very flexible 
and easy to use. I know that QGIS has the Locator interface, but the 
users like the extra interactivity that Search Layers provides.


Here is the issue: For some of the searches I am creating a regular 
expression that matches the search parameters and iterating through 
each feature and then each attribute using *re.search* to do the 
comparison. Unfortunately, this is very slow. On a 2.2 million data 
set it can take 5-10 minutes to do the search. This is way too slow. 
The SQL search is less than 5 seconds. I am using a *QgsFeatureRequest 
*and then setting *request.setFilterExpression*. I am only using this 
when searching on a single layer and single attribute and I don't 
think there is the flexibility that there is with the regular 
expressions, but I don't really use SQL and don't know what is 
possible. It sounds like the SQL searching may be limited by the 
vector file type source.


Are there any other ways for searching that I am unaware of? The 
results of the search need to identify the feature in the layer and 
what attribute or attributes matched for each of the two strings and 
then I can apply the NOT, AND, OR operators. I am trying to 
satisfy user's requests to make Search Layers into what they want it 
to be and am finding it difficult to satisfy speed, vector file types, 
and flexibility. I welcome any suggestions. Ultimately I might just 
have to constrain the file types supported and say to convert the data 
first.


Thanks,

Calvin

On Thu, Jul 29, 2021 at 1:42 AM Nyall Dawson > wrote:


On Thu, 29 Jul 2021 at 15:31, Matthias Kuhn mailto:matth...@opengis.ch>> wrote:
>
> Can you fill a bug for this? The expression compiler in QGIS
should not forward it to ogr/gpkg/sqlite in this case.

My interpretation is that Calvin is setting a layer filter, so QGIS
expressions aren't involved (i.e. no bug).

Nyall

>
> Matthias
>
> On Wed, Jul 28, 2021 at 10:08 PM C Hamilton
mailto:adenacult...@gmail.com>> wrote:
>>
>> Thanks everyone for that explanation. This does complicate the
ability to set an expression filter in a plugin when it depends on
the data source type. I'm not sure what to do about that.
>>
>> Regards,
>> Calvin
>>
>> On Wed, Jul 28, 2021 at 8:00 PM Anita Graser
mailto:anitagra...@gmx.at>> wrote:
>>>
>>> Hi Calvin,
>>>
>>> 28 Jul 2021 21:43:40 C Hamilton mailto:adenacult...@gmail.com>>:
>>> > If I use LIKE instead of ILIKE then it works. It is like
ILIKE was not implemented for GeoPackage. Can anyone verify this?
>>>
>>> Yes, there seems to be no iLike in sqlite:
>>>
>>>

https://stackoverflow.com/questions/15480319/case-sensitive-and-insensitive-like-in-sqlite
>>>
>>> And therefore neither in geopackage.
>>>
>>> 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


___
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
___
QGIS-Developer mailing 

[QGIS-Developer] Fwd: Re: QGIS Docs: ReStructureText flavour?

[Jonathan Moules]

Thanks Rosa!

Both yes and no.

That does have the spec (though no reference to the "only::" thing), but 
it doesn't say what parser to use for it.


I see that the :ref: thing is pulled from python 
(https://devguide.python.org/documenting/#cross-linking-markup) but 
again, the parsers I've been trying are barfing on that (and one is a 
Python IDE!) meaning I can't actually reliably preview an RST which I 
imagine reduces contributions (I've lost an hour to this so far!).


A more general question to the community would be: Wouldn't it make more 
sense to use plain RST to allow the largest toolset possible to edit the 
docs?


Thanks again,

Jonathan


On 2021-03-31 13:28, l wrote:

Hey.
Is this what you are looking for:
https://docs.qgis.org/testing/en/docs/documentation_guidelines/writing.html#writing-documentation?
Best,
Rosa



-
MSc Rosa Aguilar - PhD Candidate
University of Twente
Faculty of Geoinformation Science and Earth Observation
Connect with me on LinkedIn
https://rosaguilar.github.io
-
The essential is invisible to the eye. Saint-Exupéry

-Original Message-
From: QGIS-Developer  On 
Behalf Of Jonathan Moules

Sent: 31 March 2021 14:21
To: QGIS Developer Mailing List 
Subject: [QGIS-Developer] QGIS Docs: ReStructureText flavour?

Hi List,

What flavour is the RST behind the QGIS docs? There are quite a few 
things in here that are syntax erroring all the parsers I'm trying and 
aren't in the basic RST spec either 
(https://docutils.sourceforge.io/docs/user/rst/cheatsheet.txt).


For example using ":ref:" for internal hyperlinks when the spec says 
they should be done like this:

https://docutils.sourceforge.io/docs/user/rst/quickref.html#internal-hyperlink-targets
(there is no "ref" in the specs). Or the `.. only:: html` that starts 
some files.


I tried looking at the QGIS Docs page but I couldn't see anything 
about what RST standard the docs should be written to. Where can I 
find the spec?


Cheers,

Jonathan

___
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] QGIS Docs: ReStructureText flavour?

[Jonathan Moules]

Hi List,

What flavour is the RST behind the QGIS docs? There are quite a few 
things in here that are syntax erroring all the parsers I'm trying and 
aren't in the basic RST spec either 
(https://docutils.sourceforge.io/docs/user/rst/cheatsheet.txt).


For example using ":ref:" for internal hyperlinks when the spec says 
they should be done like this: 
https://docutils.sourceforge.io/docs/user/rst/quickref.html#internal-hyperlink-targets 
(there is no "ref" in the specs). Or the `.. only:: html` that starts 
some files.


I tried looking at the QGIS Docs page but I couldn't see anything about 
what RST standard the docs should be written to. Where can I find the spec?


Cheers,

Jonathan

___
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 and privacy

[Jonathan Moules]

> I agree that exposing sensitive data would be problematic but sharing 
the username does not seem to be something too private. Your full name 
for example also appears in this mailing list or as part of your twitter 
account. So under which circumstances would it be problematic if your 
name would be written to a QGIS project file?



Not a lawyer, but I have an interest in the GDPR. Basically, this 
qualifies as "personal information" 
(https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/what-is-personal-data/what-is-personal-data/): 



“‘personal data’ means any information relating to an identified or 
identifiable natural person (‘data subject’); an identifiable natural 
person is one who can be identified, directly or indirectly, in 
particular by reference to an identifier such as a name, an 
identification number, location data, an online identifier or to one or 
more factors specific to the physical, physiological, genetic, mental, 
economic, cultural or social identity of that natural person”.


Especially as some user names will be the users actual name. Which means 
it falls under the GDPR.


This in turn means there's a whole bunch of other GDPR related 
requirements that have to be met when handling any file that has that 
data in: 
https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/ 
- and I suppose that also means you have to ensure that anyone who 
receives that file is also GDPR compliant and treats the file in 
accordance with it. And of course you can't be sharing it randomly with 
the public.


*TL;DR: include absolutely no personal data by default anywhere in any 
files.*


(And to address Thomas' point: The reason you can do it on mailing lists 
is because by posting here we're explicitly consenting to it. It's 
understood that that'll happen. 99% of users won't know their username 
is in a file that's shared so there's no basis for consent.)



On 2021-03-23 20:05, Thomas B wrote:

Hi Matteo,
can you give an example when exposing the username could be problematic?

As far as I know other common programs like Word, Excel and so on also 
add your full name as author to the metadata of every Word- or Excel 
file you create.
I think this is something very useful if you work with others within 
one company. If you send these files to someone else and want to get 
rid of these metadata you can delete this metadata information.


I agree that exposing sensitive data would be problematic but sharing 
the username does not seem to be something too private. Your full name 
for example also appears in this mailing list or as part of your 
twitter account. So under which circumstances would it be problematic 
if your name would be written to a QGIS project file?


regards,
Thomas

Am Di., 23. März 2021 um 09:01 Uhr schrieb matteo 
mailto:matteo.ghe...@gmail.com>>:


Hi devs,

in the Italian QGIS Group we had a discussion on privacy "issues"
related to the exposure of some Global Variables, like
"user_full_name",
that is automatically taken from the client.

Maybe some variable should be opt-in rather then opt-out: sharing a
project between different computers/users can expose the user name
without an explicit agreement of the final user.

What is your opinion on this?

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
___
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] SVG icons in QGIS

[Jonathan Moules]

Hi Richard,

Thanks for the clarification. No rudeness parsed. :-) Apologies, I 
should be clearer.


One of QGIS' biggest weaknesses IMHO is usability; a lot of progress has 
been made in this area, but it's an area that still needs work. The SVG 
icons are one such area, and while the Resources Plugin may technically 
provide a potential solution to this problem (i.e. just port over the 
Font-Awesome SVGs into the plugin), it:


a) doesn't solve any of the issues I raised

b) makes some of them worse. Now even more duplicate SVGs! The red cross 
one adds yet another cross for example, on top of the 5 identical ones 
already in the core, (and there's the simple marker too of course..)). 
And that's literally the first random one I picked.


c) introduces new issues. i.e.: unhelpful metadata "This collection 
contains SVGs by GIS LAB" (sorry for picking on you, not the only ones 
;-) ).



> Please try Faunalia's 'Distance Measurement Styles'. One click and it 
will be available for you.


Impressive. The Resources Plugin seems to me better suited to solving a 
different problem, though if I may provide some feedback: It took me a 
good minute or two to figure out how to access these styles once I'd 
downloaded them. (Found a bug too, but I'll open an issue for that :-) ).



> But as Saber proposes: please create a QEP so there can be some 
centralized discussion.


Is it the way to go? The blurb for QEPs says: "Generally smaller 
features do not require a QEP unless they can have large knock on 
effect." - looking at them, most of them are large chunks of dev work, 
and the rest are for project admin. Conversely, this is a couple tiny 
dev features (though I am making assumptions about the QGIS dev base... 
;-) ), and a small chunk of admin work.


Further thought (and an issue with QEPs in general): QEPs as Issues 
(which are Pull-based) are not very visible compared to the list (which 
is push-based). As in I'd expect barely anyone outside of project devs 
are likely to ever go trawling through the QEP issue tracker (i.e. I 
never have), whereas everyone on the list will get emails even if the 
chose not to read them.


I mean it's easy enough to do; mostly just copy/past my previous email. 
But I see it reducing the audience for the conversation and not adding 
anything.


Cheers,

Jonathan


On 2020-07-27 14:03, Richard Duivenvoorde wrote:

Hi Jonathan,

I do not want to sound rude, but I think you really underestimate the 
possibilities and complexity of the icons and QGIS styling and styling 
resources in general.

About the 'Resource Sharing Plugin':
- styling (of points) is never only about the little icon. styling and symbols 
are complex beasts. If you google the plugins QEP, you will see that it (also) 
started of as a 'simple todo' but ended up in current form
- did you have a look: because there are a LOT of styling resources already: simple 
ones (like mine with actually only some icons), but others giving you the 
capabilities to show all dimension labels and arrows of your geometries, and again 
others very specific for a certain working area: oil icons, Red Cross-map 
icons etc etc

I'd be OK with cleaning up, but a good thing on the Resource Plugin is that it 
fetches a (online, be it on github or on you webserver!) set of styling 
resources: symbols, styles, icons, colors, whatever is possible. Please try 
Faunalia's 'Distance Measurement Styles'. One click and it will be available 
for you.

About metadata and searching: cool, would also be nice if that could work for 
Resources. Isn't there some kind of SVG-standard for this?

About all in one directory: fine, or at least for the ones QGIS gives you upon 
install (the 'App' folder). But I also like the way the Resource plugin orders 
them in folders (see screenshot).

But as Saber proposes: please create a QEP so there can be some centralized 
discussion.

Regards,

Richard Duivenvoorde



On 7/27/20 1:42 PM, Jonathan Moules wrote:

Hi List,

The more I look at the current SVG icons, the more I'm thinking it really needs 
some TLC (Tender Loving Care). As far as I can tell, icons are categorised by 
the directory they're in, so if you want an icon to appear in two categories, 
you put the icon in there twice... and so that's just what has happened! I 
suspect the current set has simply accreted over time.

Examples of weirdnesses:
* The "food" and "entertainment" categories are basically identical, but have 
different icons for the same thing.
* There are at least 7 near-identical aeroplane icons(!)
* There's cycle parking and cycle locking, but no cycle? No car (that's under "gpsicons") 
but two taxis? Oh, and 5 (five!) aeroplanes to choose from, and multiple types of train. And that's 
just "transport".
* "Shopping" has a hammer and a pawprint in it... well, I mean, you can buy 
those things sure, but that seems like a rather odd place to put th

[QGIS-Developer] SVG icons in QGIS

[Jonathan Moules]

Hi List,

The more I look at the current SVG icons, the more I'm thinking it 
really needs some TLC (Tender Loving Care). As far as I can tell, icons 
are categorised by the directory they're in, so if you want an icon to 
appear in two categories, you put the icon in there twice... and so 
that's just what has happened! I suspect the current set has simply 
accreted over time.


Examples of weirdnesses:
* The "food" and "entertainment" categories are basically identical, but 
have different icons for the same thing.

* There are at least 7 near-identical aeroplane icons(!)
* There's cycle parking and cycle locking, but no cycle? No car (that's 
under "gpsicons") but two taxis? Oh, and 5 (five!) aeroplanes to choose 
from, and multiple types of train. And that's just "transport".
* "Shopping" has a hammer and a pawprint in it... well, I mean, you can 
buy those things sure, but that seems like a rather odd place to put them.
* "landmark" seems to basically be a subset of "religion", with a museum 
and a weird icon for a "school" thrown in for good measure.


I'm sure there are many more.

Given the importance of a good symbol library for cartography, this 
seems like a fairly significant issue, but fortunately it's pretty 
"easy" to fix (compared to writing a data processing algorithm anyway ;-) ).


My thoughts:
* Move the svg's into a single directory. (Though would break any 
current projects symbology using them I guess?)
* Use a metadata file to categorise them, so you get a list of 
categories as now and a single symbol can be in multiple categories.
* Add a search feature so the user can quickly find "museum" without 
having to guess where it has been categorised.

* Clean up the current symbols by removing duplicates.
* Add the font-awesome symbols (per my thread on the User List) to fill 
in the gaps and flesh out the collection. As a bonus, it comes with 
metadata for categories and search terms (YAML files).


* bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO), 
etc would also work for finding that museum.


Thoughts?

Cheers,
Jonathan


___
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] GeoSeer ogc services data harvesting

[Jonathan Moules]

Hi Andreas,

Interesting.

Behind the scenes, GeoSeer one-way hashes the GetCapabilities documents 
and that hash is used as the document key. Identical GetCapabilities 
documents therefore get the same key and thus only appear once in the 
final index. But one single character different in the entire document 
and it's a completely different hash.


There's also de-duplication at the endpoint, service, and dataset levels 
using a similar mechanism. GeoSeer also de-duplicates across services. 
I.e. if something is served from the same place as both WMS and WFS, we 
glue them together.


The problem with using DNS is that you get organisations the size of 
NOAA/USGS and they have deployments across various subdomains that are 
doing different (but similar) things. You also get a kind of opposite - 
a single domain belonging to a geospatial "cloud" hosting provider that 
has lots of layers that have the same names and similar metadata because 
all their local-government customers are sharing their own 
fire-stations/roads etc.


There are all manner of ways in which server admins and data custodians 
make this more complicated than it seems. :-)


Cheers,

Jonathan


On 2020-06-09 12:25, Andreas Neumann wrote:


Hi Jonathan,

Thanks for sharing this information. I don't know anything better.

While looking at some services that I know personally, I also found 
out that others services are listed twice, because a machine might 
have a DNS alias. That is also something to consider - perhaps sort 
out machines that have identical GetCapabilities responses and just 
the DNS name varies.


I agree, the numbers probably wouldn't change significantly.

Thanks and greetings,

Andreas

On 2020-06-09 13:14, Jonathan Moules wrote:


Hi Andreas,
Sure, happy to share.
There's a little on the About page: https://www.geoseer.net/about.php 
and then scattered around blog posts (the ones with the "GeoSeer" tag 
are probably best for that: https://www.geoseer.net/blog/?t=GeoSeer 
), but put simply - We scrape a lot of different sources and metadata 
catalogs and get the services from them. Then we request not only the 
GetCapabilities that was declared, but also make educated guesses as 
to what else might be on the box and request those too.


It's not perfect, but to the best of my knowledge it's by far the 
largest such index in the world, and more importantly, it's 
*current*. Everything in there responded with a valid GetCapabilities 
document with at least one meaningful named dataset when it was last 
scraped within the last few weeks.


Pertaining to your given services, GeoSeer has:
http://geoweb.so.ch/wms/sogis_natgef.wms? and a few others on that 
sub-domain, as well as some on the subdomain: 
http://www.sogis1.so.ch/cgi-bin/sogis/sogis_natgef.wms? - both are 
now defunct I see which is why they're not in the database.


Thanks for the URL, I've added it for scraping.

So I wonder how many other QGIS server installations may not be in 
your database?
Alas that's a "unknown unknown"; there's no way to know (I can't 
think of a way to find out anyway; suggestions welcome). However the 
vast majority of the time when I come across a new service manually 
(i.e. from following various mailing lists like this), it turns out 
it's already in the index, so I think it's reasonably comprehensive 
at this point.


While missing servers may change the absolute number of QGIS 
Installations, they're very unlikely to change the proportions. For a 
sample-size this large I'd expect the proportions to remain largely 
the same, certainly for deployments.


Hope that's of interest and answers the question,
Cheers,
Jonathan


On 2020-06-09 10:45, Andreas Neumann wrote:


Hi Jonathan,

Can you share with us how you harvest your information on available 
public OGC services? You probably have that information published 
somewhere - so if you could point me towards this URL, it would help.


I noticed that all of the services of our province (my employer) 
can't be found, as an example.


Here is the start point:

https://so.ch/verwaltung/bau-und-justizdepartement/amt-fuer-geoinformation/geoportal/geodienste/wms-web-map-service/

and the GetCapabilities link:

https://geo.so.ch/api/wms?SERVICE=WMS=GetCapabilities=1.3.0

So I wonder how many other QGIS server installations may not be in 
your database? Of course I know you don't claim full coverage, but 
it would still be good to know how you harvest your data.


Thanks for clarifying 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

Re: [QGIS-Developer] GeoSeer ogc services data harvesting

[Jonathan Moules]

Hi Andreas,
Sure, happy to share.
There's a little on the About page: https://www.geoseer.net/about.php 
and then scattered around blog posts (the ones with the "GeoSeer" tag 
are probably best for that: https://www.geoseer.net/blog/?t=GeoSeer ), 
but put simply - We scrape a lot of different sources and metadata 
catalogs and get the services from them. Then we request not only the 
GetCapabilities that was declared, but also make educated guesses as to 
what else might be on the box and request those too.


It's not perfect, but to the best of my knowledge it's by far the 
largest such index in the world, and more importantly, it's *current*. 
Everything in there responded with a valid GetCapabilities document with 
at least one meaningful named dataset when it was last scraped within 
the last few weeks.


Pertaining to your given services, GeoSeer has:
http://geoweb.so.ch/wms/sogis_natgef.wms? and a few others on that 
sub-domain, as well as some on the subdomain: 
http://www.sogis1.so.ch/cgi-bin/sogis/sogis_natgef.wms? - both are now 
defunct I see which is why they're not in the database.


Thanks for the URL, I've added it for scraping.

> So I wonder how many other QGIS server installations may not be in 
your database?
Alas that's a "unknown unknown"; there's no way to know (I can't think 
of a way to find out anyway; suggestions welcome). However the vast 
majority of the time when I come across a new service manually (i.e. 
from following various mailing lists like this), it turns out it's 
already in the index, so I think it's reasonably comprehensive at this 
point.


While missing servers may change the absolute number of QGIS 
Installations, they're very unlikely to change the proportions. For a 
sample-size this large I'd expect the proportions to remain largely the 
same, certainly for deployments.


Hope that's of interest and answers the question,
Cheers,
Jonathan


On 2020-06-09 10:45, Andreas Neumann wrote:


Hi Jonathan,

Can you share with us how you harvest your information on available 
public OGC services? You probably have that information published 
somewhere - so if you could point me towards this URL, it would help.


I noticed that all of the services of our province (my employer) can't 
be found, as an example.


Here is the start point:

https://so.ch/verwaltung/bau-und-justizdepartement/amt-fuer-geoinformation/geoportal/geodienste/wms-web-map-service/

and the GetCapabilities link:

https://geo.so.ch/api/wms?SERVICE=WMS=GetCapabilities=1.3.0

So I wonder how many other QGIS server installations may not be in 
your database? Of course I know you don't claim full coverage, but it 
would still be good to know how you harvest your data.


Thanks for clarifying 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

Re: [QGIS-Developer] QGIS Server and the Grants programme

[Jonathan Moules]

Hi Andreas, (& All),
A fair point, but I believe this is an important point and this year I 
do have data to back up my point; in fact the grant program is what 
motivated me to finally get around to doing this analysis.


It seems from the replies that while there are a few differentiators, 
the key one is indeed cartography and styling. (There's also an 
interesting conversation about vectors going on there too). Some thoughts:
* The vast majority of WMS/WMTS layers are not cartographically 
complicated, let alone beautiful. They're "here is a layer with small 
green points for trees", and "this polygon represents conservation 
areas". You can easily play around and see what's out there here: 
http://www.geoseer.net/api-demo/

* WFS/WCS can't be styled server side.
* It seems like overkill to create and maintain an entire server 
distribution that fundamentally only solves one (relatively simple 
compared to what QGIS Desktop can do) problem.
* Rendering is only one part the QGIS package (Analysis, digitisation, 
management, etc.).


If I'm honest, the "competition" on this point isn't really between QGIS 
and MapServer/GeoServer. It's really between QGIS and ArcGIS. Because 
ArcGIS does exactly what QGIS Server seeks to do: offer a single 
integrated solution for Desktop-> Server. And certainly ArcGIS Server 
does have a huge number of deployments (53%), however again, there 
really aren't many cartographically complicated outputs on there. And 
despite the huge number of deployments, most services and datasets are 
actually served by MapServer/GeoServer (about 60% of datasets between 
them!). Basically ArcGIS is deployed by local government and used for 
bitty-stuff ("here are our fire stations"), but if you want a real 
data-service then you go with GeoServer/MapServer/etc.


Most importantly though, I think I haven't conveyed my core point well: 
this really is a zero sum game!
Even allowing for the above, any funds spent on QGIS Server are not 
spent on QGIS Desktop. There are 60 public facing QGIS Server 
deployments. Even assuming that there's a ratio of 10:1 for 
private/public servers (made up ratio, feels too high), any funding on 
QGIS Server benefits only hundreds, or being very generous, maybe 
low-thousands number of users. Funding on QGIS Desktop however benefits 
as a *minimum* tens of thousands, potentially millions of users (no idea 
how many QGIS installs there are, I can't find the download-stats I 
remember seeing in the past).
Heck, even pretending for a second QGIS Server had 100% of the 
deployments (a 100 fold increase!), there would /still/ be orders of 
magnitude more people using the not-Server parts of QGIS Desktop by its 
very nature.


There are 3,102 open issues on the QGIS issue tracker. 95 are labelled 
regressions, 137 are "high priority", and 92 are "crash/data 
corruption". Just 49 are "Server". I'm not seeking to denigrate the 
project here; QGIS is a extremely complex tool that is an amazing 
accomplishment and by its nature it will have bugs. I raise these 
numbers to highlight that any money spent on Grants to Server (and yes 
new Desktop features) is money that isn't spent fixing these (I'm aware 
of the bug-fixing fund). Something I think the grant voters should be 
cognizant of.


Hope that clarifies,
I'll step back now. :-)
Cheers,
Jonathan


On 09/06/2020 08:09, Andreas Neumann wrote:

Hi Jonathan,
You keep repeating yourself. You started the exact same discussion a
year ago.
You have a valid point, of course, I don't argue that. But if you think
about small organizations  that do not have a lot of personal (or
financial) resources, it would be a lot of burden to invest twice the
time in styling: once for QGIS desktop and another time again for UMN
mapserver and Geoserver. Even if SLD output from QGIS improved (also
thanks to efforts of Andrea Aime and others), it still can't transport
everything. If it would, then I would better agree with your argument.
For such smaller organization, speed (and I know that UMN and Geoserver
are a bit faster than QGIS server) is not the only important thing - it
is also their personal and financial resources and complexity of their
software landscape.
And QGIS server has some other unique selling points: the proprietary
GetPrint command that doesn't have a match in Geoserver or UMN, the
ability to create Atlases from server, and who knows, in the future
perhaps QGIS server can run processing models.
Greetings,
Andreas
On 2020-06-08 22:42, Jonathan Moules wrote:


Hi List,
Some of you may have seen my blog post on the OSGeo-Discuss list 
about which mapping servers are the most deployed. For those who 
haven't seen it, QGIS Server has about 60 public deployments (1% of 
all of them), and it serves 11,924 datasets (0.5% of all public 
geospatial WMS/WFS/WCS/WMTS datasets).


Potentially controversial here and I appreciate it's not a 
compet

[QGIS-Developer] QGIS Server and the Grants programme

[Jonathan Moules]

Hi List,
Some of you may have seen my blog post on the OSGeo-Discuss list about 
which mapping servers are the most deployed. For those who haven't seen 
it, QGIS Server has about 60 public deployments (1% of all of them), and 
it serves 11,924 datasets (0.5% of all public geospatial 
WMS/WFS/WCS/WMTS datasets).


Potentially controversial here and I appreciate it's not a competition, 
but given the low uptake of QGIS Server compared to other Open Source 
offerings (GeoServer: 964 deployments, 963,603 datasets; MapServer: 544 
deployments, 389,709 datasets), is QGIS Server something the grant 
program should be funding? There are three Server proposals totalling 
€10,000, 22% of the fund.


Now, before you get the pitchforks out(!), please consider the following:

* Zero sum game - Any money spent on QGIS Server cannot be spent on QGIS 
Desktop. (The grants mostly aren't things that will improve the shared 
QGIS Core). (This reasoning also follows through to OSGeo funds).


* Multiple solutions - Open Source (and OSGeo) already has a very 
healthy ecosystem of mapping servers - does it need another one?


* Limited number of users benefited - I don't have stats for it, but 
QGIS Desktop is probably the most popular Open Source Desktop GIS, and 
is certainly going to have many orders of magnitude more users than QGIS 
Server.


* Playing to your strengths - QGIS' strength is it's Desktop and it's 
generally good practice to play to your strengths.



So given the above, and that QGIS is already "winning" as an Open Source 
Desktop (great job!), I'd like to suggest it's not a good idea to dilute 
the limited resources by spending them on QGIS Server. Instead it seems 
that far more people would benefit if that money was spent on Desktop, 
especially the bug fixing programme.


Or alternatively, given the "Unique Selling Point" of QGIS Server is its 
integration with QGIS Desktop, those resources could be used to further 
improve interoperability with GeoServer/MapServer/deegree/etc. Those are 
all successful mature OSGeo projects that excel at serving maps, have an 
architecture designed for it, and already have huge install bases.


TLDR: QGIS excels at being a Desktop, and I'd like to suggest it should 
play to its strengths and focus its limited funds there to benefit the 
most users.


I shall now retreat to my bunker. :-)

Cheers,
Jonathan

Note: The above only applies to the Grant program and funding; how 
developers wish to spend their time, and on which projects is of course 
their own prerogative.


(Disclosure: I have no horse in this race; I don't run or administer any 
mapping servers, but I have done GeoServer in the past.)




___
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] The curious case of GeoPackage on exFAT

[Jonathan Moules]

Hi Bo,

Looking at the WAL docs for SQLite (https://www.sqlite.org/wal.html) 
(what geopackage is built from) I see this:


"The WAL file exists for as long as any database connection has the 
database open. Usually, the WAL file is deleted automatically when the 
last connection to the database closes. However, if the last process to 
have the database open exits without cleanly shutting down the database 
connection, or if the SQLITE_FCNTL_PERSIST_WAL file control is used, 
then the WAL file might be retained on disk after all connections to the 
database have been closed."


So it sounds like whatever the last process is to touch the GeoPackage 
may not be closing the connection cleanly on exFat.


Cheers,

Jonathan

On 2020-05-11 13:10, Bo Victor Thomsen wrote:


Hi all -

I have a strange problem. I'm have 3 different disk on my windows 
based system on Mac hardware


 1. My system drive. Formatted to NTFS.
 2. A flash-drive. Formatted to FAT32.
 3. A data drive. Formatted to exFAT. The last is my primary data
drive and is shared between my Windows partition and my Mac
partition on my MacBook Pro. Hence the use of exFAT.

I have a QGIS plugin, which copies a template of a GeoPackage file to 
"where-ever the user wants it placed" and afterward make some content 
changes in the copy using the PyQT QSQL module with the QSPATIALITE driver


This work if the Geopackage  file is copied to either disk no 1 (NTFS) 
or disk no 2 (FAT32). However, it doesn't work if the file is copied 
to disk no 3 (exFAT). The process leaves the WAL files even after the 
database is closed properly.


And even more strange: If I reformat the flash-drive to exFAT and 
repeat the experiment using the reformatted drive it too works without 
a hitch.


The normal "divide et impera" method tells me that my exFat data disk 
is bork'ed. However this error *only* occurs with the QGIS/GeoPackage 
creation/modification scenario. Everything else is working OK.


The disk is not shared on the network. Has anyone experienced the same 
type of problems ? And have a solution ?? Just asking before I begin 
to clean up / reformat my 100 GB data disk


System setup: MacBook Pro 2014 / Windows 8.1 OS /QGIS 3.10.5 (the same 
problem occurs with 3.10.0 , 3.10.2 ...3.12.2)



--
Med venlig hilsen / Kind regards

Bo Victor Thomsen

___
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] Potential vulnerabilities

[Jonathan Moules]

Hi Nadia,
Just a random thought here, but I wonder if doing this exercise against 
QGIS Desktop would be more worthwhile from a security perspective? There 
are very few deployments of QGIS-Server but many many deployments of 
Desktop.


For example, is it possible to compromise QGIS Desktop via a 
opening/connecting to a compromised shapefile/Geopackage/web-service/CSV 
etc etc? I have no idea, but it'd definitely be a useful thing to 
investigate.

Cheers,
Jonathan

On 2020-02-02 17:36, nadiaspit wrote:

Hi Even,

thank you so much for answering my questions.

Of course my assessment is far beyond automating scanning for vulnerability.
I just wrote about 1 potential issue. As I said at the beginning, this is
about my Project Work as student of Master of Cybersecurity in Pisa, Italy.
I really appreciate your work and I think qgis server is well designed and
can be successfully used to create a robust architecture from a
cybersecurity perspective.

Before writing to qgis-developer I first submitted the issue to Lizmap
Github group, they suggested to write here, as they think it would be a qgis
issue.
Also for me the issue is likely to be LizMap specific rather than
QGIS-server.
I'll make another attempt with the Lizmap community.

Thank you for your time.
Kind Regards,
Nadia



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

___
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] Potential vulnerabilities

[Jonathan Moules]

Hi Jorge,
I don't run QGIS server, I was basing that on the original report by 
Nadia to the list which shows a 500 response for that request to their box.
But yes, testing that URL against some (ostensibly) QGIS servers I can 
find online, it does seem to work as expected. Not sure why Nadia got a 
500 back...

Cheers,
Jonathan

On 2020-02-01 21:58, Jorge Gustavo Rocha wrote:

Hi Jonathan,

If the service is unknown, my QGIS Server reports:

http://www.opengis.net/ogc;>
  Service unknown or
unsupported


Which QGIS Server are you using? Have you filled a bug?

Your help is appreciated :-)

Regards,

Jorge Gustavo

On 01/02/20 21:25, Jonathan Moules wrote:

I can't comment on the security aspect, but at the very least there's a
bug in the WMS compliance. For the GetCapabilities URL it should be
returning an XML Service Exception (because it has an invalid SERVICE
value), not a HTTP 500.

I.e., the same request to a (random) GeoServer box shows the sort of
thing that should be coming back:

http://si.icnf.pt/geoserver/POEM/ows?REQUEST=GetCapabilities=oGMQJLiHSupcMsIjmfMWZQISJOeWgvtonUKYRXwmroNKJMFRYPEnEZPkowATaGjkELTRHGnDntktuVJGaLGTcBeUUJdggwCZNQVmwtAGVOJnxxYRNoCsJqtRfbPjwKjegCwdCLmaYrUVJabXtdkmZeHXsNLjhpdJhbQOYeXwwOIZwVROYYKwXRZxkjXoeGJvmswRUKPNRMhLLkMQtoLmSfPNrQXYHtuPEuKpFIpFccNsEgRbYndKFXiFpnZqJERjSJreOgtxNGcisVVbPVvfplvDRyRbsKbFnPcmlliuCAyoDmYOffSDlAWUApgewpAiJXXdwLDDYbkPaAiqMNkqPfqkIBxhirwdeQEQmTtBeDYIbGYNbGKPxSOYDRhgiGrGPElskHmqCCUaETOPHTPEXMArEpPNYZyJoChNatgYaPfcqIRjwCwDkmMVgUdlxGWgqXxGZwrgeantfXPvxkacZQLKPwlemJfeOuvIVfZrBiwWtIoybuuQAqapuFJBDuZHtMlaIJemxOjPiefmgMSXOpoSwFAipLYwqVApjJtmbOqUBORkfqesknejRvSFQwmCYlHigIZNpBIAINfVVUxtjHekDrJMdYVNgAiZUNUYSnbSyPrFTWiYmrnFUcqnteOMEogsxDXMlbNLBcMCLwDZJCQLblDTElqcWxmcoKiZGBPqTJuSjIPimsfYklNdmIcnwsGdESbaOhtvVwRcoFIKAAninLCqKfsKFXqDfEwNCkXXRFvbcjnXggYywEynhweSdrvbCngwJtceGDAOlQQqCBhgjHmcuSrCUKwBJOeEToYIhTQCgEdBVpIlCYmIBPsNPLIedfITOfincEBqLscQJNktKIvpfgkQFhLOtiyslSKdGkjCCnYYDNVBrTDJsYxELKJcXlJLUMTBOChSpTsfgZMqKtXLkbMOnulrWQLJhwIElLJZhnQDjfmUvsDiVDAEavsGhUXSYlxbPROgZQElKUIXNBGEmducbcREVLjNoZvlNpxcWnVwhNlKOfSZBREGUZXLRfhEloTuZLPphUaEPpydHoHpcNKhVjqsKfQofaaVTAfDwXoUWQtmQaRSAEdwxCdIqllTvObUFcsdyfGqHRQFDGFvHUdeNuTWhIbgDhcTGnJBTxytfHWvQNjSqSGCBDGNPQJaclWFUHPIjAkbvDxRtqFjwtoVOtfYkbiKVbqcphyngrfcxLkGQpHjSldaqekhLoAYGbkXHdnyeKIraNcalFLUvrEKSVYoNpGoZHrKpDckZJSnPHiMIeaOrTCKRWbNcrSDrddeVIqSfSRIILuZpYnpFLJCyYxVGnRonXgCSEqQXcZreffnyaFvkaFcJyyuCivsGMHGhVViEetLWxPEnFsFGuuHFmlIJCtoyyikChSxeMrKxhZoQanBBfexwUjsjAiLUOLnhYmlyuJlsENAoMDiFbbrcfpXeyqnkJOgmCwYakTGegcbpywwAVYJSQtblnWZhfccMksXoHhkXqqbZxYgAsNwPGbJukfaGZakiImInKPoSwvCXXvpqawURRpUmaebduvgDnAYGUmhCcQGkTKqlKVoGumDuDFgpbhcyRgpnVkuymNFsMRChKBFFyBKJNkcNqTEHKHrJdECHYMnWBjJiVqaXBEJQDjoZyjNFwumfShWeeRoqwIDfYSckglinPSgDvJlFxfLtWmiYTrhVSFRQOjdZKdQRhnmpSXVvQLadJpviByssOKIrjpysnXvXHAvRKrIcGEvsvhWEmZkGKPBcFFmmjtQJQZxZIcTVmFWHEUOEejYvOjNrbqYvPaJxbTyucvdMDohGynKrodTGyRJcuMBdFPNFsPbmEQDiXeCBwPHAGvawOvBTlXoMijuSUalSrftFWCHatRoivbehiDtLbRJUItnteqdEMNdrHsqAwgiCMOPDIVCmovSVTLxkclkmBCuVpIAMJtmkdkkHIklamiCQLqtfkhhUkSocYtbQFOJXvaPBBmFWHIvwZHvnGYeaMxdGKwQjLaVvYevVyLQbWlTmKUQlkoOrQNMXdmPbTKgfXRhdoaqQapCNpsCJXvnFXBvXQemkXOdIyCpRptiJllMSdFsIjlywGJOWbpInDLB=1.3.0



On 2020-02-01 18:33, nadiaspit wrote:

Hi,
I am a student of Cybersecurity Master at University of Pisa. My final
project work is about a Security Test of an installation of qgis server +
lizmap web client.
At a first analysis, I found out that lizmap web client is vulnerable to
"Buffer overflow attack"
https://www.owasp.org/index.php/Buffer_overflow_attack

The problem:
"Potential Buffer Overflow. The script closed the connection and threw
a 500
Internal Server Error"
The solution:
"Rewrite the background program using proper return length checking. This
will require a recompile of the background executable."

Here you can view the  report
<https://drive.google.com/file/d/12s-akDIr9s127kw6MSYKRp1ph29gY_u3/view?usp=sharing>

:

I also posted this question to Lizmap web client Github: Is Buffer
Overflow
vulnerability a false positive for Lizmap web client?

They suggested to ask to this group.
Any help would be very appreciated.

Kind Regards,
Nadia Spitilli



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

___
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

J. Gustavo


___
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] Potential vulnerabilities

[Jonathan Moules]

I can't comment on the security aspect, but at the very least there's a 
bug in the WMS compliance. For the GetCapabilities URL it should be 
returning an XML Service Exception (because it has an invalid SERVICE 
value), not a HTTP 500.


I.e., the same request to a (random) GeoServer box shows the sort of 
thing that should be coming back:


http://si.icnf.pt/geoserver/POEM/ows?REQUEST=GetCapabilities=oGMQJLiHSupcMsIjmfMWZQISJOeWgvtonUKYRXwmroNKJMFRYPEnEZPkowATaGjkELTRHGnDntktuVJGaLGTcBeUUJdggwCZNQVmwtAGVOJnxxYRNoCsJqtRfbPjwKjegCwdCLmaYrUVJabXtdkmZeHXsNLjhpdJhbQOYeXwwOIZwVROYYKwXRZxkjXoeGJvmswRUKPNRMhLLkMQtoLmSfPNrQXYHtuPEuKpFIpFccNsEgRbYndKFXiFpnZqJERjSJreOgtxNGcisVVbPVvfplvDRyRbsKbFnPcmlliuCAyoDmYOffSDlAWUApgewpAiJXXdwLDDYbkPaAiqMNkqPfqkIBxhirwdeQEQmTtBeDYIbGYNbGKPxSOYDRhgiGrGPElskHmqCCUaETOPHTPEXMArEpPNYZyJoChNatgYaPfcqIRjwCwDkmMVgUdlxGWgqXxGZwrgeantfXPvxkacZQLKPwlemJfeOuvIVfZrBiwWtIoybuuQAqapuFJBDuZHtMlaIJemxOjPiefmgMSXOpoSwFAipLYwqVApjJtmbOqUBORkfqesknejRvSFQwmCYlHigIZNpBIAINfVVUxtjHekDrJMdYVNgAiZUNUYSnbSyPrFTWiYmrnFUcqnteOMEogsxDXMlbNLBcMCLwDZJCQLblDTElqcWxmcoKiZGBPqTJuSjIPimsfYklNdmIcnwsGdESbaOhtvVwRcoFIKAAninLCqKfsKFXqDfEwNCkXXRFvbcjnXggYywEynhweSdrvbCngwJtceGDAOlQQqCBhgjHmcuSrCUKwBJOeEToYIhTQCgEdBVpIlCYmIBPsNPLIedfITOfincEBqLscQJNktKIvpfgkQFhLOtiyslSKdGkjCCnYYDNVBrTDJsYxELKJcXlJLUMTBOChSpTsfgZMqKtXLkbMOnulrWQLJhwIElLJZhnQDjfmUvsDiVDAEavsGhUXSYlxbPROgZQElKUIXNBGEmducbcREVLjNoZvlNpxcWnVwhNlKOfSZBREGUZXLRfhEloTuZLPphUaEPpydHoHpcNKhVjqsKfQofaaVTAfDwXoUWQtmQaRSAEdwxCdIqllTvObUFcsdyfGqHRQFDGFvHUdeNuTWhIbgDhcTGnJBTxytfHWvQNjSqSGCBDGNPQJaclWFUHPIjAkbvDxRtqFjwtoVOtfYkbiKVbqcphyngrfcxLkGQpHjSldaqekhLoAYGbkXHdnyeKIraNcalFLUvrEKSVYoNpGoZHrKpDckZJSnPHiMIeaOrTCKRWbNcrSDrddeVIqSfSRIILuZpYnpFLJCyYxVGnRonXgCSEqQXcZreffnyaFvkaFcJyyuCivsGMHGhVViEetLWxPEnFsFGuuHFmlIJCtoyyikChSxeMrKxhZoQanBBfexwUjsjAiLUOLnhYmlyuJlsENAoMDiFbbrcfpXeyqnkJOgmCwYakTGegcbpywwAVYJSQtblnWZhfccMksXoHhkXqqbZxYgAsNwPGbJukfaGZakiImInKPoSwvCXXvpqawURRpUmaebduvgDnAYGUmhCcQGkTKqlKVoGumDuDFgpbhcyRgpnVkuymNFsMRChKBFFyBKJNkcNqTEHKHrJdECHYMnWBjJiVqaXBEJQDjoZyjNFwumfShWeeRoqwIDfYSckglinPSgDvJlFxfLtWmiYTrhVSFRQOjdZKdQRhnmpSXVvQLadJpviByssOKIrjpysnXvXHAvRKrIcGEvsvhWEmZkGKPBcFFmmjtQJQZxZIcTVmFWHEUOEejYvOjNrbqYvPaJxbTyucvdMDohGynKrodTGyRJcuMBdFPNFsPbmEQDiXeCBwPHAGvawOvBTlXoMijuSUalSrftFWCHatRoivbehiDtLbRJUItnteqdEMNdrHsqAwgiCMOPDIVCmovSVTLxkclkmBCuVpIAMJtmkdkkHIklamiCQLqtfkhhUkSocYtbQFOJXvaPBBmFWHIvwZHvnGYeaMxdGKwQjLaVvYevVyLQbWlTmKUQlkoOrQNMXdmPbTKgfXRhdoaqQapCNpsCJXvnFXBvXQemkXOdIyCpRptiJllMSdFsIjlywGJOWbpInDLB=1.3.0


On 2020-02-01 18:33, nadiaspit wrote:

Hi,
I am a student of Cybersecurity Master at University of Pisa. My final
project work is about a Security Test of an installation of qgis server +
lizmap web client.
At a first analysis, I found out that lizmap web client is vulnerable to
"Buffer overflow attack"
https://www.owasp.org/index.php/Buffer_overflow_attack

The problem:
"Potential Buffer Overflow. The script closed the connection and threw a 500
Internal Server Error"
The solution:
"Rewrite the background program using proper return length checking. This
will require a recompile of the background executable."

Here you can view the  report

:

I also posted this question to Lizmap web client Github: Is Buffer Overflow
vulnerability a false positive for Lizmap web client?

They suggested to ask to this group.
Any help would be very appreciated.

Kind Regards,
Nadia Spitilli



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


___
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] Qgis crashes while loading WMTS layers

[Jonathan Moules]

Hi Patrick,
I can't comment on the core issue, but just a point for clarification - 
I thought Swap memory usage was something the operating system dealt 
with? Isn't it usually transparent to the application?


A quick search indicates that what GIMP calls swap is really a bespoke 
folder for GIMP to store temporary files (in a fashion similar to 
virtual memory/swap) rather than the system swap file; FME does this too 
(they call it a "temporary directory").


I can certainly see why that would have value - it looks like QGIS has 
one, at least for temporary outputs - 
https://github.com/qgis/QGIS/issues/28222 - but whether it's as well 
used as it should be I leave for others to comment on (I have no idea 
what it's used for).


Cheers,
Jonathan

On 2020-01-26 12:19, Patrick Dunford wrote:

Good day to all.

Not so long ago I wrote a post about issues handling large numbers of 
raster files. This results from what appears to be an architectural 
design limitation of Qgis in that it only has enough resources 
available for a certain (unknown) number of raster layers and does not 
have any effective system for dealing with the exhaustion of these 
resources.


I also noted that the software does not appear to have the ability to 
use the swap (virtual memory) resources within a system to deal with 
the apparent exhaustion of resources, as other software would. For 
example, Gimp which I use for graphical editing is able to handle 
certain projects using a swap space of 200 GB, which consists of 32 GB 
of physical RAM and the rest in SSD. It is not unusual with some of 
these graphics projects to have 100 GB or more of swap space in use, 
without crashing the system. (This being possible since Gimp 2.10 with 
its ability to write files of more than 4 GB)


Whilst it is possible to manage the number of layers with file based 
rasters, this cannot be done with a WMTS server because there is no 
way I am aware of to manage the number of layers that can be 
downloaded from the server.


Version 2.18 and earlier almost never crashed with excess layers, 
usually all that would happen is a layer would be displayed with 
invalid data. However, crashes have become the norm with 3.x versions 
of software.


It seems to me there is a big architectural problem in the software 
with its inability to utilise the full resources of the system in 
order to process the number of layers that a WMTS server is capable of 
issuing.


___
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

___
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 with WMS Server Search

[Jonathan Moules]

Hi List,
Hopefully I can offer some insights into this as someone with some 
experience in spatial service discovery (I run GeoSeer: 
https:/www.geoseer.net - a search engine for spatial web services).


-
csw.geopole.org is what I believe is behind the search button. As it 
stands right now, this service has the following stats for *working* WMS 
services:

* Points to 229 services that have data
* Across 63 hosts
* with 3,938 layers
It has 0 working WMTS, WFS, or WCS entries.

That might seem like a lot, but GeoSeer's index has the following:
* 218,861 services
* across 5,000 hosts
* with 2,048,346 datasets/layers
More stats: https://www.geoseer.net/stats/ - The index is regularly 
refreshed.


So basically the Geopole service has less than 0.1% of the OGC services 
that are out there (GeoSeer's index isn't exhaustive, but it is several 
times larger than the next largest I know of).


---

Just to be clear, I'm not trying to sleight the GeoPole service, instead 
I'm highlighting a problem that is rarely considered: Manually searching 
CSW's/data portals is almost pointless.


Basically, there are at least 391 CSW services out there (325 of which 
work). Is it reasonable to expect users to be able to find them all and 
manually search them, even with a plugin?
And even if a user did search them all, between them, all those 325 
working CSW's only have about 5% of the spatial web services that are 
actually out there and working! You're still missing 95% of them!


This is why the solutions suggested here while good in theory don't 
really work. At best they're a placebo.


Co-incidentally, I did a blog post on this exact thing just a few days 
ago - https://www.geoseer.net/blog/?p=2020-01-10_dataportal_problems




Solution?
You're welcome to point users to GeoSeer's free web search - it's 
completely free and there are no adverts (because ethics).


GeoSeer also has an API which is designed for exactly this sort of thing 
- https://www.geoseer.net/api.php - it lets you integrate the search 
directly in the application. It's not free because that's how GeoSeer 
covers its costs. I have considered creating a GeoSeer plugin for QGIS 
that uses the API but the business case hasn't been there yet.


I'm open to questions if you want more stats, or have any thoughts/comments.
Cheers,
Jonathan


On 2020-01-20 10:10, Alexander Bruy wrote:

Hi devs,

while checking open issues I have found one about WMS Server Search
functionality https://github.com/qgis/QGIS/issues/25660.

It is about Server search tab in the "Add WMS/WMTS layer" dialog. This
search tab uses configurable catalog URL which by default is set to Sourcepole's
server. According to Pirmin, this catalog didn't get many updates since years.
Also we now have a MetaSearch plugin which is our "new" way to search
for OGC services.

What we should do with WMS Server Search? In the ticket there are two options
proposed:

1. remove WMS Server Search completely and put a hint suggesting user
to use MetaSearch plugin
2. remove default catalog URL from the QGIS settings and show WMS Server
Search tab only when user have entered an URL

Thoughts?



___
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-community-team] QGIS documentation analitics?

[Jonathan Moules]

+1 on not using Google Analytics to spy on users. You can analyse the 
Apache logs using various tools pretty easily to discover things like 
how people got to the web-pages, and which pages are most commonly 
accessed, and even see where in the world folks are.


I can run the logs through one of the tools if you want.


On 18/10/2019 17:55, Régis Haubourg wrote:

Hi,
I would prefer piwki/matamo over google analytics for ethical reasons
if possible.

https://matomo.org/

Régis

Le ven. 18 oct. 2019 à 14:29, João Gaspar  a écrit :

Hi Richard and Alexandre,

if we do not have this kind of SEO such as Google Search Console, this can be a 
good thing with Google Analytics. Google Search Console is a good thing to have 
because is possible to improve research on browsers and rank pages to first 
pages when we search for words that are related to qgis or documentation 
itself. Will help us because this kind of SEO gives hints ad tips to optimize 
de websites.

Another aspect, if we have Google Analytics in the documentation, this will 
allow to have reports about geographic IP based distribution of users, type of 
access, OS, type of device and what pages and click do the users in the sites. 
This will allow us to see and give us feedback which pages are not visited, 
pages that have a lot of access and create strategies to improve pages and so 
on.

Google Search and Google Analytics don't have cost and we can integrate. We 
don't need to create a google account for this they accept foreign emails.

Please let me know if you have any questions that I can try to help, I recently needed to 
see this "kind of tricks" to improve a web platform that I helped to develop.



Regards,
João



Richard Duivenvoorde  escreveu no dia sexta, 18/10/2019 
à(s) 12:41:

On 18/10/2019 12.46, Alexandre Neto wrote:

Do we have analytics on our documentation pages? how have access to it?

I'm not aware of that, other then Apache logs.

Others?

We (as: ad...@qgis.org) every now and then receive a Google email that
we can fix SEO things in their xyz-dashboard, but I never looked into this.

Regards,

Richard

___
Qgis-community-team mailing list for organizing community resources such as 
documentation, translation etc..
qgis-community-t...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-community-team

___
Qgis-community-team mailing list for organizing community resources such as 
documentation, translation etc..
qgis-community-t...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-community-team

___
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] Copyright in a plugin?or idea?

[Jonathan Moules]

Ideas cannot be copyrighted and that's just fine - ideas are a dime a 
dozen; everyone has them all the time. But few people ever implement them.


Which brings us to the crux of the issue - these were implemented so 
ideally should not have been duplicated? And not once but twice for a 
single author. This isn't something you want at the best of times, let 
alone on a resource constrained project like QGIS.


I guess there may be many reasons, and I won't second guess the authors 
here, but it seems that the first thing that should be done before any 
new component/plugin is worked on is to see if there's already one out 
there, and if there is, even if it's dated, try and contact the author. 
Maybe it can be built on, maybe it's a flaky pile of junk, but it only 
takes 10 minutes and may save days/weeks of duplicating work. Maybe it's 
also worth asking on the dev list if anyone has done something to this 
effect previously (I see such posts fairly often here already...).


(Full disclosure - I've recreated the wheel a few times for my own 
projects accidentally).


Just my 2p,

Cheers,

Jonathan


On 2019-10-04 08:01, Paolo Cavallini wrote:

Hola Francisco,

On 02/10/19 13:56, Fran Raga wrote:


Recently I found out about this
plugin https://github.com/qgist/toolbargenerator, which was presented in
the FOSS4G 2019 Bucharest. What surprised me is that this plugin has
EXACTLY the same functionality as mine, implemented for QGIS
3  https://github.com/All4Gis/CustomToolBar , which I developed without
any funding.

thanks for pointing this out. I understand your frustration, but I think
these things are more or less unavoidable, and in the long term are not
a serious issue - time will select the best solutions.
from a different point of view, we would really like not to have
duplication in our plugin list, as th; I regularly ask in this case to
seriously evaluate the opportunity for a merge. Could this apply also here?
Cheers, and thanks for sharing.



___
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] Issue priorization for bugfixing: go flag your favorite issues

[Jonathan Moules]

>  * thumbs up is cheap, and does not necessarily reflect real interest.

I disagree. Yes a thumb-up is a "cheap", but the only people who find 
the issue in the first place to thumb it are those it affects. For this 
sort of thing Cheap is a virtue not a problem (I very much doubt there 
are any troll-farms out there targeting bug lists (yet...)).



I think this is a great way of communicating how much certain issues 
affect people and then the limited resources can be directed appropriately.



On 2019-08-24 08:21, Paolo Cavallini wrote:

Hi Matthias,

On 24/08/19 09:16, Matthias Kuhn wrote:

Yesterday at a dinner with many well known friendly faces, a discussion
started about the priorization of issues.

One of the main problems when deciding which issues to tackle is, that a
developer perspective often differs from the one from the average user
perspective.

So we thought it might be a good idea to start giving our users a bigger
voice in how bugs are prioritized - and how the projects funds are spent
- by giving the developers more information about the "impact footprint"
of issue reports.

*In short: if you particularly hate an issue (or two or three) go to
this issue on github and just give the first post of it a thumbs up****.*

The following link will then show the leaderboard of annoying things

https://github.com/qgis/QGIS/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3ABug

While there is no guarantee that these bugs really will be solved first
(there are a couple of other things also to take into account, like a
well defined solution being at hand) this should give us a much better
(democratic) idea of the often-cited user expectation.

I find the idea interesting and positive, but I see a couple of problems:
* this may generate frustration among users (why the hell an issue with
tens of "likes" has not been solved already? You crappy developers don't
listen to us!)
* thumbs up is cheap, and does not necessarily reflect real interest.
I would be more in favour of an honest expression of interest: I put my
money where my mouth is. Can we have a mechanism of donations attached
to a articular ticket?
Cheers.




___
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] WMTS problem on QGIS 3.4 server?

[Jonathan Moules]

Hi Luca,

The first one sounds like a bug and I''d suggest reporting it to the 
qgis bug tracker.


For clarity: Are we talking about the layer Name or the layer Title? The 
Name is a unique ID for a layer; the vast majority of WxS servers don't 
use spaces in their layer names, instead they use underscores.


The Title is the human-friendly title of the layer and should only be 
used to represent things to us humans.


(Also this question would have been better asked on the QGIS Users list; 
the dev list is for actually developing QGIS)


Cheers,

Jonathan

On 2019-07-25 15:46, Luca Manganelli wrote:

Hello,

I have configured a project with a WMTS service for an ortophoto. I'm 
using QGIS Server 3.4.8 LTR


Two notes:

 - My layer is named "Ortophoto 2015" (with the space), but the WMTS 
GetCapabilities replaces the space with _ (Ortophoto_2015), and in the 
following GetTile, QGIS Server complains that if you use 
Ortophoto_2015 in LAYER, it could not find it (LayerNotFound error), 
but if you use the space it's working!


 - I am using EPSG:25832, but If I load the WMTS layer on QGIS Desktop 
3.8, it is always blank.


Any idea?

___
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] SSL Performance Overhead

[Jonathan Moules]

This has been covered a few times on StackOverflow.
https://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
https://stackoverflow.com/questions/149274/http-vs-https-performance

Basically, the expensive part is creating the connection (handshaking). 
After that, when using the connection the overhead should be minimal. 
Given this I'd suggest the obvious starting point for investigating is 
to confirm it's not recreating the connection over-and-over.


Because it's a database connection it's unlikely there's a slow-down due 
to a lack of caching.


Cheers,
Jonathan

On 18/06/2019 13:28, Bo Victor Thomsen wrote:
Has anyone tried to ascertain how big the overhead is when using SSL - 
and why ?


Regards

Bo Victor Thomsen
AestasGIS Denamrk


Den 18-06-2019 kl. 14:15 skrev Stefan Steiger:
Uh, ah, yea, also, sending a password for a DB-user over the 
intranet-network in plain text is rather bad.
While the data retrieved from the DB might not be confidential, maybe 
there is confidential data in the db.
Also, the login used could have permissions onto another DB that has 
confidential data inside.


In my opinion, the default should be SSL, including in intranet.
If anybody changes the default for performance reasons, they can, and 
correspondingly, the blame will be theirs if anything happens.

Nowadays, we use SSL even in development.
Just my 0.05 $


-Ursprüngliche Nachricht-
Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] 
Im Auftrag von Bernhard Ströbl

Gesendet: Montag, 17. Juni 2019 15:31
An: qgis-developer@lists.osgeo.org
Betreff: Re: [QGIS-Developer] SSL Performance Overhead

Hi all,

I have to add that we use SSL to encrypt the user credentials as we 
use LDAP to authentificate users at the database. So SSL is not only 
relevant looking at data stored in the database.

Bernhard

Am 17.06.2019 um 13:56 schrieb Andreas Neumann:

Hi Stefan,

Yes, sure. If I were a bank or the national bank I would also mandate
use of SSL. Also, when personal data is involved. But many gov
authorities have primarily publically available geoinformation (object
data, no personal data) in their DBs and no sensitive data.

We are just discussing the defaults, anyone can enable SSL if it is
useful or required in their usage scenario.

Andreas

On 2019-06-17 13:20, Stefan Steiger wrote:


One of our customers (Swiss National Bank) mandates the use of SSL in
their internal LAN, even for DB connections.

Using anything but SSL is an insecure mode of communication, even 
in LAN.


RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is
160 Bit, recommended 256.

-Only latest version of OpenSSL allowed

-Accepted TLS 1.1+, recommended TLS 1.2+

-SSL Version 3.0 or older are explicitly forbidden

-Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit

-Extended Validation certificates have to be used

-Wildcards in fully qualified names not allowed

-Accepted: CTR/CBC/CCM/EAX, recommended GCM

-SSL accepted with forward secrecy Disabled, recommended Enabled

-Recommended CryptRandom: /dev/random, /dev/urandom,

as per IT Security Baseline 2017-07-20

*Von:*QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org]
*Im Auftrag von *Andreas Neumann
*Gesendet:* Montag, 17. Juni 2019 09:05
*An:* Matthias Kuhn 
*Cc:* qgis-developer@lists.osgeo.org
*Betreff:* Re: [QGIS-Developer] SSL Performance Overhead

Hi,

I would say, that the use of SSL should be encouraged if the
connection goes through public networks. If the Postgis connection is
within the company LAN I don't see a strong reason for enabling SSL,
unless the company LAN is designed in an "unsafe" way, or if
sensitive data must be hidden from other employees in the same 
company.


Personally, I never had good results (performance wise) if Postgis
connections went through the public Internet, unless it is some "toy
data".

For this reason, I usually used streaming replication to replicate
Postgis, so it is as close as possible to the users who need the data.
The streaming replication, if it goes through the public internet, of
course should use SSL (or often it goes through an SSH tunnel).

Sorry, I don't have any data on the overhead of SSL connections 
though.


Andreas

On 2019-06-17 08:48, Matthias Kuhn wrote:

 Hi,

 The documentation currently promises "massive speed-ups in 
PostGIS

 layer rendering" with SSL disabled. [1
]

 I find some references to performance cost of SSL but they should
 be compensated for with connection pooling which we use for quite
 some time already.

 Recently, the web is more and more encrypted - and that is very
 good! - so I think we should also start to encourage people to
 encrypt their SSL connections. Or at least certainly not
 discourage them from using encryption by promising performance
 benefits.

 Is 

Re: [QGIS-Developer] QGIS server issue: bounding box issues

[Jonathan Moules]

Hi Andreas,

> I wonder if WMS clients should use bounding boxes at all

Unfortunately they solve a real problem and it'd be worse without them: 
Where is the data? This isn't a problem for global datasets but:


* Over 365,000 layers (of 1.2mil) have a bounding box of less than 1,000 
square km. That's a tiny area 31km on a side. Users simply won't be able 
to find that from a global view.


* A lot of WMS layers have scale thresholds for rendering and won't show 
anything if too far zoomed out. Assuming these are done competently then 
*hopefully* the data should render when you're viewing the layer extent 
on any reasonably sized screen.


> Or they should only use the top level bounding box of the whole service.

Even less of an option I'm afraid. I don't believe there's any provision 
for such a service level bounding box in the WMS Spec (couldn't find one 
just now on a quick glance).



I think wrong BBOXes simply falls under "just another way for a service 
administrator to make a service bad/useless" (and trust me, there seem 
to be a lot of ways to do that!)


Cheers,

Jonathan


On 2019-05-13 07:51, Andreas Neumann wrote:


Hi Jonathan,

Thanks for your feedback.

Seems to me that bounding boxes are a big mess. Yet they are used to 
hide data away outside of the bounding box. That behaviour seems 
really dangerous to me. People rely on the WMS that they show "all" 
data, but if so many bounding boxes are out of date in the wild this 
means that clients can't rely on them really. And neither can servers 
(and filter away data).


Also, it seems to me that OGC specifications doesn't handle edge cases 
well, such as layers with only a single point.


Given the fact that many layer bounding boxes are just plain wrong, I 
wonder if WMS clients should use bounding boxes at all, they seem to 
be really, really unreliable. Or they should only use the top level 
bounding box of the whole service. Many open questions ...


Andreas

On 2019-05-13 02:27, Jonathan Moules wrote:


Hi list,

Unless GeoServer has changed it of late, the way they do BBOX 
definition is:


* Layer BBOXes are defined at layer creation time.

* Layer BBOXes are entered manually, though there is a button to 
automatically calculate it from the data extent which automatically 
fills in the manual boxes - the values can then be manually tweaked 
as desired.


* Layer BBOXes are not automatically calculated at use-time.



It looks like GeoServer also turns a single point into a BBOX of a 
single point: 
https://gis.stackexchange.com/questions/113166/the-request-bounding-box-has-zero-area




De-factor treatment of bounding boxes: Layers do often have BBOXes 
that do not actually represent the data.


In fact, of the 1.2million WMS, WFS, WCS, WMTS layers in my database, 
nearly 55,000 don't even have BBOXes (or have not-valid-wgs84 
coordinates)!


There's no easy way to check how many of the rest are declaring the 
correct BBOX, but experience suggests a lot don't.




De jure usage: I've just taken a quick glance at the standards (WMS 
1.3, WFS 2, WCS 2) and they standards themselves don't seem to 
address the issue of keeping the bboxes contemporary at all or even 
exactly what they're for. The closest I could find as to specifying 
the exact purpose of the bboxes is in the WFS 2 spec:


"The ows:WGS84BoundingBox element may be used to indicate the edges 
of an enclosing rectangle in decimal
degrees of latitude and longitude in WGS84. Its purpose is to 
facilitate geographic searches by indicating where
instances of the particular feature type exist. Since multiple 
ows:WGS84BoundingBox elements may be
specified, a WFS may indicate where various clusters of data exist. 
This knowledge aids client applications by
letting them know where they should query in order to have a high 
probability of finding feature data."


And this is mildly telling from the WMS 1.3 spec:

"There is no provision for describing disjoint bounding boxes. For 
example, consider a dataset which covers two
areas separated by some distance. The server cannot provide two 
separate bounding boxes in the same Layer using the
same CRS to separately describe those areas. To handle this type of 
situation, the server may either define a single larger
bounding box which encloses both areas, or may define two separate 
Layers that each have distinct Name and BoundingBox

values."

So it doesn't look like handling changing extents is something the 
spec writers have specified.


And I can assure you, many servers don't have valid BBOXes defined. 
In fact


Cheers,

Jonathan


On 2019-05-09 15:37, Alessandro Pasotti wrote:


On Thu, May 9, 2019 at 4:16 PM Eric Lemoine 
mailto:eric.lemo...@oslandia.com>> wrote:


On Thu, 9 May 2019 11:28:00 +0200
Andreas Neumann mailto:a.neum...@carto.net>> wrote:

> Hi QGIS (server) devs,

Hi Andreas

>
> We came across issues ar

Re: [QGIS-Developer] QGIS server issue: bounding box issues

[Jonathan Moules]

Hi list,

Unless GeoServer has changed it of late, the way they do BBOX definition is:

* Layer BBOXes are defined at layer creation time.

* Layer BBOXes are entered manually, though there is a button to 
automatically calculate it from the data extent which automatically 
fills in the manual boxes - the values can then be manually tweaked as 
desired.


* Layer BBOXes are not automatically calculated at use-time.



It looks like GeoServer also turns a single point into a BBOX of a 
single point: 
https://gis.stackexchange.com/questions/113166/the-request-bounding-box-has-zero-area




De-factor treatment of bounding boxes: Layers do often have BBOXes that 
do not actually represent the data.


In fact, of the 1.2million WMS, WFS, WCS, WMTS layers in my database, 
nearly 55,000 don't even have BBOXes (or have not-valid-wgs84 coordinates)!


There's no easy way to check how many of the rest are declaring the 
correct BBOX, but experience suggests a lot don't.




De jure usage: I've just taken a quick glance at the standards (WMS 1.3, 
WFS 2, WCS 2) and they standards themselves don't seem to address the 
issue of keeping the bboxes contemporary at all or even exactly what 
they're for. The closest I could find as to specifying the exact purpose 
of the bboxes is in the WFS 2 spec:


"The ows:WGS84BoundingBox element may be used to indicate the edges of 
an enclosing rectangle in decimal
degrees of latitude and longitude in WGS84. Its purpose is to facilitate 
geographic searches by indicating where
instances of the particular feature type exist. Since multiple 
ows:WGS84BoundingBox elements may be
specified, a WFS may indicate where various clusters of data exist. This 
knowledge aids client applications by
letting them know where they should query in order to have a high 
probability of finding feature data."


And this is mildly telling from the WMS 1.3 spec:

"There is no provision for describing disjoint bounding boxes. For 
example, consider a dataset which covers two
areas separated by some distance. The server cannot provide two separate 
bounding boxes in the same Layer using the
same CRS to separately describe those areas. To handle this type of 
situation, the server may either define a single larger
bounding box which encloses both areas, or may define two separate 
Layers that each have distinct Name and BoundingBox

values."

So it doesn't look like handling changing extents is something the spec 
writers have specified.


And I can assure you, many servers don't have valid BBOXes defined. In fact

Cheers,

Jonathan


On 2019-05-09 15:37, Alessandro Pasotti wrote:


On Thu, May 9, 2019 at 4:16 PM Eric Lemoine > wrote:


On Thu, 9 May 2019 11:28:00 +0200
Andreas Neumann mailto:a.neum...@carto.net>>
wrote:

> Hi QGIS (server) devs,

Hi Andreas

>
> We came across issues around calculating bounding boxes in QGIS
> server.
>
> 1. Layers with only one point feature:
>
> If a layer contains only one single point feature, QGIS server
> calculates a bounding box where the minx equals maxx and miny
equals
> maxy, so resulting in a bounding box without a width and height.
> Sounds logical to QGIS server developers,


Yes. The BBOX of a point has minx=maxx and miny=maxy.  Even
PostGIS says
so :)


> but combined with the fact
> that QGIS server doesn't take into account rendered symbol sizes
> (another issue we have, see issue nr 2), it means that no WMS client
> will ever see this one single symbol rendered, which can't be the
> solution here ...


If the GetMap request's BBOX param is set to the layer extent (the
BBOX with no dimension here) then it makes sense that there's nothing
rendered in the resulting image.  If the GetMap request's BBOX
param is
set to a BBOX that contains the layer extent then the point should be
rendered in the resulting image.

So to me this is a client issue, not a QGIS Server issue.


> 2. Layer bounding boxes do not take into account rendered symbol
> sizes:
>
> Please have a look at
> http://www.carto.net/neumann/temp/qgis_server_bounding_box_issue.png
> - The green rectangle and the green arrows are not part of the QGIS
> server rendering, but they are added as an annotation to the
rendered
> QGIS server graphics, to highlight the issues.


What software do you use on the client side?  Does the green
rectangle correspond to the BBOX requested by the client? And does the
requested BBOX equal the layer extent in this case?  Or does it
contain
the layer extent?

I may be wrong but I understand that the requested BBOX (the green
rectangle) is the layer extent.  And in that case it makes sense that
the symbols are cut for points that are closed to the boundaries. 
Again
it's a client issue.


> Here we have the issue that QGIS 

[QGIS-Developer] Consistent Ordering (and terms) for buttons in dialogs

[Jonathan Moules]

Hi List,

There seems to be some inconsistent ordering and usage of the buttons on 
dialogs. Does QGIS have developer guidelines on this?


Largely it's fairly consistent but sometimes button orders seem 
incongruous. Also the use of "Cancel" versus "Close".


For example, Raster > "Raster Calculator" has: Ok, Cancel, Help

Raster > "Align Rasters": Ok, Close, Help

All the other data processing tools I looked at (not all) (Vector and 
Raster menus) were consistent:  Run, Close, Help


Data Source Manager: (other buttons), Close, Add, Help

Add new service/database dialog: Ok, Cancel, Help

CRS Dialog: Ok, Cancel, Help

Project settings: OK, Cancel, Apply, Help

Options: Ok, Cancel, Help

Style Manager: Close, Help




The ones that particularly jump out at me are:

* "Align Raster" using "close" not "cancel"

* Project Settings has an "Apply" but "Options" doesn't.

* Apply and Add seem to come after cancel/close but ok/run always comes 
before. Shouldn't add/apply be to the left?


* Data processing tools seem like they should be "Cancel" as they're 
Do/Do-Not dialogs.


These are minor things but consistency in the UI makes the application 
much easier to use as it lowers the cognitive burden on the user.


(3.4.3)

Cheers,

Jonathan



___
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: filter by categories in an OGC compatible way

[Jonathan Moules]

Hi Andrea,

Just checked the WMS 1.3.0 spec:

"HTTP supports two request methods: GET and POST. One or both of these 
methods may be offered by a server,
and the use of the Online Resource URL differs in each case. Support for 
the GET method is mandatory; support

for the POST method is optional."

The GetCaps document should indicate whether POST is supported.

So I was wrong, they can be GET, but it's not guaranteed. Sorry about 
that, thanks for checking!


Cheers,
Jonathan

On 2019-04-09 20:31, Andreas Neumann wrote:

Hi Jonathan,

I am aware about the limit in GET requests.

Are you sure that WMS servers don't support POST requests?

Some Google hits suggest otherwise

Geoserver:

https://anitagraser.com/2010/06/09/getmap-from-geoserver-using-http-post/

UMN:

https://gis.stackexchange.com/questions/232215/mapserver-wms-http-post-requests 



I am pretty sure that QGIS Server also allows POST requests, but I may 
be wrong.


Andreas

Am 09.04.19 um 19:09 schrieb Jonathan Moules:


Hi Andreas,

Another problem you may hit - the link below is hitting it being 
~2300 chars - URL's (and thus GET requests) cannot reliably be more 
than about 2000 characters long. At that point you need to shift over 
to POST requests (and I think GetMap is GET only...).


https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers 



Cheers,

Jonathan


On 2019-04-09 16:07, Andreas Neumann wrote:

Hi Paul
Thanks - now I know that I have to use SLD_BODY for the case where the
SLD is in the URL.
Another QGIS-Server specific question:
Can I count on it that the SLD output by QGIS server with the GetStyles
request can also be consumed again by QGIS server? What about complex
styles (e.g. something with a style that can't easily be represented by
SLD). If I first consume the styles from QGIS server, then filter and
send back, would the complex styles potentially be lost/destroyed?
Again: our intent here is merely to filter categories, not to change 
the

styles.
Thanks,
Andreas
On 2019-04-09 16:28, pblottiere wrote:


Hi Andreas,
Can you point me to an example how to create a valid GetMap 
request with an SLD submitted? 


There's a basic example in unit tests: 
https://github.com/qgis/QGIS/blob/master/tests/src/python/test_qgsserver_wms_getmap.py#L1309-L1325


Regards,

Paul
On 4/9/19 4:14 PM, Andreas Neumann wrote:
Hi,
I did some test:
Here is a long URL with the SLD (originally sent by QGIS server, 
stripped away some RULES manually) and sending it back in a GetMap 
request:


https://services.geo.zg.ch/ows-oereb/Grundwasserschutz?SERVICE=WMS=1.3.0=GetMap=2682932,1225299,2684213,1226054=EPSG:2056=1615=952=ch.zg.grundwasserschutz.gwszonen==image/png=96_RESOLUTION=96_OPTIONS=dpi:96=TRUE=%3CStyledLayerDescriptor+xmlns%3D%22http%3A%2F%2Fwww.opengis.net%2Fsld%22+xmlns%3Axlink%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxlink%22+xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22+xsi%3AschemaLocation%3D%22http%3A%2F%2Fwww.opengis.net%2Fsld+http%3A%2F%2Fschemas.opengis.net%2Fsld%2F1.1.0%2FStyledLayerDescriptor.xsd%22+xmlns%3Ase%3D%22http%3A%2F%2Fwww.opengis.net%2Fse%22+version%3D%221.1.0%22+xmlns%3Aogc%3D%22http%3A%2F%2Fwww.opengis.net%2Fogc%22%3E%0D%0A+%3CNamedLayer%3E%0D%0A++%3Cse%3AName%3Ech.zg.grundwasserschutz.gwszonen%3C%2Fse%3AName%3E%0D%0A++%3CUserStyle%3E%0D%0A+++%3Cse%3AName%3Edefault%3C%2Fse%3AName%3E%0D%0A+++%3Cse%3AFeatureTypeStyle%3E%0D%0A%3Cs 

e%3ARule%3E%0D%0A+%3Cse%3AName%3EGrundwasserschutzzone+S1%3C%2Fse%3AName%3E%0D%0A+%3Cse%3ADescription%3E%0D%0A++%3Cse%3ATitle%3EGrundwasserschutzzone+S1%3C%2Fse%3ATitle%3E%0D%0A+%3C%2Fse%3ADescription%3E%0D%0A+%3Cogc%3AFilter+xmlns%3Aogc%3D%22http%3A%2F%2Fwww.opengis.net%2Fogc%22%3E%0D%0A++%3Cogc%3APropertyIsEqualTo%3E%0D%0A+++%3Cogc%3APropertyName%3Etyp_code%3C%2Fogc%3APropertyName%3E%0D%0A+++%3Cogc%3ALiteral%3ES1%3C%2Fogc%3ALiteral%3E%0D%0A++%3C%2Fogc%3APropertyIsEqualTo%3E%0D%0A+%3C%2Fogc%3AFilter%3E%0D%0A+%3Cse%3APolygonSymbolizer%3E%0D%0A++%3Cse%3AFill%3E%0D%0A+++%3Cse%3ASvgParameter+name%3D%22fill%22%3E%23003bb3%3C%2Fse%3ASvgParameter%3E%0D%0A++%3C%2Fse%3AFill%3E%0D%0A++%3Cse%3AStroke%3E%0D%0A+++%3Cse%3ASvgParameter+name%3D%22stroke%22%3E%2380%3C%2Fse%3ASvgParameter%3E%0D%0A+++%3Cse%3ASvgParameter+name%3D%22stroke-width%22%3E1%3C%2Fse%3ASvgParameter%3E%0D%0A+++%3Cse%3ASvgParameter+name%3D%22stroke-linej 

oin%22%3Ebevel%3C%2Fse%3ASvgParameter%3E%0D%0A++%3C%2Fse%3AStroke%3E%0D%0A+%3C%2Fse%3APolygonSymbolizer%3E%0D%0A%3C%2Fse%3ARule%3E%0D%0A+++%3C%2Fse%3AFeatureTypeStyle%3E%0D%0A++%3C%2FUserStyle%3E%0D%0A+%3C%2FNamedLayer%3E%0D%0A%3C%2FStyledLayerDescriptor%3E 



The response is:

http://www.opengis.net/ogc; 
version="1.3.0">
 SLD 
('http://www.opengis.net/sld; [1] 
xmlns:xlink="http://www.w3.org/1999/xlink; [2] 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; [3] 
xsi:schemaLocation=

Re: [QGIS-Developer] PyQGIS WMS tiles don't load on Windows

[Jonathan Moules]

Hi Erik,

(Staying on list)

I'm afraid I can't help you with QGIS stuff as I don't know anything 
about the code-base. Just wanted to clear up confusion.


That Google service is definitely not a WMS service. To get a maptile 
via WMS it would have this in the query string somewhere: 
=getmap=WMS= at the minimum. Most OGC services 
build URLs similar that, so they're easy to spot.


Other map service types are TMS (which is most similar to Google map 
tiles and OSM tile services) and WMTS (a more complex version of TMS). 
Both are designed for sharing basemap tiles. It took me a while to get 
my head around the different types too!


Cheers,

Jonathan


On 2019-04-09 19:53, Erik Polzin wrote:

Hi Jonathan,
Thanks for your reply.

I'd been reading through some of the documentation on the OGC specifications
<https://docs.qgis.org/testing/en/docs/user_manual/working_with_ogc/ogc_client_support.html>,
and came across those URLs to the google maps servers elsewhere. So I
glanced at the data from this url
https://mt1.google.com/vt?lyrs=s=0=0=0, and thought it looked like a
WMS server - so hardly an educated approach!
But, like I mentioned, that source works fine in the full-blown QGIS app
(as a WMS layer).

But I haven't been working with map servers for very long - so I guess my
question is what other options for server types are there? You mention that
Google has a non-WMS based service. Anywhere you know of I can find out
more about this? Can I use it through QGIS?

I appreciate the help,
Erik

On Tue, Apr 9, 2019 at 6:25 PM Jonathan Moules 
wrote:


Hi Erik,

I think maybe there's a nomenclature problem here. I wasn't aware that any
Google services were available via WMS.

WMS is a specific specification, and if you're googling around using that
term you're going to find results that aren't pertinent to what you
actually want to do (which is using Google's tile based, non-WMS services).

Cheers,

Jonathan


On 2019-04-09 08:54, Erik Polzin wrote:

I'm busy developing an app using the QGIS Python api, PyQGIS, and am
noticing some strange behaviour when loading WMS tiles: Running the python
script on Linux Mint loads xyz layers from Google Maps and Google Satellite
just fine. On Windows, only the Google Maps layer loads.

Here is a test script I wrote to demonstrate the problem:

from qgis.core import QgsApplication, QgsProject, QgsRasterLayer
from qgis.gui import QgsMapCanvas, QgsLayerTreeMapCanvasBridge

from PyQt5.QtWidgets import QMainWindow
import os

GOOGLE_MAPS_SOURCE = 
"type=xyz=https://mt1.google.com/vt?lyrs%3Dm%26x%3D%7Bx%7D%26y%3D%7By%7D%26z%3D%7Bz%7D=19=0
"
GOOGLE_SATELLITE_SOURCE = 
"type=xyz=https://mt1.google.com/vt?lyrs%3Ds%26x%3D%7Bx%7D%26y%3D%7By%7D%26z%3D%7Bz%7D=19=0
"

class WMSTestApp(QMainWindow):

 def __init__(self):
 super().__init__()

 self.canvas = QgsMapCanvas(self)
 self.bridge =
QgsLayerTreeMapCanvasBridge(QgsProject.instance().layerTreeRoot(),
self.canvas)

 layer = QgsRasterLayer(GOOGLE_SATELLITE_SOURCE, "Test WMS Layer",
"wms")

 QgsProject.instance().addMapLayer(layer)
 self.canvas.setLayers([layer])

 self.setCentralWidget(self.canvas)


QgsApplication.setPrefixPath(os.environ.get("QGIS_PREFIX_PATH", "C:\Program
Files\QGIS 3.4\apps\qgis"), True)
qgs = QgsApplication([], True)
qgs.initQgis()

app = WMSTestApp()
app.show()
qgs.exec_()
qgs.exitQgis()

Interestingly, the layers (from the same sources!) both load from the
Windows QGIS app.
So I did some digging and noticed that the default Google Maps url returns
PNG files, while the Satellite url returns JPEGs. I tested a couple of
other links, and it seems like only PNG tile servers have any effect on
windows systems.

Have tested this on Windows 7 and 10, with the same results.

Does PyQgis need to be reconfigured in some way to get this to work? Or is
it a known issue with the version (3.4) I'm using?

Cheers and thanks,
Erik



___
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] QGIS-Server: filter by categories in an OGC compatible way

[Jonathan Moules]

Hi Andreas,

Another problem you may hit - the link below is hitting it being ~2300 
chars - URL's (and thus GET requests) cannot reliably be more than about 
2000 characters long. At that point you need to shift over to POST 
requests (and I think GetMap is GET only...).


https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers

Cheers,

Jonathan


On 2019-04-09 16:07, Andreas Neumann wrote:

Hi Paul
Thanks - now I know that I have to use SLD_BODY for the case where the
SLD is in the URL.
Another QGIS-Server specific question:
Can I count on it that the SLD output by QGIS server with the GetStyles
request can also be consumed again by QGIS server? What about complex
styles (e.g. something with a style that can't easily be represented by
SLD). If I first consume the styles from QGIS server, then filter and
send back, would the complex styles potentially be lost/destroyed?
Again: our intent here is merely to filter categories, not to change the
styles.
Thanks,
Andreas
On 2019-04-09 16:28, pblottiere wrote:


Hi Andreas,
Can you point me to an example how to create a valid GetMap request 
with an SLD submitted? 


There's a basic example in unit tests: 
https://github.com/qgis/QGIS/blob/master/tests/src/python/test_qgsserver_wms_getmap.py#L1309-L1325


Regards,

Paul
On 4/9/19 4:14 PM, Andreas Neumann wrote:
Hi,
I did some test:
Here is a long URL with the SLD (originally sent by QGIS server, 
stripped away some RULES manually) and sending it back in a GetMap 
request:


https://services.geo.zg.ch/ows-oereb/Grundwasserschutz?SERVICE=WMS=1.3.0=GetMap=2682932,1225299,2684213,1226054=EPSG:2056=1615=952=ch.zg.grundwasserschutz.gwszonen==image/png=96_RESOLUTION=96_OPTIONS=dpi:96=TRUE=%3CStyledLayerDescriptor+xmlns%3D%22http%3A%2F%2Fwww.opengis.net%2Fsld%22+xmlns%3Axlink%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxlink%22+xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22+xsi%3AschemaLocation%3D%22http%3A%2F%2Fwww.opengis.net%2Fsld+http%3A%2F%2Fschemas.opengis.net%2Fsld%2F1.1.0%2FStyledLayerDescriptor.xsd%22+xmlns%3Ase%3D%22http%3A%2F%2Fwww.opengis.net%2Fse%22+version%3D%221.1.0%22+xmlns%3Aogc%3D%22http%3A%2F%2Fwww.opengis.net%2Fogc%22%3E%0D%0A+%3CNamedLayer%3E%0D%0A++%3Cse%3AName%3Ech.zg.grundwasserschutz.gwszonen%3C%2Fse%3AName%3E%0D%0A++%3CUserStyle%3E%0D%0A+++%3Cse%3AName%3Edefault%3C%2Fse%3AName%3E%0D%0A+++%3Cse%3AFeatureTypeStyle%3E%0D%0A%3Cs 

e%3ARule%3E%0D%0A+%3Cse%3AName%3EGrundwasserschutzzone+S1%3C%2Fse%3AName%3E%0D%0A+%3Cse%3ADescription%3E%0D%0A++%3Cse%3ATitle%3EGrundwasserschutzzone+S1%3C%2Fse%3ATitle%3E%0D%0A+%3C%2Fse%3ADescription%3E%0D%0A+%3Cogc%3AFilter+xmlns%3Aogc%3D%22http%3A%2F%2Fwww.opengis.net%2Fogc%22%3E%0D%0A++%3Cogc%3APropertyIsEqualTo%3E%0D%0A+++%3Cogc%3APropertyName%3Etyp_code%3C%2Fogc%3APropertyName%3E%0D%0A+++%3Cogc%3ALiteral%3ES1%3C%2Fogc%3ALiteral%3E%0D%0A++%3C%2Fogc%3APropertyIsEqualTo%3E%0D%0A+%3C%2Fogc%3AFilter%3E%0D%0A+%3Cse%3APolygonSymbolizer%3E%0D%0A++%3Cse%3AFill%3E%0D%0A+++%3Cse%3ASvgParameter+name%3D%22fill%22%3E%23003bb3%3C%2Fse%3ASvgParameter%3E%0D%0A++%3C%2Fse%3AFill%3E%0D%0A++%3Cse%3AStroke%3E%0D%0A+++%3Cse%3ASvgParameter+name%3D%22stroke%22%3E%2380%3C%2Fse%3ASvgParameter%3E%0D%0A+++%3Cse%3ASvgParameter+name%3D%22stroke-width%22%3E1%3C%2Fse%3ASvgParameter%3E%0D%0A+++%3Cse%3ASvgParameter+name%3D%22stroke-linej 

oin%22%3Ebevel%3C%2Fse%3ASvgParameter%3E%0D%0A++%3C%2Fse%3AStroke%3E%0D%0A+%3C%2Fse%3APolygonSymbolizer%3E%0D%0A%3C%2Fse%3ARule%3E%0D%0A+++%3C%2Fse%3AFeatureTypeStyle%3E%0D%0A++%3C%2FUserStyle%3E%0D%0A+%3C%2FNamedLayer%3E%0D%0A%3C%2FStyledLayerDescriptor%3E 



The response is:

http://www.opengis.net/ogc; 
version="1.3.0">
 SLD 
('http://www.opengis.net/sld; [1] 
xmlns:xlink="http://www.w3.org/1999/xlink; [2] 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; [3] 
xsi:schemaLocation="http://www.opengis.net/sld 
http://schemas.opengis.net/sld/1.1.0/StyledLayerDescriptor.xsd; [4] 
xmlns:se="http://www.opengis.net/se; [5] version="1.1.0" 
xmlns:ogc="http://www.opengis.net/ogc; [6]>  
ch.zg.grundwasserschutz.gwszonen  
default   
Grundwasserschutzzone S1  
Grundwasserschutzzone S1  
http://www.opengis.net/ogc; [6]> 
 typ_code 
S1   
  name="fill">#003bb3   
name="stroke">#80 name="stroke-width">1 name="stroke-linejoin">bevel  

 ') cannot be converted into QString

 
So apparently the SLD cannot be converted to a QString. Is my 
encoding in the URL above wrong or am I missing a required additional 
parameter?
Can you point me to an example how to create a valid GetMap request 
with an SLD submitted?

Thanks a lot, Andreas
On 2019-04-09 15:38, Andreas Neumann wrote:
Hi,
Does QGIS-Server support SLD styles to filter away RULEs in a GetMap 
Request?
I would assume, yes, but in what encoding would I submit such an SLD 
in a GET request? I know that one should rather use POST reqests for 
such long 

Re: [QGIS-Developer] PyQGIS WMS tiles don't load on Windows

[Jonathan Moules]

Hi Erik,

I think maybe there's a nomenclature problem here. I wasn't aware that 
any Google services were available via WMS.


WMS is a specific specification, and if you're googling around using 
that term you're going to find results that aren't pertinent to what you 
actually want to do (which is using Google's tile based, non-WMS services).


Cheers,

Jonathan


On 2019-04-09 08:54, Erik Polzin wrote:

I'm busy developing an app using the QGIS Python api, PyQGIS, and am
noticing some strange behaviour when loading WMS tiles: Running the python
script on Linux Mint loads xyz layers from Google Maps and Google Satellite
just fine. On Windows, only the Google Maps layer loads.

Here is a test script I wrote to demonstrate the problem:

from qgis.core import QgsApplication, QgsProject, QgsRasterLayer
from qgis.gui import QgsMapCanvas, QgsLayerTreeMapCanvasBridge

from PyQt5.QtWidgets import QMainWindow
import os

GOOGLE_MAPS_SOURCE = "type=xyz=
https://mt1.google.com/vt?lyrs%3Dm%26x%3D%7Bx%7D%26y%3D%7By%7D%26z%3D%7Bz%7D=19=0
"
GOOGLE_SATELLITE_SOURCE = "type=xyz=
https://mt1.google.com/vt?lyrs%3Ds%26x%3D%7Bx%7D%26y%3D%7By%7D%26z%3D%7Bz%7D=19=0
"

class WMSTestApp(QMainWindow):

 def __init__(self):
 super().__init__()

 self.canvas = QgsMapCanvas(self)
 self.bridge =
QgsLayerTreeMapCanvasBridge(QgsProject.instance().layerTreeRoot(),
self.canvas)

 layer = QgsRasterLayer(GOOGLE_SATELLITE_SOURCE, "Test WMS Layer",
"wms")

 QgsProject.instance().addMapLayer(layer)
 self.canvas.setLayers([layer])

 self.setCentralWidget(self.canvas)


QgsApplication.setPrefixPath(os.environ.get("QGIS_PREFIX_PATH", "C:\Program
Files\QGIS 3.4\apps\qgis"), True)
qgs = QgsApplication([], True)
qgs.initQgis()

app = WMSTestApp()
app.show()
qgs.exec_()
qgs.exitQgis()

Interestingly, the layers (from the same sources!) both load from the
Windows QGIS app.
So I did some digging and noticed that the default Google Maps url returns
PNG files, while the Satellite url returns JPEGs. I tested a couple of
other links, and it seems like only PNG tile servers have any effect on
windows systems.

Have tested this on Windows 7 and 10, with the same results.

Does PyQgis need to be reconfigured in some way to get this to work? Or is
it a known issue with the version (3.4) I'm using?

Cheers and thanks,
Erik


___
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] How to update features with WFS-T & QGIS-Server 3.4?

[Jonathan Moules]

A quick google found this:

https://github.com/opengisch/QField/issues/300

Don't know if it helps.

Cheers,

Jonathan

On 2019-03-25 14:31, Piotr Bednarek wrote:

Hi

I have a problem with WFS-T. I'm creating map using OpenLayers 5.3,
Qgis-server 3.4 and postgis 9.6-2.4. The task is to get layer with WFS and
add possibility to draw new layer records, modify(update) existing or
delete.

Getting layers, insert and delete works but there is problem with
modify(update).

I don't understand error when trying to commit update with modification. Do
you know how to fix it?
I mean "PostGIS error while changing attributes: ERROR:  prepared statement
"updatefeature" already exists" in TransactionResponse on the bottom.

Request: POST /ogc/test?request=Transaction

Body:


http://www.opengis.net/wfs;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; service="WFS"
version="1.1.0">

   
  geometry
  
 http://www.opengis.net/gml;
srsName="EPSG:3857">

   
  
 
2207239.1899058325 6495535.477306303
2212704.4203063278 6494579.978657217 2212589.761230811 6492898.498726965
2206589.418038072 6493089.550906483 2205977.9400751446 6493089.550906483
2208294.948366083 6494322.088930524 2207239.1899058325
6495535.477306303
 
  
   

 
  
   
   
  gid
  12
   
   
  __gid
  12
   
   
  imie
   
   
  nazwisko
   
   
  adresprywa
   
   
  adres
   
   
  nrdzialki
   
   
  oznaczenie
   
   
  trescuwagi
  assd
   
   
  sesja
  1544771921921
   
   
  nrobrebu
   
   http://www.opengis.net/ogc;>
  
   




Response:
http://www.opengis.net/ogc;
xmlns="http://www.opengis.net/wfs;
xsi:schemaLocation="http://www.opengis.net/wfs
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
 
 0
 
 
 
 Error committing updates:
   Provider errors:; PostGIS error while changing attributes: ERROR:
prepared statement "updatefeature" already exists
 
 
 


code:

var WFSTSerializer = new ol.format.WFS();
var featObject = WFSTSerializer.writeTransaction(insertedFeatures,
vectorSource.getFeatures(), deletedFeatures, {
 featureType: editedLayer,
 service: 'WFS',
 version: '1.1.0',
 srsName: 'EPSG:3857',
});
var serializer = new XMLSerializer();
var featString = serializer.serializeToString(featObject);
var request = new XMLHttpRequest();
request.open('POST', location.protocol+ "//"+ location.hostname+ ":81/ogc/"
+ projectUrl + "?request=Transaction");
request.setRequestHeader('Content-Type', 'text/xml');
request.send(featString);





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


___
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-psc] Request for Change of UserAgent

[Jonathan Moules]

Interesting thought. But then, what scenario are you imagining? "Mozilla 
5.0" is typically for web-browsers (Richards original point), it doesn't 
seem to be used for most other GIS and tooling (at least when making OGC 
requests).


Examples of other user-agents that I have to hand (somewhat dated):

"ArcGIS Client Using WinInet" - ArcGIS 9.x (but probably 10.x too)

"Tableau 8100.14.0408.1805; pro; libcurl-client; 64-bit; en_US; 
Microsoft Windows 8 Professional (build 9200)"


"FME/2015.7.8.15021  libcurl/7.26.0 OpenSSL/0.9.8a zlib/1.2.7 libidn/1.25"

And I just downloaded gvSIG and uDig:

"uDig 2.0.0. (http://udig.refractions.net) Java/1.8.0_111"

"Mozilla/5.0 (gvSIG) like Gecko"

So it looks like only gvSIG does the Mozilla thing.


On 2019-02-24 23:25, Nyall Dawson wrote:

On Mon, 25 Feb 2019 at 09:05, Jonathan Moules
 wrote:

This makes sense, but thinking about it, it doesn't seem plausible.

If I were whitelisting user agents, there are three ways I'd consider
doing it.

Explicit full string:
* "Mozilla/5.0 QGIS/3.4.3-Madeira" - except of course that'd break next
time someone updates QGIS by even a point version. So I doubt anyone is
doing that; too much maintenance. And if they *are* doing this, well
then they'll have to update their whitelist with the new user agent on
the new release whether it includes "Mozilla" or not.

* Some sort of regexp looking for that structure (i.e. "Mozilla/5.0
QGIS/[0-9].[0-9]...") but allow any set of numbers. I can't conceive of
when this would be the best option or even a "good" option - it's just
asking for problems with version numbers (what happens when QGIS gets to
double-digits in any version field for instance?). I don't doubt it may
solve a particular problem somewhere maybe, but I would hope there
wouldn't be many using this method (and of course, this is assuming that
the "Mozilla" is part of the regex).

* Search the user agent for the string "QGIS". I do some things that
look at user-agents and this is what I do. It's easily the simplest and
definitely the most fool-proof way to validate a client is at least
claiming to be QGIS.

Actually - I'm thinking more of the case where a server doesn't
know/care about QGIS, and is only allowing requests which begin with
"Mozilla/5.0".

Nyall



___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] Request for Change of UserAgent

[Jonathan Moules]

Hi Richard,

I don't think without more information it's clear precisely what QGIS 
should change to help them?


Indeed, personally I'm still not sure what the current problem is for 
them. I get that they have some over-users of their service and need to 
curtail this (a very tricky problem), but what's their current solution 
and how does a user-agent change help it?


I'd suggest against QGIS using different user-agents for destinations as 
was suggested earlier in the thread because down that road lies madness 
(it's a highly opaque thing that /will/ bite people as they try and 
debug issues).


Cheers,

Jonathan


On 23/02/2019 11:17, Richard Duivenvoorde wrote:

For what I understand, they use some cookie-based trick to help maintain
their QOS (and then to make it possible to throttle a very demanding web
application?).

This made sense to me. Also because I really do not envy maintainers of
such services: it is hard to keep up such free services (as an example
(see irc log) he mentioned that certain transportation software started
to poll the reverse geocoding every second in every car). I think it's
pretty important for us to have OSM, and be helpfull to them.
But if Firefishy/Grant is willing to give more details (he is in bcc)
that would be great.

Regards,

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



___
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-psc] Request for Change of UserAgent

[Jonathan Moules]

It seems to me there are a few different aspects to this.

- The convention is to stick "Mozilla 5" into user-agents for browsers 
because every other browser uses it. At this point they all pretend to 
be each other - 
https://stackoverflow.com/questions/1114254/why-do-all-browsers-user-agents-start-with-mozilla


- Looking at a bunch of random user-agents, non-browsers don't usually 
put "Mozilla" in them (there are websites with long lists).


- For some reason OSM can't block the QGIS agent. I'm with Mathieu - 
this seems odd because it explicitly says "QGIS".


- Cookies - QGIS doesn't do this (makes sense, doesn't need them), but 
why does OSM need them? Relying on cookies alone isn't a good idea - 
many users don't allow 3rd party cookies, and many users delete cookies 
when the browser closes or even when the tab is closed (self-destructing 
cookies plugins).


So I'd suggest it probably is worth removing the "Mozilla" component but 
it's not clear what the OSM request is about or why, so there's no way 
to know how to help them solve their problem.


Cheers,
Jonathan


On 21/02/2019 08:13, Richard Duivenvoorde wrote:

On 21/02/2019 08.56, Mathieu Pellerin wrote:

I would really like to understand (i.e. get an explanation) from the OSM
admins as to why a user agent that explicitly identifies itself as QGIS
like we have now is not enough for them before moving forward.

Being a web admin/developer myself, I can hardly find a reason why
that's not enough.

I'm more curious than anything else, lots of love to the great OSM guys :)

Cc'ing this to Grant/Firefishy too, so maybe he wants to answer here.

But one of the things he convinced me with was, that for example in
browsers they can work with cookies, while QGIS shows itself as a
Mozilla browser, BUT does not accept cookies etc etc.

Regards,

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



___
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 WCS is requesting FULL dataset?

[Jonathan Moules]

Hi Lists,

I'm cross posting this to GeoServer-Users over from QGIS-Dev as the 
current QGIS code seems to be trying to work around a GeoServer quirk 
based on Nyall's code-comment snippet.


Is there something different QGIS can do to work around the stated issue 
in a better way given I guess requesting a 10x10 Coverage via WCS isn't 
going to be doing the host server any favours?


Cheers,

Jonathan


On 2018-10-15 00:54, Nyall Dawson wrote:


I can't explain the background here, but it seems deliberate. There's
a comment before this request is made:

"
   // It may happen (GeoServer) that extent reported in
spatialDomain.Envelope is larger
   // than the coverage. Then if that larger BBOX is requested, the
server returns
   // request BBOX intersected with coverage box scaled to requested
WIDTH and HEIGHT.
   // GDAL WCS client does not suffer from this probably because it
probably takes
   // extent from lonLatEnvelope (it probably does not calculate it from
   // spatialDomain.RectifiedGrid because calculated value is slightly
different).

   // To get the true extent (it can also be smaller than real if
reported Envelope is
   // than real smaller, but smaller is safer because data cannot be
shifted) we make
   // request of the whole extent cut the extent from spatialDomain.Envelope if
   // necessary"

  getCache( 1, mCoverageExtent, 10, 10 );


Radim may know more and may be able to explain if this workaround is
still necessary


Nyall


Hi,

using our national DEM WCS:

https://geodata.nationaalgeoregister.nl/ahn3/wcs?

Loading the layer ahn3_5m_dtm for an area of a couple of km in
epsg:28992 is very slow.

I'm not so familiar with the WCS specs, but I see QGIS asking:

https://geodata.nationaalgeoregister.nl/ahn3/wcs?SERVICE=WCS=1.0.0=GetCoverage=GEOTIFF_FLOAT32=ahn3_5m_dtm=1,25,356250,618750=EPSG:28992_CRS=EPSG:28992=10=10

which is the whole of the Netherlands (in a 10x10 pixel output??) and
after that a more proper bbox.

Is this supposed to go like this?
I reckon that (if the WCS data does not have overviews), loading the
whole dataset all the time is pretty intensive.

Anybody more familiar with this can tell something about this?

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

Re: [QGIS-Developer] QGIS WCS is requesting FULL dataset?

[Jonathan Moules]

Hi Richard,

I don't know about the QGIS side, but from the server side I'd agree 
with your assessment.


The WCS 1.0 spec says that the server will use the interpolation method 
specified in the getcapabilities (or if none is defined (as here), then 
assume Nearest Neighbour) for alternative widths/heights.


Having to interpolate an entire country down to a 10x10 grid seems 
utterly bonkers for a WCS. Even WMS (where you will have overviews so 
it'll be massively faster) I can't think of why you'd want a tiny 10x10 
output.


Maybe this is QGIS's way of trying to creating a WCS legend icon?

Whatever the reason, I'd suggest raising it as a bug report as it's not 
going to be doing any favours to the WCS servers for no real benefit.


Cheers,

Jonathan


On 2018-10-12 11:48, Richard Duivenvoorde wrote:

Hi,

using our national DEM WCS:

https://geodata.nationaalgeoregister.nl/ahn3/wcs?

Loading the layer ahn3_5m_dtm for an area of a couple of km in
epsg:28992 is very slow.

I'm not so familiar with the WCS specs, but I see QGIS asking:

https://geodata.nationaalgeoregister.nl/ahn3/wcs?SERVICE=WCS=1.0.0=GetCoverage=GEOTIFF_FLOAT32=ahn3_5m_dtm=1,25,356250,618750=EPSG:28992_CRS=EPSG:28992=10=10

which is the whole of the Netherlands (in a 10x10 pixel output??) and
after that a more proper bbox.

Is this supposed to go like this?
I reckon that (if the WCS data does not have overviews), loading the
whole dataset all the time is pretty intensive.

Anybody more familiar with this can tell something about this?

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

Re: [QGIS-Developer] What to do about WFS test failures?

[Jonathan Moules]

I'd suggest based on Tom's post that the work should include some sort 
of reliable way of testing the WFS client (and of course full test 
coverage) - I don't know if GeoServer is Docker-happy these days, but 
the default install in a VM should be sufficient for the task (it comes 
with test layers) - although GeoServer doesn't support WFS-T for writing.


Cheers,
Jonathan

On 03/09/2018 12:04, Régis Haubourg wrote:

Hi all,
I very much think that the WFS client is an really bad state, and is 
not really reliable, especially in WFS-T context.

The good news is that we just have been funded to refactor it !
The work should start in september and land in 3.6. I will let our 
dev's come here with more technical details about the goals. I hope we 
will also be able to take benefit of this to this the OGC compliancy 
of the client here.

Best regards,
Régis

Le lun. 3 sept. 2018 à 11:36, Tom Chadwin > a écrit :


I can't offer any helpful suggestions, but just to let you know I
finally had
to disable all my plugin WFS tests. I used to cope, by rerunning
failed
Travis runs, but by about three months ago, it seemed no longer
usable -
failure after failure.

I was using a third-party WFS, and perhaps I could have got round
this by
adding a WFS provider to the test docker image, but in this
plugin's case, I
didn't think it worth the significant effort to do so. The WM(T)S
tests also
use third-party sources and seem stable, so perhaps this wasn't the
underlying issue anyway.

If an improvement or solution could be found, it would be great to
reinstate
these tests.

Thanks

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
--
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



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

[Jonathan Moules]

Hi Nyall,

Looking at this from another angle (and being aware I know nothing of 
the QGIS code-base) - to me at least that would suggest that maybe it's 
worth improving the crash dumps so that they're better able to be used 
as a stand-alone debugging thing that doesn't require user feedback/insight.


Or alternatively make it clear during the crash dump process that the 
user needs to supply other information beyond just the file.


Cheers,

Jonathan


On 2018-08-14 01:23, Nyall Dawson wrote:

On Mon, 13 Aug 2018 at 18:11, Paolo Cavallini  wrote:

I agree, better be conservative. Furthermore, not always lack of feedback means 
an issue is not valid. I'd be against automatically closing the issues without 
further verification.

I agree in general, but there's a lot of tickets recently with just a
crash dump (with no clues in the dump) and no further info about how
to reproduce the crash or what triggered it. These reports don't have
*any* value on their own.

Nyall


I'm available to help checking, maybe creating a view of tickets needing a 
check could be useful.

All the best.


On 08/13/2018 10:06 AM, Alessandro Pasotti wrote:


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


--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
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] About QGIS-*.DMP files in Temp folder on Windows

[Jonathan Moules]

Hi,
Have you reported it to the bug tracker - https://hub.qgis.org/issues - 
That's the best way to report this sort of behaviour. While I can see 
why a dmp file would be useful, no program should be leaving GB of dump 
files behind.


Maybe it should clean up when there are more than x number?

Cheers,
Jonathan

On 09/11/2016 11:28, Geo DrinX wrote:

Good morning,


purging my PC,  I found 1595  files named "qgis-*.dmp"  in my Temp  
folder.


Totally, they amount to 36 giga of space  :(

For example, I have many of:

myUSER\AppData\Local\Temp\qgis-20140915-160805-11200-8480-c3a2817.dmp

each of 23 mega.


So, for each quitting of QGIS since 2.18  from september 05 2014  I 
had a crash (also without any plugin installed).


Also, randomically I had crashes.

So, now I am deleting these files, to have space sufficent in my PC to 
work.



I hope this can be sufficient for you to start a good debug of this 
problem, that I have reported more than once.


If you need, I can share that files with you (also if I don't know how).


Best regards

Geo



___
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] Legal advice for a client wanting to use QGIS API

[Jonathan Moules]

Hi Tim,
You may be better off asking the OSI - https://opensource.org/ - I'd guess this 
is the sort of thing they can help with, or at least point you in the right 
direction.
Cheers,
Jonathan


 On Thu, 04 Aug 2016 10:15:16 +0100 Tim Suttont...@kartoza.com 
wrote  

Hi

Apologies if this is a side topic from actual development


I have a potential client who wants to use QGIS API in their app. They live in 
a complicated bureaucratic  world and need to get legal advice to ensure they 
are properly GPL v2 or greater compliant. Does anyone know of a good lawyer who 
deals with this stuff? Preferably someone you have used before that you can 
vouch for? And no simply reading the license is not enough for them they need 
to have legal review.


Thanks!


Regards


Tim
 —











Tim Sutton


Co-founder: Kartoza
Project chair: QGIS.org


Visit http://kartoza.com to find out about open source:


Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services


Skype: timlinux 
IRC: timlinux on #qgis at freenode.net


Kartoza is a merger between Linfiniti and Afrispatial
 
 



___
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] Release naming and path problems

[Jonathan Moules]

 The second version of the installer now uses the version number in the 
path.

I'd suggest paths using version numbers is a better idea anyway and should be 
the default.
As well as avoiding these sorts of problems, they're also more understandable 
to users - is "Essen" newer of older than "Brighton"? What version was "Lyon"? 
I honestly have no idea the answers to any of those questions, but scattered 
around my machines I have versions of all of those. Version numbers are easy to 
compare though.

Cheers,
Jonathan

___
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] [Qgis-user] Better tags for plugins

[Jonathan Moules]

Hi Paulo,
Surely this can be enforced by having requirements for acceptance on the 
official plugin repository. If a plugin doesn't fulfil all the requirements, it 
doesn't get included.

Possible requirements (to give an idea):
- Brief description of plugin,
- Detailed explanation of plugin.
- How to use documentation.
- Useful, consistent tags.
- Homepage/tracker/repository links (that work and go somewhere relevant).
- Author
- Changelog
- Date of last plugin release
- Supported QGIS Versions

This may (will) mean fewer plugins, however the plugins that don't get included 
would be ones with poor user documentation. Most plugins fail quite badly at 
making it clear what they do, let alone how to use them. That lot wouldn't take 
much more than half an hour to do for any given plugin (with only a few 
very-complex exceptions) and would make plugins much more useable.

Cheers,
Jonathan


-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini
Sent: Friday, February 20, 2015 1:12 PM
To: Lynton Cox
Cc: qgis-user; qgis-developer
Subject: Re: [Qgis-developer] [Qgis-user] Better tags for plugins

Hi Lynton,

Il 19/02/2015 19:21, Lynton Cox ha scritto:
 Please don't forget the newbies need to know exactly what plugins
 might be used for - some have hardly any description. Once out of the
 basic QGIS manual finding one's way around isnt that easy. Many
 amateurs in areas such as local studies realise how useful GIS but see
 that jargon and acronyms can fog the path.

Yes, the About is often neglected. I invite plugin authors to add a reasonable 
description, but I cannot enforce this.
A very good idea would be for the user to write a short note and add it to a 
feature request, through the plugin bugtracker; even better, this could be 
added as a Pull Request on the plugin repository.
All the best, and thanks.

--
Paolo Cavallini - www.faunalia.eu
QGIS  PostGIS courses: http://www.faunalia.eu/training.html
*New course* QGIS for naturalists:
http://www.faunalia.eu/en/nat_course.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


This message has been scanned for viruses by MailControl - www.mailcontrol.com



Click 
https://www.mailcontrol.com/sr/SVGcvJSn6gnGX2PQPOmvUizKrmxxhcEGGlzw3ci4oH!oYUmIc3YrHGSGHzny8KZlOXtgio1tB25zr!jqbv!p6A==
 to report this email as spam.



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

[Qgis-developer] Proposed questions for QGIS Certification questionnaire

[Jonathan Moules]

Hi Tim (and all),
Per the IRC meeting, I've come up with a possible questionnaire that we can 
spam. Currently it's all text, but it can be converted easily enough. What 
platform should we stick it on for the question/answers? I can do a free 
surveymonkey unless someone has something better to suggest.

Suggestions as to questions/answers welcome from all. It is a first draft.

Cheers,
Jonathan


===


The QGIS development community is interested in creating a set of QGIS 
Certifications. We're interested in feedback from the entire community as to 
what you'd like/use.

The following is a set of prospective certificates; open to change.
QGIS User - Can operate QGIS to a functional level.
QGIS Professional - An expert user.
QGIS Developer - (Core or Plugins?)
QGIS Trainer - Can train for and test for certifications.


Questions:

As a GIS professional, would you be interested in getting a QGIS Certification?
[Yes / No]


If No, why not?
[Open question]


As a GIS Employer, would you be more interested in candidates who have a QGIS 
Certification?
[Yes / No / Not an Employer]


If No, why not?
[Open question]


Rank these in the order you think they're important in a QGIS Certification?
[Rank]
Knowledge of GIS Concepts
Familiarity with QGIS
Time using QGIS
Exposure to different areas of QGIS
Community participation
Other [Open answer]


Which of these would interest you:
[Choices for each: Not at all, Mildly, Definitely]
QGIS User - Can operate QGIS to a functional level.
QGIS Professional - An expert user.
QGIS Developer - (Core or Plugins?)
QGIS Trainer - Can train for and test for certifications.


Do you agree/disagree with the proposed certificates? If you disagree, what 
certificates would you suggest?
[Open question]


What do you think would be a good way of measuring suitability for a 
certificate:
[Rank]
Community participation track record
Exam
Portfolio of work
Professional experience
Academic qualifications


Any comments or feedback?
[Open question]



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] Proposed questions for QGIS Certification questionnaire

[Jonathan Moules]

Hi Trevor,
Good suggestion and something I’d thought of myself (though yours 
has more detail). However to simplify this version I decided to skip that. 
Further, if it does get published via a free SurveyMonkey, I think you only get 
10 questions, so will have to think carefully about exactly which ones to use.

Cheers,
Jonathan

From: Trevor Wiens [mailto:tsw@gmail.com]
Sent: Tuesday, February 17, 2015 6:09 PM
To: Jonathan Moules
Cc: Tim Sutton; QGIS Developer Mailing List
Subject: Re: [Qgis-developer] Proposed questions for QGIS Certification 
questionnaire

Jonathan.
This looks good. I do have one suggestion. For the second last question of 
What do you think would be a good way of measuring suitability for a 
certificate, I think it is more complex. For example, for a developer 
certification, I would assume most people would think that community 
participation would be important. However for the other certifications, exams 
might be more suitable. I can even see cases for trainers where we might want 
to institute a train the trainer type of course that would be mandatory (even 
if an online course) to ensure that people who want to be trainers can benefit 
from the knowledge and experience of experienced teachers / trainers.

Because of this complexity you might want to separate this out into questions 
like:
For a QGIS User certification, what do you think would be a good way of 
measuring suitability for a certificate...
For a QGIS Professional certification, what do you think would be a good way of 
measuring suitability for a certificate...
For a QGIS Developer certification, what do you think would be a good way of 
measuring suitability for a certificate...
For a QGIS Trainer certification, what do you think would be a good way of 
measuring suitability for a certificate...

TSW

On Tue, Feb 17, 2015 at 10:20 AM, Jonathan Moules 
j.mou...@hrwallingford.commailto:j.mou...@hrwallingford.com wrote:
Hi Tim (and all),
Per the IRC meeting, I've come up with a possible questionnaire that we can 
spam. Currently it's all text, but it can be converted easily enough. What 
platform should we stick it on for the question/answers? I can do a free 
surveymonkey unless someone has something better to suggest.

Suggestions as to questions/answers welcome from all. It is a first draft.

Cheers,
Jonathan


===


The QGIS development community is interested in creating a set of QGIS 
Certifications. We're interested in feedback from the entire community as to 
what you'd like/use.

The following is a set of prospective certificates; open to change.
QGIS User - Can operate QGIS to a functional level.
QGIS Professional - An expert user.
QGIS Developer - (Core or Plugins?)
QGIS Trainer - Can train for and test for certifications.


Questions:

As a GIS professional, would you be interested in getting a QGIS Certification?
[Yes / No]


If No, why not?
[Open question]


As a GIS Employer, would you be more interested in candidates who have a QGIS 
Certification?
[Yes / No / Not an Employer]


If No, why not?
[Open question]


Rank these in the order you think they're important in a QGIS Certification?
[Rank]
Knowledge of GIS Concepts
Familiarity with QGIS
Time using QGIS
Exposure to different areas of QGIS
Community participation
Other [Open answer]


Which of these would interest you:
[Choices for each: Not at all, Mildly, Definitely]
QGIS User - Can operate QGIS to a functional level.
QGIS Professional - An expert user.
QGIS Developer - (Core or Plugins?)
QGIS Trainer - Can train for and test for certifications.


Do you agree/disagree with the proposed certificates? If you disagree, what 
certificates would you suggest?
[Open question]


What do you think would be a good way of measuring suitability for a 
certificate:
[Rank]
Community participation track record
Exam
Portfolio of work
Professional experience
Academic qualifications


Any comments or feedback?
[Open question]



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.orgmailto:Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo

Re: [Qgis-developer] [Qgis-psc] QGIS Certification IRC meeting, Thrus 12 Feb, 2015

[Jonathan Moules]

Hi Trevor,
We never really discussed that during the meeting, though it’s a good question. 
The meeting more went in an “assigning tasks” kind of direction, touching a few 
questions here and there. I think one of the potential tasks was going to be 
about covering that sort of question. It’s also something I’ll try and work 
into the questionnaire I’m formulating.

Cheers,
Jonathan

From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Trevor Wiens
Sent: Thursday, February 12, 2015 11:53 PM
To: Robert Szczepanek
Cc: qgis-community; qgis-developer; qgis-...@lists.osgeo.org
Subject: Re: [Qgis-developer] [Qgis-psc] QGIS Certification IRC meeting, Thrus 
12 Feb, 2015


Thanks for the link. I would have liked to be involved but couldn't be there 
today.

I know this was discussed briefly before but I'm still unsure of the answer. Is 
the main push to test tool competency or is underlying knowledge of spatial 
problems and processes part of the purpose?  I have materials from my GIS intro 
course I teach for the University of Calgary that is more focused on 
understanding that uses QGIS. I am willing to share these but the how to 
sections are older and would need to be updated (I teach this course every 18 
months).

I realize that this will be QGIS focused and to provide something similar to 
commercial certification the focus needs to mostly focus on tool specific 
competency. I would however suggest that having a solid coverage of basic GIS 
knowledge would be a step up over commercial certification programs where it is 
not uncommon to see people with credentials on paper who understand very little.

If someone can fill me in where we are at that level of specifics I would 
appreciate it.

TSW
On Feb 12, 2015 10:14 AM, Robert Szczepanek 
rob...@szczepanek.plmailto:rob...@szczepanek.pl wrote:
Log from IRC meeting is available at:
http://hub.qgis.org/wiki/quantum-gis/Certification

regards,
Robert

W dniu 06.02.2015 o 16:34, Tim Sutton pisze:
Hi All

We will be holding a meeting on IRC to discuss QGIS training and
certification on Thursday 12 Feb 2015 and 14h00 GMT in the channel
#qgis-certification.

If you have ideas about a certification programme for QGIS, please come
along and join us, or submit your ideas but email for discussion in the
meeting!

Regards

Tim

--
--
Tim Sutton
Visit http://kartoza.com http://kartoza.com/ to find out about open
source:
  * Desktop GIS programming services
  * Geospatial web development
* GIS Training
* Consulting Services
Skype: timlinux Irc: timlinux on #qgis at freenode.nethttp://freenode.net
http://freenode.net/
Tim is a member of the QGIS Project Steering Committee
---
Kartoza is a merger between Linfiniti and Afrispatial


___
Qgis-psc mailing list
qgis-...@lists.osgeo.orgmailto:qgis-...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-psc
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.orgmailto:Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


This message has been scanned for viruses by 
MailControlhttp://www.mailcontrol.com/, a service from BlackSpider Technology

Click 
herehttps://www.mailcontrol.com/sr/ZUSX5EQEwCLGX2PQPOmvUkyXKmclf+CPKBPokuppE9L5FIzdy1s33fuzyofpwq55pfmunE2R0s4eq4Nrivo6iw==
 to report this email as spam.





HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] [Qgis-psc] QGIS Certification IRC meeting, Thrus 12 Feb, 2015

[Jonathan Moules]

You can get to it via:
http://webchat.freenode.net/?channels=#qgis-certification



-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Robert Szczepanek
Sent: Thursday, February 12, 2015 2:08 PM
To: Tim Sutton; qgis-...@lists.osgeo.org; QGIS Developer Mailing List; 
qgis-community
Subject: Re: [Qgis-developer] [Qgis-psc] QGIS Certification IRC meeting, Thrus 
12 Feb, 2015

Hi,

Is this channel public?
Can't find it ...

regards,
Robert

W dniu 06.02.2015 o 16:34, Tim Sutton pisze:
 Hi All

 We will be holding a meeting on IRC to discuss QGIS training and
 certification on Thursday 12 Feb 2015 and 14h00 GMT in the channel
 #qgis-certification.

 If you have ideas about a certification programme for QGIS, please
 come along and join us, or submit your ideas but email for discussion
 in the meeting!

 Regards

 Tim

 --
 --
 
 Tim Sutton
 Visit http://kartoza.com http://kartoza.com/ to find out about open
 source:
   * Desktop GIS programming services
   * Geospatial web development
 * GIS Training
 * Consulting Services
 Skype: timlinux Irc: timlinux on #qgis at freenode.net
 http://freenode.net/ Tim is a member of the QGIS Project Steering
 Committee
 --
 - Kartoza is a merger between Linfiniti and
 Afrispatial


 ___
 Qgis-psc mailing list
 qgis-...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-psc

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


This message has been scanned for viruses by MailControl - www.mailcontrol.com



Click 
https://www.mailcontrol.com/sr/xOB12O50SJPGX2PQPOmvUkHxlm0SZLPCY30nK+u2CpUZXx64D5lly6aj+FGy0WGypfmunE2R0s4eRLY+cWrx9g==
 to report this email as spam.



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] Layer properties dialogue: OK/Cancel not active anymore?

[Jonathan Moules]

I wonder, might it be worth adding a test for it as well? Now that QGIS has 
unit tests, the more the merrier?


-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Richard 
Duivenvoorde
Sent: Wednesday, January 07, 2015 5:15 PM
To: Denis Rouzaud; Andreas Neumann
Cc: qgis-developer
Subject: Re: [Qgis-developer] Layer properties dialogue: OK/Cancel not active 
anymore?


Yep, already created an issue for it:

http://hub.qgis.org/issues/11960

Regards,

Richard Duivenvoorde

On 07-01-15 17:14, Denis Rouzaud wrote:
 I do,  at least on Ubuntu

 Le 7 janv. 2015 17:14, Andreas Neumann a.neum...@carto.net
 mailto:a.neum...@carto.net a écrit :

 Hi,

 With a recent master build it seems like the OK/Cancel buttons of
 the layer properties dialogue do not properly react anymore - they
 don't close the dialogue.

 Can others confirm?

 Thanks,
 Andreas
 _
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org mailto:Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/__mailman/listinfo/qgis-__developer
 http://lists.osgeo.org/mailman/listinfo/qgis-developer



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


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


This message has been scanned for viruses by MailControl - www.mailcontrol.com



Click 
https://www.mailcontrol.com/sr/HZnKeTYvbPHGX2PQPOmvUoRq5N+0kMbNruWYuNTUKIWNcXDNzadNzxWmHqwom9YeYp+2JwU2ZCwhei1KLnaPDA==
 to report this email as spam.



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] Huge TIFF files - problem

[Jonathan Moules]

Hi Lene,
What’s the GDALINFO for the 122GB image? That will confirm (or debunk) some of 
the theories posted here as to the cause. Figured it’s worth asking just in 
case there’s another cause too.

Cheers,
Jonathan


From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Lene Fischer
Sent: Tuesday, December 09, 2014 9:56 AM
To: Alexandre Neto; t...@wildintellect.com
Cc: qgis-dev; Giovanni Manghi
Subject: Re: [Qgis-developer] Huge TIFF files - problem

I think this is a good idea.
It gives problems when I end up with data files on 122 GB. I know how to 
change, but not basic users.
Regards


Lene Fischer
Lektor

Skovskolen
Københavns Universitet

DIR 40115084
l...@ign.ku.dkmailto:l...@ign.ku.dk


[SCIENCE_bomaerke]


Fra: 
qgis-developer-boun...@lists.osgeo.orgmailto:qgis-developer-boun...@lists.osgeo.org
 [mailto:qgis-developer-boun...@lists.osgeo.org] På vegne af Alexandre Neto
Sendt: 9. december 2014 10:12
Til: t...@wildintellect.commailto:t...@wildintellect.com
Cc: qgis-dev; Giovanni Manghi
Emne: Re: [Qgis-developer] Huge TIFF files - problem


Em 09/12/2014 07:43, Alex Mandel 
tech_...@wildintellect.commailto:tech_...@wildintellect.com escreveu:
 ... Seems to me a
 reasonable default to use one of the lossless compression methods. Not
 much to be done about the storage type though other than offer users

Could / should we make it default in gdal tools then? IMHO, a standard user 
should not have to worry about that.

Best regards,
Alexandre Neto


This message has been scanned for viruses by 
MailControlhttp://www.mailcontrol.com/, a service from BlackSpider Technology

Click 
herehttps://www.mailcontrol.com/sr/vl7MADbPXAvGX2PQPOmvUoRq5N+0kMbNpBLGRwvwJz4CR0U4bUTFeO2fvKRWDWKvYNcelilqCBKTKOxjbsImtQ==
 to report this email as spam.





HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

[Qgis-developer] 2.6.1 - fix for crash release?

[Jonathan Moules]

Hi,
I was wondering if there's been any progress with creating a 2.6.1 release to 
fix the crash-and-data-destroying bug (http://hub.qgis.org/issues/11592)?
There have been a couple threads requesting it 
(http://lists.osgeo.org/pipermail/qgis-developer/2014-November/035516.html - 
http://lists.osgeo.org/pipermail/qgis-developer/2014-November/035629.html) - 
but I've not seen anything indicating this has happened.

If one isn't forthcoming then I'd suggest that the responsible thing to do is 
put a nice big scary warning up on the download page telling users there's a 
known issue that may destroy their work if the project trigger's specific 
conditions.

Cheers,
Jonathan



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] QGIS 2.6.0 georeferencer fails in windows

[Jonathan Moules]

Hi Roy,
I just did a quick one and it worked; Windows using the stand alone installed 
version, 64bit I think.

Which transformation are you using? I tested polynomial 1.

That said, if it's repeatable, it's probably worth reporting as a bug anyway; 
including the sample data and detailed info.

Cheers,
Jonathan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Roy
Sent: Friday, November 14, 2014 9:35 AM
To: QGIS Developer Mailing List
Subject: [Qgis-developer] QGIS 2.6.0 georeferencer fails in windows

Dear list,

i'm georeferencing some rasters and the georeferencing process fails (in 
winodows osgeo4w 32bit) with this message:

  failed to compute GCP transform: Transform is not solvable

the georeferencing process works in linux using the very same data (raster and 
GCP list) is it only my system or should i open a bug report ?

thanks,

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


This message has been scanned for viruses by MailControl - www.mailcontrol.com



Click 
https://www.mailcontrol.com/sr/!U2xHBz6!6PGX2PQPOmvUgfUspOYWKRbcUkhPk2aSypSSjzNKybY9IsDGAD0hjxQxXDcnlWWD4mTKOxjbsImtQ==
 to report this email as spam.



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] 2.6.1 Windows patch?

[Jonathan Moules]

Hi Bernhard,
  I believe it's this conversation: 
http://lists.osgeo.org/pipermail/qgis-developer/2014-November/035492.html - and 
this ticket: http://hub.qgis.org/issues/11592


---

I think this is a good test of the maturity of the QGIS project; a release has 
been made which has a significant regression that means opening historical 
projects not only crashes QGIS in some instances (very bad), but can also 
*overwrite* and thus corrupt the project file resulting in data loss for the 
end user. If that doesn't warrant a timely emergency hotfix I don't know what 
does.
As it stands I'd be surprised if there isn't ongoing data-loss from 
early-adopters. :-(

Cheers,
Jonathan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Bernhard Ströbl
Sent: Wednesday, November 12, 2014 11:17 AM
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] 2.6.1 Windows patch?

Hi Nathan,

which ticket are you refering to?
I was about to roll out QGIS 2.6 for Windows (both 32 and 64 bit).

thanks

Bernhard

Am 12.11.2014 12:00, schrieb Nathan Woodrow:
 Hey,

 Mainly for Jurgen.  Is there any possibility of getting a patched
 2.6.1 into the Windows installers and binaries. The bug that Martin
 fixed just after release that corrupted project files is a pretty
 nasty one that I think could do with a patched 2.6.1 if we can.

 Pretty please...

 Regards,
 Nathan


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




__ Information from ESET Mail Security, version of virus signature 
database 10711 (20141112) __

The message was checked by ESET Mail Security.
http://www.eset.com


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


This message has been scanned for viruses by MailControl - www.mailcontrol.com



Click 
https://www.mailcontrol.com/sr/u2otVfl3jp7GX2PQPOmvUizKrmxxhcEG6k4vv+L2k850nqTLme8L4cgt!bBGUvwPDZBLv8O0BTT1VsBVsOva5A==
 to report this email as spam.



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] FW: Support | Custom install for XenApp | Removing menu options

[Jonathan Moules]

Hi Steven,
Just a notion, and this is more of a “last ditch attempt” than anything else, 
but I’m reasonably sure that the pyramids are created using GDAL’s gdaladdo.

So one possible option is to remove/rename gdaladdo.exe. In theory this would 
disable the functionality.

I can’t test it myself because local admin privs stop me. But it might be worth 
a try if you’re feeling bold. Not sure if it’ll affect anything else; gdaladdo 
only seems to do pyramids, so might be ok.

Cheers,
Jonathan

From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Steven Campbell
Sent: Tuesday, November 11, 2014 2:45 PM
To: 'qgis-developer@lists.osgeo.org'
Subject: [Qgis-developer] FW: Support | Custom install for XenApp | Removing 
menu options

Hi,

I’ve been trying to remove some functions from QGIS so we can deploy a stripped 
down version of it into a Citrix - XenApp 6.5 environment.

I’ve posted on the QGIS 
forumhttp://gis.stackexchange.com/questions/120199/qgis-deployment-in-citrix-xenapp-how-to-remove-pyramids-from-the-image-proper
 to see if anyone could help me with this set-up.

I need to remove the ability to build pyramids on QGIS when it is installed in 
XenApp (GIS team will use PC’s to do rendering\pyramids overviews etc).  I can 
use the customization tool built in QGIS to remove the Menu options, however I 
need to remove the ‘Properties’ (or just the Pyramids) option from the context 
menu when you right click on an Image.

Here is an image of what I am trying to remove:

[cid:image001.png@01CFFDD8.79EC3440] 
[cid:image002.jpg@01CFFDD8.79EC3440]

I need to prevent this option from being used on our XenApp environment due to 
the amount of memory it grabs.  If a user runs this on a highly loaded server 
it could cause outage for the other users on that server, if possible I’d like 
to configure GIS to avoid the option being used by mistake.

If it is not possible, that is fine.  This is my last point of call for 
support, any help would be much appreciated.

Thanks in advance.

Steve

DISCLAIMER: This email and any files transmitted with it may be confidential, 
legally privileged and protected in law and are intended solely for the use of 
the individual to whom it is addressed. The copyright in all documentation is 
the property of the Borough of Poole and this email and any documentation must 
not be copied or used other than as strictly necessary for the purpose of this 
email, without prior written consent which may be subject to conditions. Any 
view or opinions presented are solely those of the author and do not 
necessarily represent those of the Borough of Poole. The Borough of Poole 
reserves the right to inspect incoming and outgoing emails. If you have 
received this email in error please contact the sender by return and confirm 
that its contents have been destroyed. Telephone enquiries should be directed 
to the Borough switchboard on 01202 633633.'

This message has been scanned for viruses by 
MailControlhttp://www.mailcontrol.com/, a service from BlackSpider Technology

Click 
herehttps://www.mailcontrol.com/sr/59afDHgHmtHGX2PQPOmvUvmldA89nuwl+uVwa3cC2WMYqA+tYINQQcgt!bBGUvwP+pKcdHXFkgmOdoKZwoXR0w==
 to report this email as spam.





HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] Stability (2.8 LTS) vs development (3.0), a proposed way forward

[Jonathan Moules]

A couple of thoughts from a non-dev looking inwards:

 Sorry I do not agree here: we had many cases of fixes breaking other stuff
Would not something like Unit Tests help ameliorate that? That's what they're 
designed for isn't it? I realise the state of QGIS' unit test infrastructure 
isn't optimal currently, but I thought I saw a project to fix get funding 
recently.

 : what is blocking for an user is not relevant for another. I have customers 
 and friends that cannot upgrade to various versions for very specific bugs.

Then why not fix the bugs and require them to be backported? I know that seems 
flippant, but is there a reason that backporting by the submitter/committer 
can't be required for any bugfix submitted? If a bugfix breaks other stuff, 
then either the bugfix should be regressed or the breakage fixed with another 
fix.

Neither of these suggestions would require any outlay from the QGIS core fund, 
though they may increase the cost of any individual feature/bugfix. I believe 
GeoServer does both of these and has a healthy 30-day release schedule 
consisting of up to 3 branches despite having considerably fewer resources than 
QGIS.

Just my 2p.
Cheers,
Jonathan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini
Sent: Monday, November 10, 2014 9:59 AM
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Stability (2.8 LTS) vs development (3.0), a 
proposed way forward

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 10/11/2014 10:56, Nathan Woodrow ha scritto:

 IMO we don't need resources to do bug fixing.  The dev that does the
 bug fix in master can do it in the 2.x branch for that stable release
 if

Sorry I do not agree here: we had many cases of fixes breaking other stuff, so 
backporting should be done with great care, and lots of extra work; that's why 
I believe that without significant resources we are not going to solve the 
problem satisfactorily.

All the best.
- --
Paolo Cavallini - www.faunalia.eu
QGIS  PostGIS courses: http://www.faunalia.eu/training.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRgjH0ACgkQ/NedwLUzIr72yQCdHYe2bCc19H3eyfsammiMur1P
KtEAnik3lf96t2D1daJ4ZaiST8Rw5Qtd
=0gqs
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


This message has been scanned for viruses by MailControl - www.mailcontrol.com



Click 
https://www.mailcontrol.com/sr/IIyLovGDSdTGX2PQPOmvUizKrmxxhcEGFn0HB2PmJETu!FF59CPCcZfM1iyAeuy4hu5YqLyvUFQhei1KLnaPDA==
 to report this email as spam.



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] Behaviour when create new features

[Jonathan Moules]

Personally I’d think there are two bugs here, at least from a user-interface 
perspective, even if they’re not from a technical one:


a) Edits showing when editing was disabled (I’ve seen this one myself).


b)No warning that the edited features hadn’t been “finished” when saving 
and/or when disabling editing.

(2.6 Testing indicates that disabling and then re-enabling editing while 
editing but not “finishing” a feature shows that you continue editing the same 
feature; I’m not sure that’s very intuitive, hence item (b).)

Cheers,
Jonathan

From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Casper Børgesen 
(CABO)
Sent: Monday, November 10, 2014 9:09 AM
To: qgis-developer
Subject: [Qgis-developer] Behaviour when create new features

I have an inexperienced QGIS user who needed to draw some simple line strings. 
She created a new shapefile layer (line type), enabled editing and used the 
“Add Feature” button to draw a line string.


-  She didn’t right click to finished the feature when she was done!

She saved the alterations (none because she didn’t finish the feature creation 
process) and disabled editing. Upon opening the layer in another QGIS instance, 
the feature she created was missing – obvious since she didn’t entirely created 
it.

Why did she though that she had created it?

Because even though she drew the line string (without saving it) and disabled 
the editing, the left over line string remains visible on the screen. You 
cannot click it, get feature info and so on, but it appears to be exactly where 
she created it.

I don’t know if this is created as an issue but is this the expected behavior 
when creating and aborting new features?

This applies to QGIS 2.4 and 2.6.


Kind regards, Casper


This message has been scanned for viruses by 
MailControlhttp://www.mailcontrol.com/, a service from BlackSpider Technology

Click 
herehttps://www.mailcontrol.com/sr/6TqvtsvWU1!GX2PQPOmvUqy!8K4P2+30kzTs6GKpZSmWH+w0+RKE!5fM1iyAeuy4hu5YqLyvUFQhei1KLnaPDA==
 to report this email as spam.





HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] Save selection as

[Jonathan Moules]

Hi,
Irrespective of which is the way to do it (I lean toward checking it when 
there's a selection), I'd suggest that the behaviour should be consistent. So 
either this default be changed, or the field calculator one be, otherwise you 
end up with confused users.

Cheers,
Jonathan


-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Jürgen E. Fischer
Sent: Saturday, November 08, 2014 11:41 AM
To: qgis-developer@lists.osgeo.org; qgis...@lists.osgeo.org
Subject: Re: [Qgis-developer] Save selection as

Hi Anita,

On Sat, 08. Nov 2014 at 12:32:52 +0100, Anita Graser wrote:
 On Sat, Nov 8, 2014 at 11:53 AM, Paolo Cavallini cavall...@faunalia.it 
 wrote:
  Il 08/11/2014 10:18, Matthias Kuhn ha scritto:
  I think this could result in unexpected outcome for the users.
  All the best.

 Seems like a UX question ;-)

 I'm with Jürgen, it's very likely to confuse users because they don't
 realize that the had a selection and then they find that features are
 missing in the export.

But I don't have a opinion on it - there's probably no save default for it.  In 
that way having the two menu entries might have been better.

Jürgen

--
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] issues in QGIS 2.6 when saving/working with projects saved in previous QGIS releases

[Jonathan Moules]

Hi,
Is there an ETA on this? We're thinking of moving up to 2.6, but I can see this 
hitting us if we do.
Thanks,
Jonathan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini
Sent: Saturday, November 08, 2014 7:37 AM
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] issues in QGIS 2.6 when saving/working with 
projects saved in previous QGIS releases

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 08/11/2014 01:32, Mathieu Pellerin ha scritto:
 IMO, this is serious enough to package a 2.6.1 release speedily.
 There are enough ppl out there that don't backup their documents on a
 regular basis for this bug to be hugely problematic.

seems reasonable to me
all the best

- --
Paolo Cavallini - www.faunalia.eu
QGIS  PostGIS courses: http://www.faunalia.eu/training.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRdyDcACgkQ/NedwLUzIr7TbQCgg8MNiVXmwrXkFXvPnL1bh7kM
OnAAni654JHAkWQqdNBCcAw1HXw7yo8H
=YjGY
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


This message has been scanned for viruses by MailControl - www.mailcontrol.com



Click 
https://www.mailcontrol.com/sr/E6m3fMEKmGjGX2PQPOmvUkHxlm0SZLPCJKgYTJXEtXtEcF1xMGmboSw3pDhQYZTTb6gPET3dChj1VsBVsOva5A==
 to report this email as spam.



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] 2.2 - 2.6 oracle table SRID not identified

[Jonathan Moules]

Hi Sylvain,
I’m not seeing this. For me at least, using 2.2, 2.4, and 2.6, all exhibit the 
same behaviour with showing SRID’s for layers that have geometry. All are 
correctly showing the SRID as 8607 (Oracle’s version of WGS84).

Maybe it’s your connection options?

Cheers,
Jonathan


From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of PIERRE Sylvain
Sent: Monday, November 03, 2014 12:55 PM
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] 2.2 - 2.6 oracle table SRID not identified


Hi,

There’s difference between 2.2 and 2.6 release when scanning an Oracle database:
With 2.2 table’s SRID are well identified, not with 2.6 and DB is the same.

What should be the reason of these different behaviour? (and the solution ;-)?

Thanks

Sylvain Pierre


This message has been scanned for viruses by 
MailControlhttp://www.mailcontrol.com/, a service from BlackSpider Technology

Click 
herehttps://www.mailcontrol.com/sr/9HQv42idpQHGX2PQPOmvUizKrmxxhcEG3GTnIjV23qqAqtQF7!FWUw1p4Vj8kvahaMndD5wzWU8YNBM7q0TQEQ==
 to report this email as spam.





HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] Please stop spamming commit logs!

[Jonathan Moules]

Hi Larry,
At the risk of being a dissenting voice, is this really the message QGIS wants 
to spread? That sponsorship is king? As an Open Source GIS project, I would 
hope that its prowess lay in producing exceptional GI software rather than 
finding sponsorship. The later is a means to an end.

Also, what qualifies as “funded by”? There was a monetary transaction? In which 
case what about the people who donate code they created in their own time and 
have received no fiscal incentive at all – should not their contributions be 
similarly highlighted?

Cheers,
Jonathan


From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Larry Shaffer
Sent: Saturday, October 11, 2014 12:58 AM
To: Alessandro Pasotti
Cc: QGIS Developer Mailing List
Subject: Re: [Qgis-developer] Please stop spamming commit logs!

Hi Alessandro,

On Fri, Oct 10, 2014 at 6:57 AM, Alessandro Pasotti 
apaso...@gmail.commailto:apaso...@gmail.com wrote:
2014-10-10 14:44 GMT+02:00 Jürgen E. j...@norbit.demailto:j...@norbit.de:
 Hi Matthias,

 On Fri, 10. Oct 2014 at 11:53:28 +0200, Matthias Kuhn wrote:
 To make an example, this is a good commit message.

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

 It states
  * which problem it solves
  * and what it does exactly

 And I could not care less about an additional line at the bottom stating
 Funded by John Wayne

 Almost.  It should have Fixes #8166 in it to automatically link to the issue
 and close it - Bugfix #8166 doesn't create that link.


Good hints. If it's not already in CODING, we could add these
guidelines in that file.

Also, since most of you don't seem to be annoyed by the funded by
sentences, I  think we can agree on Victor's proposal: if the new
feature/bug fix etc. was funded by an organization, a company or an
individual, a single line (80 chars max) sentence can be added as the
last line of the commit, after a blank line.

That line should be added only in the last merge (final) commit and
not on all and every individual commit.

I disagree. Funded by attribution lines should go wherever the author feels 
is appropriate, regardless of whether the commit is a merge type, pulling in a 
whole branch, or the commits are simply rebased on top of master.

It is a matter of public record:
* QGIS is a public project
* The funding is for a public project.
* The funding is a matter of public record (unless otherwise deemed by sponsor).
* The commit log is a public record (and the longest standing one for the 
project).
I fail to see how any of that can be misconstrued as spam, if the line in a 
commit is merely an attribution, i.e. not part of the first line of the commit.
Even if *every* single commit message in the QGIS repo had a Funded by 
attribution line, I could not see how that is anything but a matter of fact. 
Actually, I think that would be an awesome record of the project's prowess of 
finding sponsorship.
Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota


--
Alessandro Pasotti
w3:   www.itopen.ithttp://www.itopen.it
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.orgmailto:Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer



This message has been scanned for viruses by 
MailControlhttp://www.mailcontrol.com/, a service from BlackSpider Technology

Click 
herehttps://www.mailcontrol.com/sr/I0txt8yKWP!GX2PQPOmvUihCLhWP7Wj9hp54mmEOLsPcfq!3p+2gK8O0TJTgqoXxCOZlUrWwm5Ieq4Nrivo6iw==
 to report this email as spam.





HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] Please stop spamming commit logs!

[Jonathan Moules]

 Every single log line has the committer's GitHub name so it isn't anonymous.

I know, but that also includes the paid-for devs; my point was that if QGIS 
wishes to highlight those paying for work with money, then highlighting those 
paying for work with time seems fair too.

Other than that, I'm +1 your entire message and don't think anything of the 
sort should be in the logs!

Cheers,
Jonathan



HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] Please stop spamming commit logs!

[Jonathan Moules]

Chiming in from the perspective of someone who was working for an occasional 
feature “sponsor” until recently (mostly GeoServer, but also one or two QGIS), 
we didn’t do it with the intent of getting our name in anything (be it commit 
log, appendix, or even h1 on the project front-page). We did it because we 
needed a feature or wanted to help the project.
If we were doing it to raise awareness of our philanthropy, the commit log is 
quite probably the absolute last place we’d have wanted it to be.


From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Lene Fischer
Sent: Friday, October 10, 2014 9:09 AM
To: Nyall Dawson; Alessandro Pasotti
Cc: QGIS Developer Mailing List
Subject: Re: [Qgis-developer] Please stop spamming commit logs!


I agree to Nyall –

We need sponsors. And sponsors don´t want to be in footnotes fontsize 6.5

Right now I´ve started to get sponsors to the next developer/usermeeting in 
Denmark. And I´m sure sponsors will not be satisfied to be put into an appendix.

I think these small textnotes in the mail are harmless

Regards

Lene Fischer
Associate Professor

Department of Geosciences and Natural Resource Management
University of Copenhagen

MOB +45 40115084
l...@ign.ku.dkmailto:l...@ign.ku.dk


[SCIENCE_bomaerke_UK]




-Oprindelig meddelelse-
Fra: 
qgis-developer-boun...@lists.osgeo.orgmailto:qgis-developer-boun...@lists.osgeo.org
 [mailto:qgis-developer-boun...@lists.osgeo.org] På vegne af Nyall Dawson
Sendt: 10. oktober 2014 09:51
Til: Alessandro Pasotti
Cc: QGIS Developer Mailing List
Emne: Re: [Qgis-developer] Please stop spamming commit logs!



On 10 October 2014 18:11, Alessandro Pasotti 
apaso...@gmail.commailto:apaso...@gmail.com wrote:

 Hi,



 I noticed that somebody started to add commercials to commit logs:



 Sponsored by 



 Funded by ...



 etc. etc.



 We should take this seriously, mostly ever developer works for a

 company or run its own business.



 Imagine if everybody starts adding those (not really useful) sentences

 to every commit.





Is this really an issue? It seems rather trivial. I personally am strongly in 
favour of these attributions in the commit log. Reasons

are:



- It gives credit to sponsors. That's important! Look at how many cool features 
were added in 2.6 thanks to sponsorship...

- It gives credit to developers who donate their free/company time.

That's also important. QGIS wouldn't exist if it wasn't for these developers 
donating their time

- The commit log is basically for developers or power users/contributors only. 
It's a fairly harmless place to advertise these sponsorship messages. For a 
while there was a few sponsored by

messages in code comments - that's a much worse/more intrusive place for these 
messages.

- It lets us blow off steam when release pressures ramp up :P see 68c49fe09, 
34f00d106 and 2427546d8



So, +1 for allowing these messages.



Nyall

___

Qgis-developer mailing list

Qgis-developer@lists.osgeo.orgmailto:Qgis-developer@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/qgis-developer


This message has been scanned for viruses by 
MailControlhttp://www.mailcontrol.com/, a service from BlackSpider Technology

Click 
herehttps://www.mailcontrol.com/sr/dlpPl07p8H3GX2PQPOmvUnWSlf6oUOY8Cn6S0JRwpIyA3vav42EuV7HMmaV05UyNCOZlUrWwm5L46EHnGWFGZQ==
 to report this email as spam.





HR Wallingford and its subsidiaries uses faxes and emails for confidential and 
legally privileged business communications. They do not of themselves create 
legal commitments. Disclosure to parties other than addressees requires our 
specific consent. We are not liable for unauthorised disclosures nor reliance 
upon them.
If you have received this message in error please advise us immediately and 
destroy all copies of it.

HR Wallingford Limited
Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
Registered in England No. 02562099


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

Re: [Qgis-developer] [Qgis-user] Centroid of polygon

[Jonathan Moules]

Hi All,
Thanks for the replies, that did it.

I've opened https://hub.qgis.org/issues/11008 per Andreas' suggestion.

Cheers,
Jonathan



On 5 August 2014 10:58, Andreas Neumann a.neum...@carto.net wrote:

 Hi,

 For me it is very strange that

 x(centroid($geometry))
 y(centroid($geometry))

 does not work in the QGIS expressions.

 There is a $x and $y - but this does only work directly on a current
 feature if it is a point feature.

 The workaround with xmin/ymin

 xmin(centroid($geometry))
 ymin(centroid($geometry))

 works, but seems cumbersome.

 Could you open a ticket please?

 Andreas

 Am 04.08.2014 17:22, schrieb Goyo:
  This works in master:
 
  xmin(centroid($geometry))
  ymin(centroid($geometry))
 
  Goyo
 
  2014-08-04 18:28 GMT+02:00 Jonathan Moules 
 jonathanmou...@warwickshire.gov.uk:
  Hi list,
  Quick question, how do you use the Field Calculator to get the centroid
 as
  an attribute? I'm aware of this question answer:
 
 http://gis.stackexchange.com/questions/11705/using-field-calculator-in-qgis-to-update-columns-with-centroid-coordinates
  - but want to do it using just the field calculator.
 
  I see under Geometry that there's a centroid function, but can't
 figure
  out how to use it for this purpose.
 
  Suggestions welcome.
  Thanks,
  Jonathan
 
  This transmission is intended for the named addressee(s) only and may
  contain confidential, sensitive or personal information and should be
  handled accordingly. Unless you are the named addressee (or authorised
 to
  receive it for the addressee) you may not copy or use it, or disclose
 it to
  anyone else. If you have received this transmission in error please
 notify
  the sender immediately. All email traffic sent to or from us, including
  without limitation all GCSX traffic, may be subject to recording and/or
  monitoring in accordance with relevant legislation.
  ___
  Qgis-user mailing list
  qgis-u...@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-user
  ___
  Qgis-user mailing list
  qgis-u...@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-user
 

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


-- 
This transmission is intended for the named addressee(s) only and may 
contain confidential, sensitive or personal information and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify 
the sender immediately. All email traffic sent to or from us, including 
without limitation all GCSX traffic, may be subject to recording and/or 
monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] Stress about release plans

[Jonathan Moules]

Hi Otto,
You make some excellent points. Just to follow on one of them:

But usually customers and developers don't think about also spending
an additional
 little amount to document the feature in the QGIS docs and training
 material.


I think that's a QGIS problem. I know when I get quotes for GeoServer
stuff, or for our JavaScript library we use, the quote includes time spent
updating the documentation.

The solution is very simple: Require up to date, accurate documentation for
all commits of new features. This is one for the PSC.
After all, what's the point in having tons of features if no-one knows how
to use them or what they do?
Will it slow down new feature feature commit? Probably, but I figure that's
a small price to pay for actually having documentation. And from that
documentation, universal training materials can be developed much more
easily.

Cheers,
Jonathan

On 22 July 2014 10:10, Otto Dassau das...@gbd-consult.de wrote:

 Hi,

 I would prefere another solution instead of changing the releases. The
 documentation team is in the same situation. We are always behind the
 releases, but the problem I see is that there are not enough people working
 on the documents. At the moment we were not even able to start updating the
 manual for 2.4 yet :(.

 From my experience, we get many new features for every release because
 developers work together on the master source.

 For some reason trainers prefere starting from scratch working on her/his
 own documents and training material, which is ok, of course but leads into
 the situation Lene discribed.

 Here are two ideas that come to my mind:

 a) Trainers could combine their forces and prepair general training
 materials
 together that everybody can use and extend. All tools and the document
 basis
 is available and provided by QGIS project in the documentation repository.
 I
 know there are many people conducting trainings on QGIS, if they all work
 together as developers already do, we would probably be in a much better
 situation.

 b) An idea that already works for the development of QGIS features is
 paying
 some amount or percantage of each development for good documentation and
 training material. Many new features in QGIS are payed by customers. But
 usually customers and developers don't think about also spending an
 additional little amount to document the feature in the QGIS docs and
 training material. I don't know why, but that's reality.

 So for me, the problem is not just about changing the releases cycles. It
 is
 more about bringing documenters and trainers closer to the project again to
 combine their forces. And to make customers/users/developers aware, that
 documentation and training material is an important part of the software
 and
 should not be forgotten and maybe automatically added to an offer, if new
 (payed) features are added.

 Regards,
 Otto

 Am Tue, 22 Jul 2014 08:43:02 +0300
 schrieb Micha Silver mi...@arava.co.il:

  I also do some short training courses using QGIS, and I fully understand
  and support Lene's idea.
 
 
  On 21/07/2014 18:35, Lene Fischer wrote:
 
  Hi,
 
  This is not a mail about bugs or issues on a special feature - just a
  matter of time.
 
  Right now I´m preparing a 3 week intensive GIS course at university level
  - looking forward to these annual events. But I get stressed when I see
  that there are only 94 days until next version of QGIS. Because in
  November I start over again with a 8 week course and in February a 3 week
  course, in may a 3 week course. All in all we have more than 140 students
  learning QGIS every year - and they are impressed of this program!!!
 
 
 
  I love getting new features in the program, but fear the work to run
  through every assignment, every video and being a bit unsure how the
  program works in the latest version on the different platforms.
 
  Small changes which I haven´t noticed and therefore unaware of. So a new
  version so soon gives me a lot of stress and so many hours of work -
   hours which could be used to ex. testing.
 
 
 
  When I ask users to download the program they take the official latest
  version - sometimes with bugs included... It gives an impression of an
  unprofessional product (not my words), it gives me- and others hard times
  to fix or explain. I´ve been talking to other users/administrators who
 has
  the same experience.
 
  What if we had :
 
  ·A long term stable version for ex. 12 months with bugfix only
 
  ·A developer version for 4 months with new features and bugfixes
  = Stable version with short bugfix-period = New developer
 
 
 
  I do know it will give the developers more work - I do know it will cost
  more money - But I´m sure a lot of administrators will recommend,  use
 and
  support if we get a more stable environment.
 
  So please - consider another release plan in the future.
 
  Regards
 
  Lene Fischer
 
  Associate Professor
 
 
 
  Department of Geosciences and 

Re: [Qgis-developer] [Qgis-user] Stress about release plans

[Jonathan Moules]

Except that self-evidently the current solution doesn't work well. Of the
three projects I listed, QGIS has by far the worst documentation; as Otto
noted, they've not even started updating for 2.4 yet.

Just looking now, not a single one of the QGIS Geoalgorithms that I've
ever looked at (which are I think is what Victor is referencing) have
anything in the help tab. And these are a core part of the software.

I appreciate developers hate writing documentation, and in fact they're
often very bad at it anyway, but if other projects can do it with far fewer
resources then I think QGIS should be able to manage it to, especially the
commercial organisations that charge for feature development.

Cheers,
Jonathan




On 22 July 2014 11:05, Alexander Bruy alexander.b...@gmail.com wrote:

 + 1 to Otto and Victor.

 Developers should develop, the can document some aspects of
 code/feature (and they
 already do this!) but we can not ask them to write manuals

 2014-07-22 13:01 GMT+03:00 Victor Olaya vola...@gmail.com:
  +1 to what Otto said. Very good point. Those creating training materials
  should coordinate and help the core QGIS documentation (both the manual
 and
  the training manual) improve.
 
 
  The solution is very simple: Require up to date, accurate documentation
  for all commits of new features. This is one for the PSC.
  After all, what's the point in having tons of features if no-one knows
 how
  to use them or what they do?
  Will it slow down new feature feature commit? Probably, but I figure
  that's a small price to pay for actually having documentation. And from
 that
  documentation, universal training materials can be developed much more
  easily.
 
 
  -1 from me. Features are also  documented by people using them, not just
 by
  the devs. We like to say that you can contribute to open source projects
 not
  just by coding, but if we do that, I don't think we are going to get many
  contributions from users, leaving the documentation to be written only by
  developers.
 
  I try to keep the Processing documentation up to date, but only
 documenting
  the interface itself and the framework, not the algorithms. That's the
  reason why a large part of algorithms in Processing are not documented.
  Fortunately, some users have contributed documentation, and they have
 added
  descriptions of several algorithms, but the have done that *after* using
 the
  (hitherto undocumented) algorithm and becoming familiar with it. No one
 is
  going to document something that he cannot use yet.
 
  Let's encourage developers to commit features when they are well
 documented,
  but let's also give some flexibility, since that's not always going to be
  possible.
 
  my 2 cents
 
  Cheers
  Víctor
 
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer



 --
 Alexander Bruy


-- 
This transmission is intended for the named addressee(s) only and may 
contain confidential, sensitive or personal information and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify 
the sender immediately. All email traffic sent to or from us, including 
without limitation all GCSX traffic, may be subject to recording and/or 
monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Stress about release plans

[Jonathan Moules]

Hi Paolo,


  But is it working? I believe the point of an LTS is that each version is
 more stable
  than the last and that there are no new features which in turn means no
 new bugs

 The question is simple: maintaining a stable branch costs (developr
 time|money).
 If someone will put the ncessary resources, I'm pretty sure nobody will
 object.
 All the best.


Fair point, but then I'd ask - what would the cost be? Is it not something
that can be covered by the current sponsorship given that a significant (or
maybe just significantly vocal ;-) ) portion of the community seems to be
interested in it? I've tried finding the financials for QGIS but failed;
are they online publically available?

And this also goes back to the other questions I asked - how do other Open
Source projects do it? I know GeoServer has no central pot and a much
smaller community yet maintains multiple branches (at least 3!).
Just throwing money at a problem won't necessarily resolve it in the most
efficient way possible. Knowing where it went wrong last time and how other
projects do it seems like a logical starting place.

Just my 2p,

Best Regards,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain confidential, sensitive or personal information and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify 
the sender immediately. All email traffic sent to or from us, including 
without limitation all GCSX traffic, may be subject to recording and/or 
monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Fwd: [Qgis-user] Simplified interface - toolbox

[Jonathan Moules]

Hi List,
Further to this, has a new build of QGIS been created/released that has
this issue resolved? I note the version number is now 2.4.0.1.

Thanks,
Jonathan



On 10 July 2014 00:24, Victor Olaya vola...@gmail.com wrote:

 The issue is actually a packaging issue. There was a problem in the
 cmake.txt file, and it is not copying the file that is used to classify the
 algorithm in categories in the simplified interface.

  The problem should be fixed now, and I guess that we will release a new
 version in the following days, which will include this fix and the new
 modeler

 You can manually fix it by adding the missing file in the gui folder under
 the processing folder. In a OSGEO4W installation, that would
 be C:\OSGeo4W64\apps\qgis\python\plugins\processing\gui

 The file can be found here:


 https://raw.githubusercontent.com/qgis/QGIS/master/python/plugins/processing/gui/algclasssification.txt


 Thanks for your help


 2014-07-09 14:03 GMT+02:00 Jonathan Moules 
 jonathanmou...@warwickshire.gov.uk:

 Ok,
 I've reported it to the tracker:
 https://hub.qgis.org/issues/10854

 Seems like quite a bad bug from a user-interface perspective.

 Thanks,
 Jonathan



 On 9 July 2014 12:33, Randal Hale rjh...@northrivergeographic.com
 wrote:

  Same Bug on Ubuntu 12.04 using ubuntuGIS Repository




 On 07/09/2014 07:28 AM, Victor Olaya wrote:

 No, it sounds like a bug, and someone else reported that to me yesterday
 as well. It doens't happen in all installations of QGIS apparently. I will
 try to work on that at the end of the day today.

  Thanks for your help!


 2014-07-09 12:44 GMT+02:00 Jonathan Moules 
 jonathanmou...@warwickshire.gov.uk:

 Hi List,
 Using 2.4 I've noticed that on the simplified toolbox there aren't
 actually any tools any more.

  There are only Models and Scripts (neither of which is simple. And
 also recently used, although that requires the user to have found the
 advanced interface.

  Is this intentional? I guess not given it seems pointless to have a
 simplified interface for a toolbox that has no tools.

  Cheers,
 Jonathan

 This transmission is intended for the named addressee(s) only and may
 contain confidential, sensitive or personal information and should be
 handled accordingly. Unless you are the named addressee (or authorised to
 receive it for the addressee) you may not copy or use it, or disclose it to
 anyone else. If you have received this transmission in error please notify
 the sender immediately. All email traffic sent to or from us, including
 without limitation all GCSX traffic, may be subject to recording and/or
 monitoring in accordance with relevant legislation.
 ___
 Qgis-user mailing list
 qgis-u...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-user




 ___
 Qgis-user mailing 
 listQgis-user@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-user


 --
 -
 Randal Hale
 North River Geographic Systems, 
 Inchttp://www.northrivergeographic.com423.653.3611 
 rjh...@northrivergeographic.com
 twitter:rjhalehttp://about.me/rjhale


 ___
 Qgis-user mailing list
 qgis-u...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-user



 This transmission is intended for the named addressee(s) only and may
 contain confidential, sensitive or personal information and should be
 handled accordingly. Unless you are the named addressee (or authorised to
 receive it for the addressee) you may not copy or use it, or disclose it to
 anyone else. If you have received this transmission in error please notify
 the sender immediately. All email traffic sent to or from us, including
 without limitation all GCSX traffic, may be subject to recording and/or
 monitoring in accordance with relevant legislation.




-- 
This transmission is intended for the named addressee(s) only and may 
contain confidential, sensitive or personal information and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify 
the sender immediately. All email traffic sent to or from us, including 
without limitation all GCSX traffic, may be subject to recording and/or 
monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Navigation toolbar

[Jonathan Moules]

Hi Andreas,

On 2 July 2014 08:40, Andreas Neumann a.neum...@carto.net wrote:

 Hi,

 In addition to the discussion around the selection tool I would like to
 discuss a reduction of buttons in the navigation toolbar. I think it eats
 way too much screen-space by default. I'd like to suggest the following:

 1. get rid of the refresh button. I never use it. If you have to use it,
 than it is a bug in the software.


-1 = Alas there are bugs in QGIS, I do have to use it fairly frequently.
More than many on that toolbar actually.


 2. Potentially remove the Zoom to Layer button. It is available in the
 context menu of the layer and in the View menu, should you need it.

3. Potentially remove the Zoom to native resolution button. I think it is
 good enough if this functionality is available in the View menu. Do
 people really use this function? Maybe with raster layers?


+1 Never used it native resolution myself from the nav bar. Always right
click on a layer - that would probably be the most logical place to leave
both functions/

4. Potentially combine the touch zoom/and pan tool with the pan tool into a
 single tool. Is there a specific reason why both of these tools are
 available? Doesn't the Touch zoom and pan also support pan with the mouse?


+1 I've never been clear what the difference between them is anyway.


 5. Potentially combine the pan to selected and zoom to selected into a
 drop-down button menu, like we have with the measure or select tool.


+1 seems sensible.

Just my 2p.
Cheers,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain confidential, sensitive or personal information and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify 
the sender immediately. All email traffic sent to or from us, including 
without limitation all GCSX traffic, may be subject to recording and/or 
monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Using PostGIS on a slow connection

[Jonathan Moules]

It sounds like the PostGIS connection provider could use some optimisations.

The Oracle provider had/has a few which are being resolved (thanks
Jurgen!), but it does first require identifying what queries are being run
during what actions. If you have access, watch what queries are running on
PostGIS when you perform actions within QGIS.



On 26 February 2014 13:52, Paolo Cavallini cavall...@faunalia.it wrote:

 Il 26/02/2014 13:29, Andreas Neumann ha scritto:
  Hi,
 
  As far as I know libpq does not support compression.
 
  There is a lengthy discussion on libpq compression at
  http://postgresql.1045698.n5.nabble.com/libpq-compression-td5712541.html

 Some of the slowness is understandable, some not really, e.g. why
 deactivating a layer in the legend should require time?
 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
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] DD form gone?

[Jonathan Moules]

 You're right, sorry for the noise.
  The fact that the dropdown is empty induced me in error: perhaps better
 to fill it with the default value?

 +1
Looks like it should be pre-populated with autogenerate (or at least,
selecting that option does nothing so I guess it's already selected).

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS UX list not on website

[Jonathan Moules]

I've seen a couple of references to a qgis-ux list, however it's not
linked to on maillists list of the website:
http://www.qgis.org/en/site/getinvolved/mailinglists.html#qgis-mailinglists

Might be worth adding. (I guess it's this one -
http://lists.osgeo.org/mailman/listinfo/qgis-ux )
Cheers,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS UX list not on website

[Jonathan Moules]

Hi Richard,
Thanks. I remembered there's a special issue tracker for the website but
couldn't remember where it was so went with this instead.
Regards,
Jonathan


On 26 February 2014 15:09, Richard Duivenvoorde rdmaili...@duif.net wrote:

 On 26-02-14 15:07, Jonathan Moules wrote:
  I've seen a couple of references to a qgis-ux list, however it's not
  linked to on maillists list of the website:
 
 http://www.qgis.org/en/site/getinvolved/mailinglists.html#qgis-mailinglists
 
  Might be worth adding. (I guess it's this one
  - http://lists.osgeo.org/mailman/listinfo/qgis-ux )

 Ok, done:


 https://github.com/qgis/QGIS-Website/commit/14984d873fa0d3ce8fbb1112cfa99254c1811dbf

 Regards,

 Richard Duivenvoorde

 ps plz consider creating issues for this kind of ommisions, so it does
 not get missed/forgotten



-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS weekly builds not built in a while

[Jonathan Moules]

Hi List,
Just an observation but the weekly builds -
http://qgis.org/downloads/weekly/ - don't seem to have built for the last
couple of weeks. Are they still meant to be getting built or has something
gone wrong?

They're a good way around the myriad issues I seem to perpetually have with
the OSGeo4W installer.
Cheers,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Announcing the release of QGIS 2.2

[Jonathan Moules]

Excellent work, thanks guys.

Just a thought, but as part of the release process (I'm guessing there's a
big list of things to do somewhere) I'd suggest updating the Affected
Version on redmine to whatever the newest version is. There's no 2.2.0 on
there currently.

Cheers,
Jonathan


On 22 February 2014 08:58, Jürgen E. j...@norbit.de wrote:

 QGIS is a user friendly Open Source Geographic Information System
 that runs on Linux, Unix, Mac OSX, and Windows.

 We are very pleased to announce the release of QGIS 2.2 'Valmiera'.  The
 emphasis on this release has been very much on polish and performance - we
 have
 added many new features, tweaks and enhancements to make the user interface
 more consistent and professional looking (and hopefully easier to use). The
 composer (used for creating print ready maps) has had a lot of work done
 to it
 to make it a more viable platform for creating great cartographic outputs.

 This is first release following our new four month release schedule that is
 meant to make new features and bugfixes available quicker and the
 development
 and new releases more predictable.

 In order to streamline the release process, we only release the source code
 today.  The binaries will be created in close succession by the individual
 package maintainers.  The source code is and the binaries soon will be
 available via the large download link on our home page: http://qgis.org

 If there is not yet a binary package for your platform on the above page,
 please check back regularly as packagers push out their work and the
 download page will reflect the new packages.


 A word of thanks to our contributors, donors and sponsors
 --

 QGIS is a largely volunteer driven project, and is the work of a dedicated
 team
 of developers, documenters and supporters. We extend our thanks and
 gratitude
 for the many, many hours people have contributed to make this release
 happen.
 Many companies and organizations contribute back their improvements to
 QGIS and
 fund development of new features when they use it as their platform, and
 we are
 grateful for this and encourage others to do the same! We would also like
 to
 thank our sponsors and donors for helping to promote our work through their
 financial contributions. Our current sponsors are (QGIS Sponsorship is
 valid
 for one year):

 Gold Sponsor:
 Asia Air Survey (http://www.asiaairsurvey.com/)

 Silver Sponsor:
 State of Vorarlberg (http://www.vorarlberg.at)
 G.A.I.A. mbH (http://www.gaia-mbh.de/)

 Bronze Sponsors:
 ArguSoft GmbH  Co KG (http://argusoft.de)
 Molitec (http://www.molitec.it/)

 A current list of donors who have made financial contributions large and
 small to the project can be seen here:

 http://qgis.org/en/site/about/sponsorship.html#list-of-donors

 If you would like to make a donation or sponsor our project, please visit
 *http://qgis.org/en/site/about/sponsorship.html#sponsorship* . QGIS is
 Free software and you are under no obligation to do so. Sponsoring QGIS
 helps
 us to fund our six monthly developer meetings, maintain project
 infrastructure
 and fund bug fixing efforts

 Visual tour of the new release:
 --

 You can find a list of highlighted changes and new features listed on the
 detailed release announcement available here:

 *
 http://changelog.linfiniti.com/qgis/version/21/
 *


 Give us your feedback:
 --

 We welcome your feedback - please visit our issue tracker if you encounter
 an issue with the new release:

 http://hub.qgis.org/

 Please consult the existing issues there before filing any new ones.


 Happy QGISing!

 Regards,

 The QGIS Team!



 --
 Jürgen E. Fischer - QGIS Project Steering Committee Member
 ==
 Please do not email me off-list with technical support
 questions. Using the lists will gain more exposure for
 your issues and the knowledge surrounding your issue will
 be shared with all.

 IRC: jef on #qgis at freenode.net
 ==

 --
 norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
 Rheinstrasse 13, 26506 Norden
 GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, 

Re: [Qgis-developer] Post-release period of portable commits only?

[Jonathan Moules]

  Why not?  We're talking about a feature freezed period!?  The nightly
 build
 is a snapshot what what will get release.  Where do you see a difference?


I think it's a perception thing.
Nightly build in my mind always means bleeding edge may or may not work,
use at own risk. I'm aware that doesn't always mean *it will crash your
computer, burn down your house, and spend your life savings on questionable
drugs*, but it's certainly not what I see as a synonym for stable either.

Every time I see a nightly, it always comes with a big scary caveat (QGIS
does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This
trains users not to use them. Taking one of the nightlies and re-branding
it to something more amicable would get more folks to test it. Just copy
and paste it and rename the file. :-)

Cheers,
Jonathan




  Very few average user will install a nightly development build, but you
 get
  an higher chance of getting a broader number of people (that interacts
 with
  QGIS in different ways) to test out your product before it's released.

 Why should it matter if we call it weekly snapshot, nightly build or
 prerelease?   It's the same thing, just the tag is different.  And
 installation is essential as easy as installing the stable release.


  It also helps channel what your describing as noise (i.e. users running
  into problems) into a better managed call for people to test and report.
  The noise will happen no matter what. But it might make some sense to
  trigger some of that noise (valid bugs and invalid RTFM cases) _before_
  you release your final version via a pre-release social media and news
 site
  try this pre-release build :)

  It's really more a matter of presentation to the users than of actual
 work.

 Exactly.  And that's what I meant with noise: tada, there's a new weekly
 snapshot/prerelease/nightly build - not users running into problems.
  Because
 I see that as the only significant difference to what we already have.


 Jürgen

 --
 Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
 Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
 Software Engineer D-26506 Norden
 http://www.norbit.de
 QGIS PSC member (RM)  Germany  IRC: jef on FreeNode

 --
 norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
 Rheinstrasse 13, 26506 Norden
 GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Post-release period of portable commits only?

[Jonathan Moules]

Slightly deviating from the topic, but I'm quite fond of the GeoServer
release process; they're revamping a little to offer better Long Term
Support:
http://geoserver.org/display/GEOS/GSIP+107+-+Extended+Release+Schedule

I feel a similar system would solve most of QGIS' release problems:
- Bugfix releases
- LTS (if/when required)
- Predictable releases (though now fixed by QGIS)
- Clear test releases (betas and release candidates)

In comparison the QGIS release system feels... haphazard I guess is the
best word.

I know the common complaint is a lack of a resources, but QGIS has far more
resources than GeoServer - both in number of developers and the existence
of a general fund.

Just thought I'd put it out there.
Cheers,
Jonathan


On 24 February 2014 14:41, Filipe Dias filipesd...@gmail.com wrote:

 How about making a formal announcement (mailing list, website, wiki etc)
 telling the users that QGIS version 2.X is in feature freeze and therefore
 is sufficiently stable to be tested by end users? This may increase the
 number of testers.

 As an end user that uses QGIS for production, this is the only time I work
 with QGIS Master.


 On Mon, Feb 24, 2014 at 2:17 PM, Jonathan Moules 
 jonathanmou...@warwickshire.gov.uk wrote:



  Why not?  We're talking about a feature freezed period!?  The nightly
 build
 is a snapshot what what will get release.  Where do you see a difference?


 I think it's a perception thing.
 Nightly build in my mind always means bleeding edge may or may not
 work, use at own risk. I'm aware that doesn't always mean *it will
 crash your computer, burn down your house, and spend your life savings on
 questionable drugs*, but it's certainly not what I see as a synonym for
 stable either.

 Every time I see a nightly, it always comes with a big scary caveat (QGIS
 does too - http://www.qgis.org/en/site/forusers/alldownloads.html ).
 This trains users not to use them. Taking one of the nightlies and
 re-branding it to something more amicable would get more folks to test it.
 Just copy and paste it and rename the file. :-)

 Cheers,
 Jonathan




  Very few average user will install a nightly development build, but
 you get
  an higher chance of getting a broader number of people (that interacts
 with
  QGIS in different ways) to test out your product before it's released.

 Why should it matter if we call it weekly snapshot, nightly build or
 prerelease?   It's the same thing, just the tag is different.  And
 installation is essential as easy as installing the stable release.


  It also helps channel what your describing as noise (i.e. users running
  into problems) into a better managed call for people to test and
 report.
  The noise will happen no matter what. But it might make some sense to
  trigger some of that noise (valid bugs and invalid RTFM cases)
 _before_
  you release your final version via a pre-release social media and news
 site
  try this pre-release build :)

  It's really more a matter of presentation to the users than of actual
 work.

 Exactly.  And that's what I meant with noise: tada, there's a new weekly
 snapshot/prerelease/nightly build - not users running into problems.
  Because
 I see that as the only significant difference to what we already have.


 Jürgen

 --
 Jürgen E. Fischer norBIT GmbH   Tel.
 +49-4931-918175-31
 Dipl.-Inf. (FH)   Rheinstraße 13Fax.
 +49-4931-918175-50
 Software Engineer D-26506 Norden
 http://www.norbit.de
 QGIS PSC member (RM)  Germany  IRC: jef on
 FreeNode

 --
 norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
 Rheinstrasse 13, 26506 Norden
 GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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



 This transmission is intended for the named addressee(s) only and may
 contain sensitive or protectively marked material up to RESTRICTED and
 should be handled accordingly. Unless you are the named addressee (or
 authorised to receive it for the addressee) you may not copy or use it, or
 disclose it to anyone else. If you have received this transmission in error
 please notify the sender immediately. All email traffic sent to or from us,
 including without limitation all GCSX traffic, may be subject to recording
 and/or monitoring in accordance with relevant legislation.
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer




-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have

Re: [Qgis-developer] Metadata fields in QGIS

[Jonathan Moules]

I posted this to the user list a couple of weeks ago but no interest. Maybe
the dev list has some thoughts?

Hi List,
   I'm wondering if anyone uses the metadata fields for data in QGIS
 (Layer Properties - Metadata)? I've been told that this is supposed to be
 filled in manually.

 I ask because I originally thought it was supposed to be filled in
 automatically - http://hub.qgis.org/issues/8870 - And for OGC services
 (WMS, WFS etc) this seems logical as all of the data is in the
 GetCapabilities.

 Does anyone have a view on this? Should the metadata be filled in
 automatically or should the user enter it manually? My issue with the later
 is that I guess the metadata is only saved in a .qgs file, and not the
 source itself, so no-one else is going to be able to see manually entered
 data.

 Thoughts? Comments?

 Cheers,
 Jonathan


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Oracle layers - improving the speed

[Jonathan Moules]

Hi Jürgen,
  Thinking about it, the simplest solution is to just trust
MDSYS.USER_SDO_GEOM_METADATA and get everything from that where possible -
SRID and BBOX. The geometry-type it doesn't have, but is that strictly
necessary for the list?

This seems like the optimal solution for us; I'd suggest adding the
functionality behind the current Use estimated table metadata and/or
only look in meta data table checkboxes. In fact I expected only look in
meta data table to already do this.

I realise that this can be dangerous as Oracle doesn't keep it up to date,
however we do a good job of keeping it up to date ourselves (because if we
don't, ArcMap starts doing silly things). I'm sure other organisations are
similarly good at keeping their metadata up to date and could benefit too.

Does that seem like a plausible solution? A local-cache could build on that
I guess (store geometry types from pre-accessed tables?)
Cheers,
Jonathan


On 8 February 2014 17:45, Jürgen E. j...@norbit.de wrote:

 Hi Jonathan,

 On Tue, 04. Feb 2014 at 17:54:10 +, Jonathan Moules wrote:
 The native Oracle provider has been in QGIS for quite a while (a
 year?)
 and is generally quite good.
 However there are still two fundamental issues that we have with it,
 both
 as a result of the fact that Oracle doesn't store accurate spatial
 metadata:

 a) Whenever I Connect to the Oracle database, QGIS performs a scan
 of
 every table to get the metadata which can take almost 2 minutes (the
 results are cached by Oracle and subsequent Connects are faster, but
 only for an hour or two). This is using the Only look in metadata
 table,
 use estimated table metadata and only existing geomtetry types
 checkboxes.
 See also - [1]http://hub.qgis.org/issues/8689

 That's to determine the geometry types and srids used in the tables.

 That the available metadata tables in Oracle are somewhat optional and you
 can't safely assume much about them is really unfortunate.

 We could do another metadata table that stores the outcome of those
 queries in
 the database.  That would require the user to have INSERT/UPDATE on that
 table
 and/or CREATE TABLE rights.

 We could also do a local user cache.  That would have the advantaage that
 it
 could be used for any database.

 b) When I add a specific Oracle table, QGIS then performs some checks
 against it (I believe trying to find the actual BBOX). This is fine
 for
 small tables, but for large tables it can take several minutes for the
 layer to get added - locking up QGIS in the interim - even if
 render is
 disabled!

 The issue becomes even more problematical when re-opening a project -
 QGIS
 then rescans all of the tables included in the project which can mean
 a
 several minute delay after opening the project.

 The extent could also be added to that cache.  But for this the extent
 could
 also be added as cachedExtent to the data source uri.  Parameters for srid
 and
 (geometry)type are already there and I just changed the postgres provider
 to
 depend on those without verifying them. Extent would be the next natural
 candidate and possibly speed up the loading of projects even more.

 But those are features which will have to wait until after the release.


 Jürgen

 --
 Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
 Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
 Software Engineer D-26506 Norden
 http://www.norbit.de
 QGIS PSC member (RM)  Germany  IRC: jef on FreeNode

 --
 norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
 Rheinstrasse 13, 26506 Norden
 GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Oracle layers - improving the speed

[Jonathan Moules]

Hey Jürgen,



 There's always an extent, but that not necessarily reflect an actual bbox,
 but
 just sets the available bounds, which are often set much bigger than the
 actual
 data.  But the bounding box is determined after insertion of the layer
 anyway.


Fair point, but for us it's definitely still preferable over having QGIS
hang for several minutes waiting for Oracle to perform a MBR check on a
table with millions of features.



 To insert the layer we just need tablename, column, type and srid - and
 that's
 what the thread searches for.


How about doing the search for type when the layer is actually added to
QGIS? It could also confirm the other stuff (which it got from metadata) at
that time too.





 An additional idea would be to use the filters upfront.  Currently you can
 only
 filter the result of the layer search after the search has already been
 run.
 Instead we could reduce the searches we want by just looking for tables
 with
 given (partial) name, in a given schema, srid and/or geometry type.
  Especially
 in cases where the search is expensive, because there are loads of tables,
 this
 is would even be useful if performance wasn't an issue.


 And that would also be interesting for all other database providers.


Oooh, I like that idea!

Kind regards,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] some flaw in RDP algorithm?

[Jonathan Moules]

Hi,
QGIS already has access to tons of generalisation options via the grass
v.generalise tool

http://grass.osgeo.org/grass64/manuals/v.generalize.html

Split into four categeories - Generalisation, Smoothing, Displacement,
Network Generalisation.

Is there a reason those can't be used? I wonder how many implementations of
Douglas Peucker QGIS already has? Re-implementing other ones when they
already exist doesn't seem optimal. Of course maybe you want a new one, but
then I'd suggest maybe it could be added to Grass and that in turn would
automatically feed into QGIS.

Cheers,
Jonathan



On 3 February 2014 14:29, kimaidou kimai...@gmail.com wrote:

 Hi,

 We definitely need a better simplify algo in QGIS than Douglas Peucker. It
 is very fast, but does not really preserve the shape of polygons/lines
 and does not preserve topology. Your work seems interesting. Is you
 approach similar to Visvalingam algo (used for example in Mapshaper :
 http://mapshaper.org/ ) ? Does it preserve topology ?
 Having a simplifier that can preserver topology while being fast like
 Visvalingam would be great indeed !

 ps: sorry to bring personnal will in response of your topic instead of
 really answering your question..

 Michael


 2014-02-03 giulianc51 giulian...@gmail.com:

 Hi all,


 I do not know if this is the right place to talk about it but I think I
 have found a small problem in the plugin fTools, particularly in the
 Simplify geometry of the module Geometry tool;

 more precisely, the problem is in the RDP algorithm used by the
 function;

 nothing dramatic, the procedure works properly and provides a
 simplified line, but I have isolated some cases in which the solution
 is not optimal: some points, not needed for the definition of the line,
 are left;

 to sum up, I put some considerations in some slides here
 http://www.slideshare.net/giulianc/clean-lines-presentation;

 can you tell me where and how it can be of interest to discuss this
 topic?

 thanks, best regards, sfm+Gtbe(*) :-)
 giuliano curti


 (*) sorry for my (+ Google translation) bad english :-)
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer



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


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] some flaw in RDP algorithm?

[Jonathan Moules]

Hi Giuliano,



 you're probably right, but I have never advised to develop a new
 simplification algorithm :-)

 I am a mathematical as a hobby, I have only met a little problem
 with the RDP algorithm and I reported it, and I had fun writing an
 algorithm for fun but no idea of proposing developments in this
 direction;

 Ah, I missed that. If it's a new algorithm, maybe try and get it published
into a journal? Then other math types who are into that sort of thing (and
more importantly, understand it! :-) ) can give you feedback on it. As you
may know, there's quite a bit of literature on
generalisation/simplification algorithms, including for RDP -
http://scholar.google.co.uk/scholar?q=rdp+simplification - you may find
some of that interesting reading.

Kind Regards,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Oracle layers - improving the speed

[Jonathan Moules]

Hi List,
The native Oracle provider has been in QGIS for quite a while (a year?) and
is generally quite good.

However there are still two fundamental issues that we have with it, both
as a result of the fact that Oracle doesn't store accurate spatial metadata:

a) Whenever I Connect to the Oracle database, QGIS performs a scan of
every table to get the metadata which can take almost 2 minutes (the
results are cached by Oracle and subsequent Connects are faster, but only
for an hour or two). This is using the Only look in metadata table, use
estimated table metadata and only existing geomtetry types checkboxes.
See also - http://hub.qgis.org/issues/8689

b) When I add a specific Oracle table, QGIS then performs some checks
against it (I believe trying to find the actual BBOX). This is fine for
small tables, but for large tables it can take several minutes for the
layer to get added - locking up QGIS in the interim - even if render is
disabled!
The issue becomes even more problematical when re-opening a project - QGIS
then rescans all of the tables included in the project which can mean a
several minute delay after opening the project.


None of the other GIS-y systems we have have this problem. ArcMap and
MapInfo solve it by having their own metadata tables that we have to
manually maintain :-( . FME solves it by... well I don't know how (not
separate metadata tables).


So my question is - is there any development work that can be done on the
QGIS end to speed either of these things up? Ticket 8689 linked above has a
couple of my thoughts, but I'm sure the list can come up with better
suggestions.


Any thoughts? Particularly item (b). We're willing to consider sponsoring
these particular changes as we're heavy Oracle users, hence me asking. :-)

Thanks,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Consistency in adding layers (especially OGC)

[Jonathan Moules]

Hi Alvaro,
That seems really interesting, hopefully something similar thing can be
created for QGIS. Your video shows how slick it can be.

I've created a fairly bland issue for this - http://hub.qgis.org/issues/9451
What's next?

Cheers,
Jonathan



On 28 January 2014 15:19, A Huarte ahuart...@yahoo.es wrote:

 +1 to create an universal dialog for adding layers (or folder of
 files/layers)

 I have resolved the same problem in a personal application integrating all
 formats and types in a single loading form.
 Basically each provider offers a PropertyPage collection to build the
 ConnectionString that each provider know to open.

 I attach a short video to show the idea (~2.5 mb).

 http://www.filedropper.com/GenericCadgisLoadingDialog

 Best Regards
 Alvaro

   --
  *De:* Jonathan Moules jonathanmou...@warwickshire.gov.uk
 *Para:* Nathan Woodrow madman...@gmail.com
 *CC:* qgis-developer@lists.osgeo.org qgis-developer@lists.osgeo.org
 *Enviado:* Martes 28 de enero de 2014 11:57
 *Asunto:* Re: [Qgis-developer] Consistency in adding layers (especially
 OGC)

 Hi Nathan,
 Unfortunately my talent lies with finding flaws and suggesting
 tweaks/improvements to things rather than designing UI's. I'm more than
 happy to offer feedback.

 Is there any way to spur this along? We have a limited amount of
 commercial support (we're a local authority going through austerity
 measures- budgets dwindling); this would be good to see in 2.4 if possible.

 Cheers,
 Jonathan


 On 28 January 2014 10:39, Nathan Woodrow madman...@gmail.com wrote:

 Hey Jonathan,

 Yes this is a bit of a known issue.  It has always been a goal of mine to
 try and tackle the issue of refactoring the whole lot into single dialog.
  I have some early dialog mockups floating around that you might be able to
 find, although I would tweak it a bit now.

 If you have some ideas for a new single UI it would be good to have a
 look, or even if you just have ideas on what you want to see.

 - Nathan


 On Tue, Jan 28, 2014 at 8:03 PM, Jonathan Moules 
 jonathanmou...@warwickshire.gov.uk wrote:

 Hi List,
  This may be too late for 2.2 (some are features), but something that's
 bugging me no end is the complete lack of consistency between all the
 dialogs for the OGC services. Below I've created a somewhat exhaustive list
 of differences-that-shouldn't-be between the way they behave - mostly the
 add-layer dialog.

 However, rather than rectify the issues, would it maybe make more sense to
 just create a single new dialog from scratch and use that instead? Ideally
 for all formats, but if necessary, just the OGC stuff.

   What are the plans relating to add-layer dialogs? Is there a preferred
 option? Or will/desire to create a universal dialog for adding layers?

 Cheers,
 Jonathan

 -

 *Adding Layers:*

 Add/Close buttons
 For WCS these are the wrong way around!

 Layer Title|Name:
 - For WMS, WCS - use the layer Title rather than the layer Name when
 adding to the layers list (WFS  WMTS already do this).
  - Either add Use title for layer name checkbox to WMS/WMTS, WCS, or
 remove from WFS.
 - WMS seems to allow you to fill in a Layer name - add to other dialogs?
 If so, make it more obvious what it does.

 Filter:
 Add Filter function for WMS, WMTS, WCS (already exists for WFS).

 Differentiate windows:
  http://hub.qgis.org/issues/9193

 Tabs:
 WCS: Remove Layers tab as pointless.
 WMS/WMTS - I have no idea what Server Search or Layer order do - never
 seen them active.

 CRS:
 All - Make CRS section same between dialogs.
 WMS - why is Tile Size and Feature limit for GetFeatureInfo inside the
 CRS box?

 Format:
 WCS or WMS/WMTS - Use same method for selecting format. One uses dropdown
 (WCS), one uses checkboxes. I guess WFS doesn't need this option.

 Column list:
 All - In list of layers, use same order of columns and same selection of
 columns.
 WCS, WMS - Column widths autodetected. (Already done for WMTS, WFS)

 Caching:
 WCS / WFS - Offer same method for choosing caching settings.

 Add Layer:
 WFS - Don't close the dialog. Or Do close it for WMS/WMTS and WCS.



 -
 *Create Connection*:
 WMS/WMTS - says Create a new WMS connection - should say WMTS too.
  WCS/WFS - Referer option (in WMS already)
 WFS - Connection details not in bold (is on WMS/WCS)


 -

 *Metadata*:
 Following on from this ticket - http://hub.qgis.org/issues/8870 -
 suggested changes to layer properties - Metadata:

 WMS, WMTS and WCS:
  - Don't list entire Get Capabilities in properties, only the section for
 that particular layer. WFS already does this.

  - All OGC Services - Populate the Description/attribution/metadataURL
 from the GetCapabilities.


 This transmission is intended for the named addressee(s) only and may
 contain sensitive or protectively marked material up to RESTRICTED and
 should be handled accordingly. Unless you are the named addressee (or
 authorised to receive it for the addressee

[Qgis-developer] Consistency in adding layers (especially OGC)

[Jonathan Moules]

Hi List,
This may be too late for 2.2 (some are features), but something that's
bugging me no end is the complete lack of consistency between all the
dialogs for the OGC services. Below I've created a somewhat exhaustive list
of differences-that-shouldn't-be between the way they behave - mostly the
add-layer dialog.

However, rather than rectify the issues, would it maybe make more sense to
just create a single new dialog from scratch and use that instead? Ideally
for all formats, but if necessary, just the OGC stuff.

  What are the plans relating to add-layer dialogs? Is there a preferred
option? Or will/desire to create a universal dialog for adding layers?

Cheers,
Jonathan

-

*Adding Layers:*

Add/Close buttons
For WCS these are the wrong way around!

Layer Title|Name:
- For WMS, WCS - use the layer Title rather than the layer Name when adding
to the layers list (WFS  WMTS already do this).
 - Either add Use title for layer name checkbox to WMS/WMTS, WCS, or
remove from WFS.
- WMS seems to allow you to fill in a Layer name - add to other dialogs?
If so, make it more obvious what it does.

Filter:
Add Filter function for WMS, WMTS, WCS (already exists for WFS).

Differentiate windows:
http://hub.qgis.org/issues/9193

Tabs:
WCS: Remove Layers tab as pointless.
WMS/WMTS - I have no idea what Server Search or Layer order do - never
seen them active.

CRS:
All - Make CRS section same between dialogs.
WMS - why is Tile Size and Feature limit for GetFeatureInfo inside the
CRS box?

Format:
WCS or WMS/WMTS - Use same method for selecting format. One uses dropdown
(WCS), one uses checkboxes. I guess WFS doesn't need this option.

Column list:
All - In list of layers, use same order of columns and same selection of
columns.
WCS, WMS - Column widths autodetected. (Already done for WMTS, WFS)

Caching:
WCS / WFS - Offer same method for choosing caching settings.

Add Layer:
WFS - Don't close the dialog. Or Do close it for WMS/WMTS and WCS.



-
*Create Connection*:
WMS/WMTS - says Create a new WMS connection - should say WMTS too.
 WCS/WFS - Referer option (in WMS already)
WFS - Connection details not in bold (is on WMS/WCS)


-

*Metadata*:
Following on from this ticket - http://hub.qgis.org/issues/8870 - suggested
changes to layer properties - Metadata:

WMS, WMTS and WCS:
 - Don't list entire Get Capabilities in properties, only the section for
that particular layer. WFS already does this.

 - All OGC Services - Populate the Description/attribution/metadataURL from
the GetCapabilities.

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Consistency in adding layers (especially OGC)

[Jonathan Moules]

Hi Nathan,
Unfortunately my talent lies with finding flaws and suggesting
tweaks/improvements to things rather than designing UI's. I'm more than
happy to offer feedback.

Is there any way to spur this along? We have a limited amount of commercial
support (we're a local authority going through austerity measures-
budgets dwindling); this would be good to see in 2.4 if possible.

Cheers,
Jonathan


On 28 January 2014 10:39, Nathan Woodrow madman...@gmail.com wrote:

 Hey Jonathan,

 Yes this is a bit of a known issue.  It has always been a goal of mine to
 try and tackle the issue of refactoring the whole lot into single dialog.
  I have some early dialog mockups floating around that you might be able to
 find, although I would tweak it a bit now.

 If you have some ideas for a new single UI it would be good to have a
 look, or even if you just have ideas on what you want to see.

 - Nathan


 On Tue, Jan 28, 2014 at 8:03 PM, Jonathan Moules 
 jonathanmou...@warwickshire.gov.uk wrote:

 Hi List,
 This may be too late for 2.2 (some are features), but something that's
 bugging me no end is the complete lack of consistency between all the
 dialogs for the OGC services. Below I've created a somewhat exhaustive list
 of differences-that-shouldn't-be between the way they behave - mostly the
 add-layer dialog.

 However, rather than rectify the issues, would it maybe make more sense
 to just create a single new dialog from scratch and use that instead?
 Ideally for all formats, but if necessary, just the OGC stuff.

   What are the plans relating to add-layer dialogs? Is there a preferred
 option? Or will/desire to create a universal dialog for adding layers?

 Cheers,
 Jonathan

 -

 *Adding Layers:*

 Add/Close buttons
 For WCS these are the wrong way around!

 Layer Title|Name:
 - For WMS, WCS - use the layer Title rather than the layer Name when
 adding to the layers list (WFS  WMTS already do this).
  - Either add Use title for layer name checkbox to WMS/WMTS, WCS, or
 remove from WFS.
 - WMS seems to allow you to fill in a Layer name - add to other
 dialogs? If so, make it more obvious what it does.

 Filter:
 Add Filter function for WMS, WMTS, WCS (already exists for WFS).

 Differentiate windows:
 http://hub.qgis.org/issues/9193

 Tabs:
 WCS: Remove Layers tab as pointless.
 WMS/WMTS - I have no idea what Server Search or Layer order do -
 never seen them active.

 CRS:
 All - Make CRS section same between dialogs.
 WMS - why is Tile Size and Feature limit for GetFeatureInfo inside
 the CRS box?

 Format:
 WCS or WMS/WMTS - Use same method for selecting format. One uses dropdown
 (WCS), one uses checkboxes. I guess WFS doesn't need this option.

 Column list:
 All - In list of layers, use same order of columns and same selection of
 columns.
 WCS, WMS - Column widths autodetected. (Already done for WMTS, WFS)

 Caching:
 WCS / WFS - Offer same method for choosing caching settings.

 Add Layer:
 WFS - Don't close the dialog. Or Do close it for WMS/WMTS and WCS.



 -
 *Create Connection*:
 WMS/WMTS - says Create a new WMS connection - should say WMTS too.
  WCS/WFS - Referer option (in WMS already)
 WFS - Connection details not in bold (is on WMS/WCS)


 -

 *Metadata*:
 Following on from this ticket - http://hub.qgis.org/issues/8870 -
 suggested changes to layer properties - Metadata:

 WMS, WMTS and WCS:
  - Don't list entire Get Capabilities in properties, only the section for
 that particular layer. WFS already does this.

  - All OGC Services - Populate the Description/attribution/metadataURL
 from the GetCapabilities.


 This transmission is intended for the named addressee(s) only and may
 contain sensitive or protectively marked material up to RESTRICTED and
 should be handled accordingly. Unless you are the named addressee (or
 authorised to receive it for the addressee) you may not copy or use it, or
 disclose it to anyone else. If you have received this transmission in error
 please notify the sender immediately. All email traffic sent to or from us,
 including without limitation all GCSX traffic, may be subject to recording
 and/or monitoring in accordance with relevant legislation.
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer




-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation

Re: [Qgis-developer] Plugins approval

[Jonathan Moules]

On 7 January 2014 08:04, Matthias Kuhn matthias.k...@gmx.ch wrote:

 Is there a real problem we are trying to solve with this?


Users (even technical ones) have problems finding where plugins have
actually installed stuff - I've seen it first hand. By using a logical and
consistent approach, that issue is minimised. The biggest weakness of QGIS
in my mind is the fact that it's extremely hodge-podge and inconsistent
from the user-interface/user-experience perspective. Anything to fix that
is a good thing IMHO.
Cheers,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Easy Issues for QGIS dev

[Jonathan Moules]

Hi,
I've gone through a small set of my bug reports - these ones appear like
they may be easy. However (a) I'm not a QGIS dev so don't know; (b) I don't
have tagging permissions anyway.

http://hub.qgis.org/issues/8899
http://hub.qgis.org/issues/8900
http://hub.qgis.org/issues/9196
http://hub.qgis.org/issues/9217
http://hub.qgis.org/issues/8870
http://hub.qgis.org/issues/8872

If they are and this easy issues thing takes off/is used, I can go
through the rest of my tickets too.

Cheers,
Jonathan


On 7 January 2014 11:18, Paolo Cavallini cavall...@faunalia.it wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Il 05/01/2014 14:33, Olivier Dalang ha scritto:

  I'd like to flag a few tickets I reported as easy, but I'm unable to
 set tags using
  the update link... Is it possible to fix that ?
  If no, here are ticket's I'd flag as easy:
  http://hub.qgis.org/issues/7541
  http://hub.qgis.org/issues/9244
  http://hub.qgis.org/issues/7177

 Hi all.
 Any progress on this? We currently have just 3 tickets on the list
 http://hub.qgis.org/projects/quantum-gis/issues?query_id=62
 not exactly encouraging.
 All the best.
 - --
 Paolo Cavallini - www.faunalia.eu
 Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)
 Comment: Using GnuPG with Icedove - http://www.enigmail.net/

 iEYEARECAAYFAlLL4poACgkQ/NedwLUzIr6N7QCeNAhDXTwYzvkQSkj9Xws3q9kJ
 +OYAoKIQ1nhiiJUwasDVjo69YcBz3sG6
 =pHO7
 -END PGP SIGNATURE-
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugins approval

[Jonathan Moules]

  I remember, I discussed another key website with Borys, which would be
 shown in a frame in the plugin description page. This could be used to show
 even pictures in a description. Or we could just embed the URL listed in
 homepage.


If I'm understanding correctly, you're proposing that the explanations etc
be hosted online? From what I've picked up reading the lists and elsewhere,
QGIS is used in quite a few instances in locations where internet access is
lacking or merely unreliable. I think any help/explanation should be
integrated and distributed with the software.

So I would not say anything to fix that is a good approach

A poor choice of words on my part. Obviously a good fix is preferable to.
:-)
Cheers,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] How to deal with plugins which are not useful for users (e.g. Hello world)

[Jonathan Moules]

+1 to Anita's post. The vast majority of GIS users aren't programmers in my
experience (which is my masters and my current employment with 100+ people
who use GIS in some form). Simpler is almost always better.

It may not seem that way from mailing lists, but these are a self-selecting
group of the more technically-proactive users (dev lists even more so).
Cheers,
Jonathan


On 30 December 2013 13:32, Anita Graser anitagra...@gmx.at wrote:

 Hi Alessandro,

 Am 30.12.2013, 13:54 Uhr, schrieb Alessandro Pasotti apaso...@gmail.com:

 Did you have any real feedback from users being confused from the
 HelloWorld plugin? After all, it clearly advertises itself as an example
 do-nothing plugin.


 There is feedback from at least one user who think it should not be on the
 list of official plugins:
 https://twitter.com/dig_geo_com/statuses/417293802387152896

 I can understand that it does not leave the most professional impression
 if users find weird testing stuff in the official plugin list. (Note
 that I'm speaking from the perspective of users without open
 source/programming background.)

  Can you explain me why do you put plugin developers in a different
 category
 than users? I tend to see plugin authors as (power) users.


 Many GIS users are not programmers. They have QGIS installed by their IT
 department and might or might not be able to install additional plugins.
 They certainly won't touch programming with a ten-foot pole.
 I think it's a valid distinction to make and the first impression should
 not alienate these more casual users.

   If I were a new QGIS user, I would like to have starting point to develop
 plugins, of course we have the coockbook and the builder plus plenty of
 blog articles, but as a programmer, what I would search is exactly that:
 the simplest possible plugin to start tampering with.


 I totally agree with your statement from the perspective of someone who
 knows at least some programming. But not everyone is in this position. Many
 users come to QGIS without feeling the need to develop plugins. Too often
 all they want to do is visualize some data, maybe have some background map
 from OpenLayers plugin.

  But I definitely agree that HelloWorld should not have a dual purpose
 (testing the plugin repository and provide a barebone example for wannabe
 plugin authors), so here's my proposal: unpublish HelloWorld and create a
 new Example plugin with the purpose of providing a simple starting point
 for new plugin authors.


 Personally, that doesn't bother me. I'm fine however you decide.

 Best wishes,
 Anita


 ___
 anitagraser.com
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Multi-threaded Rendering

[Jonathan Moules]

Hi Martin,
Just a minor thing, probably an accidental omission. Your list of
data-providers that don't work doen't include the Oracle native one but I
suspect probably should.
From a non-dev's perspective it looks quite promising. :-)
Cheers,
Jonathan


On 12 December 2013 12:14, Martin Dobias wonder...@gmail.com wrote:

 Hi everyone!

 [attention: long text ahead]

 In recent weeks I have been working on moving map rendering into
 background worker threads and all related infrastructure changes.
 There is still quite a lot of work to do, but finally I think it is a
 time for a preview and a broader discussion about the whole thing. Not
 every little QGIS feature is working yet, but things work fine with
 most commonly used data sources (GDAL/OGR, PostGIS, SpatiaLite).
 Please give it a try! The code is available in my QGIS repository on
 GitHub, the branch is called threading-revival:
 https://github.com/wonder-sk/QGIS/tree/threading-revival

 The plan is to continue working on the project in the following weeks
 to reintroduce support for features and data providers currently not
 supported (e.g. WMS, WFS). Hopefully by the time of feature freeze in
 late January the code will in condition to be merged to master, so the
 multi-threaded rendering can appear in QGIS 2.2 release.

 The project has already quite some history: it started as my GSoC
 project in summer of 2010, unfortunately it was not merged back to
 master branch because the code never get into production level
 quality. The scope of the project is not just about moving rendering
 into background: it is mostly about updating various pieces of QGIS
 core library and data providers to behave correctly in the case that
 more threads simultaneously try to access the same resource - until
 now the assumption always was that there was only one thread. Back in
 2010, QGIS code was much less ready to change those assumptions. Now,
 after the release of 2.0, the code is much closer to what we need for
 multi-threaded rendering: both vector and raster layer code went
 through a major overhaul in the preparation for 2.0.

 What to expect from the project:
 1. better user experience. Browsing the map in canvas gets much
 snappier - pan and zoom map smoothly with instant preview, without
 having to wait until rendering of the previous view is finished,
 without flickers or other annyoances. Even if the map takes longer to
 render, you are free to do any actions in the meanwhile. It is a bit
 hard to describe the difference of the overall feel, one needs to try
 it out :)

 2. faster rendering of projects with more layers. Finally, it is
 possible to use the full power of your CPU. The rendering of map
 layers can be done in parallel: layers will be rendered separately at
 the same time and then composited together to form the final map
 image. In theory, rendering of two layers can get twice as fast. The
 speedup depends a lot on your data.

 3. starting point for more asynchronous operations. With safe access
 to map layers from worker threads, more user actions could be
 processed in background without blocking GUI, e.g. opening of
 attribute table, running analyses, layer identification or change of
 selection.

 What not to expect from the project:
 - faster rendering of one individual layer. A project with one layer
 that took five seconds to render will still take five seconds to
 render. The parallelization happens at the level of map layers. With
 one map layer QGIS will still use just one core. Optimizing the
 rendering performance of an individual layer is outside of the scope
 of this project.

 What to expect from the project *right now*: things should generally
 work, except for the following:
 - data providers: delimited text, gpx, grass, mssql, sql anywhere, wfs,
 wms, wcs
 - QGIS server
 - point displacement renderer

 For testing, simply use QGIS as you would usually do and see if you
 feel a difference when browsing the map. In Options dialog, Rendering
 tab, there are few new configuration options for you to play with: 1.
 parallel or sequential rendering, 2. map update interval. The parallel
 rendering may use all your CPU power, while sequential (currently
 being the default) will use just one CPU core. The default map preview
 update interval is now set to 250ms - feel free to experiment with
 other values. Lower values will bring faster updates, at the expense
 of wasting more time doing just updates instead of real work. Parallel
 rendering can be switched on/off also directly in the map canvas by
 pressing 'P' key - useful when you want to quickly compare the
 difference between sequential and parallel rendering. There is another
 magical shortcut, 'S' key, that will show very simple stats about the
 rendering (currently just total rendering time), so you can again
 quickly compare the impact of various factors (antialiasing, parallel
 rendering, caching etc). These shortcuts are likely to be removed from
 the final version, so 

Re: [Qgis-developer] QGIS Multi-threaded Rendering

[Jonathan Moules]

I believe GeoServer (well, GeoWebCache) uses metatiling for that purpose
within its WMTS/TMS. My understanding is that rather than rendering a
single 256*256 pixel tile like it was asked to, it renders a grid of 4*4
(adjustable; but that's the default) of those tiles (so 1024*1024 pixels)
and then clips that to get the requested tile. The result is that labels
look quite good crossing tile borders. Maybe something similar could work
for QGIS.

Jonathan


On 12 December 2013 16:23, Bernhard Ströbl bernhard.stro...@jena.de wrote:

 Hi Martin,

 Am 12.12.2013 16:50, schrieb Martin Dobias:

  Hi Tim!


  That all sounds absolutely brilliant! Thanks for such a nice clear
 description of how it all fits together. I know you are only considering
 layer-by-layer rendering but does your design accommodate further future
 optimisations easily? I'm thinking of things like:

 * predictive / off screen  rendering of 3x3 canvas dimensions after the
 initial render so that any pan is near instantaneous (and would trigger a
 new off-screen render)


 I have had this idea in my mind while working on the project. In
 theory map canvas can spawn several renderer jobs (instead of just
 one) and let them render just one tile of the map. Some special
 handling of the labeling would be necessary if we wanted labels that
 are allowed to cross the border of tiles.


 that reminds me that I needed some way to keep a stripe around the edge
 free of labels in QGIS server for tiling purposes (labels were cut)
 if you address this issue it would be nice to have this somehow
 customizable for QGIS server.

 Bernhard


 __ Information from ESET Mail Security, version of virus signature
 database 9165 (20131212) __

 The message was checked by ESET Mail Security.
 http://www.eset.com



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


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Context help is evil and old

[Jonathan Moules]

Hi Richard,
For reference, I opened a ticket on this a couple of months ago -
http://hub.qgis.org/issues/8699 - and had similar findings to yourself
Cheers,
Jonathan


On 27 November 2013 08:31, Richard Duivenvoorde rdmaili...@duif.net wrote:

 Hi,

 while the idea of context help buttons in dialogs is great...

 In practice that help is either not available, or outdated or not
 translated or (differently) duplicated into the Documentation
 (and as a tranlator it is pretty boring to translate all the context
 help texts).

 What about unifying all help in the Manual (website). With Sphinx (our
 docs are generated with it) it is pretty easy to point to a specific
 paragraph in the manual ( right click on the paragraph sign next to the
 heading ). Eg the section about loading shapfiles:


 http://www.qgis.org/en/docs/user_manual/working_with_vector/supported_data.html#loading-a-shapefile

 We could:

 1) either just put a link into the context help so a connected user can
 jump to the docs website

 2) or we could load that page in the QGIS help dialog (in a webkit widget)

 3) or (??) we could try to package the docs into the QGIS install and
 load the local file inot the QGIS help dialog.

 Only 'problem' I see is that we maybe have to write some more
 specialized or more general paragraphs in the manual which are suited
 for the context help. I'm thinking about for example the description of
 all the functions in the field calculator etc. Or in case of the 'Open
 Vector Layer Dialog' about a more general paragraph about the loading of
 vector data via OGR.

 Another example of very different results for the same topic:

 The context help for delimited text context help is VERY verbose and
 helpfull:


 https://github.com/qgis/QGIS/blob/master/resources/context_help/QgsDelimitedTextSourceSelect

 While compared with the docs, these are rather thin:


 http://www.qgis.org/en/docs/user_manual/introduction/general_tools.html?highlight=delimited#add-delimited-text-layer

 So my proposal: let's get rid of help TEXT in the context help. Put all
 text (and energy) in DOCS and link to them or show them.

 Regards,

 Richard Duivenvoorde







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


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS website download links

[Jonathan Moules]

Hi folks,

Couple of thoughts on the website:

1) - There doesn't seem to be a link to the weeklies, or at least not one I
can find on http://www.qgis.org/en/site/forusers/alldownloads.html

2) That same page has a link under QGIS testing which 404's -
http://download.opensuse.org/repositories/Application:/Geo/VERSION/ -
looking closer that link is on the page three times.

Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.0 point release?

[Jonathan Moules]

 It's fine for us that control the hardware we run stuff on but a lot of
 people don't and have to go though a major process to get an update.


To that end, would it be possible to create an update that's more like a
patch of the sort that Windows, ArcGIS, most-games use, rather than (or
maybe on top of) an entirely new install? I realise this would be a lot of
work to initially set up (I don't think QGIS has this ability yet?), but
for end users, it would make keeping up to date much easier.

Joanthan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.0 point release?

[Jonathan Moules]

+1

I was going to ask if there were plans for something like this, but it's
great to see someone taking the initiative on it!



On 29 October 2013 22:21, Nyall Dawson nyall.daw...@gmail.com wrote:

 Hey all,

 I'm just scoping things out -- if I was to go through all the commits
 which have hit master since the 2.0 release and apply any relevant bug
 fixes to the release-2_0 branch, what's the chance of getting this packaged
 up and released as a 2.0 point release?

 I'm happy to apply all the bug fixes, but packaging isn't in my skillset!

 Nyall


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


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS context help

[Jonathan Moules]

On the issue of which format to use, pandoc can translate between most
document formats it seems, including the ones specified by Alexander as
being used by QGIS. Project is here:

http://johnmacfarlane.net/pandoc/

The help should definitely be in a single format; ideally something that is
easily editable by non-technical users.

Cheers,
Jonathan



On 23 October 2013 17:55, Paolo Cavallini cavall...@faunalia.it wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Il 23/10/2013 18:51, Alexander Bruy ha scritto:

  Keeping context help up-to-date requires additional efforts and
  maybe separate team. Maybe it is better to drop context help in
  favor of documentation? Opinions?

 IMHO we should unify the two. The context help should appear as a box
 in the manual, and the GUI should take it from there (one source,
 copied both in the GUI and in the manual).
 Thanks.
 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.14 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlJn/4AACgkQ/NedwLUzIr7IagCdFTxhUI37jtzwH7Jx1w6gsf74
 b4sAnRhjHREod8xKIOPnfuUAqfn4ra/Q
 =5CIq
 -END PGP SIGNATURE-
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] problems with tiff

[Jonathan Moules]

Hi Paolo,
Looking at a Paletted GeoTiff on Windows 2.0.1, x64 and it works fine,
including all of the layer properties tabs.
Might it be a GDAL thing?

Jonathan



On 17 October 2013 08:44, Paolo Cavallini cavall...@faunalia.it wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi all.
 Opening properties of a paletted tiff on win (osgeo4w 32 bit) crashes
 qgis: anyone
 confirms? Sample raster available on request.
 Thanks.
 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)
 Comment: Using GnuPG with Icedove - http://www.enigmail.net/

 iEYEARECAAYFAlJflXAACgkQ/NedwLUzIr6STQCfZ/oZViEssXDHTynBmXMF8pP8
 2XwAni0T1q3dacxYhpYg/T1qiEEQ0hqP
 =1Bu5
 -END PGP SIGNATURE-
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Installing Processing problems

[Jonathan Moules]

Hi Paolo,
According to this just-closed ticket, I think (some of?) this stuff has
been resolved in future standalone builds:

http://hub.qgis.org/issues/8627#change-45754

Jonathan

On 17 October 2013 17:22, Paolo Cavallini cavall...@faunalia.it wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi all.
 I'm struggling to set up Processing, with saga, otb, and grass, on several
 machines,
 and I'm encountering a series of issues:
 * on Win, I had to install osgeo4w 32 bit to have OTB; this resulted in a
 series of
 problems in autoconfig of Processing, solved by removing the standalone,
 the registry
 keys, and activating the saga 2.0.8 compatibility option
 * on osx, grass is not found, even if the path seems correct
 * on Ubuntu 13.04, running grass from processing freezes QGIS
 * on Debian Wheezy saga is not available.
 I think we still have something to improve to make life easier for our GIS
 analysts.
 Any hint welcome, available for testing.
 Thanks.
 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)
 Comment: Using GnuPG with Icedove - http://www.enigmail.net/

 iEYEARECAAYFAlJgDtcACgkQ/NedwLUzIr5VQQCfeOG08RUZYjgJtRE6uTszP8Bn
 hbIAniTN/dFWtCQOSTQZPFmZnRlR0pB3
 =RqzN
 -END PGP SIGNATURE-
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2 64bits, is it stable ?

[Jonathan Moules]

  maintainance costs, for which it is always difficult to find funding.
  We need more unit test, more code quality dashboards and much stricter
 rules
  relative to what code has to be accepted into master.

 I think this is a matter of balance: a large part of QGIS success is due
 to the huge
 number of new functions and developers that keep on coming. Setting up to
 srtict
 rules will dry up our main source.


I have to respectfully disagree with the premise behind this. I'm sure
ease-of-committing has facilitated much of the development, but at a
certain point in a popular project's life it should become mature - unit
tests, code reviews, etc. This will make it harder to commit that cool new
tool that someone hacked up over the weekend, but you know that when it is
committed and approved, it is a lot less likely to break something else.

Yes QGIS is almost undoubtedly the most popular FOSS GIS on the planet, but
it will struggle to maintain that reputation if lots of users start
encountering regressions and bugs and crashes.


  A PostgreSQL-like code inclusion workflow, with commitfest and review,
 could be
  something interested, to be discussed.

 IMHO a desktop program is a totally different beast from a server one.
 Unit testing
 for atomic functions is relatively easy, it can be a nightmare when you
 have very
 complex user interactions.


Maybe the question should be - how do other successful Open Source desktop
applications do it? Could QGIS not find some other projects that release
regular relatively bug-free builds and ask them what their process is? QGIS
isn't the first project to encounter these problems; it can learn from
others. I don't know the answers which is why I'm posing them as questions
- but maybe someone else does.

Cheers,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2 64bits, is it stable ?

[Jonathan Moules]

 The stability of the current release is heavily influenced by
 increasing the major version number. What I mean with this is, that
 because for the next release only the minor number will increase, I
 expect it to be to be more stable and not less. Regardless of testing.

 Agreed, the new features should be expected to have bugs in, but with a
proper testing regime the regressions should be fewer as they'd get picked
up and the commit wouldn't/shouldn't be accepted until they're fixed.
You're right it won't cure everything, but it would mitigate a good chunk
of one subset of bug type.

Let me quote Martin Grässlin I rather use a working system without unit
 tests than a system with unit tests that doesn’t work

It sounds good, but it's a false dichotomy - why can't you have both?

Regards,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2 64bits, is it stable ?

[Jonathan Moules]

  It sounds good, but it's a false dichotomy - why can't you have both?

 because of limited resources. if all the 1.000.000+ users of QGIS would
 invest 1 euro
 per year in it, this would be quite feasible.
 All the best.


True, but that's back to my comment previously about what other projects do
- there's bound to be OS software out there that also has very limited
resources (most aren't supported by RedHat or IBM) yet manage a more
rigorous testing regime. What could be learnt from them? Staying within the
very-niche GIS world I know the GeoServer devs also complain about limited
resources (it appears to have far fewer committers than QGIS), yet they
have a unit-test requirement for all patches/commits and regular bugfix
releases. I know it's not like-for-like, but it's indicative of what might
be accomplished.

Kind regards,
Jonathan

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2 64bits, is it stable ?

[Jonathan Moules]

Assuming it's not already done, I'd suggest that requiring Unit Tests for
all new features should be mandatory for a Pull Request/patch to be
accepted into QGIS. In the long term that would hopefully help alleviate
the significant number of regressions that we're seeing in 2.0.

Jonathan

On 3 October 2013 11:51, Régis Haubourg regis.haubo...@eau-adour-garonne.fr
 wrote:

 Hi Matthias. agreed.
 How to fund, this is the question. I have budget (at least at the moment).
 I haven't been able to spend it completly in 2.0 release sprint because all
 goes too fast for classical contract, where I'm constrained to pay for a
 specific work (debug or feature).
 Please be warned to public finances are not good in europe, and every
 unconsumed budget can be erased.
 Sponsoring should be a way to finance infrastructure consolidation, but in
 current rules, sponsoring can't be oriented.

 I need help from the community to have a serious real use case unit test
 suite. I'm ready to fund a part if PSC gives an infrastructure and a
 manager. If no work canvas is given, I'm sure I won't have any successfull
 commercial proposal to such a funding.

 I also kindly ask other funders to systematically include unit test
 developpement for every new feature.

 Again today, I found 3 regressions, hard to find. I thought once 2.0 was
 out, I could spend less time testing, and more time working. It's still not
 the case.

 Again, you gave a lot unpaid work, when I was struggling to find a way to
 spend some..
 Hope we'll find a way.
 Régis




 --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/QGIS-2-64bits-is-it-stable-tp5081507p5081586.html
 Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Oracle connection dialog broken in 64 bit 2.0.1-2 ?

[Jonathan Moules]

Hi Régis,
  Windows x64 2.0.1-2 install here - the Oracle dialog works fine. I didn't
use the OSGEO installer but instead used the standalone one. Worth trying
that?
Cheers,
Jonathan


On 2 October 2013 08:47, Régis Haubourg regis.haubo...@eau-adour-garonne.fr
 wrote:

 Hi,
 Oracle connection dialog does not show in 64 bits version (revision
 d94c044,
 gdal 1.10), installed with OSGEO4W here.
 I get a error message Impossible to obtain Oracle selection dialog from
 provider.
 32 bits versions does well (revision 341139bc, gdal 1.9.2).

 Something wrong only on my system? If someone can reproduce, I will open a
 ticket.
 Régis



 --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/Oracle-connection-dialog-broken-in-64-bit-2-0-1-2-tp5081363.html
 Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] QGIS 2.0 in Portable App

[Jonathan Moules]

This is probably better placed on the developer list (cc'd).
However I believe I read a message on there suggesting it was being ported
over.

Jonathan



On 3 October 2013 04:01, maning sambale emmanuel.samb...@gmail.com wrote:

 Has anyone tried using QGIS 2.0 in USB Portable App [0]?
 There are instructions and build with QGIS 1.8 here [1].

 [0] http://portableapps.com/
 [1]
 http://cyclatron.users.sourceforge.net/menuitem-howto-soft-alterations/7-article-howto-softalteration-qgisportable-1-8
 --
 cheers,
 maning
 --
 Freedom is still the most radical idea of all -N.Branden
 wiki: http://esambale.wikispaces.com/
 blog: http://epsg4253.wordpress.com/
 --
 ___
 Qgis-user mailing list
 qgis-u...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-user


-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer