[Geoserver-devel] R: R: R: [Geotools-devel] Attacking the tiling rendering issues (Geoserver, but uDig too)

GeoServer GeoServer Developer
1

-----Messaggio originale-----
Da: Andrea Aime [mailto:aaime@anonymised.com]
Inviato: giovedì 4 gennaio 2007 12.16
A: Fabio Da Soghe
Cc: 'geoserver-devel'; 'Geotools-Devel list'
Oggetto: Re: [Geoserver-devel] R: R: [Geotools-devel]
Attacking the tiling rendering issues (Geoserver, but uDig too)

Fabio Da Soghe ha scritto:

> I'm still concerned about a "closed" client. For example, how a
> uDig-tiled would act with this solution? It should be extended with
> some preferences where the user has to put in the metabuffer size?

Yeah, you point is well taken... we could have both, that is,
a default
for the feature type, and a user override in the GetMap request...
this started as a little rendering patch and it's becoming
really big,
bleah :slight_smile:

I see, and I cannot do anything but agree. To say the truth, I was hesitant to say that (default for the feature type and a user override parameter), but maybe it's the ultimate solution (and it follows the style logic: feature types have already the same treatment in Geoserver: a default style and the user override parameter).

>> Moreover, I don't want to spend another half a day just to add a
>> single parameter to Geoserver... I may end up to, but the very idea
>> of putting my hands again in that mess makes me shiver...
>
> I see. What is the mess you talk about? The configuration web pages
> where the metabuffer and other additional FeatureTypes
options should
> have be put?

Well, to add a new parameter in the feature type configuration, you
have to modify the JSP, the form bean, the action, the actual
configuration object, its DTO, the xml reader, the xml writer... oh
my... Did I ever told you I hate Struts and DTO's alike? :-p

Indeed, Struts is one of my biggest disappointment about libraries and frameworks. Didn't you started the migration to Spring?

Anyway, with client libraries like OpenLayers spreading over the developers community and with web mapping concurrents like Google Maps (to say only one: for example, here in Italy - as you already know :wink: - we have already several public web mapping portals with cool tiling client), I think a correct and efficient tiling mechanism is already a standard expectation. So maybe it's more important to have earlier an acceptable solution then later a complete implementation (imho, of course).

Cheers,

Fabio

Cheers
Andrea

2

Fabio Da Soghe ha scritto:

Well, to add a new parameter in the feature type configuration, you
have to modify the JSP, the form bean, the action, the actual configuration object, its DTO, the xml reader, the xml writer... oh
my... Did I ever told you I hate Struts and DTO's alike? :-p

Indeed, Struts is one of my biggest disappointment about libraries
and frameworks. Didn't you started the migration to Spring?

Yup, but the UI is still Struts. We'll migrate soon to another
framework, probably Wicket or GWT, but we have a few options
on the plate and no decision is taken. We're looking for something
that allows to store the whole UI in module jars (so that adding
a new module adds the UI as well), so jsp are out of question,
and possibly something that does not need extra xml configuration
for pages. Ideally, I would be happy with anything that allows me
to write an XHTML template and a single action/page/whatever class
to back it.

Cheers
Andrea