<div dir="ltr">Thank you <span style="font-size:12.8000001907349px">Andreas Neumann. My placement settings were wrong it was curved.</span><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 2, 2015 at 10:42 AM, <span dir="ltr"><<a href="mailto:qgis-developer-request@lists.osgeo.org" target="_blank">qgis-developer-request@lists.osgeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send Qgis-developer mailing list submissions to<br>
<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:qgis-developer-request@lists.osgeo.org">qgis-developer-request@lists.osgeo.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:qgis-developer-owner@lists.osgeo.org">qgis-developer-owner@lists.osgeo.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Qgis-developer digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Thoughts about multi-type tables in QGIS (Matthias Kuhn)<br>
2. Re: Thoughts about multi-type tables in QGIS (Bo Victor Thomsen)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 02 Apr 2015 14:59:12 +0200<br>
From: Matthias Kuhn <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a>><br>
To: <a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a><br>
Subject: Re: [Qgis-developer] Thoughts about multi-type tables in QGIS<br>
Message-ID: <<a href="mailto:551D3D20.3020404@opengis.ch">551D3D20.3020404@opengis.ch</a>><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
I agree with Nathan, for algorithms, symbology and a lot of small things<br>
it will become very complicated.<br>
<br>
As an alternative approach, we could think about having some layer<br>
settings defined on group level (and maybe even a merged attribute table<br>
for the whole group). That would already make a lot of things easier to<br>
configure for multiple layers at once. We could even mark such a group<br>
as a "union layer group" or similar, so for algorithms that support this<br>
kind of thing it would be possible to offer such a "union layer group"<br>
as choice while all other things just continue to work.<br>
<br>
Matthias<br>
<br>
On 04/02/2015 02:30 PM, Nathan Woodrow wrote:<br>
><br>
> I would not be in favour of supporting a many geometry type per layer<br>
> type setup, it just makes things a heap more complicated IMO for<br>
> little gain.<br>
><br>
> Also makes your code a lot more complicated, you now have to check<br>
> each geometry for type because you are never sure what you will get.<br>
><br>
> MapInfo did this and it was more a pain then a feature.<br>
><br>
><br>
> On Thu, 2 Apr 2015 10:11 pm Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com">denis.rouzaud@gmail.com</a><br>
> <mailto:<a href="mailto:denis.rouzaud@gmail.com">denis.rouzaud@gmail.com</a>>> wrote:<br>
><br>
> Hi Olivier,<br>
><br>
> I think you can easily extend your reasoning to the support of<br>
> multiple geometry columns in QGIS.<br>
> I believe that this would come in QGIS at some point.<br>
><br>
> If QGIS 3 is getting closer, our company will support this feature.<br>
><br>
> As you suggest, the layer could have different geometry types<br>
> and/or columns. This could be seen as sub-layer level for rendering:<br>
> layer > geometry types/columns > symbology rules<br>
><br>
> I suppose this is quite a big change. Many things depends on the<br>
> geometry type in QGIS (like map map tools), and that would<br>
> represent a large API break.<br>
><br>
> But, on my side, I believe it's a logic evolution for QGIS.<br>
><br>
> Best wishes,<br>
><br>
> Denis<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On 04/02/2015 01:52 PM, Olivier Dalang wrote:<br>
>> Hi,<br>
>><br>
>> In some projects of mine, I work with multiple geometry types in<br>
>> one postgis table, using a column of type geometry(Geometry,4326).<br>
>> This is very well supported by postgis.<br>
>><br>
>> It is possible to load such a table in QGIS by manually selecting<br>
>> the geometry type you want to load. This means that to display<br>
>> all the features, you need to add the table three times, one for<br>
>> each feature type.<br>
>><br>
>> This works more or less. There are a few bugs though :<br>
>> - <a href="http://hub.qgis.org/issues/12499" target="_blank">http://hub.qgis.org/issues/12499</a> (you can edit other type's<br>
>> node with the node tool)<br>
>> - <a href="http://hub.qgis.org/issues/12500" target="_blank">http://hub.qgis.org/issues/12500</a> (other type's records are<br>
>> shown in the attribute table)<br>
>><br>
>> This also has some limitations. When having such a setup, it's<br>
>> pretty sure you'll want to have the same edit forms for all the<br>
>> layers. You'll also probably want the same filter, the same<br>
>> labels, the same actions, etc...<br>
>> The only thing you'd want to be able to define on a geometry type<br>
>> basis are the symbol (well, even the classification/colors/etc<br>
>> could be shared) and the label placement.<br>
>> For now, you must do all settings three times, because of this<br>
>> bug/feature request :<br>
>> - <a href="http://hub.qgis.org/issues/12303" target="_blank">http://hub.qgis.org/issues/12303</a> (copy/paste style from one<br>
>> geometry type to another)<br>
>><br>
>><br>
>> As you see, support multiple geometry types in QGIS is not perfect.<br>
>><br>
>> Of course it's possible to fix the bugs/pr, and there are some<br>
>> workarounds (postgis view instead of tables) but maybe it's also<br>
>> worth thinking a bit more in depth about this.<br>
>><br>
>> We could consider point/line/polygons as subcategories/sublayers<br>
>> of a layer. A shapefile or a mono-typed table would have only one<br>
>> of those sublayer, but a postgis table could perfectly have the<br>
>> three. Most of the settings would be defined at the layer level,<br>
>> while only some settings would be defined at the subcategory level.<br>
>><br>
>> This is probably especially relevant when thinking long term (the<br>
>> day we support 3D, curves, etc...).<br>
>><br>
>><br>
>> What do you think ?<br>
>> Do you think the relation 1 layer = 1 geometry type will hold ?<br>
>><br>
>> I think we inherited this from the old shapefile format, but most<br>
>> data sources QGIS handles don't have this limitation. I also<br>
>> think it does not hold with quite a lot of modern GIS uses<br>
>> (especially web related, think of openstreetmaps for instance).<br>
>><br>
>> There's this feature request (6th oldest open issue on the<br>
>> tracker) about postgis geometry collections :<br>
>> <a href="http://hub.qgis.org/issues/167" target="_blank">http://hub.qgis.org/issues/167</a><br>
>><br>
>><br>
>> Best,<br>
>><br>
>> Olivier<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Qgis-developer mailing list<br>
>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a> <mailto:<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a> <mailto:<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/fb00ce95/attachment-0001.html" target="_blank">http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/fb00ce95/attachment-0001.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: OpenPGP digital signature<br>
URL: <<a href="http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/fb00ce95/attachment-0001.pgp" target="_blank">http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/fb00ce95/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 02 Apr 2015 16:41:56 +0200<br>
From: Bo Victor Thomsen <<a href="mailto:bo.victor.thomsen@gmail.com">bo.victor.thomsen@gmail.com</a>><br>
To: <a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a><br>
Subject: Re: [Qgis-developer] Thoughts about multi-type tables in QGIS<br>
Message-ID: <<a href="mailto:551D5534.6060904@gmail.com">551D5534.6060904@gmail.com</a>><br>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br>
<br>
As an old MapInfo user/developer my opion is: Don't do it. It has always<br>
been a problem in MapInfo and it will be a problem in QGIS - if<br>
implemented.<br>
<br>
A better approach is to have the possibility to let different QGIS<br>
layers share some common characteristics (for example labelling). And -<br>
of course - clean up the current errors in QGIS when splitting contents<br>
of data sources by object types.<br>
<br>
Regards<br>
Bo Victor Thomsen<br>
AestasGIS<br>
Denmark<br>
<br>
Den 02-04-2015 kl. 13:52 skrev Olivier Dalang:<br>
> Hi,<br>
><br>
> In some projects of mine, I work with multiple geometry types in one<br>
> postgis table, using a column of type geometry(Geometry,4326).<br>
> This is very well supported by postgis.<br>
><br>
> It is possible to load such a table in QGIS by manually selecting the<br>
> geometry type you want to load. This means that to display all the<br>
> features, you need to add the table three times, one for each feature<br>
> type.<br>
><br>
> This works more or less. There are a few bugs though :<br>
> - <a href="http://hub.qgis.org/issues/12499" target="_blank">http://hub.qgis.org/issues/12499</a> (you can edit other type's node<br>
> with the node tool)<br>
> - <a href="http://hub.qgis.org/issues/12500" target="_blank">http://hub.qgis.org/issues/12500</a> (other type's records are shown in<br>
> the attribute table)<br>
><br>
> This also has some limitations. When having such a setup, it's pretty<br>
> sure you'll want to have the same edit forms for all the layers.<br>
> You'll also probably want the same filter, the same labels, the same<br>
> actions, etc...<br>
> The only thing you'd want to be able to define on a geometry type<br>
> basis are the symbol (well, even the classification/colors/etc could<br>
> be shared) and the label placement.<br>
> For now, you must do all settings three times, because of this<br>
> bug/feature request :<br>
> - <a href="http://hub.qgis.org/issues/12303" target="_blank">http://hub.qgis.org/issues/12303</a> (copy/paste style from one geometry<br>
> type to another)<br>
><br>
><br>
> As you see, support multiple geometry types in QGIS is not perfect.<br>
><br>
> Of course it's possible to fix the bugs/pr, and there are some<br>
> workarounds (postgis view instead of tables) but maybe it's also worth<br>
> thinking a bit more in depth about this.<br>
><br>
> We could consider point/line/polygons as subcategories/sublayers of a<br>
> layer. A shapefile or a mono-typed table would have only one of those<br>
> sublayer, but a postgis table could perfectly have the three. Most of<br>
> the settings would be defined at the layer level, while only some<br>
> settings would be defined at the subcategory level.<br>
><br>
> This is probably especially relevant when thinking long term (the day<br>
> we support 3D, curves, etc...).<br>
><br>
><br>
> What do you think ?<br>
> Do you think the relation 1 layer = 1 geometry type will hold ?<br>
><br>
> I think we inherited this from the old shapefile format, but most data<br>
> sources QGIS handles don't have this limitation. I also think it does<br>
> not hold with quite a lot of modern GIS uses (especially web related,<br>
> think of openstreetmaps for instance).<br>
><br>
> There's this feature request (6th oldest open issue on the tracker)<br>
> about postgis geometry collections : <a href="http://hub.qgis.org/issues/167" target="_blank">http://hub.qgis.org/issues/167</a><br>
><br>
><br>
> Best,<br>
><br>
> Olivier<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/b59a2f9b/attachment.html" target="_blank">http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/b59a2f9b/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
End of Qgis-developer Digest, Vol 114, Issue 6<br>
**********************************************<br>
</blockquote></div><br></div></div>