[Geoserver-devel] Contributing a new labeller for GeoServer/GeoTools

GeoServer GeoServer Developer
1

Hi,
lately I've bee working on a new LabelCache implementation
for a customer of OpenGeo. The LabelCache in question is
a heavy refactoring of the existing DefaultLabelCache,
but changes are so deep that it's mid-way between an
improvement and a total rewrite.
The new features I'm implementing are:
- label displacement on linear features: in case of conflict
   with an existing label, the labeller tries to move the
   label point up to x pixels away (along the line) to find
   a free location
- label repetition on long linear features: the first label
   point in the middle of the line, the others x pixels away
   from each other (pixels measured along the line)
- multiple labels per line group: grouping usually results in
   merging a group of lines into a smaller set of longer lines.
   Usually only the longest gets labelled, with this option all
   get labelled
- in group min distance for linear features: make sure there
   is a minimum cartesian distance between every two labels in
   a group. This helps when a group is made up of multiple
   non subsequent lines, and when there is a single line that
   makes a very close U turn (eventually going back on itself,
   like bus routes often do).
- label along a line (aka curved labels)
- multi line labels, with split on newlines and when
   a certain maximum line length is reached (splitting on word
   boundaries)

So far I've implemented the displacement and the line group
related features, and started working on curved labels (whether
I'll work on multiline ones is still on the hook).

Now, the question is, how do I contribute the change back
into GeoServer/GeoTools? The change is tentatively scheduled
to go into GeoServer 1.7.2 (as the new default labeller),
yet it's quite a change.

GeoServer wise, I'd propose to make it the default labeller,
but allow an option (System variable) to disable it and go back
to the old labeller. I could even contribute it to 1.7.1
and play it the other way, that is, have the new labeller disabled
by default, and enabled when a certain option is set, to gather
early feedback.

GeoTools wise, I guess I can contribute it on 2.5.x and trunk
under a different name, make it the default labeller on trunk,
and just let it as an option on 2.5.x (the label cache used by
the renderer is already customizable, can be set as a rendering
hint).

So... opinions?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

Ciao Andrea,
I would suggest to make this available as soon as possible, but not as
the default option so that people can test it evaluate it now without
waiting too much.

I am not sure about the geotools part though. The 2.5. branch is a
stable one and the renderer is pretty core. Are there any changes to
the lib involved?

Simone.
-------------------------------------------------------
Eng. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

-------------------------------------------------------

On Thu, Nov 13, 2008 at 11:36 AM, Andrea Aime <aaime@anonymised.com> wrote:

Hi,
lately I've bee working on a new LabelCache implementation
for a customer of OpenGeo. The LabelCache in question is
a heavy refactoring of the existing DefaultLabelCache,
but changes are so deep that it's mid-way between an
improvement and a total rewrite.
The new features I'm implementing are:
- label displacement on linear features: in case of conflict
  with an existing label, the labeller tries to move the
  label point up to x pixels away (along the line) to find
  a free location
- label repetition on long linear features: the first label
  point in the middle of the line, the others x pixels away
  from each other (pixels measured along the line)
- multiple labels per line group: grouping usually results in
  merging a group of lines into a smaller set of longer lines.
  Usually only the longest gets labelled, with this option all
  get labelled
- in group min distance for linear features: make sure there
  is a minimum cartesian distance between every two labels in
  a group. This helps when a group is made up of multiple
  non subsequent lines, and when there is a single line that
  makes a very close U turn (eventually going back on itself,
  like bus routes often do).
- label along a line (aka curved labels)
- multi line labels, with split on newlines and when
  a certain maximum line length is reached (splitting on word
  boundaries)

So far I've implemented the displacement and the line group
related features, and started working on curved labels (whether
I'll work on multiline ones is still on the hook).

Now, the question is, how do I contribute the change back
into GeoServer/GeoTools? The change is tentatively scheduled
to go into GeoServer 1.7.2 (as the new default labeller),
yet it's quite a change.

GeoServer wise, I'd propose to make it the default labeller,
but allow an option (System variable) to disable it and go back
to the old labeller. I could even contribute it to 1.7.1
and play it the other way, that is, have the new labeller disabled
by default, and enabled when a certain option is set, to gather
early feedback.

GeoTools wise, I guess I can contribute it on 2.5.x and trunk
under a different name, make it the default labeller on trunk,
and just let it as an option on 2.5.x (the label cache used by
the renderer is already customizable, can be set as a rendering
hint).

So... opinions?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

3

Simone Giannecchini ha scritto:

Ciao Andrea,
I would suggest to make this available as soon as possible, but not as
the default option so that people can test it evaluate it now without
waiting too much.

I am not sure about the geotools part though. The 2.5. branch is a
stable one and the renderer is pretty core. Are there any changes to
the lib involved?

Nope, I would just add a new set of classes (the new labeller is
split into a few classes that do handle collision detection,
label painting, linestring walking and general orchestration
instead of being one big bad class).

The renderer already accepts a label cache implementation as an
option, so the current behaviour would not be changed, it would
just be an extra option.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

Not that I know anything about how our labeling works :), but I think the approach you propose is a good one, ie an option on 2.5.x and the default on trunk.

Is there any instances where the new labeler might perform worse than the old? I ask b/c if so i think the option makes sense b/c some people might be in for a surprise when updating. If it will perform the same or better all the time then I am ok with changing the default.

My 2c,

-Justin

Andrea Aime wrote:

Hi,
lately I've bee working on a new LabelCache implementation
for a customer of OpenGeo. The LabelCache in question is
a heavy refactoring of the existing DefaultLabelCache,
but changes are so deep that it's mid-way between an
improvement and a total rewrite.
The new features I'm implementing are:
- label displacement on linear features: in case of conflict
   with an existing label, the labeller tries to move the
   label point up to x pixels away (along the line) to find
   a free location
- label repetition on long linear features: the first label
   point in the middle of the line, the others x pixels away
   from each other (pixels measured along the line)
- multiple labels per line group: grouping usually results in
   merging a group of lines into a smaller set of longer lines.
   Usually only the longest gets labelled, with this option all
   get labelled
- in group min distance for linear features: make sure there
   is a minimum cartesian distance between every two labels in
   a group. This helps when a group is made up of multiple
   non subsequent lines, and when there is a single line that
   makes a very close U turn (eventually going back on itself,
   like bus routes often do).
- label along a line (aka curved labels)
- multi line labels, with split on newlines and when
   a certain maximum line length is reached (splitting on word
   boundaries)

So far I've implemented the displacement and the line group
related features, and started working on curved labels (whether
I'll work on multiline ones is still on the hook).

Now, the question is, how do I contribute the change back
into GeoServer/GeoTools? The change is tentatively scheduled
to go into GeoServer 1.7.2 (as the new default labeller),
yet it's quite a change.

GeoServer wise, I'd propose to make it the default labeller,
but allow an option (System variable) to disable it and go back
to the old labeller. I could even contribute it to 1.7.1
and play it the other way, that is, have the new labeller disabled
by default, and enabled when a certain option is set, to gather
early feedback.

GeoTools wise, I guess I can contribute it on 2.5.x and trunk
under a different name, make it the default labeller on trunk,
and just let it as an option on 2.5.x (the label cache used by
the renderer is already customizable, can be set as a rendering
hint).

So... opinions?
Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

Justin Deoliveira ha scritto:

Not that I know anything about how our labeling works :), but I think the approach you propose is a good one, ie an option on 2.5.x and the default on trunk.

Is there any instances where the new labeler might perform worse than the old? I ask b/c if so i think the option makes sense b/c some people might be in for a surprise when updating. If it will perform the same or better all the time then I am ok with changing the default.

Hum, I haven't done benchmarks, but everything being equal (same parameters) the new labeller should be faster. When you start
activating extra functionality it will become slower.
My idea was to enable by default a small displacement over lines
(say 50 pixels) so that performance stays roughly the same with
some extra goodies in the quality department.

Anyways, I'll have to run some benchmarks to confirm the above,
at the moment it's just some speculation.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

6

I am +1 to have it optional and 2.5.x and default on trunk.
Interested in seeing benchmarks :-).

Simone.
-------------------------------------------------------
Eng. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

-------------------------------------------------------

On Thu, Nov 13, 2008 at 11:28 PM, Andrea Aime <aaime@anonymised.com> wrote:

Justin Deoliveira ha scritto:

Not that I know anything about how our labeling works :), but I think
the approach you propose is a good one, ie an option on 2.5.x and the
default on trunk.

Is there any instances where the new labeler might perform worse than
the old? I ask b/c if so i think the option makes sense b/c some people
might be in for a surprise when updating. If it will perform the same or
better all the time then I am ok with changing the default.

Hum, I haven't done benchmarks, but everything being equal (same
parameters) the new labeller should be faster. When you start
activating extra functionality it will become slower.
My idea was to enable by default a small displacement over lines
(say 50 pixels) so that performance stays roughly the same with
some extra goodies in the quality department.

Anyways, I'll have to run some benchmarks to confirm the above,
at the moment it's just some speculation.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel