[Qgis-developer] 2.5D rendering crowdfunding

[Matthias Kuhn]

On 11/05/2015 05:07 PM, Hugo Mercier wrote:
> 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.
The conversion provider side are probably straightforward (just use the
code that is used to create the main geometry of the feature).
But I don't know if it can be considered an API break. If you have a
plugin that currently makes use of the WKT format, that may be broken by
this change. Maybe implementing QgsGeometry.__str__() is already fine?

>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Help to improve QGIS rendering possibilities before Nov 30, 2015
http://www.opengis.ch/2015/11/02/qgis-crowdfunding-2-5d-rendering


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151105/bfdbb764/attachment.sig>