[Qgis-developer] Background to Lable
Nikhil Murarka
nikhilmurarka14 at gmail.com
Thu Apr 2 09:42:09 PDT 2015
Thank you Andreas Neumann. My placement settings were wrong it was curved.
On Thu, Apr 2, 2015 at 10:42 AM, <qgis-developer-request at lists.osgeo.org>
wrote:
> Send Qgis-developer mailing list submissions to
> qgis-developer at lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> or, via email, send a message with subject or body 'help' to
> qgis-developer-request at lists.osgeo.org
>
> You can reach the person managing the list at
> qgis-developer-owner at lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Qgis-developer digest..."
>
>
> Today's Topics:
>
> 1. Re: Thoughts about multi-type tables in QGIS (Matthias Kuhn)
> 2. Re: Thoughts about multi-type tables in QGIS (Bo Victor Thomsen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 02 Apr 2015 14:59:12 +0200
> From: Matthias Kuhn <matthias at opengis.ch>
> To: qgis-developer at lists.osgeo.org
> Subject: Re: [Qgis-developer] Thoughts about multi-type tables in QGIS
> Message-ID: <551D3D20.3020404 at opengis.ch>
> Content-Type: text/plain; charset="windows-1252"
>
> I agree with Nathan, for algorithms, symbology and a lot of small things
> it will become very complicated.
>
> As an alternative approach, we could think about having some layer
> settings defined on group level (and maybe even a merged attribute table
> for the whole group). That would already make a lot of things easier to
> configure for multiple layers at once. We could even mark such a group
> as a "union layer group" or similar, so for algorithms that support this
> kind of thing it would be possible to offer such a "union layer group"
> as choice while all other things just continue to work.
>
> Matthias
>
> On 04/02/2015 02:30 PM, Nathan Woodrow wrote:
> >
> > I would not be in favour of supporting a many geometry type per layer
> > type setup, it just makes things a heap more complicated IMO for
> > little gain.
> >
> > Also makes your code a lot more complicated, you now have to check
> > each geometry for type because you are never sure what you will get.
> >
> > MapInfo did this and it was more a pain then a feature.
> >
> >
> > On Thu, 2 Apr 2015 10:11 pm Denis Rouzaud <denis.rouzaud at gmail.com
> > <mailto:denis.rouzaud at gmail.com>> wrote:
> >
> > Hi Olivier,
> >
> > I think you can easily extend your reasoning to the support of
> > multiple geometry columns in QGIS.
> > I believe that this would come in QGIS at some point.
> >
> > If QGIS 3 is getting closer, our company will support this feature.
> >
> > As you suggest, the layer could have different geometry types
> > and/or columns. This could be seen as sub-layer level for rendering:
> > layer > geometry types/columns > symbology rules
> >
> > I suppose this is quite a big change. Many things depends on the
> > geometry type in QGIS (like map map tools), and that would
> > represent a large API break.
> >
> > But, on my side, I believe it's a logic evolution for QGIS.
> >
> > Best wishes,
> >
> > Denis
> >
> >
> >
> >
> >
> >
> > On 04/02/2015 01:52 PM, 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 <mailto:
> Qgis-developer at lists.osgeo.org>
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> >>
> >
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org <mailto:
> Qgis-developer at lists.osgeo.org>
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> >
> > _______________________________________________
> > 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/20150402/fb00ce95/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: OpenPGP digital signature
> URL: <
> http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/fb00ce95/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 2
> Date: Thu, 02 Apr 2015 16:41:56 +0200
> From: Bo Victor Thomsen <bo.victor.thomsen at gmail.com>
> To: qgis-developer at lists.osgeo.org
> Subject: Re: [Qgis-developer] Thoughts about multi-type tables in QGIS
> Message-ID: <551D5534.6060904 at gmail.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> 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.
>
> A better approach is to have the possibility to let different QGIS
> layers share some common characteristics (for example labelling). And -
> of course - clean up the current errors in QGIS when splitting contents
> of data sources by object types.
>
> Regards
> Bo Victor Thomsen
> AestasGIS
> Denmark
>
> Den 02-04-2015 kl. 13:52 skrev Olivier Dalang:
> > 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
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/b59a2f9b/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> End of Qgis-developer Digest, Vol 114, Issue 6
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150402/0ca024ea/attachment-0001.html>
More information about the Qgis-developer
mailing list