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] [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] 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-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] 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&SERVICE=oGMQJLiHSupcMsIjmfMWZQISJOeWgvtonUKYRXwmroNKJMFRYPEnEZPkowATaGjkELTRHGnDntktuVJGaLGTcBeUUJdggwCZNQVmwtAGVOJnxxYRNoCsJqtRfbPjwKjegCwdCLmaYrUVJabXtdkmZeHXsNLjhpdJhbQOYeXwwOIZwVROYYKwXRZxkjXoeGJvmswRUKPNRMhLLkMQtoLmSfPNrQXYHtuPEuKpFIpFccNsEgRbYndKFXiFpnZqJERjSJreOgtxNGcisVVbPVvfplvDRyRbsKbFnPcmlliuCAyoDmYOffSDlAWUApgewpAiJXXdwLDDYbkPaAiqMNkqPfqkIBxhirwdeQEQmTtBeDYIbGYNbGKPxSOYDRhgiGrGPElskHmqCCUaETOPHTPEXMArEpPNYZyJoChNatgYaPfcqIRjwCwDkmMVgUdlxGWgqXxGZwrgeantfXPvxkacZQLKPwlemJfeOuvIVfZrBiwWtIoybuuQAqapuFJBDuZHtMlaIJemxOjPiefmgMSXOpoSwFAipLYwqVApjJtmbOqUBORkfqesknejRvSFQwmCYlHigIZNpBIAINfVVUxtjHekDrJMdYVNgAiZUNUYSnbSyPrFTWiYmrnFUcqnteOMEogsxDXMlbNLBcMCLwDZJCQLblDTElqcWxmcoKiZGBPqTJuSjIPimsfYklNdmIcnwsGdESbaOhtvVwRcoFIKAAninLCqKfsKFXqDfEwNCkXXRFvbcjnXggYywEynhweSdrvbCngwJtceGDAOlQQqCBhgjHmcuSrCUKwBJOeEToYIhTQCgEdBVpIlCYmIBPsNPLIedfITOfincEBqLscQJNktKIvpfgkQFhLOtiyslSKdGkjCCnYYDNVBrTDJsYxELKJcXlJLUMTBOChSpTsfgZMqKtXLkbMOnulrWQLJhwIElLJZhnQDjfmUvsDiVDAEavsGhUXSYlxbPROgZQElKUIXNBGEmducbcREVLjNoZvlNpxcWnVwhNlKOfSZBREGUZXLRfhEloTuZLPphUaEPpydHoHpcNKhVjqsKfQofaaVTAfDwXoUWQtmQaRSAEdwxCdIqllTvObUFcsdyfGqHRQFDGFvHUdeNuTWhIbgDhcTGnJBTxytfHWvQNjSqSGCBDGNPQJaclWFUHPIjAkbvDxRtqFjwtoVOtfYkbiKVbqcphyngrfcxLkGQpHjSldaqekhLoAYGbkXHdnyeKIraNcalFLUvrEKSVYoNpGoZHrKpDckZJSnPHiMIeaOrTCKRWbNcrSDrddeVIqSfSRIILuZpYnpFLJCyYxVGnRonXgCSEqQXcZreffnyaFvkaFcJyyuCivsGMHGhVViEetLWxPEnFsFGuuHFmlIJCtoyyikChSxeMrKxhZoQanBBfexwUjsjAiLUOLnhYmlyuJlsENAoMDiFbbrcfpXeyqnkJOgmCwYakTGegcbpywwAVYJSQtblnWZhfccMksXoHhkXqqbZxYgAsNwPGbJukfaGZakiImInKPoSwvCXXvpqawURRpUmaebduvgDnAYGUmhCcQGkTKqlKVoGumDuDFgpbhcyRgpnVkuymNFsMRChKBFFyBKJNkcNqTEHKHrJdECHYMnWBjJiVqaXBEJQDjoZyjNFwumfShWeeRoqwIDfYSckglinPSgDvJlFxfLtWmiYTrhVSFRQOjdZKdQRhnmpSXVvQLadJpviByssOKIrjpysnXvXHAvRKrIcGEvsvhWEmZkGKPBcFFmmjtQJQZxZIcTVmFWHEUOEejYvOjNrbqYvPaJxbTyucvdMDohGynKrodTGyRJcuMBdFPNFsPbmEQDiXeCBwPHAGvawOvBTlXoMijuSUalSrftFWCHatRoivbehiDtLbRJUItnteqdEMNdrHsqAwgiCMOPDIVCmovSVTLxkclkmBCuVpIAMJtmkdkkHIklamiCQLqtfkhhUkSocYtbQFOJXvaPBBmFWHIvwZHvnGYeaMxdGKwQjLaVvYevVyLQbWlTmKUQlkoOrQNMXdmPbTKgfXRhdoaqQapCNpsCJXvnFXBvXQemkXOdIyCpRptiJllMSdFsIjlywGJOWbpInDLB&VERSION=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] 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&SERVICE=oGMQJLiHSupcMsIjmfMWZQISJOeWgvtonUKYRXwmroNKJMFRYPEnEZPkowATaGjkELTRHGnDntktuVJGaLGTcBeUUJdggwCZNQVmwtAGVOJnxxYRNoCsJqtRfbPjwKjegCwdCLmaYrUVJabXtdkmZeHXsNLjhpdJhbQOYeXwwOIZwVROYYKwXRZxkjXoeGJvmswRUKPNRMhLLkMQtoLmSfPNrQXYHtuPEuKpFIpFccNsEgRbYndKFXiFpnZqJERjSJreOgtxNGcisVVbPVvfplvDRyRbsKbFnPcmlliuCAyoDmYOffSDlAWUApgewpAiJXXdwLDDYbkPaAiqMNkqPfqkIBxhirwdeQEQmTtBeDYIbGYNbGKPxSOYDRhgiGrGPElskHmqCCUaETOPHTPEXMArEpPNYZyJoChNatgYaPfcqIRjwCwDkmMVgUdlxGWgqXxGZwrgeantfXPvxkacZQLKPwlemJfeOuvIVfZrBiwWtIoybuuQAqapuFJBDuZHtMlaIJemxOjPiefmgMSXOpoSwFAipLYwqVApjJtmbOqUBORkfqesknejRvSFQwmCYlHigIZNpBIAINfVVUxtjHekDrJMdYVNgAiZUNUYSnbSyPrFTWiYmrnFUcqnteOMEogsxDXMlbNLBcMCLwDZJCQLblDTElqcWxmcoKiZGBPqTJuSjIPimsfYklNdmIcnwsGdESbaOhtvVwRcoFIKAAninLCqKfsKFXqDfEwNCkXXRFvbcjnXggYywEynhweSdrvbCngwJtceGDAOlQQqCBhgjHmcuSrCUKwBJOeEToYIhTQCgEdBVpIlCYmIBPsNPLIedfITOfincEBqLscQJNktKIvpfgkQFhLOtiyslSKdGkjCCnYYDNVBrTDJsYxELKJcXlJLUMTBOChSpTsfgZMqKtXLkbMOnulrWQLJhwIElLJZhnQDjfmUvsDiVDAEavsGhUXSYlxbPROgZQElKUIXNBGEmducbcREVLjNoZvlNpxcWnVwhNlKOfSZBREGUZXLRfhEloTuZLPphUaEPpydHoHpcNKhVjqsKfQofaaVTAfDwXoUWQtmQaRSAEdwxCdIqllTvObUFcsdyfGqHRQFDGFvHUdeNuTWhIbgDhcTGnJBTxytfHWvQNjSqSGCBDGNPQJaclWFUHPIjAkbvDxRtqFjwtoVOtfYkbiKVbqcphyngrfcxLkGQpHjSldaqekhLoAYGbkXHdnyeKIraNcalFLUvrEKSVYoNpGoZHrKpDckZJSnPHiMIeaOrTCKRWbNcrSDrddeVIqSfSRIILuZpYnpFLJCyYxVGnRonXgCSEqQXcZreffnyaFvkaFcJyyuCivsGMHGhVViEetLWxPEnFsFGuuHFmlIJCtoyyikChSxeMrKxhZoQanBBfexwUjsjAiLUOLnhYmlyuJlsENAoMDiFbbrcfpXeyqnkJOgmCwYakTGegcbpywwAVYJSQtblnWZhfccMksXoHhkXqqbZxYgAsNwPGbJukfaGZakiImInKPoSwvCXXvpqawURRpUmaebduvgDnAYGUmhCcQGkTKqlKVoGumDuDFgpbhcyRgpnVkuymNFsMRChKBFFyBKJNkcNqTEHKHrJdECHYMnWBjJiVqaXBEJQDjoZyjNFwumfShWeeRoqwIDfYSckglinPSgDvJlFxfLtWmiYTrhVSFRQOjdZKdQRhnmpSXVvQLadJpviByssOKIrjpysnXvXHAvRKrIcGEvsvhWEmZkGKPBcFFmmjtQJQZxZIcTVmFWHEUOEejYvOjNrbqYvPaJxbTyucvdMDohGynKrodTGyRJcuMBdFPNFsPbmEQDiXeCBwPHAGvawOvBTlXoMijuSUalSrftFWCHatRoivbehiDtLbRJUItnteqdEMNdrHsqAwgiCMOPDIVCmovSVTLxkclkmBCuVpIAMJtmkdkkHIklamiCQLqtfkhhUkSocYtbQFOJXvaPBBmFWHIvwZHvnGYeaMxdGKwQjLaVvYevVyLQbWlTmKUQlkoOrQNMXdmPbTKgfXRhdoaqQapCNpsCJXvnFXBvXQemkXOdIyCpRptiJllMSdFsIjlywGJOWbpInDLB&VERSION=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]

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

[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] 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 W

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&REQUEST=GetCapabilities&VERSION=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,

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&REQUEST=GetCapabilities&VERSION=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

[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] 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&gas 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".
* "Sho

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

[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

[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

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 l

[Qgis-developer] Displacement and SLD's

[Jonathan Moules]

Hi List,
  We've contracted some work on GeoServer to try and get the SLD 1.1
"displacement" tag implemented, because we wanted to replicate the sort of
results you can get in QGIS 1.8 here with the SVG filled green areas:
http://hub.qgis.org/wiki/quantum-gis/OS_Styles

Those are QML files, but QGIS allows them to be exported as SLD.

So my question is - how should that style be created with SLD's? Does QGIS
does it "properly"? Andrea (who's implementing it), has noted that
displacement alone can't do this, so has proposed a solution which would
work, but would require an SLD file different from the one that QGIS 1.8
exported. His proposed solution is:
https://jira.codehaus.org/browse/GEOS-5794?focusedCommentId=324800#comment-324800

What is the QGIS solution to this? Does it implement it at all from an SLD
file? When I try and load the SLD it saves back into QGIS, I encounter a
QGIS bug (http://hub.qgis.org/issues/7759), so can't actually confirm it.

I ask because I think one common implementation concept would be better
than multiple divergent incompatible ones as QGIS is used by some people to
style SLD's for GeoServer.

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] [Qgis-user] New Icons - difficult to "read"

[Jonathan Moules]

+1

i.e. The difference between the "Add PostGIS layers" and "Add SpatiaLite
layers" is that one has a regular cylinder and the other has a fat-waisted
hour-glass cylinder - about 20-30 pixels are different in an icon that's
got 1024 pixels! I have to look at them in detail to see the differences.
And there's still MSSQL and Oracle icons to be created in the new schema
which using this system will only confuse things more.


Don't get me wrong, I like the style of the new icons, but they're really
hard to visually differentiate.


I did a quick google and came across this:
http://turbomilk.com/blog/cookbook/icon_design/10_mistakes_in_icon_design/

The QGIS icons do all of the top three things.

Jonathan





On 24 May 2013 09:27, skampus  wrote:

> that could be a useful option.
> sincerely, from my point of view, many icons are
> unreadable/undistinguishable so i click them correctly only because now i
> remberer relative position
>
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Re-Qgis-user-New-Icons-difficult-to-read-tp5055427p5055467.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] New Icons - difficult to "read"

[Jonathan Moules]

Hi Marco,
I'm afraid I respectfully disagree. A "short adaptation period" won't make
the icons more obvious.

I'm not a big QGIS user. If I want to use /any/ function in QGIS, I have to
stare at the icons and use the tooltips to figure out what button does
what, so I'm not "adapted" to the 1.8 set, let alone the 2.x ones.

That said, when I look at the 2.0 set what I see is many icons that are
almost identical. Any icon that is only ~3% different from its neighbour
(i.e. the database ones) is never going to be any good for its purpose. I'd
imagine people with a visual impairment may struggle even more.

Also remember, not all users navigate by knowing where the buttons are (in
fact, most don't). For those users you *have* to have a good set of icons
that are easily differentiated at a glance.

I think colour would be a start, but the designs themselves are still too
similar.

I think resolving this in time for the 2.x release makes sense. Otherwise
those who do learn these icons will have to re-learn them for 2.1. It
doesn't make sense to change something as fundamental as the iconography
twice in as many releases.

Just my 2p.

Kind Regards,
Jonathan


On 24 May 2013 13:23, Marco Bernasocchi  wrote:

> Agree as well with Werner and Anita.
> It is just matter of a short adaptation period.
>
> Ciao
>
>
> On 05/24/2013 01:34 PM, Anita Graser wrote:
>
>> Hi,
>>
>> -1. I agree with Werner. Having used the "gis" icon set for many months,
>> I have problems using the old ones. That's just how the human mind works.
>> Let's improve the "gis" icons where it makes sense but let us focus or
>> work on one set.
>>
>> Best wishes,
>> Anita
>>
>>
>>
>> On Fri, May 24, 2013 at 1:14 PM, Werner Macho > <mailto:werner.ma...@gmail.com**>> wrote:
>>
>> Hi!
>>
>> -1 for keeping the old Icons..
>>
>> I'd rather vote to probably leave them for 2.0 but get rid of them
>> afterwards.. It does not make any sense to have different sets of
>> icons ..
>> And as GRASS is using the same icon set in their GUI it does indeed
>> make sense to use it probably in every open source GIS ..
>>
>> I know that the first time might be hard but that"s just the usual
>> human behaviour of refusing new things.
>> But for e.g. I am working with the new icon set since a very long
>> time (to use GRASS and QGIS in parallel) and I can find everything
>> at once but rather have some kind of problems when I switch to the
>> old ones..
>>
>> So I know that I could adapt myself to the old iconset within a few
>> days .. It"s just human that every "more work" you have to do gets
>> refused at first regardless of the advatnages it might bring later
>>
>> So maybe for a period of migration I"d leave the old icons inside
>> but definitely not for 2.1 or later ..
>>
>> OF course that all is just my personal experience and opinion
>>
>> kind regards
>> Werner
>>
>>
>>
>>
>> On Fri, May 24, 2013 at 12:15 PM, Duarte Carreira > <mailto:dcarre...@edia.pt>> wrote:
>>
>> I would like to ask the “powers that be” to keep the old and
>> trusted icons. They never failed me and the gui is quite
>> uplifting. The new set may be technically better but is not as
>> friendly to users.
>>
>> Please keep both.
>>
>> Duarte
>>
>> *De:*Jonathan Moules 
>> [mailto:jonathanmoules@**warwickshire.gov.uk
>> 
>> <mailto:jonathanmoules@**warwickshire.gov.uk
>> >]
>> *Enviada:* sexta-feira, 24 de Maio de 2013 09:59
>> *Para:* skampus
>> *Cc:* qgis-u...@lists.osgeo.org
>> <mailto:qgis-user@lists.osgeo.**org >;
>> qgis-developer@lists.osgeo.org
>> 
>> <mailto:qgis-developer@lists.**osgeo.org
>> >
>> *Assunto:* Re: [Qgis-user] [Qgis-developer] New Icons -
>>
>> difficult to "read"
>>
>> +1
>>
>> i.e. The difference between the "Add PostGIS layers" and "Add
>> SpatiaLite layers" is that one has a regular cylinder and the
>> other has a fat-waisted hour-glass cylinder - about 20-30 pixels
>> are different in an icon that's got 1024 pixels! I have to look
>> at them in detail to see the differences. And there's still
>> MSS

Re: [Qgis-developer] New Icons - difficult to "read"

[Jonathan Moules]

+1 for unified data adding button. From a use-perspective there's no good
reason that raster adding should be separate from vectors for instance.


Relating to the new iconset - I agree with liking the style and see what
it's trying to do. The design philosophy seems to be that there are common
components which are then glued together. A yellow star seems to mean
"new", a magnifying glass means some sort of zoom thing etc.

It's logical, the sort of thing that makes sense to a developer.

The problem is, I don't believe it works. Icons should be
immediately recognisable - if you have 10 (TEN!) icons which have a big
magnifying glass and then only a small portion of the icon is different
between each of them, they become harder to use.

In depth example: take the Back, Next, and Refresh view icons. The new QGIS
icons all have a magnifying glass behind them (I can barely make out the
"refresh" circle). Why? In comparison, I have four web-browsers in front of
me, all have these buttons and all of them are simple arrows/refresh
circles. None of them have a picture of a web-page behind them.
ArcGIS and MapModeller both use simple arrows/circles too. MapInfo doesn't
seem to have this functionality.
At this point these icons are standard conventions, but the QGIS 2.0
iconography makes that part only 1/6th of the actual icon, instead giving
prominence to a magnifying glass that's entirely unnecessary.

Jonathan

On 27 May 2013 23:11, Antonio Locandro  wrote:

> Just a thought, but most of the problems are due to the fact each *add
> feature* has an icon for "quick access". I would simply vote to have an
> unified add data button and then select the data you want, someone has
> proposed something about it but don´t know if it will make it for 2.0 nor
> do I remember the exact reference. IMHO QGIS has way to many icons
> cluttering the UI and using precious space specially on small screen laptops
>
> *Ing. Antonio Locandro*
> Tegucigalpa, Honduras
> +504 9503 5747
> Need a GPS map for Central America, Asia or South America / Necesitas un
> mapa GPS para Centro America, Asia o Sur 
> America
>
>
>
>
> > Date: Mon, 27 May 2013 23:07:16 +0200
> > From: rob...@szczepanek.pl
> > To: li...@linfiniti.com
> > CC: qgis-developer@lists.osgeo.org
> > Subject: Re: [Qgis-developer] New Icons - difficult to "read"
>
> >
> > Hi Tim,
> >
> > On 25.05.2013 11:06, Tim Sutton wrote:
> > >
> > > @Robert - what about using a background colour scheme whereby e.g. all
> > > add layer icons get the same background colour and then you can remove
> > > e.g. the + and layer picture elements as they are visually grouped.
> > > Just a thought anyway
> >
> > This is an interesting idea, but I'm afraid hard to implement. We could
> > get very strange mixture of colours (location of icons changes...). We
> > could also make one background colour per toolbar. But there are several
> > toolbars and we (man) - in opposite to women - don't recognize so many
> > colours :)
> >
> > Maybe simply skip some icon elements in toolbars, with many similar
> > operations (like add layer)?
> > regards,
> > Robert
> > ___
> > 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] New Icons - difficult to "read"

[Jonathan Moules]

Hi Anita,

> I think we have to be fair and recognize that a GIS is a little more
> complex than a web browser and will always have more buttons. Many
> functions which have only one meaning in a simpler application can have
> different meanings in a GIS depending on context. To simply assume the
> context from the placement in a certain toolbar could raise other issues.


Fair point, but that's why I also compared other GIS's where I could
(ArcGIS, MapModeller (FME Data Inspector uses the refresh circle but
doesn't have a back/forward feature) and noted that they hold the same
convention.
Also, that was only one single example, there are others.
These days people *expect* certain icons for certain things. To use a
different icon throws away the years of pre-training the user will have
already have using other applications that stuck to the convention.

I don't think I've ever seen a single application that had 10 icons that
were mostly the same before in the same that the magnifying glass ones in
QGIS 2.0 are.

Regards,
Jonathan

On 28 May 2013 11:11, Anita Graser  wrote:

> Hi,
>
> On Tue, May 28, 2013 at 11:23 AM, Jonathan Moules <
> jonathanmou...@warwickshire.gov.uk> wrote:
>
>> +1 for unified data adding button. From a use-perspective there's no good
>> reason that raster adding should be separate from vectors for instance
>> In depth example: take the Back, Next, and Refresh view icons. The new
>> QGIS icons all have a magnifying glass behind them (I can barely make out
>> the "refresh" circle). Why? In comparison, I have four web-browsers in
>> front of me, all have these buttons and all of them are simple
>> arrows/refresh circles. None of them have a picture of a web-page behind
>> them.
>> ArcGIS and MapModeller both use simple arrows/circles too. MapInfo
>> doesn't seem to have this functionality.
>> At this point these icons are standard conventions, but the QGIS 2.0
>> iconography makes that part only 1/6th of the actual icon, instead giving
>> prominence to a magnifying glass that's entirely unnecessary.
>>
>
> While I agree to some degree (+1 for unified data adding button), I think
> we have to be fair and recognize that a GIS is a little more complex than a
> web browser and will always have more buttons. Many functions which have
> only one meaning in a simpler application can have different meanings in a
> GIS depending on context. To simply assume the context from the placement
> in a certain toolbar could raise other issues.
>
> Best wishes,
> Anita
>
> ___
> 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] Navigation toolbar

[Jonathan Moules]

Hi Andreas,

On 2 July 2014 08:40, Andreas Neumann  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

[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  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 
>> 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] [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  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 :
>
> > 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

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  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 :
> > +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 Jürgen,

Fixes and features are released every four months - including a four weeks
> window for testing and fixing.  Which is of course not as good as LTS, but
> it's apparently feasible and working.


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 should be introduced. Everyone wants QGIS to be stable of
course, but adding new features by definition isn't going to be compatible
with that - New features introduce new bugs irrespective of the amount of
testing there is. It's far less common (but by no means unknown) for a
bugfix to introduce a new bug.

I don't know the story of why having two branches failed in the past, but
the fact that this topic is raised every couple of months by new people
should indicate that there's a strong desire for it within the community,
so maybe it's worth investigating again.
What caused it to fail last time? Is there anything the community can learn
from that? Can QGIS learn from any of the other Open Source communities
that successfully maintain multiple branches? What resources are needed to
make it happen?

Cheers,
Jonathan


On 22 July 2014 11:16, Jürgen E.  wrote:

> Hi Lene,
>
> On Mon, 21. Jul 2014 at 15:35:55 +, Lene Fischer wrote:
> > 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??..
>
> Not much news there.  This comes up again and again.
>
> We already tried to maintain two branches in the past and failed.  I'm not
> sure
> if we still would, but I don't see any big changes that makes it less
> likely
> either.
>
> And that's why we have the tight release schedule now - it's there to both
> get
> bugfixes out and new features in in a reasonable time frame and with
> minimum
> extra or duplicate effort (which backports and packing are - not a awful
> lot,
> but some).
>
> Fixes and features are released every four months - including a four weeks
> window for testing and fixing.  Which is of course not as good as LTS, but
> it's
> apparently feasible and working.
>
>
> 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
>
> --
> 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 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

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  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] 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  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.dk


[SCIENCE_bomaerke_UK]




-Oprindelig meddelelse-
Fra: 
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 
mailto: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.org

http://lists.osgeo.org/mailman/listinfo/qgis-developer


This message has been scanned for viruses by 
MailControl, a service from BlackSpider Technology

Click 
here
 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 
mailto:apaso...@gmail.com>> wrote:
2014-10-10 14:44 GMT+02:00 Jürgen E. mailto: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.it
___
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, a service from BlackSpider Technology

Click 
here
 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] 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 
MailControl, a service from BlackSpider Technology

Click 
here
 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 
MailControl, a service from BlackSpider Technology

Click 
here
 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  
> 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] 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 
forum
 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 
MailControl, a service from BlackSpider Technology

Click 
here
 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] 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

[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] User-contributed scripts/models for Processing

[Jonathan Moules]

As an author of some scripts, I think this feature is a great opportunities to 
easily share useful snippets. I am not sure though we made enough publicity 
around it. I fear only "power users" will have the idea to open the branches of 
processing toolbox and discover there is a Scripts / Tools / Get scripts from 
collection. I have no idea though how to improve this.

Especially as it’s a subitem under something that says “0 geoalgorithms”; that 
implies there’s nothing under there (it’s non-obvious that these are different 
things).

I’d suggest that a dedicated button for that functionality be added to the 
interface somewhere, probably under the “processing toolbox”.

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] 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.dk


[SCIENCE_bomaerke]


Fra: 
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.com
Cc: qgis-dev; Giovanni Manghi
Emne: Re: [Qgis-developer] Huge TIFF files - problem


Em 09/12/2014 07:43, "Alex Mandel" 
mailto: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 
MailControl, a service from BlackSpider Technology

Click 
here
 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 é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 
> 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] [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  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
>  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] [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" 
mailto: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  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

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, a service from BlackSpider Technology

Click 
here
 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 
mailto: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.org<mailto:Qgis-developer@lists.osgeo.org>
http://

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

Re: [Qgis-developer] Download stats : 558909 ?

[Jonathan Moules]

Ah, the impossible metric of knowing how many users there are.

Myself I'd guess that the number is (far?) too high for number of users.
I've probably downloaded 1.8 at least 10 times myself.
While Paulo is right organisations do only download one copy, this is
countered by the countless people who download it and:
1) Find it doesn't do what they want how they want - immediate delete.
2) Use it for their one-off task and delete it a few days later.

Number (1) in particular I think has a lot of people in it.
But the user count is probably still very high, so well-done to all the
devs!

If QGIS had a "check for update weekly" kind of feature, that'd give a much
better (though still not complete) count of number of users.

Regards,
Jonathan


On 7 June 2013 18:56, Borys Jurgiel  wrote:

> And, what is very strange, over 94% of the 558909 users don't use
> plugins...
>
> The most populat plugin (kudos to Victor) has 34k downloads:
> http://plugins.qgis.org/plugins/?sort=downloads
> ___
> 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] WFS Client skipping features?

[Jonathan Moules]

I'm not seeing this. My WFS is GeoServer 2.3.4. I've tried several layers
and they're all showing the right feature count.
Are you certain it's the client that's skipping?

Jonathan



On 31 July 2013 18:27, Giovanni Manghi  wrote:

> >  I am testing QGIS desktop WFS client against a QGIS WFS server and see
> >  that the client is skipping features - quite a lot in fact.
> >
> >  The server part seems to be fine as I can get all features to display
> >  when using FME viewer as a client.
> >
> >  Do others have similar issues? Are there open bugs on the WFS client
> >  regarding this? Any tips what I can do? Any hidden settings for limiting
> >  the number of features?
>
>
> I had files a ticket about a similar issue
>
> http://hub.qgis.org/issues/8287
>
> is the same issue or another one?
>
> cheers!
> ___
> 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 HF Accomodation

[Jonathan Moules]

Hi Peter,
  Just a thought, but what about the university's halls of residence?
That's what they're using for FOSS4G.

http://www.sussex.ac.uk/conferences/accommodation

Jonathan



On 7 August 2013 11:26, Peter Wells wrote:

> Hi Paolo,
>
> We've already taken some time to consider the locations carefully.
>
> -  Finding a venue to give up an appropriate room and for a reasonable
> price
> limited us to the University of Sussex's campus
> -  Google shows only a single hotel nearby
> -  The campus is on the outskirts of the town, far from restaurants, bars
> and other fun stuff
>
> We have also tried to keep costs as low as possible.  As people have
> already
> started making their accommodation arrangements and we have booked a number
> of venues for dinners throughout the long weekend in Brighton, it makes
> sense to stick to the current proposals.  If you manage to find better
> options, please let me know.
>
>
> Kind regards,
>
> Pete
>
>
> -Original Message-
> From: Paolo Cavallini [mailto:cavall...@faunalia.it]
> Sent: 07 August 2013 10:58
> To: peter.we...@lutraconsulting.co.uk
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: QGIS HF Accomodation
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Il 07/08/2013 11:17, Peter Wells ha scritto:
>
> > I've just made an update to the wiki page (accommodation section) with
> > distances of the hotels from Brighton rail station.  They range
> > between 0.1 and 1.0 miles (0.2 to 1.6km) from Brighton rail station.
> > As the venue is on the edge of the town (in the university campus), we
> > will either need to take a bus or a train there each morning, hence
> > why I've listed the distances from the rail station rather than the
> > venue.  From the rail station to the
> > venue:
> >
> > - By bus, 25mins - By train, 15mins
>
> Hi Pete,
> thanks for the clarification; having an hotel far from the HF venue proved
> a
> major hassle, and caused loss of productivity and fun: isn't it possible to
> find something closer to the University?
> Possibly something simpler and cheaper?
> All the best.
> - --
> 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/
>
> iEYEARECAAYFAlICGjsACgkQ/NedwLUzIr4qYACdFaJNhEDqf3Ags1sUO5TaDkbS
> s+QAn3MwVULJNseuZVrIWtyhBWUj9w99
> =l4Qn
> -END PGP SIGNATURE-
>
>
> --
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately
> by e-mail if you have received this e-mail by mistake and delete this
> e-mail from your system. If you are not the intended recipient you are
> notified
> that disclosing, copying, distributing or taking any action in reliance on
> the contents of this information is strictly prohibited.
>
> Whilst reasonable care has been taken to avoid virus transmission, no
> responsibility for viruses is taken and it is your responsibility to carry
> out
> such checks as you feel appropriate.
>
> Saber Razmjooei and Peter Wells trading as Lutra Consulting.
> ___
> 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] Renaming SEXTANTE

[Jonathan Moules]

On 12 August 2013 09:33, Paolo Cavallini  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Il 12/08/2013 10:10, Tim Sutton ha scritto:
>
> > Yes I should have asked this too - personally I prefer we do it in
> > a future version. Maybe its something we should keep for V3?
>
> IMHO renaming sextante after people got used to it will introduce more
> and more confusion. Better remove it now; deeper chamges in the UI can
> wait.
>
>
+1; And I think this philosophy should be carried over to the other plugins
mentioned in this discussion - that they should be renamed sooner rather
than later.
Everyone in this thread knows what all of these things do, but a regular
user isn't going to know what "GDAL" is, or "fTools" or "SEXTANTE". As an
example - just last week I was wondering where my spatial analysis
functions were that were in a tutorial I was following - turns out I'd
disabled the pointless-sounding-to-me "fTools" plugin and they were in
there.
(I'm still quite new to QGIS, but have a technical GIS background - a
non-technical user would have struggled to resolve that).

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] What's up with the 2.0.2 designation?

[Jonathan Moules]

As a user I'm very fond of the GeoServer model. I believe they have a
master branch which releases 2.x version every 6 months or so and includes
big features. Once a month they release a point release (2.3.x) which
contains bug fixes backported from the master branch as well as some lesser
"features" that have been in the master branch for a month or two.

This means there are regular releases and as I user I know what to expect
when. Much as I like both QGIS and GeoServer, both have a considerable
number of bugs and regular bug-fix releases help ameliorate this. Users
shouldn't be hitting the same bug in their stable release that was fixed in
master 12 months ago, that's something Open Source can do better than
"E$RI" (Hi Tim :-) ) and their commercial ilk.

Just my 2p,

Jonathan



On 26 September 2013 18:18, Marco Bernasocchi wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> > 2.1.0 will be a new feature release, will only come out when
> > enough features are included.
> IIRC 2.1.0 should be the dev branch, 2.2 will be the next release. At
> least this is what timlinux and jef were discussing in Brighton.
>
> ciao
>
>
> - --
> Marco Bernasocchi
> http://opengis.ch
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJSRGxvAAoJEOxelKxGjIJhHLwH/i6+EqC+XAe3F2c9SfTNQ17e
> 1mjhWlbCiT1PCs6pbhhmSpM+MX6LA4NTTxfbVHhWecp7NGZI3I1JH0+mCvITVlg8
> /98Rb0xHtEeNJK2UEQ2/r+KbniC5qiGF+eUB4JhZ04zij1nCV9UpXwz9dO9wZUsn
> emXw2kqX8f91IwtBYclgzff4hhrS/y7okoIcOfNSqXl4M/KdCOjbwEanB6Fz+jGL
> F9Nt+eGDJlnzmJqQCiE8IVS3RjfXKV2sRGUIMXzLpx39V6S7tkEGiUDwjNoxKOfE
> qrXOqqgBojiRkA+zxofmyY0snRsK4gXuqn1OW43edynS7mtRpQQjhV4a26D4Nqo=
> =BCZ8
> -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

[Qgis-developer] The case for bugfix releases

[Jonathan Moules]

Oops, this was meant to go to the dev list.


Hi List,
Following on from the other thread, I wanted to put forward the case
for bugfix releases. I missed the previous conversation and apologise for
rekindling it, but feel strongly on the subject so wanted to put forth my
reasoning.
The reason given for why QGIS doesn't as I understand it is lack of
resources.


I think by not using some developer resources on bugfixes, the cost of
not releasing regularly is passed on to the users and becomes considerably
inflated. There's also a hidden cost to developers who spend their time
interacting with users.

All of the following are consequences of irregular releases (there are
probably more):

- Users spend a considerable amount of time reporting a bug in stable
only to discover it's "fixed in master". This has happened multiple times
to me.

- Users are often asked to "please test this in master" when they
report a bug, forcing them to spend potentially much more time reporting
the same issue.

- There are countless threads in the user list where the final
conclusion is - "this is already implemented/fixed in master".

- All the time lost by users on stable as they hit bugs that are
already fixed in master.

---

Furthermore, regular releases are also part of the iterative cycle of
OpenSource development. With 2.x, a ton of new bugs have no doubt appeared
in the new features (I know you've all done lots to minimise this, but it's
inevitable). By releasing regularly the cycle of Bug Reporting ->
Development -> Release, can stay tight and efficient. As shown above that's
not the case currently.

The current cycle discourages users (well, at least it does me) from
reporting bugs except immediately after a release.

---

I do appreciate QGIS has finite developer resources, and while I don't
pretend to know/understand how the GeoServer/QGIS projects are structured,
it does seem that QGIS has considerably more developers (both core and
contributory) than GeoServer which does manage regular bugfix releases.

Maybe there's scope for optimising the release process, or issuing
patches rather than full releases, or something else, but that isn't my
area.

See also: https://en.wikipedia.org/wiki/Release_early_release_often

Just a thought from a bug-reporting non-developer,
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] The case for bugfix releases

[Jonathan Moules]

Interesting discussion.
Packaging isn't something I know much of anything about, but from a Windows
perspective, if there are bugfix releases, might it be worth releasing them
as patches/service packs rather than complete new releases? In a corporate
environment where software installation is scripted an entirely new release
needs to be scripted which can be a lot of effort and potentially can wipe
out a users preferences. Patches/service packs are a lot easier for the
user.
No idea how feasible that is.

>> Jonathan
> > I think by not using some developer resources on bugfixes,
> Jürgen
> Um, we bugfix.  We just don't do do stable/bugfix releases and master is 
> released
too infrequent.

Sorry, I meant "bugfix releases". I know you (and the others) bugfix and a
lot of my reported bugs are closed, reflecting that! :-)   - Despite
proofreading it a couple of times I still missed that.

Cheers,
Jonathan


On 30 September 2013 09:37, Andreas Neumann  wrote:

> Am 30.09.2013 10:30, schrieb Jürgen E. Fischer:
> > Hi,
> >
> > On Mon, 30. Sep 2013 at 08:53:06 +0200, Sandro Santilli wrote:
> >> Also, insisting in the production of binary makes the release process
> more
> >> complex than it could be. Binary packaging and source releases should be
> >> separate processes, IMHO.
> >
> > Any only else share the opinion that we should stop making packages and
> trust
> > that others will pick up?
>
> Probably not for the most popular platforms (Windows, OSX,
> Ubuntu/Debian). I hope that one day we will have enough donations to pay
> for the release and packaging work. Or maybe a commercial QGIS support
> company will have enough contract work that allows it to subsidize work
> and be responsible for the packaging of at least one of the major
> platforms. This way the packaging work could be better distributed.
>
> Andreas
> ___
> 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]

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

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

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

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  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). The

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  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] 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  wrote:

> Hi Alessandro,
>
> Am 30.12.2013, 13:54 Uhr, schrieb Alessandro Pasotti :
>
>> 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] OSM address search

[Jonathan Moules]

Hi,


> The implementation should be generic enough that we can add other data
>> sources.
>
> That would be very good. Ideally including the ability to use a WFS - then
organisations could use their already-extant WFS service to supplement (or
replace) OSM.

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] Plugins approval

[Jonathan Moules]

On 7 January 2014 08:04, Matthias Kuhn  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  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

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

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  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 
> *Para:* Nathan Woodrow 
> *CC:* "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  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 fr

[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] 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  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 :
>
> 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

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.  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] 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] 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.  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 th

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

[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] 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  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] D&D 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  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

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] 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 Sutton 
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] 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] 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&geo=IT&q=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] 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] 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&VERSION=1.0.0&REQUEST=GetCoverage&FORMAT=GEOTIFF_FLOAT32&COVERAGE=ahn3_5m_dtm&BBOX=1,25,356250,618750&CRS=EPSG:28992&RESPONSE_CRS=EPSG:28992&WIDTH=10&HEIGHT=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