Re: [QGIS-Developer] QGIS 3D and Graphics Card Requirements

[Bernd Vogelgesang via QGIS-Developer]

Hi,

my 2 cents from a 3D-interested (not yet experienced) user:
1. doing GIS-stuff on a notebook, no matter how performant it is, for me
is a PITA.
Clumsy keyboards, overpriced hardware. GIS-work without a large or 2
screens is useless -> so whats the point of a mobile computer then?

2. Had a 10 year old mid-range gaming computer so far (i7 4770k, 16GGB
RAM, 2GB Graphics card).
For any usage in 2D this was still more than sufficient.
Native QGIS 3D crashed.
Sniffed a bit into Blender, which had much better performance, but the
workflow to use it efficiently with real world data is still unclear to me.

3. As my pockets are full, I am in the process to order a NVIDIA RTX
4090 and will be reporting back about the finding.

4. What I would wish for the 3D-future of QGIS: Somehow wire into the
Blender 3D capabilities.
Usecase: For planning processes of construction (Windmills, solar farms,
Buildings, bridges etc.):
(Semi-)realistic landscapes based on geodata and aerial images, but
pimped up with 3D-model bushes, trees etc based on semi-automatic
classification of aerial images and underlying geodata.

Seeing such processes in "reality" will bring much better understand for
planners, authorities, population etc. than the best crafted 2D maps
ever will.

Cheers,
Bernd

Am 15.10.23 um 13:08 schrieb Martin Dobias via QGIS-Developer:

Hi Hannes


__

the two ridiculously expensive and high-end graphics cards mentioned
by Luke sound like complete overkill. Surely reading and preparing
the geodata for 3D display (from data providers, via storage, on the
CPU?) would be the bigger performance/usability issue of the 3D
views, right? I am sure that for reasonable reasons QGIS would choke
wy earlier than what those cards would be capable of. The
potential benefit of those cards for QGIS 3D definitely is not worth
paying *1200-2500€* extra.

I have not had a chance to try QGIS 3D with such high-end cards yet, but
you're right, users would be probably hitting performance issues
elsewhere when working with large amounts of data (but this also depends
on data types, formats, styling etc.)

Martin/Jean, is there any change that you could provide a more
detailed specification of the hardware and software requirements for
QGIS 3D? It comes up again and again and I've just been searching
again without success. I step up to add it to the QGIS documentation
in early November.

Okay, great, let me try... there are very few firm requirements for QGIS
3D, so it's hard to answer some of the questions exactly.

Esri provides for example infos on the required OpenGL version and
extensions on

https://pro.arcgis.com/en/pro-app/latest/get-started/arcgis-pro-system-requirements.htm
 


E.g.: What is the minimum amount of GPU RAM necessary? How does it
scale with more complex 3D scenes and what happens if there is not
enough RAM?

There's no strict minimum really, but I would say 1 GB GPU memory should
be enough for many use cases. When dealing with large amounts of 3D data
- e.g. point clouds or tiled scenes (3D tiles), it won't hurt to have
more memory, although with default settings QGIS probably would not go
over 2 GB GPU memory usage. All layers use tiling, so with increased
distance of 3D data from camera, there's less detail displayed, which
limits GPU memory usage and GPU processing power needed.

Each map layer gets up 500 MB GPU memory, but only few that are memory
intense (like point clouds or tiled scene) would normally use all of it.
When a map layer gets to the limit, it will unload data (that are
currently not being displayed) from GPU memory to get under the 500 MB
limit. In the QGIS release 3.34 it will be possible to configure the
per-layer limit (and QGIS 3D views will show a warning if the limit has
been reached and none of the tiles can be unloaded).

Does it get slow (maybe with a message) or does it crash?

Any slowness should be caused by displaying too many triangles/points in
the 3D view (or possibly there could be something in QGIS code that runs
on CPU that is slow and affecting 3D performance for example when the 3D
scene is getting updated as the camera moves, scheduling loads of tiles).

To be honest I don't really know what happens if there's not enough GPU
memory - in theory there could be crashes, or the scene would be just
missing some data - or maybe something else, like freeze. It is worth
trying - it may depend on the operating system and the graphical drivers
as well.

Which renderer does it use on which platforms (I guess always
OpenGL?). Which OpenGL version is needed?

Yes it is always using OpenGL. Our 3D window requests OpenGL 4.3 core
profile. Shaders of materials that we use only need OpenGL 3.2 or 3.3.

I am not 100% sure how things are on Windows and macOS. Apparently,
Windows by default only provides very 

Re: [QGIS-Developer] Lazy question about using views in GeoPackages

[Bernd Vogelgesang via QGIS-Developer]

Hi,

no first-hand experiences myself, but a friend once tried to do those
views with Geopackage.
Coming from views with Spatialite, it felt like a pita for him, so he
reverted to Spatialite and can not recommend a Geopackage approach.
So, seems you will indeed have to reinvent the wheel.

Cheers,
Bernd

Am 26.05.23 um 12:52 schrieb Bo Victor Thomsen via QGIS-Developer:

Hi list -

Recently, I've begun experimenting with creating spatial view's of
base-tables inside GeoPackages. A Geopackage is basically a SQLite file
containing  spatial data- and meta-tables with specific structures of
information about the spatial tables.

So it's possible to create a permanent view of a table (or tables) in
the GeoPackage by making a functioning SQL select statement and
prefixing it with "CREATE VIEW /view_name/ AS .. /the select statement/
.. (This is database 101 knowledge)

However, if you want to expose those views as "read-only" tables/layers
for "non-sql-using" QGIS users  you have to update several meta-tables
in the GeoPackage: /gpkg_contents/, /gpkg_geometry_columns/ and maybe
/gpkg_ogr_contents/.

I'm brainstorming with myself about making some kind of automated
updating of the meta-tables with information about the views created.
Maybe some python code and maybe creating triggers for the base table to
handle data changes regarding the extend of the data.

And now (at last !!) my question: I haven't been able to find very much
information about this subject using Google or StackExchange. So.. Is
there some existing code / plugin / information so I don't have to
"reinvent the wheel" ?


--
Med venlig hilsen / Best regards

Bo Victor Thomsen


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

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

Re: [QGIS-Developer] [Qgis-psc] QGIS budget 2023 RFC

[Bernd Vogelgesang via QGIS-Developer]

sneaking in from the ouside ...

Hey guys and girls,

you are providing the world (including million-$€-companies) with an
awesome "product" with a budget worth maybe 50 ESRI-licenses!!!

There has to be a way to grab those big players by the balls! THEN such
discussions about payment rates would start to make sens.

Maybe investing some money in marketing psychologists who can help
developing a campaign for that? Obviously different abilities apart from
software development are needed for this.

Just my two micro-cents
Bernd



Am 24.11.22 um 16:09 schrieb Andreas Neumann via QGIS-Developer:

Hi Vincent,

Thank you for joining the discussion.

We did not really discuss the hourly rates at the budget meeting. From
2021 to 2022 we raised the hourly dev rates from 100 to 110 - and the
hourly documentation rates from 40 to 44. I know that both rates are
low. We can discuss raising them again.

The plan for the two positions was not to have direct employees of
QGIS.ORG , but to use a proxy company, in our case
Kartoza, to act as the employer. Also - our budget does not allow
regular European or North-American salaries. With these limitations at
hand, we can use Kartoza as a proxy to hire employees in certain parts
of the world where the salaries we can offer can be attractive - and
where they have talented people to work on some of our issues
(sysadmin, documentation, etc.)

For the documentation part: Tim and Harrissou are involved in the
selection process of the candidates.

I agree that the grant budget with 10k is not very attractive. We also
discussed skipping it for one year. Not sure what is better ...

BTW: you can all help to find new sustaining members ... that would
increase our budget and would allow us to pay better hourly rates ...

I wish we had a larger budget at hand than the +/- 200k € we seem to
be able to attract each year. From certain countries where we know we
have a lot of QGIS users (France, Italy - just to name two of them)
there are not a lot of sustaining members or donations other than from
a few private persons and very small companies. Maybe companies like
yours could help us to get in touch with the larger companies with a
lot of QGIS users that could become new sustaining members ... Do you
think that would be possible?

Andreas

On Thu, 24 Nov 2022 at 15:05, Vincent Picavet (ml) via QGIS-Developer
 wrote:

Hello,

Thanks for sharing the budget with the community.

A few questions / remarks :
- in most countries, we can see a general inflation, having
consequences on every kind of costs ( hosting, salaries…). Did you
take this context into account when preparing the budget,
especially when basing planned 2023 costs on actual 2022 costs ?
- the cut on Grant budget is really hard. With a "reasonable" mean
budget of 5K per grant, this would mean 2 grants only this year.
It sounds more or less like the end of the grant program. Who
would candidate if chances to be selected are really low ?
Wouldn't there be a way to mitigate it a bit, through various
smaller budget reductions to other budget lines ? The increase in
documentation contribution is huge compared to the grant decrease.
I fear that we loose grants as a mean to attract new core developers.

My most important remark is about "allow for a regular small
salary .. for one person on each item". Disclaimer : I am quite
strongly against QGIS.org having employees. If we are in the
process of having "regular workers" for qgis.org
, then we really have to work hard on :
- having a clear, written and transparent process for how to
select these people
- .. process including a fair way for anyone to candidate
I may have missed some communications, but I have not seen this in
place up to now. This is definitely something we have to put in
place before having some internal troubles.

Best regards,
Vincent

On 24/11/2022 12:07, Marco Bernasocchi wrote:
> Hi all, we prepared the QGIS budget for 2023 and would like to have
> feedback before submitting it to the voting members for
approval. You
> can directly leave comments in the file [1].
>
> Please let us have any Feedback until December 4th. On december 7th
> we'll send the budget for vote.
>
> Cheers Marco
>
> [1]
>

https://docs.google.com/spreadsheets/d/1WyoZCKOehNhU5YB4pFPOuiJbie1mUmMPiq8YW7qyez0/edit?usp=sharing
>


>
>  -- Marco Bernasocchi
>
> QGIS.org Chair OPENGIS.ch CEO http://berna.io 
>
> ___ Qgis-psc mailing
> list qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc

___
QGIS-Developer mailing list