[Qgis-developer] Questions regarding new geometry engine
Denis Rouzaud
denis.rouzaud at gmail.com
Fri Jun 5 02:33:18 PDT 2015
thanks a lot
On 06/05/2015 11:20 AM, Marco Hugentobler wrote:
> On 05.06.2015 09:17, Denis Rouzaud wrote:
>> 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
>
> I think so, therefore assigned the tickets to me.
>
> Regards,
> Marco
>
>
>>
>> Thanks a lot,
>> Denis
>>
>> 2015-06-04 15:52 GMT+02:00 Marco Hugentobler
>> <marco.hugentobler at sourcepole.ch
>> <mailto: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
>> <mailto: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
>> <mailto:Qgis-developer at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150605/ce9b932f/attachment-0001.html>
More information about the Qgis-developer
mailing list