[Qgis-developer] Questions regarding new geometry engine
Denis Rouzaud
denis.rouzaud at gmail.com
Fri Jun 5 00:17:07 PDT 2015
Hi Marco,
Can you tell me if these two issues are related to your work?
http://hub.qgis.org/issues/12885
http://hub.qgis.org/issues/12886
Thanks a lot,
Denis
2015-06-04 15:52 GMT+02:00 Marco Hugentobler <
marco.hugentobler at sourcepole.ch>:
> 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
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150605/a8368ac8/attachment-0001.html>
More information about the Qgis-developer
mailing list