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
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
[email protected] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
