[Qgis-developer] Thoughts about multi-type tables in QGIS

Fri Apr 3 11:12:15 PDT 2015

I think there's a lot of hidden caveats - in QGIS itself as well as in
plugins - and it would be very hard to find them all and treat them
appropriately.

Therefore I would prefer not to go for a change in layer semantics in
terms of that a layer iterator suddenly may return different geometry types.
I'd prefer to re-raise the idea of having a special layer-group type
that allows to define certain settings on all sub-layers. Adding a
multi-geometry layer can by default add such a layer.

The difference is an opt-in vs. an opt-out approach.
Changing the layer geometry type semantic would require to update
everything that does not want to use multi-geometry behavior (hence
opt-out). A possibly painful story with lots of side-effects that we
possibly can't even think of right now.
The group approach would allow any component capable of handling
multi-geometry types to add possibilities on group-level. With a good
API it can be easy to determine if a layer is part of a multitype group.
And from the group an iterator can be requested and a hierarchical
setting can be introduced (define defaults at group level, override at
layer level).

I would strongly prefer the second approach. It should allow to do all
the cool things and introduce them incrementally without having to deal
with all the unintended side-effects of a sudden break in semantics.

Do you think there are downsides of this approach?

Best regards,
Matthias

On 04/02/2015 05:07 PM, Olivier Dalang wrote:
> Hi,
>
> Would it really be more complicated ?
>
> I mean, for now, an algorithm that works only with line layers already
> has to check whether the layer is of type line. That's done before
> iterating the features.
>
> Exactly in the same way, there would be functions to determine whether
> a layer supports a geometry type or not.
>
> Then, there would be functions to iterate a particular geometry type
> for a layer.
> This could be done by adding a geometry type argument to getFeatures,
> and/or by adding specific
> getLineFeatures/getPointFeatures/getPolygonFeatures functions,
> probably throwing exceptions if the layer does not support this
> particular type (shapefile or specific geometry column in postgis).
>
> To me it seems not much different from how it works currently, at
> least from a programmer's point of view. Of course it's quite a change
> in the API, that's why it's only thoughts for a future QGIS 3 or 4...
>
>
> I don't know Mapinfo at all, but it's good to know there's already
> some experience somewhere (even if bad). But do you really think the
> problem is in the principle itself, and not in Mapinfo's implementation ?
>
>
> The things at stake are maybe worth the thought still...
> The heavy distinction between geometry types is very artificial.
> There's a lot of very valid representation of real world phenomenons
> of a certain kind that require different geometry types. Having to
> distribute those across different layers because of a 25 years old
> file format is somewhat sad...
>
>
> Olivier
>
>
> 2015-04-02 16:41 GMT+02:00 Bo Victor Thomsen
> <bo.victor.thomsen at gmail.com <mailto:bo.victor.thomsen at gmail.com>>:
>
>     As an old MapInfo user/developer my opion is: Don't do it. It has
>     always been a problem in MapInfo and it will be a problem in QGIS
>     - if implemented.
>
>     A better approach is to have the possibility to let different QGIS
>     layers share some common characteristics (for example labelling).
>     And - of course - clean up the current errors in QGIS when
>     splitting contents of data sources by object types.
>
>     Regards
>     Bo Victor Thomsen
>     AestasGIS
>     Denmark    
>
>     Den 02-04-2015 kl. 13:52 skrev Olivier Dalang:
>>     Hi,
>>
>>     In some projects of mine, I work with multiple geometry types in
>>     one postgis table, using a column of type geometry(Geometry,4326).
>>     This is very well supported by postgis.
>>
>>     It is possible to load such a table in QGIS by manually selecting
>>     the geometry type you want to load. This means that to display
>>     all the features, you need to add the table three times, one for
>>     each feature type.
>>
>>     This works more or less. There are a few bugs though :
>>     - http://hub.qgis.org/issues/12499 (you can edit other type's
>>     node with the node tool)
>>     - http://hub.qgis.org/issues/12500 (other type's records are
>>     shown in the attribute table)
>>
>>     This also has some limitations. When having such a setup, it's
>>     pretty sure you'll want to have the same edit forms for all the
>>     layers. You'll also probably want the same filter, the same
>>     labels, the same actions, etc...
>>     The only thing you'd want to be able to define on a geometry type
>>     basis are the symbol (well, even the classification/colors/etc
>>     could be shared) and the label placement.
>>     For now, you must do all settings three times, because of this
>>     bug/feature request :
>>     - http://hub.qgis.org/issues/12303 (copy/paste style from one
>>     geometry type to another)
>>
>>
>>     As you see, support multiple geometry types in QGIS is not perfect.
>>
>>     Of course it's possible to fix the bugs/pr, and there are some
>>     workarounds (postgis view instead of tables) but maybe it's also
>>     worth thinking a bit more in depth about this.
>>
>>     We could consider point/line/polygons as subcategories/sublayers
>>     of a layer. A shapefile or a mono-typed table would have only one
>>     of those sublayer, but a postgis table could perfectly have the
>>     three. Most of the settings would be defined at the layer level,
>>     while only some settings would be defined at the subcategory level.
>>
>>     This is probably especially relevant when thinking long term (the
>>     day we support 3D, curves, etc...).
>>
>>
>>     What do you think ?
>>     Do you think the relation 1 layer = 1 geometry type will hold ?
>>
>>     I think we inherited this from the old shapefile format, but most
>>     data sources QGIS handles don't have this limitation. I also
>>     think it does not hold with quite a lot of modern GIS uses
>>     (especially web related, think of openstreetmaps for instance).
>>
>>     There's this feature request (6th oldest open issue on the
>>     tracker) about postgis geometry collections  :
>>     http://hub.qgis.org/issues/167
>>
>>
>>     Best,
>>
>>     Olivier
>>
>>
>>
>>     _______________________________________________
>>     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
>
>
>     _______________________________________________
>     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
>
>
>
>
> _______________________________________________
> 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/20150403/8d4122a6/attachment-0001.html>