Re: [Qgis-user] Creating ensemble and aggregates from netCDF

[Saber Razmjooei]

Hi Thiemo,

Have you tried to open your netcdf file as a mesh layer (as opposed to
Raster):
https://docs.qgis.org/3.16/en/docs/user_manual/working_with_mesh/mesh_properties.html

For basic calculations, you can use the mesh calculator in QGIS which has
aggregate functions. But for more advanced tools, I recommend CDO:
https://cds.climate.copernicus.eu/toolbox/doc/how-to/14_how_to_resample_and_aggregate/14_how_to_resample_and_aggregate.html

Kind regards
Saber

On Fri, 29 Jan 2021 at 07:30, Thiemo Kellner 
wrote:

>
> Hi all
>
> I have downloaded climate forecast raster data in NetCDF 3.6 format
> (https://nedlasting.nve.no/klimadata/kss) for a series of models and
> time resolution of one day. The data is one file per model.
> Eventually, I would like to have an ensemble file with aggregated data
> over the time axis, e.g. monthly or quarterly. Maybe it gets clearer
> when I just list some names of the files I have:
>
> rcp85_CNRM_CCLM_RR_daily_mm_2100.nc
> rcp85_CNRM_RCA_RR_daily_mm_2100.nc
> rcp85_EC-EARTH_CCLM_RR_daily_mm_2100.nc
>
> I expect all the files to have the same extent and resolution;
> gdalinfo excerpts of arbitrary two files https://pastebin.com/UtxXDDGp
> support my assumption.
>
> Being a complete noob, I assume that the ensemble would just be the
> arithmetic average, but I do not know how to average the "payload"
> axis of rasters over different layers nor over its time series/bands.
>
> I have not been able to find guidance on ecosia.org or the
> documentation and also tried to employ PostGIS for this, but I am
> stuck there as much as I am with QGIS.
>
> I heard that this was possible only with GRASS GIS but that its
> integration into QGIS was behind the required GRASS GIS version to do
> ensembles. Is that true and if so, would it be possible to place a
> bounty to have someone do the required integration?
>
> I would appreciate guidance very much.
>
> Kind regards
>
> Thiemo
>
> --
> S/MIME Public Key:
> https://oc.gelassene-pferde.biz/index.php/s/eJuAUFONag6ofnH
> Signal (Safer than WhatsApp): +49 1578 7723737
> Threema (Safer than WhatsApp): A76MKH3J
> Handys: +41 78 947 36 21 | +49 1578 772 37 37
>
>
> --
> S/MIME Public Key:
> https://oc.gelassene-pferde.biz/index.php/s/eJuAUFONag6ofnH
> Signal (Safer than WhatsApp): +49 1578 7723737
> Threema (Safer than WhatsApp): A76MKH3J
> Handys: +41 78 947 36 21 | +49 1578 772 37 37
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>


-- 
Saber Razmjooei
www.lutraconsulting.co.uk
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] Creating ensemble and aggregates from netCDF

[Thiemo Kellner]

Hi all

I have downloaded climate forecast raster data in NetCDF 3.6 format  
(https://nedlasting.nve.no/klimadata/kss) for a series of models and  
time resolution of one day. The data is one file per model.  
Eventually, I would like to have an ensemble file with aggregated data  
over the time axis, e.g. monthly or quarterly. Maybe it gets clearer  
when I just list some names of the files I have:


rcp85_CNRM_CCLM_RR_daily_mm_2100.nc
rcp85_CNRM_RCA_RR_daily_mm_2100.nc
rcp85_EC-EARTH_CCLM_RR_daily_mm_2100.nc

I expect all the files to have the same extent and resolution;  
gdalinfo excerpts of arbitrary two files https://pastebin.com/UtxXDDGp  
support my assumption.


Being a complete noob, I assume that the ensemble would just be the  
arithmetic average, but I do not know how to average the "payload"  
axis of rasters over different layers nor over its time series/bands.


I have not been able to find guidance on ecosia.org or the  
documentation and also tried to employ PostGIS for this, but I am  
stuck there as much as I am with QGIS.


I heard that this was possible only with GRASS GIS but that its  
integration into QGIS was behind the required GRASS GIS version to do  
ensembles. Is that true and if so, would it be possible to place a  
bounty to have someone do the required integration?


I would appreciate guidance very much.

Kind regards

Thiemo

--
S/MIME Public Key: https://oc.gelassene-pferde.biz/index.php/s/eJuAUFONag6ofnH
Signal (Safer than WhatsApp): +49 1578 7723737
Threema (Safer than WhatsApp): A76MKH3J
Handys: +41 78 947 36 21 | +49 1578 772 37 37


--
S/MIME Public Key: https://oc.gelassene-pferde.biz/index.php/s/eJuAUFONag6ofnH
Signal (Safer than WhatsApp): +49 1578 7723737
Threema (Safer than WhatsApp): A76MKH3J
Handys: +41 78 947 36 21 | +49 1578 772 37 37


smime.p7s
Description: S/MIME cryptographic signature


smime.p7s
Description: S/MIME Signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[Nyall Dawson]

On Fri, 29 Jan 2021 at 01:13, C Hamilton  wrote:
>
> Nyall,
>
> What you mention has merit, but I was not kidding about trying to keep a 
> plugin self contained for government use. To set up automatic downloading on 
> our networks would require PKI authentication and that opens up another can 
> of worms. I know how to deal with PKI because I already maintain plugins that 
> use authentication. It would be easier for our users to have them download a 
> data pack and have some manual installation process, but it is even easier if 
> the data is already a part of the plugin. The other option would be to 
> produce two different versions of the plugin. One for government use and the 
> other for community use, but my sponsor would probably frown on that and not 
> want me to use my time to maintain the community version.
>
> The author of timezonefinder has done a number of optimizations to provide 
> fast lookups. See
>
> https://timezonefinder.readthedocs.io/en/latest/3_about.html
>
> I wonder what the difference in time would be to use a gpkg and QGIS point in 
> polygon look up vs timezonefinder lookup. Will it be faster or slower? I'm 
> not sure without testing. What are your thoughts? I would choose the faster 
> of the two.

I'd certainly hope a dedicated GIS application can do this faster than
a random Python library :D

> I just converted the timezone data to a gpkg and its size is 102Mb. The data 
> size for timezonefinder using the same data set is 49Mb. The optimization in 
> timezonefinder can produce a maximum error of 1cm at the equator as they use 
> 32 bit ints for the data. It might actually be better to use the gpkg file, 
> but it is double in size. I will investigate using the gpkg data.

You may want to try a shapefile too, just in case...!

Nyall


>
> It seems to me that if a plugin requires a certain dataset to function then 
> that data should be included with it and not require an additional download, 
> but I understand the issues that this could cause so I am not sure of the 
> best way forward. For our use it is definitely better to include the data 
> with the plugin.
>
> I guess what I would like you to take from this conversation is that some 
> users have a completely different environment and face different challenges 
> then what you do when it comes to dealing with software. I wish that it was 
> easier for me to get QGIS acceptance in our workforce but ArcGIS still rules.
>
> Thanks for your ideas and all of the hard work that you do to keep QGIS 
> moving forward.
>
> I wish you all the very best!
>
> Calvin
>
>> Given that the size of the python library is almost entirely the size
>> of the timezone boundaries themselves, have you considered:
>> - avoiding the library entirely, and insteading using a standard
>> shapefile/gpkg/... of the boundaries and using QGIS vector layer
>> methods to determine the timezone for a point
>> - deferring the download of the boundary spatial data, so that it's
>> not supplied with the plugin but instead the plugin automatically
>> downloads it on first launch?
>>
>> This would avoid the need for the large size plugin, allowing it to be
>> supplied via the standard QGIS repo while still providing its full
>> functionality...
>>
>> Nyall
>>
>>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[David Strip]

  
  
On 1/28/2021 11:10 AM, C Hamilton
  wrote:

In
  thinking about it, if the data set is too large to include with
  QGIS, it might be worth having a simplified geometry data set
  included and if the user wants more precise data then they can
  download it and use it instead.
I was wondering this same question when this arrived in my mailbox.
It seems to me that one could achieve a very substantial reduction
in size (>90%?) while creating only a very small increase in the
error rate, as it seems these will only occur in areas where
boundaries contain very small scale details. I'll admit that have
not attempted an empirical test of this conjecture. 

  

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

Re: [Qgis-user] raster: calculate area

[chris hermansen]

Azzurra and list;

On Thu, Jan 28, 2021 at 2:31 PM Azzurra Lentini 
wrote:

> Hi List,
> I have a raster file DTM (altitude attribute in the pixels). I
> reclassified this raster in 4 classes of altitude and I need to calculate
> for each class  the area (in how many square meters is each different class
> extended).
> I can for example transform the raster file reclassified into a vector
> file and calculate the area, but is it possible to do without any
> vectorialization and so directly calculating it from the raster file?
>

You might wish to review the following link

https://gis.stackexchange.com/questions/52353/calculating-area-of-rasters-in-qgis

It suggests two approaches - using raster statistics to get the count by
classes and multiplying by the pixel area, or vectorizing, and points out
that in vectorizing you get "cluster areas", not just the total count of
pixels of each class.


-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] raster: calculate area

[Azzurra Lentini]

Hi List,
I have a raster file DTM (altitude attribute in the pixels). I reclassified
this raster in 4 classes of altitude and I need to calculate for each
class  the area (in how many square meters is each different class
extended).
I can for example transform the raster file reclassified into a vector file
and calculate the area, but is it possible to do without any
vectorialization and so directly calculating it from the raster file?

 Thanks, Azzurra

-- 
Lecturer GIS University "Roma Tre"
Consultant Environmental Risk Prevention and Hydrogeology
AZZURRA LENTINI
++
Italy Mobile Tel.: **(39) 338 24 40 676
++
SKYPE azzurrahydro
++

*azzurralent...@gmail.com *

*azzurra.lent...@uniroma3.it  *
++
*Par respect pour l'environnement,*

*n'imprimez ce mail qu'en cas d'absolue nécessité*
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[Richard Duivenvoorde]

On 1/28/21 7:10 PM, C Hamilton wrote:
> In thinking about it, if the data set is too large to include with QGIS, it 
> might be worth having a simplified geometry data set included and if the user 
> wants more precise data then they can download it and use it instead.

I downloaded the shape-with-oceans (ah and THAT one has those rectangles I 
talked about earlier :-) ): 
101Mb after exporting to geopackage, 68Mb after zipping that... 
For users sake: either add the 68Mb (Juergen? Others? Opinion) or (easier) let 
Tim put your plugin (including this data/module) on plugins.qgis.org

Regards,

Richard Duivenvoorde

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

Re: [Qgis-user] problem with python

[Richard Duivenvoorde]

On 1/28/21 9:52 PM, Richard Duivenvoorde wrote:
> DeprecationWarning: the imp module is deprecated in favour of importlib

Ah and to be clear, it is just a *Warning*, so not really a problem (untill it 
would be really removed in newer version (I'm on 3.9.1 and still fine :-) )

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

Re: [Qgis-user] problem with python

[Richard Duivenvoorde]

I've looked into this earlier. I see this also (often). This comes from the 
utils.py in core python:
DeprecationWarning: the imp module is deprecated in favour of importlib

See: https://docs.python.org/3/library/imp.html
to
https://docs.python.org/3/library/importlib.html

So seems doable fix, IF we know for sure that everybody is above Python 3.4

Regards,

Richard Duivenvoorde




On 1/28/21 7:04 PM, Luigi Pirelli wrote:
> are you are running from python console btw something external to qgis code? 
> and please give more detail about you qgis version.
> 
> Luigi Pirelli
> 
> **
> * LinkedIn: https://www.linkedin.com/in/luigipirelli 
> 
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli 
> 
> * GitHub: https://github.com/luipir 
> * Book: Mastering QGIS3 - 3rd Edition 
> 
> * Hire a team: http://www.qcooperative.net 
> **
> 
> 
> On Thu, 28 Jan 2021 at 18:33, Boaz Bar Ilan  > wrote:
> 
> 2021-01-28T19:26:26     WARNING    
> warning:C:/PROGRA~1/QGIS3~1.10/apps/qgis-ltr/./python\qgis\utils.py:792: 
> DeprecationWarning: the imp module is deprecated in favour of importlib; see 
> the module's documentation for alternative uses
>         
> 
> 
> what can be done ?
> 
> 
> thanks
> 
> 
> boaz
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org 
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user 
> 
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user 
> 
> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
> 

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

Re: [Qgis-user] pg_featureserv + OGC API Features + QGIS

[Thayer Young]

 Thanks for the update Richard! I am especially interested in whether or not 
Crunchy will bite on making pg_featureserv work with the native Vector Tiles 
functionality in QGIS!
https://github.com/CrunchyData/pg_tileserv/issues/79

-Thayer



Message: 5
Date: Thu, 28 Jan 2021 09:59:37 +0100
From: Richard Duivenvoorde 
To: "Qgis-user@lists.osgeo.org" 
Subject: [Qgis-user] pg_featureserv + OGC API Features + QGIS
Message-ID: 
Content-Type: text/plain; charset=utf-8

Hi All,

Some months ago I sent an email to this list with subject:
"Anybody playing with pg_featureserv + OGC API Features + QGIS?"
because I failed to make the play with each other at that moment...

Thanks to Stefan K (creating an issue) and Martin D (actual fix) see:
https://github.com/CrunchyData/pg_featureserv/issues/63
it is now supereasy to setup a OGC API/WFS 3 in front of your Postgis DB AND 
let QGIS talk to it!

Supercool!

Regards,

Richard Duivenvoorde


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

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[C Hamilton]

In thinking about it, if the data set is too large to include with QGIS, it
might be worth having a simplified geometry data set included and if the
user wants more precise data then they can download it and use it instead.

On Thu, Jan 28, 2021 at 10:22 AM Richard Duivenvoorde 
wrote:

> On 1/28/21 4:13 PM, C Hamilton wrote:
> > What you mention has merit, but I was not kidding about trying to keep a
> plugin self contained for government use. To set up automatic downloading
> on our networks would require PKI authentication and that opens up another
> can of worms. I know how to deal with PKI because I already
> maintain plugins that use authentication. It would be easier for our users
> to have them download a data pack and have some manual
> installation process, but it is even easier if the data is already a part
> of the plugin. The o
>
> Hi Calvin,
>
> What I 'think' Nyall meant was to add such data to QGIS itself? We already
> have a gpkg with the world countries on board (everybody know the easter
> egg: 'type world in the coordinate input' yes?).
> But... adding 102Mb to the QGIS installer is maybe too much :-) Or can you
> shrink that down to some smaller size/format?
> Also, not sure in which version this will show up then (and on what
> ancient QGIS version your government client is).
>
> If all fails, I'd accept Tim's proposal to get it uploaded on
> plugins.qgis.org via the backdoor/Tim...
>
> Regards,
>
> Richard Duivenvoorde
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] problem with python

[Luigi Pirelli]

are you are running from python console btw something external to qgis
code? and please give more detail about you qgis version.

Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Book: Mastering QGIS3 - 3rd Edition

* Hire a team: http://www.qcooperative.net
**


On Thu, 28 Jan 2021 at 18:33, Boaz Bar Ilan  wrote:

> 2021-01-28T19:26:26 WARNING
> warning:C:/PROGRA~1/QGIS3~1.10/apps/qgis-ltr/./python\qgis\utils.py:792:
> DeprecationWarning: the imp module is deprecated in favour of importlib;
> see the module's documentation for alternative uses
>
>
>
> what can be done ?
>
>
> thanks
>
>
> boaz
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] problem with python

[Boaz Bar Ilan]

2021-01-28T19:26:26 WARNING
warning:C:/PROGRA~1/QGIS3~1.10/apps/qgis-ltr/./python\qgis\utils.py:792:
DeprecationWarning: the imp module is deprecated in favour of importlib;
see the module's documentation for alternative uses



what can be done ?


thanks


boaz
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[C Hamilton]

Richard,

If the map is simplified, then you lose precision, but it would be
wonderful if a gpkg of the time zones could be added to QGIS. Here is the
time zone map data.

https://github.com/evansiroky/timezone-boundary-builder

Calvin






On Thu, Jan 28, 2021 at 10:22 AM Richard Duivenvoorde 
wrote:

> On 1/28/21 4:13 PM, C Hamilton wrote:
> > What you mention has merit, but I was not kidding about trying to keep a
> plugin self contained for government use. To set up automatic downloading
> on our networks would require PKI authentication and that opens up another
> can of worms. I know how to deal with PKI because I already
> maintain plugins that use authentication. It would be easier for our users
> to have them download a data pack and have some manual
> installation process, but it is even easier if the data is already a part
> of the plugin. The o
>
> Hi Calvin,
>
> What I 'think' Nyall meant was to add such data to QGIS itself? We already
> have a gpkg with the world countries on board (everybody know the easter
> egg: 'type world in the coordinate input' yes?).
> But... adding 102Mb to the QGIS installer is maybe too much :-) Or can you
> shrink that down to some smaller size/format?
> Also, not sure in which version this will show up then (and on what
> ancient QGIS version your government client is).
>
> If all fails, I'd accept Tim's proposal to get it uploaded on
> plugins.qgis.org via the backdoor/Tim...
>
> Regards,
>
> Richard Duivenvoorde
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] pg_featureserv + OGC API Features + QGIS

[Richard Duivenvoorde]

Should it be possible to use filters or paging when using this provider?

I cannot make QGIS use filters or paging...
(at least not with pg_featureserv... will also try qgisserver now...)

Regards,

Richard Duivenvoorde

On 1/28/21 9:59 AM, Richard Duivenvoorde wrote:
> Hi All,
> 
> Some months ago I sent an email to this list with subject:
> "Anybody playing with pg_featureserv + OGC API Features + QGIS?"
> because I failed to make the play with each other at that moment...
> 
> Thanks to Stefan K (creating an issue) and Martin D (actual fix) see:
> https://github.com/CrunchyData/pg_featureserv/issues/63
> it is now supereasy to setup a OGC API/WFS 3 in front of your Postgis DB AND 
> let QGIS talk to it!
> 
> Supercool!
> 
> Regards,
> 
> Richard Duivenvoorde
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
> 

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

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[Richard Duivenvoorde]

On 1/28/21 4:13 PM, C Hamilton wrote:
> What you mention has merit, but I was not kidding about trying to keep a 
> plugin self contained for government use. To set up automatic downloading on 
> our networks would require PKI authentication and that opens up another can 
> of worms. I know how to deal with PKI because I already maintain plugins that 
> use authentication. It would be easier for our users to have them download a 
> data pack and have some manual installation process, but it is even easier if 
> the data is already a part of the plugin. The o

Hi Calvin, 

What I 'think' Nyall meant was to add such data to QGIS itself? We already have 
a gpkg with the world countries on board (everybody know the easter egg: 'type 
world in the coordinate input' yes?).
But... adding 102Mb to the QGIS installer is maybe too much :-) Or can you 
shrink that down to some smaller size/format?
Also, not sure in which version this will show up then (and on what ancient 
QGIS version your government client is).

If all fails, I'd accept Tim's proposal to get it uploaded on plugins.qgis.org 
via the backdoor/Tim...

Regards,

Richard Duivenvoorde
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[C Hamilton]

Nyall,

What you mention has merit, but I was not kidding about trying to keep a
plugin self contained for government use. To set up automatic downloading
on our networks would require PKI authentication and that opens up another
can of worms. I know how to deal with PKI because I already
maintain plugins that use authentication. It would be easier for our users
to have them download a data pack and have some manual
installation process, but it is even easier if the data is already a part
of the plugin. The other option would be to produce two different versions
of the plugin. One for government use and the other for community use, but
my sponsor would probably frown on that and not want me to use my time to
maintain the community version.

The author of timezonefinder has done a number of optimizations to provide
fast lookups. See

https://timezonefinder.readthedocs.io/en/latest/3_about.html

I wonder what the difference in time would be to use a gpkg and QGIS point
in polygon look up vs timezonefinder lookup. Will it be faster or slower?
I'm not sure without testing. What are your thoughts? I would choose the
faster of the two.

I just converted the timezone data to a gpkg and its size is 102Mb. The
data size for timezonefinder using the same data set is 49Mb. The
optimization in timezonefinder can produce a maximum error of 1cm at the
equator as they use 32 bit ints for the data. It might actually be better
to use the gpkg file, but it is double in size. I will investigate using
the gpkg data.

It seems to me that if a plugin requires a certain dataset to function then
that data should be included with it and not require an
additional download, but I understand the issues that this could cause so I
am not sure of the best way forward. For our use it is definitely better to
include the data with the plugin.

I guess what I would like you to take from this conversation is that some
users have a completely different environment and face different challenges
then what you do when it comes to dealing with software. I wish that it was
easier for me to get QGIS acceptance in our workforce but ArcGIS still
rules.

Thanks for your ideas and all of the hard work that you do to keep QGIS
moving forward.

I wish you all the very best!

Calvin

Given that the size of the python library is almost entirely the size
> of the timezone boundaries themselves, have you considered:
> - avoiding the library entirely, and insteading using a standard
> shapefile/gpkg/... of the boundaries and using QGIS vector layer
> methods to determine the timezone for a point
> - deferring the download of the boundary spatial data, so that it's
> not supplied with the plugin but instead the plugin automatically
> downloads it on first launch?
>
> This would avoid the need for the large size plugin, allowing it to be
> supplied via the standard QGIS repo while still providing its full
> functionality...
>
> Nyall
>
>
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] fuso 12 e google maps

[Andrea Giudiceandrea]

Ciao Silvia,
questa è la mailing list internazionale degli utenti di QGIS, quindi la
maggior parte degli iscritti comprende la lingua inglese e solo pochi anche
la lingua italiana.

La mailing list degli utenti italiani è qgis-it-user
https://lists.osgeo.org/mailman/listinfo/qgis-it-user.

Comunque in teoria non dovrebbero esserci problemi di riproiezione al volo
dei layer, purché ogni layer abbia impostato il corretto sistema di
riferimento e nei limiti della precisione delle impostazioni di
trasformazione di datum che hai scelto fra quelle disponibili.

Ti consiglio di proseguire la discussione, in italiano, tramite la mailing
list italiana, oppure di continuare in questa mailing list, ma
preferibilemente in lingua inglese.

A presto.

Andrea



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-User-f4125267.html
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[Tim Sutton]

Hi

On Wed, Jan 27, 2021 at 11:38 PM Nyall Dawson 
wrote:

> On Thu, 28 Jan 2021 at 00:32, C Hamilton  wrote:
> >
> > Tim,
> >
> > I understand the position you are in and I really struggled in even
> wanting to put in the time to develop this plugin knowing that there would
> probably be a problem getting it accepted by the QGIS developers because of
> its size, but our users have a very real need for this capability which is
> why I consented to develop it at all.
> >
> > In order to deal with locating time zones based on a coordinate there is
> simply no way to get around the size of the python library required if
> accuracy of the results is desired. That feature alone requires 42Mb. I
> struggle to convince our GIS analysts to use QGIS over ArcGIS and so I try
> to provide solutions that work better than those in ArcGIS, but if there is
> any sort of complication that makes it more difficult for one of the
> analysts to get the resources they need for QGIS then I have lost the
> battle. This includes having them pip install additional python libraries
> because most of them do not have system admin privileges.
>
> Given that the size of the python library is almost entirely the size
> of the timezone boundaries themselves, have you considered:
> - avoiding the library entirely, and insteading using a standard
> shapefile/gpkg/... of the boundaries and using QGIS vector layer
> methods to determine the timezone for a point
> - deferring the download of the boundary spatial data, so that it's
> not supplied with the plugin but instead the plugin automatically
> downloads it on first launch?
>
> This would avoid the need for the large size plugin, allowing it to be
> supplied via the standard QGIS repo while still providing its full
> functionality...
>

So Chris, try Nyall's approach and if that does not work for you, pop a
note here and we will see if we can make a local exception without
generally increasing the size limit for plugins.

Regards

Tim



>
> Nyall
>
>
> >
> > I can easily set up the ability for users to point to a separate repo
> that houses this plugin, but once again that is an additional complication.
> Every once in a while I find some QGIS repo of plugins that are not a part
> of the official QGIS repo and I think that it is too bad that they are
> probably not used much outside of the organization who hosts them. Unless a
> plugin exists on the official QGIS repo it will not be discoverable and
> will not likely be used by many.
> >
> > I think the plans I have with this plugin will make it very useful to
> the QGIS community, but if it cannot be a part of the QGIS repo it will not
> be of much use to the community. Our users will make use of it because we
> will provide it to them. I would like to swap out the astral library for
> the Skyfield library with the JPL ephemeris data to provide more precise
> sun and moon calculations, but that adds an additional ~20Mb.
> >
> > I would love it if you would provide timezonefinder and Skyfield
> libraries by default with the QGIS distribution, but that increases the
> size of the QGIS download. When you are dealing with time zones and
> astronomical calculations, there is no way in getting around the plugin
> size to get the best accuracy available. I personally am not interested in
> providing tools with less accuracy.
> >
> > I don't know how important it will be for the QIGS community to have
> these tools available, but I know that there will be a number of users who
> have been looking for these capabilities in QGIS and will be valuable to
> them. Right now I have coded only one of a number of tools that I have
> planned, but part of my plans will be determined by the QGIS acceptance of
> a larger plugin. I think my other QGIS plugins I have provided including
> "Lat Lon Tools", "Shape Tools" & "KML Tools" shows how useful my plugins
> have been.
> >
> > If there is something I am missing or some other way around this let me
> know, but keep in mind I hold to two fundamental principals with my
> plugins. 1) They are as accurate at possible. 2) They are self contained
> meaning that OUR users don't need to install any software to run them. The
> functionality in Date/Time tools is simply going to take up space and there
> is no way around it that I can see. I think your "unwritten expectation" of
> small plugins prevents some capabilities from being introduced, but I also
> agree that in most instances plugins should be kept small. What I am trying
> to accomplish simply does not come small.
> >
> > Let me know if you want me to just provide the capabilities for our
> users alone or to expand it for use by the QGIS community.
> >
> > I await the QGIS developers decision on this.
> >
> > Thanks!
> >
> >>> Personally I would be more on the -1 on upping the limit for plugins -
> currently at 10mb I think - since large plugins will consume more space on
> our plugins server and our user's bandwidth. There is an unwritten
> expectation 

[Qgis-user] pg_featureserv + OGC API Features + QGIS

[Richard Duivenvoorde]

Hi All,

Some months ago I sent an email to this list with subject:
"Anybody playing with pg_featureserv + OGC API Features + QGIS?"
because I failed to make the play with each other at that moment...

Thanks to Stefan K (creating an issue) and Martin D (actual fix) see:
https://github.com/CrunchyData/pg_featureserv/issues/63
it is now supereasy to setup a OGC API/WFS 3 in front of your Postgis DB AND 
let QGIS talk to it!

Supercool!

Regards,

Richard Duivenvoorde

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