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. ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
