[Qgis-developer] 2.5D rendering crowdfunding

[Hugo Mercier]

On 04/11/2015 11:25, Matthias Kuhn wrote:
> Hi
> 
> Good to be aware of this. Let's see that we don't do work twice.
> 
> On 11/04/2015 11:17 AM, Hugo Mercier wrote:
>> On 04/11/2015 10:19, Régis Haubourg wrote:
>>> Matthias Kuhn-2 wrote
>>>>  * on-the-fly transformation of geometries while rendering (or with some
>>>> small additions also to create geometries based on attributes)
>>> Hi, this is quite inline with QEP 46 {0]  about handling geometries to draw
>>> label paths. Storing geometries in data or having on-the fly smoothing
>>> expressions for geometries seems to have the same prerequisites for 2.5 D
>>> and that QEP. Hugo  any opinion on that ? 
>>> Cheers
>>> Régis
>>>  [0] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/46
>> Hi,
>>
>> Exact. The concepts seem very close. Except that in one case it is
>> before painting and in another case, before drawing labels.
>>
>> Matthias, is this possible with your proposition to have different parts
>> of the buildings coming from different geometry columns ?
>> Currently for a PostGIS table with two geometry columns (or Spatialite I
>> guess), the second is extracted as a WKT string. I am not sure yet of
>> what changes would be needed to have them extracted as QgsGeometry. That
>> would ease (and speed up) such functionalities (2.5D or label paths)
> 
> 
> Theoretically, yes. It's just the result of an expression that is going
> to be painted. So the expression can be based on several columns. But
> the symbology will always be configured for the main geometry type of
> the layer (making it configurable will be an easy followup).

Ok, cool.

> 
> But as you noted, it will be required to have access to the additional
> columns as geometry (instead of WKT). One task will probably be to make
> the CRS of the additional columns available (IIRC that's not possible
> yet). And the other task to conver WKT to a geometry (already possible?)
> or even better, never ever handle them as WKT.

Correct.
A first step where the additional geometry columns are considered to be
expressed in the same CRS as the main geometry column would already be
interesting.
And yes, that would be better if additional geometries could be accessed
directly as QgsGeometry, and converted to WKT only when needed
(attribute table ?). It's probably only modifications provider-side.