[Qgis-developer] Thoughts about multi-type tables in QGIS
Matthias Kuhn
matthias at opengis.ch
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>
More information about the Qgis-developer
mailing list