Andrea Aime wrote: > Hum, interesting. In fact I still haven't had a look at how labeling > is performed besides the label moving due to bbox considerations. > Is there any open issue against this? If not, can you open one with > your suggested solution included? Cannot remember if it is in there or not; may just be a wiki page in the geoserver space (where a lot of these things are discussed). > Mover, I don't have a mandate to due tile caching, just to make > answers to tiled request look right. So the tiling 3by3 is not something > I can really do, it's something I'd like to do when I'll have a mandate > to implement TMS thought. 3x3 idea is similar to one of your suggestions - yours sound easier to implement & smarter. The important part is the what to do when labels get dense idea - which is part of making tiled requests look right (as you zoom in this time, rather then as you pan). > 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. 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. > 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. >> One option you did not mention was making use of the data bounds >> (rather then the map context area). It may look strange at the edge >> of smaller datasets but would be the most broadly applicable. > Sorry, aren't map context bounds equal to the data bounds? Oh, not always - sometimes your map is made up of several sources of data resulting in the difference. > Anyways, I was thinking to data bounds, but computing them on each > request may > be really expensive (I have postgis datasets where a bounds calculation > request takes seconds even on my PC with RAID 0 disks...). That is why geoserver caches (or overrides) the data bounds as part of configuration :-) > 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. > 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).
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. Jody ------------------------------------------------------------------------- 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
