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

Tue Apr 7 02:55:42 PDT 2015

Hi,

I think the topic of handling multiple geometry columns in one table and
the topic of handling multiple geometries types in one column are distinct.
They don't overlap and we can do one, or the other, or both.

*Multitypes*

I'm a bit surprised at how many of you have the strong opinion that
handling mixed geometries is a bad idea. The most recurring argument is
that Mapinfo did it, and it sucks.

So I'd still like a bit more details about what went so wrong with
Mapinfo... Here are Bo Victor's points.

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.

Couldn't we use QGIS drawing order options for this, to make sure that by
default, we have points, then lines, then polygons ?
The case can also happen where you want polygons in front of points, so
having the ability to change that using drawing order could even be
considered a feature.

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.

Yes that's true, but we are not talking about creating any new file type
here. The case you're talking about only happens when the user mistakenly
chooses to create a multityped column while he actually wanted to model
only a particular type of features. This won't happen most of the time,
since unexperienced users tend to use shapefiles that are mono typed. We
could consider adding some kind of warning in the UI before creating
multityped columns in spatialite/postgis, but honestly, at this point,
there are already tons of other possible mistakes for people who are
unfamiliar with GIS (single/multipart, 2d/3d, projection, nullable columns,
etc.).

Still, we'd have probably to implement something for exportation of
multityped layers to monotyped formats. It could be a bit like the "export
selected features only" checkbox, except that there would be radio buttons
to choose which type to export.

Thematics in MapInfo does not work properly when used on a multi object
> type layer

That really sounds like an implementation problem, or is there some
classification that are feature-type specific ?

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.

Doesn't the solution of type-specific iterators solve this ? (plus the fact
that multityped layer wouldn't be considered as Point/Line/Polygon layers).

Bernard thanks for your use case.
But as you say, it's workarounds, and I'm pretty sure it gets confusing for
your user when they want to display say "all compensating features planned
after 2008", since they'll have to run the filter on all the three tables.
Even worse if they want to do some changes in the attributes using the
field calculator, they have to remember that each layer actually only shows
a third of the actual data, risking to cause some trouble if they don't...

About use cases, I have two that I'm currently meeting :

*Event data management*
I have a postgis table for historical events, which can be of any
geometrical type.
The events can have links to other events (using references like
previous_event_id).
Currently, I have to add the postgis table four times. Once for each
geometry type, plus once as a no-geometry table so that I can have the full
attribute table to be able to use the relations widget.
At this point, every setting (filtering, labels, actions, symbols...) must
be made four times, which starts to become annoying (could be improved :
#12303).
The file is also quite complex to use, because one must know that the four
different layers are actually the same.
All scripting around this setup becomes quite tricky since I have to check
four layers instead of one. Python actions that depend on selection are
very complex to do for instance : I need the reference to the other layers
that represent the same table, and must deal with four selections instead
of one.
And then there's the question of performance, where having four layers
probably results in having four times as many queries.

*CAD data in QGIS*
I have some CAD data (.dxf) that I want to be able to show in some projects
of mine. Those contain lines and polygons. Currently, I have to load the
layer twice, and do my filtering separately on each layer. Nothing
impossible, but still I need to do the same operation twice each time I
want to change my filters.

*Other cases...*
I think if one day we want QGIS to be able to work in write access to
formats like geojson or csv (with wkt representation), we'd need this kind
of support.
That would be great, and I definitely believe these kind of formats already
started to grow more and more important, so that we'll want to have that in
near future.

In short, I know in most cases it's much better to work with specific
geometry types. I'm not arguing against that at all, and I'm not saying we
should go towards using mixed-types file formats all over (that would
indeed be terrible).

It's just that there are some cases where the data you model is effectively
of mixed geometry types, and that the artificial separation of types brings
quite some complications to their editing and display in QGIS, while it's
pretty straightforward at database level.

And moreover, we would keep the possibility to load a mixed-type layer as a
mono-type layer (current implementation), so we wouldn't loose anything.

*Multi-columns*

Nyall I like your idea very much.
I always found it a bit disturbing not to see the geometry in the table
view, while it's just another column from a data point of view.
There are some things to think about from an UI point of view :
- distinguish the geometry column used by qgis to display the layer on the
map from the others
- would it be possible to sort the attribute table using some of the
geometries attribute you're mentioning ? (validity, number of points,
rings, etc.)
- make distinction between "delete geometry" and "delete record" very clear
(would there be a map tool to delete a geometry)
- probably allow to edit geometries directly on the map, rather than only
by entering wkt text (in case of edits of the main geometry, simply
activate the edit node tools on the chosen geometry, in case of edits on
another geometry, display it using an editable rubber band)

But if I get it correctly, your idea is to support other geometries merely
as attributes (with the specific fact that they can be used for things such
as label placement), not to support alternative geometries on the map
canvas, right ?
Denis is that what you were suggesting ?

(Well maybe it would be better to start another topic on this ;) )

At least all of this is food for thoughts !!

Best,

Olivier

2015-04-06 12:08 GMT+02:00 Nyall Dawson <nyall.dawson at gmail.com>:

> On 3 April 2015 at 01:41, Bo Victor Thomsen <bo.victor.thomsen at gmail.com>
> wrote:
> > 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.
>
> Count me in as another MapInfo graduate who has seen the mess which
> multi-type tables cause and isn't in favour of this approach.
>
> That said, I'm very interested in this conversation as it touches on
> some thoughts/work I've been tackling lately. I think there's some big
> improvements we can make as to how QGIS handles geometries in a layer.
>
> I often work with layers which have a mix of null/not null geometries.
> It's important for me to be able to easily edit tables of this form,
> including adding new records with no geometry to the table. This isn't
> currently (easily) achievable in QGIS. You can add geometries to an
> existing record, remove the geometry from a record, add a new record
> with a geometry but you can't add a record without a geometry.
>
> I've been thinking of modifying the attribute table to show geometry
> columns. This would be done via a new QgsGeometryWidget widget, which
> would display the geometry type ((multi)point/line/polygon) and a
> button with an attached menu for clear geometry/copy as wkt/copy as
> geojson/paste geometry options. Actually, this is already written -
> see
> https://github.com/nyalldawson/QGIS/commit/fc7c79fb322bf3f6d681bb3a013efea941517767
> . This could be extended with the suggestions from
> http://hub.qgis.org/issues/10283 and the functionality from the
> plain-geometry-editor plugin.
>
> Then, we could add a new "Add record" button to the attribute table
> dialog for adding a new (empty) row, which would initially contain no
> geometry. That fixes the first part of my issues with geometry
> columns.
>
> On 4 April 2015 at 07:59, Régis Haubourg
> <regis.haubourg at eau-adour-garonne.fr> wrote:
>
> > The only thing annoying me currently is that QGIS "sees" all geometry
> > columns when this slow down attribute view a lot. In 1.8 or before (can't
> > remember), QGIS did not see them and that was fine to me, and avoided to
> > type SQL in DBmanager to add correctly the data in QGIS.
>
> This is my second big issue with geometry handling. I think the
> solution would be to use the proposed QgsGeometryWidget as the default
> editor for geometry columns in the dialog. This would avoid the issue
> of massive WKT strings choking the table and grinding QGIS to a halt.
> However, this relies on implementation of the suggestion from Martin
> here:
>
> http://osgeo-org.1560.x6.nabble.com/Multiple-geometry-columns-per-layer-tp5019573p5019895.html
>
> If this suggestion was implemented, then it also opens the possibility
> of having data defined geometry overrides for symbology/labeling. Eg,
> a table could have an additional line geometry column for label
> placement overrides. If this line geometry is not null then it would
> be used as the geometry for label placement, otherwise it would fall
> back to the actual feature's geometry. Think along the lines of
> manually curved labels for selected polygons...
>
> Nyall
> _______________________________________________
> 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/20150407/056b9bd4/attachment-0001.html>