In general the labels are accumulated in a collection during rendering, and rendered all together. If there is no priority, they are rendered in the order they are added, otherwise they get sorted by priority. What you seem to want is to force labels of a given layer to display regardless of conflict, but mark their bounds as occupied for labels showing later on. This functionality is not available, but could be implemented using some new vendor option (e.g., forceLabel=true/false)
Cheers Andrea On Thu, Nov 21, 2019 at 5:50 PM Nikolaos Pringouris <nprig...@gmail.com> wrote: > > So essentially what I understand is that labels with turned off conflict > resolution are not considred at all when labels with conflict resolutionon > are checked for rendering. > However the remaining labels if they belong to different layers (that is > have distinct SLDs) are checked sequentially? I.e.the rendering process > progress as follows: > 1. features of layer B are first rendered (according to their > textsymbolizer and/or vendor options) > 2. features of layer C afterwards considering all placements of layer B > labels > 3. features of layer D afterwards consideringlayer C and so on ... > (things become more complicated since an sld may contain multiple text > symbolizers for the same featureType) > That is how the ordering of resolution (among the layers not the features > within a layer) is decided supposing no special priority is set in any SLD? > > > Στις Πέμ, 21 Νοε 2019 στις 5:56 μ.μ., ο/η Jody Garnett < >> jody.garn...@gmail.com> έγραψε: >> >>> Nikolaos: >>> >>> Moved over to the user list (trust you are subscribed). >>> >>> To answer your question - if you turn off conflict resolution the labels >>> are just blindly drawn (as if they were symbols). So you could use this as >>> a way to use emoji to represent point locations for example :P >>> >>> When conflict resolution is used each label "reserves" a bounding box as >>> it is generated. The rendering engine takes all the proposed labels and >>> does its best to draw them in a pleasing manner on the screen. You have a >>> whole bunch of control on how this happens using vendor options when >>> styling. >>> -- >>> Jody Garnett >>> >>> >>> On Thu, 21 Nov 2019 at 05:34, Jody Garnett <jody.garn...@gmail.com> >>> wrote: >>> >>>> You may wish to set a high label priority to strongly prefer labels >>>> from one layer. >>>> >>>> We should move this discussion to geotools user list please. This list >>>> focuses on those working on codebase. >>>> >>>> On Thu, Nov 21, 2019 at 2:06 AM Nikolaos Pringouris <nprig...@gmail.com> >>>> wrote: >>>> >>>>> Hi, >>>>> I would like to request some enlightment regarding the way conflict >>>>> resolution behaves during rendering of labels in geotools. >>>>> the user guide mentions the following: >>>>> conflictResolution(true): Enables conflict resolution (default, true) >>>>> meaning no two labels will be allowed to overlap. Symbolizers with >>>>> conflict >>>>> resolution off are considered outside of the conflict resolution game, >>>>> they >>>>> don’t reserve area and can overlap with other labels. >>>>> >>>>> what does the above means? >>>>> Supposing that we have multiple layers and want in layer A labels >>>>> always to be rendered. It is rational to set conflictResolution=false. All >>>>> other layers i.e B*, C* have this flag set to true meaning they >>>>> participate in conflict resolution. >>>>> The fact that in A conflict is disabled means that during rendering of >>>>> C and B A's label are completely ignored (consider as not existent)) or >>>>> not? Is the rendering order of layers involved somehow in the process? >>>>> I.e. >>>>> if layer B is rendered after A will it consider the placement of A's >>>>> labels >>>>> or not? Based on some preliminary testing it seems that not is the case. >>>>> Still is there some way or option to achieve this (that is A's label >>>>> always rendered but subsequent rendered layers labels do not overlap with >>>>> A's labels) or we need to alter completely the implementation? >>>>> >>>>> thanks in advanced >>>>> _______________________________________________ >>>>> GeoTools-Devel mailing list >>>>> geotools-de...@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>>> >>>> -- >>>> -- >>>> Jody Garnett >>>> >>> _______________________________________________ > GeoTools-GT2-Users mailing list > GeoTools-GT2-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > -- Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.*
_______________________________________________ GeoTools-GT2-Users mailing list GeoTools-GT2-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
