Jody Garnett ha scritto: > Andrea Aime wrote: >> That was my first thougth as well, but simbol size (and line width, >> font size, whatever) is something that may be associated to a complex >> expression using attributes, making this approach unworkable in the >> general case. That's why I'm suggesting the user to provide >> information I cannot >> look up. > Bleah that is rough; I would rather take into acount the symbol size > (since in a lot of cases it is a literal), and only fall back on a guess > if needed.
Indeed you're right it's inconvenient in a uDig like application. Well, I'll add an improvement request and see if I have time to tackle this as well, but I have to start with the fixed parameter, since I have to support it anyways and Geosever is the driver for this change.... If nothing else, I'll pay attention and try to make the automatic hint computation easy to add. > I think that the person configuring GeoServer is in a much > better position to specify this guess then the client making the > requests. Ie provide you guess once as part of layer configuration > rather then part of each and every request. Not possible in Geoserver. Every request can associate each layer with a different SLD, having a buffer configured on the feature type (== layer in geoserver) would be inconsistent with the ability to require whatever SLD you want, or make up yours (getMap with user provided SLD). >> How does 3x3 help? You're just making quirks less common, but they >> would appear anyways on the 3x3 group borders? It's just a bigger tile. > Agreed, I had only heard about the 3x3 solution (perhaps from Chris?) > your idea is better. The 3x3 solution is the other bit from kaMap/tileCache, when they do ask for tiles to cache, they don't compute one, but a block with buffer, and then split those into single tiles after removing the buffer. It's a performance optimization, the buffer overhead is lower and usually servers are quicker at computing one big image than 9 small ones (for sure Geoserver is). >> In geoserver I can always use the bbox the user provided (hey, did not >> think about that :-) ) but >> that would be something I have to pass down the renderer as an extra >> parameter, so rendering subsystem wise, it would still be a hint. >> uDig could use MapContext.getBounds() instead, since the MapContext >> is long lived (provided the data store allow for bounds computation, >> not all do...). > Note your bbox provided by the user (say something requesting tiles) > would not be a stable hint for you (unless you mean the bounding > box of a request that is going to be made up of several tiles? Well at > least between users then it will not be stable and thus the results will > be of less value when cached). Or else I am misunderstanding you and > rather confused. I don't know why the user would change it? I mean the user should always call getMap for a specific map with a MAP_BOUNDS bbox that's always the same in order to get the same label arrangement (given the same scale). >> Hmm... it seems to me we could use a LABELING_MODE hint with the >> following values: >> * SEAMLESS: assume map has no bounds (this should be the default); >> * MAP_BOUNDS: use MapContext.getBounds() (or the full data layer >> bounds anyways) unless a second hint (LABELING_BOUNDS) with a user >> provided bbox is available; >> * RENDERING_BOUNDS: use the map bbox as labeling optimization bounds >> (current behaviour, ok for priting). >> >> Add the META_BUFFER hint and I think we're set for the moment. > DATA_BOUNDS seems the best (Map bounds would get confused with the map > context used by the GTRenderer IMHO) and I would prefer it as the > default (as you pointed out the only improvements are on the edge of the > dataset). Actually even SEAMLESS would be okay as long as the renderer > is not clipped to the valid limits of the data). Ok, I'll change the name to DATA_BOUNDS. DefaultMapContext does not have a getBounds() method, but a: * getAreaOfInterest, which may be changed by the user (not interested in this one I guess) * getLayerBounds() which provides actual data bounds -> that's what I wanted to use. > I am still worried about META_BUFFER, for GeoServer this would be fine > as a configuration option. But paying attention to the graphics marks > would be my preferred option. You're forgetting line widths, font sizes, label sizes (which are exactly the case where you cannot tell in advance how big the label is, database fields are usually oversized compared to the actual text they do contain). Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
