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

Fri Apr 3 13:02:01 PDT 2015

To me, the solution of grouping layers sounds more like a hack. I think it
will result in some quite complex code and probably UI.

It involves as you say something like inheritance or synchronization of
settings. It raises some difficult questions about the link with the
underlying db (does each sublayer have it's own dataprovider, or is it
somehow shared by the layers ?). It's not clear how the UI would treat
linked layers (how is the edit mode synced between the grouped layers, is
the selection model shared across the layers ? ...). What about features
like joins ? And so on...

If find all of this quite an overkill and a bunch of potential hard to
debug problems.

I know the approach I suggest induces some changes in the API, but I think
the changes would not even be that huge. I'm not even sure they would be
breaking changes ?

If I'm not mistaken, currently, the (only?) way to know what feature type
will be returned by QgsVectorLayer->getFeatures(...) is
QgsVectorLayer->geometryType()

Multi-typed layer could simply return a new QGis::GeometryType
('MixedGeometry' or something).

This way, current code would still work. Of course, you would not be able
to choose a mixed geometry layer for an algorithm that only allows to work
with Line layers, but that's actually quite normal, since a mixed layer is
not a line layer.

Then, we would add the
getLineFeatures/getPointFeatures/getPolygonFeatures functions (or add an
argument to getFeatures), that would allow to iterate only specific types,
for algorithms that are designed to work on MixedGeometry layers.

Am I missing something (would this break the API) ?
Or do you have in mind some things that it could break ?
Probably as Denis said map tools would require most work. They'd be
disabled on mixed layers until we fix them, and we may need some more
helper functions to fix those easily (for instance a feature-type filter
for snapping).

And then, the most tricky part, we would need to find a clever way for the
UI. We'd have to find a clever way to display geometry-type specific
settings that don't clutter the UI when we work on a mono-typed layer.

Actually, the more I think about, the more I think we shouldn't even
consider point/line/polygons as subcategories of a layer.
They should be able to sit next to each other in one normal layer.
This would need some work, on the legend for instance (there can be up to 3
symbols per legend item), some work on toolbars and editing tools, but I
don't see anything unsolvable here.

Best,

Olivier

2015-04-03 20:12 GMT+02:00 Matthias Kuhn <matthias at opengis.ch>:

>  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>
> :
>
>>  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 listQgis-developer at lists.osgeo.orghttp://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
>>
>
>
>
> _______________________________________________
> Qgis-developer mailing listQgis-developer at lists.osgeo.orghttp://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/6de9c3cb/attachment.html>