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
[email protected] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
