Re: [QGIS-Developer] Geopackage FID columns: i HATE them!!!!

[Stephane Goldstein]

I used to frequently get errors when copying and pasting features across
geopackage files.
So now, before saving the edited file, I select all features and set the
fid to NULL, which avoid errors most of the times.

On Fri, Mar 20, 2020 at 5:07 AM Alexis R.L.  wrote:

> Greetings,
>
> Personnally when splitting layers and when there are FID conflits, I try
> to solve it manually. Sometimes it tells me that the fid of feature x
> cannot be change, which are not indistinguishable.
>
> And the next time you open the geopackage there is a change that the fid
> column will now be the next column over and the initial fid column with bad
> fids is still there. If you had critical information in your second column
> too bad, its now a fid and you lost that information forever.
>
> Maybe that issue was fixed already since I'm mostly using 3.4.4 on my main
> setup as of now (waiting for some PRs to get merged before updating).
>
> Thanks
>
> Alex
>
>
> Le jeu. 19 mars 2020 à 02:04, Nyall Dawson  a
> écrit :
>
>> Hi list,
>>
>> Just wondering what everyone's thoughts are about geopackage FID
>> columns. Personally, I find them an absolute nightmare to deal with,
>> resulting in annoying (and dangerous) issues when trying to save
>> geopackage edits, such as
>> - field type issues: converting certain formats to geopackage fails,
>> because existing fields with name "fid" are of an incompatible type
>> with geopackage. Solution: manually uncheck the "fid" field from the
>> "save as" dialog.
>> - unique constraint violations: we've mostly fixed this in processing,
>> but it's still unfortunately really common to get failures when saving
>> edits to geopackage because some operation has resulted in duplicate
>> fids. This can be a nightmare to fix, if it's even possible to do so.
>>
>> I personally HATE HATE HATE these columns, and would rather I never
>> saw them ever again. Does anyone else feel the same? If so, could we
>> potentially just permanently hide these columns from QGIS and avoid
>> all these dangerous issues for users?
>>
>> 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
>
> ___
> 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] Proj 7 auto grid download

[Nyall Dawson]

On Thu, 19 Mar 2020 at 22:04, Martin Dobias  wrote:
>
> Hi Nyall
>
> On Thu, Mar 19, 2020 at 7:53 AM Nyall Dawson  wrote:
> >
> > On Thu, 19 Mar 2020 at 16:49, Jürgen E. Fischer  wrote:
> > >
> > > Yes. proj-dev-data is to huge for NSIS.  Best install via OSGeo4W until 
> > > grids
> > > are downloadable via proj.
> >
> > There's no plans to use proj 7's built in auto grid download. This
> > isn't designed for GUI applications like QGIS -- if we did, we'd get
> > UI hangs all over the place while QGIS is trying to transform
> > coordinates, and proj blocks and waits for the download to occur.
>
> Do you have some thoughts on how we are going to handle this in QGIS?
> (Apart from that plan to download all grids on the first start :-))
>
> My assumption was that QGIS would be shipped with no grids (simply too
> much data to ship in installers), and if there would be a
> transformation available with a missing grid, QGIS would show a
> warning and let user download such a grid file with one click? Or did
> you have something else in mind?

That's basically what we have now. When a grid is desirable (and not
installed) you get a warning in the message bar, which you can click
to open a dialog which explains the situation and provides a download
link, and a button to "install" (copy to the right place) the
downloaded file.

The only extra steps we could do to improve this would be:
- Avoid the "click to download in your browser" link, and instead have
a button which downloads in the background of QGIS itself and
auto-installs after download
- Take it another step further, and just immediately trigger the
download task when we first show that warning
- Avoid all these issues and download EVERYTHING for EVERYWHERE at
first startup ;)

Nyall


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

Re: [QGIS-Developer] The build of weekly snapshots stopped in February

[Nyall Dawson]

On Thu, 19 Mar 2020 at 19:00, Régis Haubourg  wrote:
>
> We would need to have a parameter to set the download location, as http or 
> file resource so that remote site with no internet available can still 
> install QGIS then...

I wouldn't suggest doing it as part of the install. I'd do it as a
post-install, first launch step (if internet connectivity is
available)

Nyall

>
> Le jeu. 19 mars 2020 à 07:53, Nyall Dawson  a écrit :
>>
>> On Thu, 19 Mar 2020 at 16:49, Jürgen E. Fischer  wrote:
>> >
>> > Hi Andrea,
>> >
>> > On Wed, 18. Mar 2020 at 16:18:39 -0700, Andrea Giudiceandrea wrote:
>> > > it seems that the build of the weekly snapshots of qgis-dev from OSGeo4W 
>> > > as
>> > > standalone installer for Windows stopped in February: the last one is
>> > > QGIS-OSGeo4W-3.11.0-8 25-Feb-2020.
>> >
>> > Yes. proj-dev-data is to huge for NSIS.  Best install via OSGeo4W until 
>> > grids
>> > are downloadable via proj.
>>
>> There's no plans to use proj 7's built in auto grid download. This
>> isn't designed for GUI applications like QGIS -- if we did, we'd get
>> UI hangs all over the place while QGIS is trying to transform
>> coordinates, and proj blocks and waits for the download to occur.
>>
>> What we should instead do is just fire up a background task on first
>> install to download ALL THE GRIDS FOR EVERYWHERE form the proj CDN and
>> install them locally. Problem solved FOREVER! ;)
>>
>> Nyall
>>
>> >
>> >
>> > 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 Nordenhttps://www.norbit.de
>> > QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>> > ___
>> > 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] 2020 budget proposal

[Andreas Neumann]

Hi PSC and contributors,

Please find the updated 2020 budget proposal at 
https://docs.google.com/spreadsheets/d/1pUlUWa7PfgxLn-sX6K2ccPN7ZWXzqrw_QNNFyvw8Sl4/edit#gid=0


Comments:

- as proposed by some (e.g. Régis) for 2021 we will discuss and approve 
the budget in late 2020. Makes more sense.


- I already took into account that the 1st contributor meeting was cancelled

- I added the Python cookbook expenses as discussed recently

- I added VAT reverse charge expense estimates

- In some cells you can find comments - the cells with the yellow 
triangles in the upper-right corner of the cells


I am awaiting your comments. Questions? Did I miss expenses that you see 
upcoming but haven't been taken into account?


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] Geopackage FID columns: i HATE them!!!!

[Alexis R.L.]

Greetings,

Personnally when splitting layers and when there are FID conflits, I try to
solve it manually. Sometimes it tells me that the fid of feature x cannot
be change, which are not indistinguishable.

And the next time you open the geopackage there is a change that the fid
column will now be the next column over and the initial fid column with bad
fids is still there. If you had critical information in your second column
too bad, its now a fid and you lost that information forever.

Maybe that issue was fixed already since I'm mostly using 3.4.4 on my main
setup as of now (waiting for some PRs to get merged before updating).

Thanks

Alex


Le jeu. 19 mars 2020 à 02:04, Nyall Dawson  a
écrit :

> Hi list,
>
> Just wondering what everyone's thoughts are about geopackage FID
> columns. Personally, I find them an absolute nightmare to deal with,
> resulting in annoying (and dangerous) issues when trying to save
> geopackage edits, such as
> - field type issues: converting certain formats to geopackage fails,
> because existing fields with name "fid" are of an incompatible type
> with geopackage. Solution: manually uncheck the "fid" field from the
> "save as" dialog.
> - unique constraint violations: we've mostly fixed this in processing,
> but it's still unfortunately really common to get failures when saving
> edits to geopackage because some operation has resulted in duplicate
> fids. This can be a nightmare to fix, if it's even possible to do so.
>
> I personally HATE HATE HATE these columns, and would rather I never
> saw them ever again. Does anyone else feel the same? If so, could we
> potentially just permanently hide these columns from QGIS and avoid
> all these dangerous issues for users?
>
> 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
___
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 "fast" mode

[Régis Haubourg]

Hi, can someone explain what is the real logic currently coded for trust
option? It feels like this topic raises again each year for 5 years now,
and we have regressions and what it is supposed to do.

It was funded at start to not check at all any metadata on the datasource
and read only qgs informations
Did it change for some reason ? Why?

It should be adequate even for big databases of QGIS stores all the
required informations.

Regards
Regis

Le jeu. 19 mars 2020 à 18:05, René-Luc Dhont  a écrit :

> Hi Tomas,
>
> The way trust option works is not enough for big databases and big
> project with more than 100 layers. It is what Michaël and I experiment.
>
> Then the problem with changes data is more about the layer extent. For
> example a natural observations layer is designed to accept data on a
> territory but t the start of the project the layer extent is null and
> will growing with data inserted. The trust option cannot be used at the
> project start unless the user can set the available extent, or can
> defined the trust option for each layer.
>
> It will be great to set trust option at the layer level so QGIS can
> trust the layer information provided by the XML : QLR or QGS content
> It will also be great to can set some technical metadata like a layer
> available extent as the geographic area for which a selected CRS is
> valid for use.
>
> Regards,
> René-Luc
>
> Le 18/03/2020 à 22:01, Tomas Straupis a écrit :
> > 2020-03-18, tr, 21:41 kimaidou rašė:
> >> # only few requests are avoided as you pointed out so the performance
> improves "only" a bit
> >In large databases those few requests take minutes and sometimes
> > even hours... For servers even 30 seconds are too much when you're
> > trying to add a new QGIS server process to existing say 10 while on
> > high load doing 500 requests per second.
> >
> >> # sometimes you have some layers with changing data, and there is
> actually no way to trust only a subset of layers inside the project
> >1. If geometry types are changing by design, then checking geometry
> > type upon project loading is not enough. Then you need to ALWAYS
> > filter your results by requested geometry type. But only if it is the
> > case of varying geometry types. In my opinion, developer of the
> > layer/query should know beforehand if it is possible for geometry
> > types to variate and then create a view filtering on geometry type (or
> > it could be an option in QGIS ~"filter on geometry type").
> >
> >2. If database schemas are changing on-line then I would say
> > something is very wrong with the IT processes. Changes should start on
> > dev environment where data changes and QGIS project changes as well.
> > Then changes to db structure go to other environments up to production
> > in patches TOGETHER with updated QGIS project. System (in this case
> > QGIS) should never (in my experience) try to "fix" the problem because
> > it does not know all required information: maybe the project was
> > opened in incorrect environment, maybe it is a temporary problem,
> > maybe the real table is missing and you're accidentally trying to
> > query incorrect table which was never supposed to be queried -> strict
> > rules/control. Of course there could be a button "refresh" on a layer
> > to allow operator to re-query layer information upon manual request.
> >
> >> Do you think it would be interesting to have the trust option per layer
> and not only per project?
> >Theoretically there could be very different data sources, but in my
> > opinion if organisation uses strict IT processes then all layers will
> > be strictly managed (you would rarely/never have direct access to the
> > database of a different company/institution with different/weaker
> > processes). And vice versa.
> >
>
> ___
> 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] Geopackage FID columns: i HATE them!!!!

[Tim Sutton]

I agree too - I also dont like that we get an FID column when we import another 
table that already has an id column….all sorts of chaos ensues….

https://github.com/qgis/QGIS/issues/30697

Regards

Tim

> On 19 Mar 2020, at 17:00, René-Luc Dhont  wrote:
> 
> I agree, so in my algorithms working with geopackage I always redefined  FID 
> with 
> 
> options = QgsVectorFileWriter.SaveVectorOptions()
> options.layerOptions = ['FID=id']
> 
> For me it is like a primary key in PostGIS, I need to manage it.
> Other point, Feature ID in QGIS is still a short integer.
> 
> Regards,
> René-Luc
> 
> Le 19/03/2020 à 10:28, Régis Haubourg a écrit :
>> +1000. I was so relieved of the fid/oid/mapinfo_id when QGIS arrived and 
>> allowed business logic primary keys. 
>> 
>> 
>> Le jeu. 19 mars 2020 à 07:52, Nathan Woodrow > > a écrit :
>> I agree.  
>> 
>> If there is an ID that is used internally as a unique primary key it should 
>> never be shown to the user. It should not be expected to be edited outside 
>> of the provider's control or be stable between edits. 
>> 
>> If you need a stable ID for reference you should make your own {{insert rant 
>> about people wanting to use increating ints as a reference ID}} 
>> 
>> On Thu, Mar 19, 2020 at 4:04 PM Nyall Dawson > > wrote:
>> Hi list,
>> 
>> Just wondering what everyone's thoughts are about geopackage FID
>> columns. Personally, I find them an absolute nightmare to deal with,
>> resulting in annoying (and dangerous) issues when trying to save
>> geopackage edits, such as
>> - field type issues: converting certain formats to geopackage fails,
>> because existing fields with name "fid" are of an incompatible type
>> with geopackage. Solution: manually uncheck the "fid" field from the
>> "save as" dialog.
>> - unique constraint violations: we've mostly fixed this in processing,
>> but it's still unfortunately really common to get failures when saving
>> edits to geopackage because some operation has resulted in duplicate
>> fids. This can be a nightmare to fix, if it's even possible to do so.
>> 
>> I personally HATE HATE HATE these columns, and would rather I never
>> saw them ever again. Does anyone else feel the same? If so, could we
>> potentially just permanently hide these columns from QGIS and avoid
>> all these dangerous issues for users?
>> 
>> 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 
>> ___
>> 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

—









Tim Sutton

Co-founder: Kartoza
Ex 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

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
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 "fast" mode

[René-Luc Dhont]

Hi Tomas,

The way trust option works is not enough for big databases and big 
project with more than 100 layers. It is what Michaël and I experiment.


Then the problem with changes data is more about the layer extent. For 
example a natural observations layer is designed to accept data on a 
territory but t the start of the project the layer extent is null and 
will growing with data inserted. The trust option cannot be used at the 
project start unless the user can set the available extent, or can 
defined the trust option for each layer.


It will be great to set trust option at the layer level so QGIS can 
trust the layer information provided by the XML : QLR or QGS content
It will also be great to can set some technical metadata like a layer 
available extent as the geographic area for which a selected CRS is 
valid for use.


Regards,
René-Luc

Le 18/03/2020 à 22:01, Tomas Straupis a écrit :

2020-03-18, tr, 21:41 kimaidou rašė:

# only few requests are avoided as you pointed out so the performance improves 
"only" a bit

   In large databases those few requests take minutes and sometimes
even hours... For servers even 30 seconds are too much when you're
trying to add a new QGIS server process to existing say 10 while on
high load doing 500 requests per second.


# sometimes you have some layers with changing data, and there is actually no 
way to trust only a subset of layers inside the project

   1. If geometry types are changing by design, then checking geometry
type upon project loading is not enough. Then you need to ALWAYS
filter your results by requested geometry type. But only if it is the
case of varying geometry types. In my opinion, developer of the
layer/query should know beforehand if it is possible for geometry
types to variate and then create a view filtering on geometry type (or
it could be an option in QGIS ~"filter on geometry type").

   2. If database schemas are changing on-line then I would say
something is very wrong with the IT processes. Changes should start on
dev environment where data changes and QGIS project changes as well.
Then changes to db structure go to other environments up to production
in patches TOGETHER with updated QGIS project. System (in this case
QGIS) should never (in my experience) try to "fix" the problem because
it does not know all required information: maybe the project was
opened in incorrect environment, maybe it is a temporary problem,
maybe the real table is missing and you're accidentally trying to
query incorrect table which was never supposed to be queried -> strict
rules/control. Of course there could be a button "refresh" on a layer
to allow operator to re-query layer information upon manual request.


Do you think it would be interesting to have the trust option per layer and not 
only per project?

   Theoretically there could be very different data sources, but in my
opinion if organisation uses strict IT processes then all layers will
be strictly managed (you would rarely/never have direct access to the
database of a different company/institution with different/weaker
processes). And vice versa.



___
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] Geopackage FID columns: i HATE them!!!!

[René-Luc Dhont]

I agree, so in my algorithms working with geopackage I always redefined  
FID with


options = QgsVectorFileWriter.SaveVectorOptions()
options.layerOptions = ['FID=id']

For me it is like a primary key in PostGIS, I need to manage it.
Other point, Feature ID in QGIS is still a short integer.

Regards,
René-Luc

Le 19/03/2020 à 10:28, Régis Haubourg a écrit :
+1000. I was so relieved of the fid/oid/mapinfo_id when QGIS arrived 
and allowed business logic primary keys.



Le jeu. 19 mars 2020 à 07:52, Nathan Woodrow > a écrit :


I agree.

If there is an ID that is used internally as a unique primary key
it should never be shown to the user. It should not be expected to
be edited outside of the provider's control or be stable between
edits.

If you need a stable ID for reference you should make your own
{{insert rant about people wanting to use increating ints as a
reference ID}}

On Thu, Mar 19, 2020 at 4:04 PM Nyall Dawson
mailto:nyall.daw...@gmail.com>> wrote:

Hi list,

Just wondering what everyone's thoughts are about geopackage FID
columns. Personally, I find them an absolute nightmare to deal
with,
resulting in annoying (and dangerous) issues when trying to save
geopackage edits, such as
- field type issues: converting certain formats to geopackage
fails,
because existing fields with name "fid" are of an incompatible
type
with geopackage. Solution: manually uncheck the "fid" field
from the
"save as" dialog.
- unique constraint violations: we've mostly fixed this in
processing,
but it's still unfortunately really common to get failures
when saving
edits to geopackage because some operation has resulted in
duplicate
fids. This can be a nightmare to fix, if it's even possible to
do so.

I personally HATE HATE HATE these columns, and would rather I
never
saw them ever again. Does anyone else feel the same? If so,
could we
potentially just permanently hide these columns from QGIS and
avoid
all these dangerous issues for users?

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

___
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] Plugin [1813] Geometric Attributes approval notification.

[noreply]

Plugin Geometric Attributes approval by zimbogisgeek.
The plugin version "[1813] Geometric Attributes 0.2" is now approved
Link: http://plugins.qgis.org/plugins/geometric_attributes/
___
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] [SoC] Request for QGIS 3D proposal draft review

[BELGACEM NEDJIMA]

Hello everyone,
I am Belgacem Nedjima, a fourth year student at the higher school of
computer science (ESI - ecole supérieure d'informatique), Algiers. I am
very interested in QGIS 3D project and discussed the project with mentor
Martin Dobias and wrote a proposal draft.
I would be very happy to receive feedback and clarify anything about my
proposal before I submit to the GSoC website. If there is anything unclear
or missing please let me know.
The list of features required for the QGIS 3D project is quite extensive,
so if there is any feature you think is more interesting than the features
I mentioned in the proposal please let me know.

Proposal document :
https://docs.google.com/document/d/1dyszmpDlMpIV0T6oKEtIfCY5N2nXSp43LqF_h4U9p4A/edit?usp=sharing

I am looking forward to your valuable feedback.

Best regards

-- 
Belgacem Nedjima
4th year computer science and engineering student student.
https://github.com/NEDJIMAbelgacem
___
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] Proj 7 auto grid download

[Martin Dobias]

Hi Nyall

On Thu, Mar 19, 2020 at 7:53 AM Nyall Dawson  wrote:
>
> On Thu, 19 Mar 2020 at 16:49, Jürgen E. Fischer  wrote:
> >
> > Yes. proj-dev-data is to huge for NSIS.  Best install via OSGeo4W until 
> > grids
> > are downloadable via proj.
>
> There's no plans to use proj 7's built in auto grid download. This
> isn't designed for GUI applications like QGIS -- if we did, we'd get
> UI hangs all over the place while QGIS is trying to transform
> coordinates, and proj blocks and waits for the download to occur.

Do you have some thoughts on how we are going to handle this in QGIS?
(Apart from that plan to download all grids on the first start :-))

My assumption was that QGIS would be shipped with no grids (simply too
much data to ship in installers), and if there would be a
transformation available with a missing grid, QGIS would show a
warning and let user download such a grid file with one click? Or did
you have something else in mind?

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

Re: [QGIS-Developer] The build of weekly snapshots stopped in February

[Paolo Cavallini]

Hi Nyall

Il 19/03/20 07:53, Nyall Dawson ha scritto:

> What we should instead do is just fire up a background task on first
> install to download ALL THE GRIDS FOR EVERYWHERE form the proj CDN and
> install them locally. Problem solved FOREVER! ;)

what a pleasure to hear - say it again please :)
Cheers.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Processing][Question] Using Data defined proprieties

[João Gaspar]

Hi Nyall,
Thank you for your feedback and quick fix.

Regards,
João

A quarta, 18/03/2020, 22:58, Nyall Dawson  escreveu:

> On Wed, 18 Mar 2020 at 02:21, João Gaspar 
> wrote:
> >
> > Hi Devs,
> > I have a question about using data defined proprieties in algorithms.
> For instance,
> > if I want to do a Buffer using a field with a distance column I can use
> the data defined proprieties and choose the field with distance.
> >
> > But when I want to use more than 1 layer and switch to batch processing
> where I want to define the field with distance of each layer I can't use
> this option.
> >
> > I try to use the name of the field in the option Add Values by
> Expression and Calculate by Expression but the batch processing always
> assumes a default value (10).
> >
> > In the case of SAGA and buffer algorithm, when you switch for batch
> processing is possible to choose the field of distance per layer.
> >
> > What am I'm doing wrong? Or This is expected behaviour?
>
> It's actually just an oversight. I just tested and (with a tiny code
> change) it works fine. I'll open a PR.
>
> Nyall
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Geopackage FID columns: i HATE them!!!!

[Régis Haubourg]

+1000. I was so relieved of the fid/oid/mapinfo_id when QGIS arrived and
allowed business logic primary keys.


Le jeu. 19 mars 2020 à 07:52, Nathan Woodrow  a écrit :

> I agree.
>
> If there is an ID that is used internally as a unique primary key it
> should never be shown to the user. It should not be expected to be edited
> outside of the provider's control or be stable between edits.
>
> If you need a stable ID for reference you should make your own {{insert
> rant about people wanting to use increating ints as a reference ID}}
>
> On Thu, Mar 19, 2020 at 4:04 PM Nyall Dawson 
> wrote:
>
>> Hi list,
>>
>> Just wondering what everyone's thoughts are about geopackage FID
>> columns. Personally, I find them an absolute nightmare to deal with,
>> resulting in annoying (and dangerous) issues when trying to save
>> geopackage edits, such as
>> - field type issues: converting certain formats to geopackage fails,
>> because existing fields with name "fid" are of an incompatible type
>> with geopackage. Solution: manually uncheck the "fid" field from the
>> "save as" dialog.
>> - unique constraint violations: we've mostly fixed this in processing,
>> but it's still unfortunately really common to get failures when saving
>> edits to geopackage because some operation has resulted in duplicate
>> fids. This can be a nightmare to fix, if it's even possible to do so.
>>
>> I personally HATE HATE HATE these columns, and would rather I never
>> saw them ever again. Does anyone else feel the same? If so, could we
>> potentially just permanently hide these columns from QGIS and avoid
>> all these dangerous issues for users?
>>
>> 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
>
> ___
> 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] Size of docker images

[Régis Haubourg]

+1
For running desktop I extensively use Dockers derived from jancelin's work.
See my branches here where I upgraded the images to be able to use startup
parameters like profiles_path.

For building and running the lighter possible images, we use this stack,
mainly for server.

https://github.com/Oslandia/docker-qgis

Sorry for being short, I'm tutoring children school work !

Le jeu. 19 mars 2020 à 09:58, Denis Rouzaud  a
écrit :

> These images are built using the same base images that are used for
> testing.
> https://github.com/qgis/QGIS/blob/master/.docker/qgis.dockerfile#L6
>
> I think it would be more appropriate to create a dedicated Dockerfile with
> only what is required to run the app and not building/testing/producing the
> docs.
>
>
>
> Le jeu. 19 mars 2020 à 07:58, Etienne Trimaille <
> etienne.trimai...@gmail.com> a écrit :
>
>> Hi,
>>
>> Just for your information, I have noticed that the size of official QGIS
>> docker images are increasing:
>>
>> qgis/qgis release-3_4  4.83GB
>> qgis/qgis release-3_106.67GB
>> qgis/qgis latest6.95GB
>>
>> Is-it an issue? A known issue?
>> Thanks
>> ___
>> 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] The build of weekly snapshots stopped in February

[Régis Haubourg]

We would need to have a parameter to set the download location, as http or
file resource so that remote site with no internet available can still
install QGIS then...

Le jeu. 19 mars 2020 à 07:53, Nyall Dawson  a
écrit :

> On Thu, 19 Mar 2020 at 16:49, Jürgen E. Fischer  wrote:
> >
> > Hi Andrea,
> >
> > On Wed, 18. Mar 2020 at 16:18:39 -0700, Andrea Giudiceandrea wrote:
> > > it seems that the build of the weekly snapshots of qgis-dev from
> OSGeo4W as
> > > standalone installer for Windows stopped in February: the last one is
> > > QGIS-OSGeo4W-3.11.0-8 25-Feb-2020.
> >
> > Yes. proj-dev-data is to huge for NSIS.  Best install via OSGeo4W until
> grids
> > are downloadable via proj.
>
> There's no plans to use proj 7's built in auto grid download. This
> isn't designed for GUI applications like QGIS -- if we did, we'd get
> UI hangs all over the place while QGIS is trying to transform
> coordinates, and proj blocks and waits for the download to occur.
>
> What we should instead do is just fire up a background task on first
> install to download ALL THE GRIDS FOR EVERYWHERE form the proj CDN and
> install them locally. Problem solved FOREVER! ;)
>
> Nyall
>
> >
> >
> > 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
> https://www.norbit.de
> > QGIS release manager (PSC)  GermanyIRC: jef on
> FreeNode
> > ___
> > 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] Size of docker images

[Denis Rouzaud]

These images are built using the same base images that are used for testing.
https://github.com/qgis/QGIS/blob/master/.docker/qgis.dockerfile#L6

I think it would be more appropriate to create a dedicated Dockerfile with
only what is required to run the app and not building/testing/producing the
docs.



Le jeu. 19 mars 2020 à 07:58, Etienne Trimaille 
a écrit :

> Hi,
>
> Just for your information, I have noticed that the size of official QGIS
> docker images are increasing:
>
> qgis/qgis release-3_4  4.83GB
> qgis/qgis release-3_106.67GB
> qgis/qgis latest6.95GB
>
> Is-it an issue? A known issue?
> Thanks
> ___
> 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] Size of docker images

[Etienne Trimaille]

Hi,

Just for your information, I have noticed that the size of official QGIS
docker images are increasing:

qgis/qgis release-3_4  4.83GB
qgis/qgis release-3_106.67GB
qgis/qgis latest6.95GB

Is-it an issue? A known issue?
Thanks
___
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 build of weekly snapshots stopped in February

[Nyall Dawson]

On Thu, 19 Mar 2020 at 16:49, Jürgen E. Fischer  wrote:
>
> Hi Andrea,
>
> On Wed, 18. Mar 2020 at 16:18:39 -0700, Andrea Giudiceandrea wrote:
> > it seems that the build of the weekly snapshots of qgis-dev from OSGeo4W as
> > standalone installer for Windows stopped in February: the last one is
> > QGIS-OSGeo4W-3.11.0-8 25-Feb-2020.
>
> Yes. proj-dev-data is to huge for NSIS.  Best install via OSGeo4W until grids
> are downloadable via proj.

There's no plans to use proj 7's built in auto grid download. This
isn't designed for GUI applications like QGIS -- if we did, we'd get
UI hangs all over the place while QGIS is trying to transform
coordinates, and proj blocks and waits for the download to occur.

What we should instead do is just fire up a background task on first
install to download ALL THE GRIDS FOR EVERYWHERE form the proj CDN and
install them locally. Problem solved FOREVER! ;)

Nyall

>
>
> 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 Nordenhttps://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
> ___
> 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] Geopackage FID columns: i HATE them!!!!

[Nathan Woodrow]

I agree.

If there is an ID that is used internally as a unique primary key it should
never be shown to the user. It should not be expected to be edited outside
of the provider's control or be stable between edits.

If you need a stable ID for reference you should make your own {{insert
rant about people wanting to use increating ints as a reference ID}}

On Thu, Mar 19, 2020 at 4:04 PM Nyall Dawson  wrote:

> Hi list,
>
> Just wondering what everyone's thoughts are about geopackage FID
> columns. Personally, I find them an absolute nightmare to deal with,
> resulting in annoying (and dangerous) issues when trying to save
> geopackage edits, such as
> - field type issues: converting certain formats to geopackage fails,
> because existing fields with name "fid" are of an incompatible type
> with geopackage. Solution: manually uncheck the "fid" field from the
> "save as" dialog.
> - unique constraint violations: we've mostly fixed this in processing,
> but it's still unfortunately really common to get failures when saving
> edits to geopackage because some operation has resulted in duplicate
> fids. This can be a nightmare to fix, if it's even possible to do so.
>
> I personally HATE HATE HATE these columns, and would rather I never
> saw them ever again. Does anyone else feel the same? If so, could we
> potentially just permanently hide these columns from QGIS and avoid
> all these dangerous issues for users?
>
> 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
___
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 build of weekly snapshots stopped in February

[Jürgen E . Fischer]

Hi Andrea,

On Wed, 18. Mar 2020 at 16:18:39 -0700, Andrea Giudiceandrea wrote:
> it seems that the build of the weekly snapshots of qgis-dev from OSGeo4W as
> standalone installer for Windows stopped in February: the last one is
> QGIS-OSGeo4W-3.11.0-8 25-Feb-2020.

Yes. proj-dev-data is to huge for NSIS.  Best install via OSGeo4W until grids
are downloadable via proj.


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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
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] Geopackage FID columns: i HATE them!!!!

[Matthias Kuhn]

Hi Nyall,

Similar thoughts here.

Not sure what a format wins from forcing people into using an integer 
based primary key column.


I think ultimately it is the data producer's responsibility to assign 
unique and sensible identifiers with meaningful names (aka primary keys) 
to data.


All the fid_1, fid_2 etc columns after processing, all the troubles with 
shifted columns because field indexes changed, all the extra effort to 
clean up with these generated clutter ids ... So much wasted time that 
no one will ever give us back.


If it was for me, may it rest in peace.

Matthias


On 3/19/20 7:03 AM, Nyall Dawson wrote:

Hi list,

Just wondering what everyone's thoughts are about geopackage FID
columns. Personally, I find them an absolute nightmare to deal with,
resulting in annoying (and dangerous) issues when trying to save
geopackage edits, such as
- field type issues: converting certain formats to geopackage fails,
because existing fields with name "fid" are of an incompatible type
with geopackage. Solution: manually uncheck the "fid" field from the
"save as" dialog.
- unique constraint violations: we've mostly fixed this in processing,
but it's still unfortunately really common to get failures when saving
edits to geopackage because some operation has resulted in duplicate
fids. This can be a nightmare to fix, if it's even possible to do so.

I personally HATE HATE HATE these columns, and would rather I never
saw them ever again. Does anyone else feel the same? If so, could we
potentially just permanently hide these columns from QGIS and avoid
all these dangerous issues for users?

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


___
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] Geopackage FID columns: i HATE them!!!!

[Nyall Dawson]

Hi list,

Just wondering what everyone's thoughts are about geopackage FID
columns. Personally, I find them an absolute nightmare to deal with,
resulting in annoying (and dangerous) issues when trying to save
geopackage edits, such as
- field type issues: converting certain formats to geopackage fails,
because existing fields with name "fid" are of an incompatible type
with geopackage. Solution: manually uncheck the "fid" field from the
"save as" dialog.
- unique constraint violations: we've mostly fixed this in processing,
but it's still unfortunately really common to get failures when saving
edits to geopackage because some operation has resulted in duplicate
fids. This can be a nightmare to fix, if it's even possible to do so.

I personally HATE HATE HATE these columns, and would rather I never
saw them ever again. Does anyone else feel the same? If so, could we
potentially just permanently hide these columns from QGIS and avoid
all these dangerous issues for users?

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