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

[Bernd Vogelgesang]

Hi,

While reading this thread, I again stumbled upon the topic that QGIS is  
not able to handle arcs so far. Is that topic somehow also connect to the  
fact that each layer can only hold one type of geometry?

Cheers
Bernd



Am 04.04.2015, 10:28 Uhr, schrieb Marco Hugentobler  
<marco.hugentobler at sourcepole.ch>:

> Hi
>
> Yes, the implicit assumption that each layer has one geometry type  
> probably goes back to the shapefile. I agree it is a wrong >design from  
> QGIS to assume that and it is not in line with the logic of many  
> important datasources (Postgres, Oracle, MS SQL, WFS >and also some OGR  
> formats like dxf), therefore causing workarounds on the dataprovider  
> level to seperate db tables into several >layers. I think it is best (at  
> least in the long term) to have a logic compatible to the datasources  
> instead of doing workarounds >at provider and gui level.
>
> There are many places where this has an impact (e.g. symbology system,  
> editing). Therefore it will be good to break the 'one >geometry type'  
> assumption not before version 3. A first step could be to identify the  
> places in core/gui/app where changes would >be needed.
>
> @Nathan and Victor: I don't have experience with MapInfo. What is the  
> exact reason why multi-geometries have been user-unfriendly >there?
>
> Regards,
> Marco
>
>
>
> On 02.04.2015 13:52, Olivier Dalang wrote:
>> 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
>> 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



-- 
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150406/f5dc9144/attachment.html>