Hi,
as you may know, Geoserver has issues dealing properly with tiled
requests, in that labels and other symbols may be cut, moved or
replicated from tile to tile. I'm cc'ing gt2-devel because uDiggers
may be interested in this discussion, since it would hit their rendering
subsystem as well.
There are two issues here ar work:
a) labelling manager tries to fit all labels in the currently rendered
bbox, which generates the "jumping labels" issue.
b) some symbols are not rendered because their geometry falls out of
the current bbox, this is an issue because its rendering may be
bigger than the geomtry (think points rendered as big circles).
b) can be handled by extending the area that gets really rendered using
the so called (in ka-map and tile-cache) meta-buffer.
The users specifies a buffer distance used to enlarge the current
rendering area, in order to catch the extra geometries.
The buffer is specified in pixels, which makes sense since rendering
elements widths are pixels too.
So, to handle this, we can simply add a custom parameter to WMS
requests. We keep on returning the same image, but we use a larger
area than the rendered one to look for geometries to be rendered (a
larger bbox filter).
The StreamingRender should be extended to get a meta-buffer hint as
well.
a) is probably the wrong default behavior to start with. I mean,
bbox fitting is ok during printing, but both uDig and Geoserver do
render images that are parts of a bigger map.
One way would be to simply have the labels ignore bbox limits unless
an "optimize for printing" flag is set (as an extra parameter, useful
when rendering to PDF for example).
This is easy, but may have a glitch a the actual map borders,
because labels may well go beyond the total MapContext area...
so another way could be to keep on adjusting label position, but against
the MapContext bbox instead of using the current rendering bbox.
This should be ok for uDig, less so for Geoserver, since MapContext
gets re-created (we cannot cache the bbox as a result), and usually
we don't see the real map extent, clients such as OpenLayer make
separate request for separate layers.
So, the overall bbox may well become a custom parameter as well,
so that we can use a global bbox on the web as well, and avoid
having to recompute bounds at each request.
I'd like to have feedback on this, what do you think?
Cheers
Andrea
a) is probably the wrong default behavior to start with. I mean,
bbox fitting is ok during printing, but both uDig and Geoserver do
render images that are parts of a bigger map.
One way would be to simply have the labels ignore bbox limits unless
an "optimize for printing" flag is set (as an extra parameter, useful
when rendering to PDF for example).
This is easy, but may have a glitch a the actual map borders,
because labels may well go beyond the total MapContext area...
so another way could be to keep on adjusting label position, but against
the MapContext bbox instead of using the current rendering bbox.
This should be ok for uDig, less so for Geoserver, since MapContext
gets re-created (we cannot cache the bbox as a result), and usually
we don't see the real map extent, clients such as OpenLayer make
separate request for separate layers.
So, the overall bbox may well become a custom parameter as well,
so that we can use a global bbox on the web as well, and avoid
having to recompute bounds at each request.
My concern with using the MapContext is that in uDig we use a number of MapContexts, one for each layer but the entire MapBounds may be larger since the other layers would be in seperate MapContext objects. And same as Geotools we keep recreating the MapContext object.
Jesse
Jesse Eichar ha scritto:
a) is probably the wrong default behavior to start with. I mean,
bbox fitting is ok during printing, but both uDig and Geoserver do
render images that are parts of a bigger map.
One way would be to simply have the labels ignore bbox limits unless
an "optimize for printing" flag is set (as an extra parameter, useful
when rendering to PDF for example).
This is easy, but may have a glitch a the actual map borders,
because labels may well go beyond the total MapContext area...
so another way could be to keep on adjusting label position, but against
the MapContext bbox instead of using the current rendering bbox.
This should be ok for uDig, less so for Geoserver, since MapContext
gets re-created (we cannot cache the bbox as a result), and usually
we don't see the real map extent, clients such as OpenLayer make
separate request for separate layers.
So, the overall bbox may well become a custom parameter as well,
so that we can use a global bbox on the web as well, and avoid
having to recompute bounds at each request.
My concern with using the MapContext is that in uDig we use a number of MapContexts, one for each layer but the entire MapBounds may be larger since the other layers would be in seperate MapContext objects. And same as Geotools we keep recreating the MapContext object.
So we're in the same boat, you need to use LABELING_MODE = SEAMLESS
or LABELING_MODE = DATA_BOUNDS and then provide the LABELING_BOUNDS
hint as well. You can compute the LABELING_BOUNDS before rendering,
cache it, update it when you add/remove layers.
Would that work for you?
Oh, btw, removing bbox label constraints will get us a pretty nice
speed improvement. On the Geoserver tiger demo all the intersections
needed to contraint labels into the rendering bbox are sucking
20-25% of the whole rendering time, and that's for very simple
line geometries (the bigger hitter is still the stroked shape
computation needed to draw halo, I have ideas on how to optimize
that one too, but for the moment I don't have time).
Cheers
Andrea
Le Mercredi 3 Janvier 2007 19:52, Andrea Aime a écrit :
I'd like to have feedback on this, what do you think?
I might be wrong, but reading the thread, it seems that the following links
could be interesting to follow :
http://labs.metacarta.com/wms-c/
http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation
On the metacarta page, there is a python wrapper that "builds" a tiles cache
on the fly above a standard WMS (I believe this one could be rewritten as a
java servlet or better as a geoserver plugin ?-). Furthermore as MapBuilder
incorporates OpenLayers, the tiled WMS could be tested directly.
Hope this helps
Cheers
All the best,
Andrea
didier
Jesse Eichar ha scritto:
a) is probably the wrong default behavior to start with. I mean,
bbox fitting is ok during printing, but both uDig and Geoserver do
render images that are parts of a bigger map.
One way would be to simply have the labels ignore bbox limits unless
an "optimize for printing" flag is set (as an extra parameter, useful
when rendering to PDF for example).
This is easy, but may have a glitch a the actual map borders,
because labels may well go beyond the total MapContext area...
so another way could be to keep on adjusting label position, but against
the MapContext bbox instead of using the current rendering bbox.
This should be ok for uDig, less so for Geoserver, since MapContext
gets re-created (we cannot cache the bbox as a result), and usually
we don't see the real map extent, clients such as OpenLayer make
separate request for separate layers.
So, the overall bbox may well become a custom parameter as well,
so that we can use a global bbox on the web as well, and avoid
having to recompute bounds at each request.
My concern with using the MapContext is that in uDig we use a number of MapContexts, one for each layer but the entire MapBounds may be larger since the other layers would be in seperate MapContext objects. And same as Geotools we keep recreating the MapContext object.
Hum, it occurs to me now that by doing so you're giving up cross layer label conflict resolution (the LabelCacheDefault needs to have a look at all layer labels in order to provide this kind of functionality).
Cheers
Andrea