[Qgis-developer] Questions regarding new geometry engine

[Marco Hugentobler]

Hi Nyall

 >Firstly, I *think* that there's an issue with the
 >inheritance of some of the classes. Specifically QgsMultiLineStringV2
 >and QgsMultiPolygonV2. Currently both of these derive from
 >QgsGeometryCollectionV2, but I think they should derive from
 >QgsMultiCurveV2 and QgsMultiSurfaceV2. This would seem logical to me
 >since QgsLineStringV2 derives from QgsCurveV2 and QgsPolygonV2 derives
 >from QgsCurvePolygonV2. It also would match with how I understand the
 >OGC simple features access specification describes (see 6.1.8.1 -
 >MultiCurve should be non-instantiable, 6.1.9 multiline is a
 >multicurve, and 6.1.13.1 and 6.1.14 for the corresponding
 >multisurface/multipolygon types). What's your thoughts?

Yes, in the ISO and OGC models, MultiPolygon inherits from MultiSurface 
and MultiLineString from MultiCurve. The implementation of the 
geometryV2 classes differs a bit compared to the model, because most 
methods are implemented on GeometryCollection level (e.g. in the ISO 
model, length() and area() are not in the collection class). So there is 
little practical relevance if QgsMultiPolygon is derived from 
MultiSurface (and overwrites all its methods) or from 
GeometryCollection. One exception is the segmentize() method. By default 
(straight geometries), this is equal to a normal clone(). As 
MultiSurface needs to overwrite it (may contain curved geometries), 
MultiPolygon would need to overwrite it again with the default behaviour 
if it was derived from MultiSurface.

 >MultiCurve should be non-instantiable

In the OGC model, it is non-instantiable. In the ISO model (which is 
relevant here), it is left to the implementation if it is instantiable 
or not.

Regards,
Marco

On 03.06.2015 09:05, Marco Hugentobler wrote:
> Hi Nyall
>
> Thanks for your input. I'll back in the office tomorrow and can give 
> you more detailed answers to the technical questions.
>
> To the technical issues:
> Yes, I plan to fix them in the next time, but definitely before 
> release ( fixed #12857 and started to look at #12836 already). I think 
> you should focus on other bugs, otherwise we risk to do the same work 
> twice.
>
> Regards,
> Marco
>
>
> Am 02.06.2015 um 23:34 schrieb Nyall Dawson:
>> Hi Marco (also cc-ing dev list)
>>
>> I've been looking over the new geometry engine and it's really nice
>> stuff. It's fantastic to have this in QGIS and it's a huge improvement
>> over the old geometry class. Thank you!
>>
>> I have a couple of questions regarding this which I'm hoping you can
>> clarify for me. Firstly, I *think* that there's an issue with the
>> inheritance of some of the classes. Specifically QgsMultiLineStringV2
>> and QgsMultiPolygonV2. Currently both of these derive from
>> QgsGeometryCollectionV2, but I think they should derive from
>> QgsMultiCurveV2 and QgsMultiSurfaceV2. This would seem logical to me
>> since QgsLineStringV2 derives from QgsCurveV2 and QgsPolygonV2 derives
>> from QgsCurvePolygonV2. It also would match with how I understand the
>> OGC simple features access specification describes (see 6.1.8.1 -
>> MultiCurve should be non-instantiable, 6.1.9 multiline is a
>> multicurve, and 6.1.13.1 and 6.1.14 for the corresponding
>> multisurface/multipolygon types). What's your thoughts?
>>
>> Secondly, are you able to share your plans for bug fixing leading up
>> to 2.10? There's a number of serious regressions following this work,
>> and I'm wondering if I should be focusing on these during the
>> sponsored bug fixing or whether you plan to tackle them before
>> release? The biggest issues I see are:
>> - #12836 : layers fail to render
>> - unfiled: I get a lot of unknown exceptions when working with
>> geometries. I can reproduce this consistently by trying to use the
>> reshape tool on a polygon, or by rotating a map within the canvas or a
>> composer.
>> - #12843: simplify tool broken
>> - i noticed there's also a number of stubbed methods in geometry with
>> todo comments (eg QgsGeometry::buffer ).
>>
>> If you can share your plans then I can plan my work accordingly.
>>
>> Again, thanks again for this fantastic work!
>>
>> Nyall
>
>


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee