[Geoserver-devel] Priority Labeling (Lite/SLD)

GeoServer GeoServer Developer
1

After talking with James, I've decided to start improving the Labeler
(again).

My first improvement will be to add "priority labeling". Right now,
labeling order is random (ie. based on the hashtable). I'd like to
change it so I can give features different "priority" values so they
show up "first".

Here's a simple example;

I have a city DB (point, population, name) and, on my map, i want "New
York" (population 8,000,000) to be drawn before "Yonkers" (population
200,000). These 2 cities are very close, so if only one can be drawn I
want New York to be drawn instead of it being "random".

Another example would be to use "<Function name='geomArea'>" to so you
can have "Central Park" labeled instead of "The Pool" (a little lake in
the middle of the park.

This isnt too difficult a change;

1. add an expression "labelPriority" to TextSymbolizer
      + default = 1,000 (or what have you)

2. Modify the HashTable so that it also stores the priority value
      + for items-with-the-same-label-grouping I think we should use an
"add" priority strategy for the group. In the future, we'll have ways
of turning off grouping.

3. Modify the labeler so instead of just grabbing stuff from the
hashtable, it sorts it on the priority value

4. modify the SLD parse so it has a "<Priority>" tag with an
<Expression> inside it

5. update the geoserver SLD validator so the .xsd reflects the extra
Priority tag.

You'll notice that the results will be the same as they are now if
people dont put a "<Priority>" tag in, so this is backwards compatible.

There could be some layer-to-layer conflicts, but thats up to the people
writing the SLDs deal with.

I believe the PMC already gave an okay to these changes a while ago, I
(or anyone else) havent had a chance to do them.

Other improvements will be things like:
* grouping - on/off
* always render (for people who dont care if the label overlaps)

I'd like to see the labeling get pretty good, since its probably one of
the top "missing pieces" in Geotools (apart from really good raster
support - which others are currently working on). Does anyone have any
comments or other things that they want supported? Anyone willing to
help (ie. programming, testing, giving feedback, trying it on their
data to see how the results look)...

NOTE: THE BIGGEST PROBLEM ABOUT THIS IS THAT OUR SLD FILE WILL NO LONGER
BE 100% OGC 1.0 COMPATIBLE.

We've already discussed this and noone (except me) has had a problem
with it. But, we really dont have any other way of doing this.

dave

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

2

This is very interesting to me. I would also like to see some concept
of turning off all labels based on the zoom level.

I'm a little confused as to whether this works with all feature types,
and if so how would you specify the constraints (e.g. from a PostGIS
database).

The data we are labeling is primarily roads and buildings, so it would
make the most since to prioritize based on feature size. This leads to
the simple inclusion of the zoom concept since you could tell it not
to label if the feature is below some threshold.

What changes would need to be made to uDig in order to support this?
Or should I direct that to the uDig list?

I will be happy to do some testing, and might have some time to help
with the uDig side as well.

Cole Markham

On 8/23/05, dblasby@anonymised.com <dblasby@anonymised.com> wrote:

After talking with James, I've decided to start improving the Labeler
(again).

My first improvement will be to add "priority labeling". Right now,
labeling order is random (ie. based on the hashtable). I'd like to
change it so I can give features different "priority" values so they
show up "first".

Here's a simple example;

I have a city DB (point, population, name) and, on my map, i want "New
York" (population 8,000,000) to be drawn before "Yonkers" (population
200,000). These 2 cities are very close, so if only one can be drawn I
want New York to be drawn instead of it being "random".

Another example would be to use "<Function name='geomArea'>" to so you
can have "Central Park" labeled instead of "The Pool" (a little lake in
the middle of the park.

This isnt too difficult a change;

1. add an expression "labelPriority" to TextSymbolizer
      + default = 1,000 (or what have you)

2. Modify the HashTable so that it also stores the priority value
      + for items-with-the-same-label-grouping I think we should use an
"add" priority strategy for the group. In the future, we'll have ways
of turning off grouping.

3. Modify the labeler so instead of just grabbing stuff from the
hashtable, it sorts it on the priority value

4. modify the SLD parse so it has a "<Priority>" tag with an
<Expression> inside it

5. update the geoserver SLD validator so the .xsd reflects the extra
Priority tag.

You'll notice that the results will be the same as they are now if
people dont put a "<Priority>" tag in, so this is backwards compatible.

There could be some layer-to-layer conflicts, but thats up to the people
writing the SLDs deal with.

I believe the PMC already gave an okay to these changes a while ago, I
(or anyone else) havent had a chance to do them.

Other improvements will be things like:
* grouping - on/off
* always render (for people who dont care if the label overlaps)

I'd like to see the labeling get pretty good, since its probably one of
the top "missing pieces" in Geotools (apart from really good raster
support - which others are currently working on). Does anyone have any
comments or other things that they want supported? Anyone willing to
help (ie. programming, testing, giving feedback, trying it on their
data to see how the results look)...

NOTE: THE BIGGEST PROBLEM ABOUT THIS IS THAT OUR SLD FILE WILL NO LONGER
BE 100% OGC 1.0 COMPATIBLE.

We've already discussed this and noone (except me) has had a problem
with it. But, we really dont have any other way of doing this.

dave

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

3

Dave,

Cole is talking about something called "Label by Scale" in Geomedia.
ArcGIS handles it better than Geomedia by some automatic scale calc.
This is real important as it clutters up the whole graphics if rendered
without zoomed in scale. Rendering labels takes a horrible amount of
time otherwise. I think most people here know about it.

Thansk

--- Cole Markham <markhamc@anonymised.com> wrote:

This is very interesting to me. I would also like to see some concept
of turning off all labels based on the zoom level.

I'm a little confused as to whether this works with all feature
types,
and if so how would you specify the constraints (e.g. from a PostGIS
database).

The data we are labeling is primarily roads and buildings, so it
would
make the most since to prioritize based on feature size. This leads
to
the simple inclusion of the zoom concept since you could tell it not
to label if the feature is below some threshold.

What changes would need to be made to uDig in order to support this?
Or should I direct that to the uDig list?

I will be happy to do some testing, and might have some time to help
with the uDig side as well.

Cole Markham

On 8/23/05, dblasby@anonymised.com <dblasby@anonymised.com> wrote:
> After talking with James, I've decided to start improving the
Labeler
> (again).
>
> My first improvement will be to add "priority labeling". Right
now,
> labeling order is random (ie. based on the hashtable). I'd like to
> change it so I can give features different "priority" values so
they
> show up "first".
>
> Here's a simple example;
>
> I have a city DB (point, population, name) and, on my map, i want
"New
> York" (population 8,000,000) to be drawn before "Yonkers"
(population
> 200,000). These 2 cities are very close, so if only one can be
drawn I
> want New York to be drawn instead of it being "random".
>
> Another example would be to use "<Function name='geomArea'>" to so
you
> can have "Central Park" labeled instead of "The Pool" (a little
lake in
> the middle of the park.
>
> This isnt too difficult a change;
>
> 1. add an expression "labelPriority" to TextSymbolizer
> + default = 1,000 (or what have you)
>
> 2. Modify the HashTable so that it also stores the priority value
> + for items-with-the-same-label-grouping I think we should
use an
> "add" priority strategy for the group. In the future, we'll have
ways
> of turning off grouping.
>
> 3. Modify the labeler so instead of just grabbing stuff from the
> hashtable, it sorts it on the priority value
>
> 4. modify the SLD parse so it has a "<Priority>" tag with an
> <Expression> inside it
>
> 5. update the geoserver SLD validator so the .xsd reflects the
extra
> Priority tag.
>
>
> You'll notice that the results will be the same as they are now if
> people dont put a "<Priority>" tag in, so this is backwards
compatible.
>
> There could be some layer-to-layer conflicts, but thats up to the
people
> writing the SLDs deal with.
>
>
> I believe the PMC already gave an okay to these changes a while
ago, I
> (or anyone else) havent had a chance to do them.
>
> Other improvements will be things like:
> * grouping - on/off
> * always render (for people who dont care if the label overlaps)
>
> I'd like to see the labeling get pretty good, since its probably
one of
> the top "missing pieces" in Geotools (apart from really good raster
> support - which others are currently working on). Does anyone have
any
> comments or other things that they want supported? Anyone willing
to
> help (ie. programming, testing, giving feedback, trying it on their
> data to see how the results look)...
>
> NOTE: THE BIGGEST PROBLEM ABOUT THIS IS THAT OUR SLD FILE WILL NO
LONGER
> BE 100% OGC 1.0 COMPATIBLE.
>
> We've already discussed this and noone (except me) has had a
problem
> with it. But, we really dont have any other way of doing this.
>
>
> dave

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

4

With SLD you can specify a rule with a MinScaleDenominator and a
MaxScaleDenominator - above the max don't render labels, below do. You
can specify any type of rendering within a rule, and can control it with
min/max, or with a Filter (so that you could just render labels on roads
over a certain length if you wanted to - you can filter on any attribute,
and even use functions, I think you could do length(geom)).

Chris

On Tue, 23 Aug 2005, Amit Kulkarni wrote:

Dave,

Cole is talking about something called "Label by Scale" in Geomedia.
ArcGIS handles it better than Geomedia by some automatic scale calc.
This is real important as it clutters up the whole graphics if rendered
without zoomed in scale. Rendering labels takes a horrible amount of
time otherwise. I think most people here know about it.

Thansk

--- Cole Markham <markhamc@anonymised.com> wrote:

> This is very interesting to me. I would also like to see some concept
> of turning off all labels based on the zoom level.
>
> I'm a little confused as to whether this works with all feature
> types,
> and if so how would you specify the constraints (e.g. from a PostGIS
> database).
>
> The data we are labeling is primarily roads and buildings, so it
> would
> make the most since to prioritize based on feature size. This leads
> to
> the simple inclusion of the zoom concept since you could tell it not
> to label if the feature is below some threshold.
>
> What changes would need to be made to uDig in order to support this?
> Or should I direct that to the uDig list?
>
> I will be happy to do some testing, and might have some time to help
> with the uDig side as well.
>
> Cole Markham
>
> On 8/23/05, dblasby@anonymised.com <dblasby@anonymised.com> wrote:
> > After talking with James, I've decided to start improving the
> Labeler
> > (again).
> >
> > My first improvement will be to add "priority labeling". Right
> now,
> > labeling order is random (ie. based on the hashtable). I'd like to
> > change it so I can give features different "priority" values so
> they
> > show up "first".
> >
> > Here's a simple example;
> >
> > I have a city DB (point, population, name) and, on my map, i want
> "New
> > York" (population 8,000,000) to be drawn before "Yonkers"
> (population
> > 200,000). These 2 cities are very close, so if only one can be
> drawn I
> > want New York to be drawn instead of it being "random".
> >
> > Another example would be to use "<Function name='geomArea'>" to so
> you
> > can have "Central Park" labeled instead of "The Pool" (a little
> lake in
> > the middle of the park.
> >
> > This isnt too difficult a change;
> >
> > 1. add an expression "labelPriority" to TextSymbolizer
> > + default = 1,000 (or what have you)
> >
> > 2. Modify the HashTable so that it also stores the priority value
> > + for items-with-the-same-label-grouping I think we should
> use an
> > "add" priority strategy for the group. In the future, we'll have
> ways
> > of turning off grouping.
> >
> > 3. Modify the labeler so instead of just grabbing stuff from the
> > hashtable, it sorts it on the priority value
> >
> > 4. modify the SLD parse so it has a "<Priority>" tag with an
> > <Expression> inside it
> >
> > 5. update the geoserver SLD validator so the .xsd reflects the
> extra
> > Priority tag.
> >
> >
> > You'll notice that the results will be the same as they are now if
> > people dont put a "<Priority>" tag in, so this is backwards
> compatible.
> >
> > There could be some layer-to-layer conflicts, but thats up to the
> people
> > writing the SLDs deal with.
> >
> >
> > I believe the PMC already gave an okay to these changes a while
> ago, I
> > (or anyone else) havent had a chance to do them.
> >
> > Other improvements will be things like:
> > * grouping - on/off
> > * always render (for people who dont care if the label overlaps)
> >
> > I'd like to see the labeling get pretty good, since its probably
> one of
> > the top "missing pieces" in Geotools (apart from really good raster
> > support - which others are currently working on). Does anyone have
> any
> > comments or other things that they want supported? Anyone willing
> to
> > help (ie. programming, testing, giving feedback, trying it on their
> > data to see how the results look)...
> >
> > NOTE: THE BIGGEST PROBLEM ABOUT THIS IS THAT OUR SLD FILE WILL NO
> LONGER
> > BE 100% OGC 1.0 COMPATIBLE.
> >
> > We've already discussed this and noone (except me) has had a
> problem
> > with it. But, we really dont have any other way of doing this.
> >
> >
> > dave

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--