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

Sat Apr 4 02:40:06 PDT 2015

Regarding MapInfo as a user:

  * You can't be sure abut the drawing order for different object types
    in a single layer. With multiple types you risk having a small
    object (ie point) being hidden by a larger object (ie a polygon)
    becuase the polygon is drawn "above" the point.
  * Import tab files to different GIS systems that can't handle multi
    type layers. When you try to import 1 million object layer there is
    always 999999 objects of one type and 1 object of a different type -
    and the import will fail. This is confusing for a lot of users and
    irritating for the rest.
  * Thematics in MapInfo does not work properly when used on a multi
    object type layer

Regarding MapInfo as a developer:

It's a royal pain having to deal with all the possible situations in a 
MapBasic script when you have to deal with a layer with multiple object 
types. Suddenly a script will fail because it's trying make an otherwise 
legal operation on a type of object  its not supposed to deal with. You 
can of course remedy the situation with a lot of "if-then-else" type 
checking or "onerror" goto's but your scripts readability will be horrible.

Regards
Bo Victor Thomsen
AestasGIS
Denmark

Den 04-04-2015 kl. 10:28 skrev Marco Hugentobler:
> 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
>
>
> _______________________________________________
> 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/20150404/2c195d74/attachment.html>