[QGIS-Developer] Might snap change a 2D layer to 3D? discussion how to fix https://issues.qgis.org/issues/16927

[Matthias Kuhn]

On 09/08/2017 02:31 PM, Luigi Pirelli wrote:
> Hi
> 
> next week I'll work on some 2.18 regressions [1] [2] [3] all regarding
> issues related if a provider can or not manage an automatic geometry
> type conversion.
> 
> One of them [1] is the fact that snapping a 2d layer to a 3d one, the
> new feature become 3D, but the original layer remain 2d => error
> during commit because incompatibility.
> 
> IMHO a solution should leave the snapping to modify 2D to 3D. The
> reason is to allow user to rise up a flat vector if this is the user
> intention (do you agree?)
> some considerations:
> 1) IMHO if there is a single-2-multi type conversion have to be
> notified via messageBar (do you agree?)
> 2) We can add a snapping option like "maintain geometry type" (True by
> default) that avoid to change geom from 2d to 3d => raise exception as
> soon as it happen (do you agree?) and not only at commit time (e.g.
> when save changes)
> 3) add a generic check in the editing buffer that check geom
> compatibility as soon as a geom is changed.
> 
> 3) can be solved as stated here:
> https://qgis.org/api/2.18/qgsvectorlayereditbuffer_8cpp_source.html#l00197
> "// TODO: check compatible geometry"
> in this place can be added the same controls set in commitChanges() of
> the same class... or moved these controls in a reusable methods.
> Would be great to have this control outside EditBuffed or as static
> method and with SIP binding to allow other application to do this
> check for their business functions.

I think this should go to the layer logic, If I understand correctly
option 3.

If a feature is added onto a layer with a different geometry type and
there is only one conversion that makes sense, let's do it. Possibly
inform the user about what's up ("Dropping 3D information because layer
X only has 2 dimensions").

This applies IMO to

* dropping and adding Z/M dimensions
* Promoting single to multi geometries
* Demoting single-part multi geometries (carefully, only if there's a
consistent solution we don't want to have only 3 out of 20 pasted
features actually ending up on the layer).


I would try to avoid introducing the same logic in all tools like
snapping, pasting, GPS digitizing, processing, ...

Matthias

> 
> any opinion?
> 
> Luigi Pirelli
> 
> p.s. these fixes can be applied to 3.x too
> 
> [1] https://issues.qgis.org/issues/16927
> [2] https://issues.qgis.org/issues/16948
> [3] https://issues.qgis.org/issues/15741
> 
> **************************************************************************************************
> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * GitHub: https://github.com/luipir
> * Mastering QGIS 2nd Edition:
> * https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
> **************************************************************************************************
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>