[Geoserver-devel] JAIMapResponse changed to StyledMapRenderer instead of LiteRenderer?

[Chris_Holmes1]

It looks like we are now using StyledMapRenderer in JAIMapResponse?

My understanding was that we should be using LiteRenderer, because it
has a faster load for the first response, and thus is better in a
stateless environment. Is that true, or was there a reason to change
to StyledMapRenderer (I admit close to complete ignorance on this front
(which is why I never updated those classes, sorry David. Though it
was probably a good thing Andrea deleted, so we did actually stop using
them, I'm just sorry it fell on you)). I'd change it right now, but
I'm not super positive. Andrea? GeoServer should be using
LiteRenderer?

Actually, looking at JAIMapResponse, I have a few more questions Andrea.
It looks like we are still using FeatureCollections in GeoServer, we
get FeatureResults, but then call results.collection. It looks like
DefaultMapLayer then just turns this back into a FeatureSource? And we
can pass a FeatureSource directly to DefaultMapLayer, and liteRenderer
then calls getFeatureSource().getFeatureResults(), and it looks like it
actually streams from there.

But in GeoServer we do not want to pass a FeatureSource in, since our
FeatureResults are the result of a Query, and thus we just want those
rendered. Was there a reason FeatureResults were not used in the
DefaultMapContext stuff? It would seem to make more sense to me, as
all that is done with the FeatureSource in the lite renderer is that it
just gets everything from the FeatureSource. Or does the other
renderer actually query the FeatureSource?

In short, what I'm asking is, what is the best way to get GeoServer to
use the jai rendering stuff and to actually stream, not load from
memory? Because right now we are loading from memory. And we want to
do the query beforehand, so passing in the whole FeatureSource does not
make sense, we only want the results of our query rendered. One hacky
way out would be to somehow wrap our FeatureResults in a FeatureSource,
but that seems silly. With refactoring we could probably pass the
DefaultMap stuff a FeatureSource and a Query, but it seems to me to
make more sense to change DefaultMapLayer to take a FeatureResult.
Though yes, I admit close to near ignorance on this front, so any help
would be appreciated.

And while we're at it, is there a way to _stop_ the rendering? In
GeoServer we have this nice abort() method, and perhaps the most useful
thing that it does is that it is called when GeoServer detects that a
client has closed a connection. So it stops using the resources that
are being used to make the response. This is super nice if a client
requests a really large map but gets impatient with how long it takes
to render. Abort will get called, and for the SVGEncoder we stop
writing the response. Is there anything like that in the geotools
renderers? Where we can stop the loading of features? (looking right
now we still need to implement this on the wfs side of things, I'm just
asking for the future, no rush).

thanks,

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

[Andrea_Aime4]

On Monday 12 April 2004 04:01, cholmes@anonymised.com wrote:

It looks like we are now using StyledMapRenderer in JAIMapResponse?

My understanding was that we should be using LiteRenderer, because it
has a faster load for the first response, and thus is better in a
stateless environment. Is that true, or was there a reason to change
to StyledMapRenderer (I admit close to complete ignorance on this front
(which is why I never updated those classes, sorry David. Though it
was probably a good thing Andrea deleted, so we did actually stop using
them, I'm just sorry it fell on you)). I'd change it right now, but
I'm not super positive. Andrea? GeoServer should be using
LiteRenderer?

Don't ask me, according to CVS history David did this as of version 1.14 (that
is, a week ago?) with a comment "Think I fixed this". Not very informative
Anyway, I've cc'ed him so he will hopefully provide some more information.
Performance wise, the old version was better.

Actually, looking at JAIMapResponse, I have a few more questions Andrea.
It looks like we are still using FeatureCollections in GeoServer, we
get FeatureResults, but then call results.collection. It looks like
DefaultMapLayer then just turns this back into a FeatureSource? And we
can pass a FeatureSource directly to DefaultMapLayer, and liteRenderer
then calls getFeatureSource().getFeatureResults(), and it looks like it
actually streams from there.

Yes, getting the collection is weird an unecessary. Just get directly the
FeatureSource. And yes, DefaultMapLayer just wraps the collection into
a CollectionDataStore that adapts it to the DataStore API.

But in GeoServer we do not want to pass a FeatureSource in, since our
FeatureResults are the result of a Query, and thus we just want those
rendered. Was there a reason FeatureResults were not used in the
DefaultMapContext stuff?

Probably it's a leftover of the first implementation... . Strange, in the CVS history
I don't see any commit of mine, thought I remember doing something on this
file...

It would seem to make more sense to me, as
all that is done with the FeatureSource in the lite renderer is that it
just gets everything from the FeatureSource. Or does the other
renderer actually query the FeatureSource?

It does, but it generates lots of cached information in memory that are
unecessary with the current setup and slow down the response. They are useful
only if you keep them in a cache from one request to the other, but they will
probably use too much memory if the layers are really big.

In short, what I'm asking is, what is the best way to get GeoServer to
use the jai rendering stuff and to actually stream, not load from
memory? Because right now we are loading from memory. > And we want to
do the query beforehand, so passing in the whole FeatureSource does not
make sense, we only want the results of our query rendered. One hacky
way out would be to somehow wrap our FeatureResults in a FeatureSource,
but that seems silly. With refactoring we could probably pass the
DefaultMap stuff a FeatureSource and a Query, but it seems to me to
make more sense to change DefaultMapLayer to take a FeatureResult.
Though yes, I admit close to near ignorance on this front, so any help
would be appreciated.

The best way with the current classes is, IMHO, to get the FeatureSources
and use a LiteRenderer, then the lite renderer should load only the features in
the requested bounding box and the requested attributes. I can add the
bbox bit, and also make it read only the attributes needed for rendering (it does
not do it now since the shapefile did load every attribute into memory anyway, and
I was working with shapefiles) so that you get good performance on it.
I could also fix myself the JAIMapResponse, but I don't want to step on David foots...

And while we're at it, is there a way to _stop_ the rendering? In
GeoServer we have this nice abort() method, and perhaps the most useful
thing that it does is that it is called when GeoServer detects that a
client has closed a connection. So it stops using the resources that
are being used to make the response. This is super nice if a client
requests a really large map but gets impatient with how long it takes
to render. Abort will get called, and for the SVGEncoder we stop
writing the response. Is there anything like that in the geotools
renderers?

No, as far as I know, but I can add it quite easily to LiteRenderer if you need
it. Doing the same for j2d is way more complex since there are many classes involved.

Where we can stop the loading of features? (looking right
now we still need to implement this on the wfs side of things, I'm just
asking for the future, no rush).

Well, the lite renderer loads as it paints, so the best place is in the processSymbolizers
call...

Best regards
Andrea Aime

[Chris_Holmes1]

On Monday 12 April 2004 04:01, cholmes@anonymised.com wrote:
> It looks like we are now using StyledMapRenderer in JAIMapResponse?
>
> My understanding was that we should be using LiteRenderer, because
it
> has a faster load for the first response, and thus is better in a
> stateless environment. Is that true, or was there a reason to
change
> to StyledMapRenderer (I admit close to complete ignorance on this
front
> (which is why I never updated those classes, sorry David. Though
it
> was probably a good thing Andrea deleted, so we did actually stop
using
> them, I'm just sorry it fell on you)). I'd change it right now,
but
> I'm not super positive. Andrea? GeoServer should be using
> LiteRenderer?

Don't ask me, according to CVS history David did this as of version
1.14 (that
is, a week ago?) with a comment "Think I fixed this". Not very
informative
Anyway, I've cc'ed him so he will hopefully provide some more
information.
Performance wise, the old version was better.

I was just asking you if the literenderer was better for our purposes,
which you've confirmed. I imagine David just went with the first thing
that worked, as I think he kner less than the little bit about
rendering, was just trying to get it to work at all. Though yeah, good
idea to check to be sure. David?

> Actually, looking at JAIMapResponse, I have a few more questions
Andrea.
> It looks like we are still using FeatureCollections in GeoServer,
we
> get FeatureResults, but then call results.collection. It looks
like
> DefaultMapLayer then just turns this back into a FeatureSource?
And we
> can pass a FeatureSource directly to DefaultMapLayer, and
liteRenderer
> then calls getFeatureSource().getFeatureResults(), and it looks
like it
> actually streams from there.

Yes, getting the collection is weird an unecessary. Just get directly
the
FeatureSource. And yes, DefaultMapLayer just wraps the collection
into
a CollectionDataStore that adapts it to the DataStore API.

Hrm. I don't think FeatureSource works as well for us, as we just pass
the FeatureResults to our delegates (so as to cut down on duplicated
logic).

> But in GeoServer we do not want to pass a FeatureSource in, since
our
> FeatureResults are the result of a Query, and thus we just want
those
> rendered. Was there a reason FeatureResults were not used in the
> DefaultMapContext stuff?

Probably it's a leftover of the first implementation... . Strange, in
the CVS history
I don't see any commit of mine, thought I remember doing something on
this
file...

Hmmm....

> In short, what I'm asking is, what is the best way to get GeoServer
to
> use the jai rendering stuff and to actually stream, not load from
> memory? Because right now we are loading from memory. > And we
want to
> do the query beforehand, so passing in the whole FeatureSource does
not
> make sense, we only want the results of our query rendered. One
hacky
> way out would be to somehow wrap our FeatureResults in a
FeatureSource,
> but that seems silly. With refactoring we could probably pass the
> DefaultMap stuff a FeatureSource and a Query, but it seems to me to
> make more sense to change DefaultMapLayer to take a FeatureResult.
> Though yes, I admit close to near ignorance on this front, so any
help
> would be appreciated.

The best way with the current classes is, IMHO, to get the
FeatureSources
and use a LiteRenderer, then the lite renderer should load only the
features in
the requested bounding box and the requested attributes. I can add
the
bbox bit, and also make it read only the attributes needed for
rendering (it does
not do it now since the shapefile did load every attribute into
memory anyway, and
I was working with shapefiles) so that you get good performance on
it.

Ok, can I also get MaxFeatures? And can I get more filtering than just
the bbox? In short, can I get a full on query object, instead of just
a bbox? We do a decent bit of processing to make the Query (and we can
add the logic for only getting the needed attributes, though I think
Gabriel may have already done that...), so we'd prefer to just use that
directly, to get the full FeatureResults that we do. My first
preference is to just allow FeatureResults in the Renderer (as that
will lead to less duplicated logic and refactoring for GeoServer), but
if that's not possible (which I can understand), then can you at least
take my full Query along with the FeatureSource?

I could also fix myself the JAIMapResponse, but I don't want to step
on David foots...

> And while we're at it, is there a way to _stop_ the rendering? In
> GeoServer we have this nice abort() method, and perhaps the most
useful
> thing that it does is that it is called when GeoServer detects that
a
> client has closed a connection. So it stops using the resources
that
> are being used to make the response. This is super nice if a
client
> requests a really large map but gets impatient with how long it
takes
> to render. Abort will get called, and for the SVGEncoder we stop
> writing the response. Is there anything like that in the geotools
> renderers?

No, as far as I know, but I can add it quite easily to LiteRenderer
if you need
it. Doing the same for j2d is way more complex since there are many
classes involved.

If it's easy to add that'd be great. It's a nice capability, freeing up
the resources when clients don't really want them.

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

[Andrea_Aime4]

On Monday 12 April 2004 10:46, cholmes@anonymised.com wrote:

> On Monday 12 April 2004 04:01, cholmes@anonymised.com wrote:

...

> The best way with the current classes is, IMHO, to get the
> FeatureSources
> and use a LiteRenderer, then the lite renderer should load only the
> features in
> the requested bounding box and the requested attributes. I can add
> the
> bbox bit, and also make it read only the attributes needed for
> rendering (it does
> not do it now since the shapefile did load every attribute into
> memory anyway, and
> I was working with shapefiles) so that you get good performance on
> it.

Ok, can I also get MaxFeatures? And can I get more filtering than just
the bbox? In short, can I get a full on query object, instead of just
a bbox? We do a decent bit of processing to make the Query (and we can
add the logic for only getting the needed attributes, though I think
Gabriel may have already done that...), so we'd prefer to just use that
directly, to get the full FeatureResults that we do. My first
preference is to just allow FeatureResults in the Renderer (as that
will lead to less duplicated logic and refactoring for GeoServer), but
if that's not possible (which I can understand), then can you at least
take my full Query along with the FeatureSource?

Well, there is a reason for creating MapLayer from FeatureSource
instead from FeatureResult. In general, in an interactive editor:
- the bbox changes as the user explores the map
- the attributes you really need to read from the data source depend
  on the current style, which may change as the user changes the
  styles around.
For the two above, you are definitely not willing to rebuild the MapLayer
every time, so I expect that the renderer is dealing with those.
Now, about taking a full query, erm... we should think to attach it to the
layer, which is sensible in my opinion. I mean, even the interactive user
may be willing to filter out the data. So, the map layer will be attached to a
query object, defaulting to Query.ALL, and the renderer will attach to this
query filter another one that takes into account the current bbox and style.
What do you think, do you like this design?

> No, as far as I know, but I can add it quite easily to LiteRenderer
> if you need
> it. Doing the same for j2d is way more complex since there are many
> classes involved.

If it's easy to add that'd be great. It's a nice capability, freeing up
the resources when clients don't really want them.

Ok, I will add it to the list of things I need to do (the pile is getting
pretty high lately...)

Best regards
Andrea Aime

[Andrea_Aime4]

On Monday 12 April 2004 10:46, cholmes@anonymised.com wrote:

...

If it's easy to add that'd be great. It's a nice capability, freeing up
the resources when clients don't really want them.

Ok, I've added to the LiteRenderer the following two abilities:
* filter out uneeded attributes and also load only features laying at least
  partly in the painting bbox. It must be enabled using the
  setOptimizingDataLoadingEnabled method since it won't work in
  with FeatureCollections made up of eterogeneous features.
* forcefully stop the rendering by calling the stopRendering() method

Best regards
Andrea Aime

[Chris_Holmes1]

> > The best way with the current classes is, IMHO, to get the
> > FeatureSources
> > and use a LiteRenderer, then the lite renderer should load only
the
> > features in
> > the requested bounding box and the requested attributes. I can
add
> > the
> > bbox bit, and also make it read only the attributes needed for
> > rendering (it does
> > not do it now since the shapefile did load every attribute into
> > memory anyway, and
> > I was working with shapefiles) so that you get good performance
on
> > it.
>
> Ok, can I also get MaxFeatures? And can I get more filtering than
just
> the bbox? In short, can I get a full on query object, instead of
just
> a bbox? We do a decent bit of processing to make the Query (and we
can
> add the logic for only getting the needed attributes, though I
think
> Gabriel may have already done that...), so we'd prefer to just use
that
> directly, to get the full FeatureResults that we do. My first
> preference is to just allow FeatureResults in the Renderer (as that
> will lead to less duplicated logic and refactoring for GeoServer),
but
> if that's not possible (which I can understand), then can you at
least
> take my full Query along with the FeatureSource?

Well, there is a reason for creating MapLayer from FeatureSource
instead from FeatureResult. In general, in an interactive editor:
- the bbox changes as the user explores the map
- the attributes you really need to read from the data source depend
  on the current style, which may change as the user changes the
  styles around.
For the two above, you are definitely not willing to rebuild the
MapLayer
every time, so I expect that the renderer is dealing with those.
Now, about taking a full query, erm... we should think to attach it
to the
layer, which is sensible in my opinion. I mean, even the interactive
user
may be willing to filter out the data. So, the map layer will be
attached to a
query object, defaulting to Query.ALL, and the renderer will attach
to this
query filter another one that takes into account the current bbox and
style.
What do you think, do you like this design?

Cool, it should work for us. Will have to do a bit of refactoring, but
I think that should be fine. Gabriel? Any thoughts? We can just pass
a Query and a FeatureSource to the SVGDelegate and move down the code
to create the FeatureResults there, right?

> > No, as far as I know, but I can add it quite easily to
LiteRenderer
> > if you need
> > it. Doing the same for j2d is way more complex since there are
many
> > classes involved.
>
> If it's easy to add that'd be great. It's a nice capability,
freeing up
> the resources when clients don't really want them.

Ok, I will add it to the list of things I need to do (the pile is
getting
pretty high lately...)

Thanks a ton for doing this Andrea, they'll definitely be in the next
version of GeoServer. Hopefully the refractions team will start to
pick up some of the slack on gui and rendering, you've definitely been
doing more than your share of the work. Sometime soon I hope to learn
the wms side of geoserver better and hopefully be able to contribute to
rendering instead of just leveraging your great work to make geoserver
even better (I'm actually itching to try to somehow integrate your
legend builder code, maybe into an applet or something. I don't know
how possible it is, but I want it to be super easy for users to style
and make pretty maps).

thanks again!

Chris

Best regards
Andrea Aime

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

[Andrea_Aime4]

On Monday 12 April 2004 16:37, cholmes@anonymised.com wrote:

Thanks a ton for doing this Andrea, they'll definitely be in the next
version of GeoServer. Hopefully the refractions team will start to
pick up some of the slack on gui and rendering, you've definitely been
doing more than your share of the work.

Sometime soon I hope to learn
the wms side of geoserver better and hopefully be able to contribute to
rendering instead of just leveraging your great work to make geoserver
even better (I'm actually itching to try to somehow integrate your
legend builder code, maybe into an applet or something. I don't know
how possible it is, but I want it to be super easy for users to style
and make pretty maps).

Ah-hem.. not so fast bud... the legend module is not finished. Problems:
* javadocs are missing;
* preview is missing;
* grid coverage styling is missing;
* bugs, bugs, bugs
* Ian S. complained that the user interface does not use property editors...

Unfortunately it has sucked a lot of time and I did had to switch to some more
important topics. For the moment, I won't work on it until I've finished the
tutorials, the jdbc fid handling code and the geotiff reader/writer. Unless
something happens that makes me raise its priority...

Best regards
Andrea Aime

[David_Zwiers1]

Quoting cholmes@anonymised.com:

> On Monday 12 April 2004 04:01, cholmes@anonymised.com wrote:
> > It looks like we are now using StyledMapRenderer in JAIMapResponse?
> >
> > My understanding was that we should be using LiteRenderer, because
> it
> > has a faster load for the first response, and thus is better in a
> > stateless environment. Is that true, or was there a reason to
> change
> > to StyledMapRenderer (I admit close to complete ignorance on this
> front
> > (which is why I never updated those classes, sorry David. Though
> it
> > was probably a good thing Andrea deleted, so we did actually stop
> using
> > them, I'm just sorry it fell on you)). I'd change it right now,
> but
> > I'm not super positive. Andrea? GeoServer should be using
> > LiteRenderer?
>
> Don't ask me, according to CVS history David did this as of version
> 1.14 (that
> is, a week ago?) with a comment "Think I fixed this". Not very
> informative
> Anyway, I've cc'ed him so he will hopefully provide some more
> information.
> Performance wise, the old version was better.
I was just asking you if the literenderer was better for our purposes,
which you've confirmed. I imagine David just went with the first thing
that worked, as I think he kner less than the little bit about
rendering, was just trying to get it to work at all. Though yeah, good
idea to check to be sure. David?

Yah was trying to get the app to run, but would have prefered to use the
LiteRenderer because I think the literenderer should be used as it is faster,
and has fewer dependencies on the intalation of the "head" of the box ... does
not depend as much on java 2d, the other one uses Components which if for GUIs.
But I could not quite understand how to get the LiteRenderer to work, as before
there was an automagic method that did the rendering after setting up the inputs
... and I don't know enough about that stuff.

> > Actually, looking at JAIMapResponse, I have a few more questions
> Andrea.
> > It looks like we are still using FeatureCollections in GeoServer,
> we
> > get FeatureResults, but then call results.collection. It looks
> like
> > DefaultMapLayer then just turns this back into a FeatureSource?
> And we
> > can pass a FeatureSource directly to DefaultMapLayer, and
> liteRenderer
> > then calls getFeatureSource().getFeatureResults(), and it looks
> like it
> > actually streams from there.
>
> Yes, getting the collection is weird an unecessary. Just get directly
> the
> FeatureSource. And yes, DefaultMapLayer just wraps the collection
> into
> a CollectionDataStore that adapts it to the DataStore API.
Hrm. I don't think FeatureSource works as well for us, as we just pass
the FeatureResults to our delegates (so as to cut down on duplicated
logic).

>
> > But in GeoServer we do not want to pass a FeatureSource in, since
> our
> > FeatureResults are the result of a Query, and thus we just want
> those
> > rendered. Was there a reason FeatureResults were not used in the
> > DefaultMapContext stuff?
>
> Probably it's a leftover of the first implementation... . Strange, in
> the CVS history
> I don't see any commit of mine, thought I remember doing something on
> this
> file...
Hmmm....
>
> > In short, what I'm asking is, what is the best way to get GeoServer
> to
> > use the jai rendering stuff and to actually stream, not load from
> > memory? Because right now we are loading from memory. > And we
> want to
> > do the query beforehand, so passing in the whole FeatureSource does
> not
> > make sense, we only want the results of our query rendered. One
> hacky
> > way out would be to somehow wrap our FeatureResults in a
> FeatureSource,
> > but that seems silly. With refactoring we could probably pass the
> > DefaultMap stuff a FeatureSource and a Query, but it seems to me to
> > make more sense to change DefaultMapLayer to take a FeatureResult.
> > Though yes, I admit close to near ignorance on this front, so any
> help
> > would be appreciated.
>
> The best way with the current classes is, IMHO, to get the
> FeatureSources
> and use a LiteRenderer, then the lite renderer should load only the
> features in
> the requested bounding box and the requested attributes. I can add
> the
> bbox bit, and also make it read only the attributes needed for
> rendering (it does
> not do it now since the shapefile did load every attribute into
> memory anyway, and
> I was working with shapefiles) so that you get good performance on
> it.
Ok, can I also get MaxFeatures? And can I get more filtering than just
the bbox? In short, can I get a full on query object, instead of just
a bbox? We do a decent bit of processing to make the Query (and we can
add the logic for only getting the needed attributes, though I think
Gabriel may have already done that...), so we'd prefer to just use that
directly, to get the full FeatureResults that we do. My first
preference is to just allow FeatureResults in the Renderer (as that
will lead to less duplicated logic and refactoring for GeoServer), but
if that's not possible (which I can understand), then can you at least
take my full Query along with the FeatureSource?

> I could also fix myself the JAIMapResponse, but I don't want to step
> on David foots...

Go for it, it was only an educated guess (Andrea sent a bit out in an email
couple days back).

>
> > And while we're at it, is there a way to _stop_ the rendering? In
> > GeoServer we have this nice abort() method, and perhaps the most
> useful
> > thing that it does is that it is called when GeoServer detects that
> a
> > client has closed a connection. So it stops using the resources
> that
> > are being used to make the response. This is super nice if a
> client
> > requests a really large map but gets impatient with how long it
> takes
> > to render. Abort will get called, and for the SVGEncoder we stop
> > writing the response. Is there anything like that in the geotools
> > renderers?
>
> No, as far as I know, but I can add it quite easily to LiteRenderer
> if you need
> it. Doing the same for j2d is way more complex since there are many
> classes involved.
If it's easy to add that'd be great. It's a nice capability, freeing up
the resources when clients don't really want them.

Chris

Hope this helps, David

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

[Gabriel_Roldan1]

> What do you think, do you like this design?
Cool, it should work for us. Will have to do a bit of refactoring, but
I think that should be fine. Gabriel? Any thoughts? We can just pass
a Query and a FeatureSource to the SVGDelegate and move down the code
to create the FeatureResults there, right?

sure, sorry for the late response.

[Gabriel_Roldan1]

Hi,
how those of you who use eclipse to develop geosever run the application?
there exists any free tomcat launcher with debug capabilities?
I'm just trying to leave JBuilder after many years.

thanks a lot.

Gabriel

[jive]

Quoting Gabriel Roldán <gabriel.roldan@anonymised.com>:

Hi,
how those of you who use eclipse to develop geosever run the application?
there exists any free tomcat launcher with debug capabilities?
I'm just trying to leave JBuilder after many years.

Eclipse has nice ant intergration - we just run the ant test-ext target (you
need to point the external entry in your ant build.xml file to tomcat webapps
directory first.

But as of yesterday chris has the test targtet working (it usses jetty?). It ran
for me inside eclipse and was quite squiffy.

Jody

thanks a lot.

Gabriel

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.Compare, Download & Develop Open Source & Business Software - SourceForge
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Gabriel_Roldan1]

So I just changed the signature of the execute method to
GetMapDelegate.execute(FeatureTypeInfo , Query, Style).

would preffer passing a single list of command objects, each one holding a
single typeinfo, query and style, instead of three arrays, if nobody
worries.

I can take care of using LiteRenderer again tomorrow, and since this may
need some touches in the renderer side, I'll me happy of doing it since I
was wishing to get involved in the gui/renderer side and it can be a good
starting point.

So, if nobody complains, I can try it, but may be will need some pointers
with the renderer stuff since I'm feeling a bit lost trying to join all the
input from previous emails (it could be just that it is 5:00 am and tomorrow
will see things clearer).

Is this action plan is correct or I'm missing something important? :

- Add a Query attribute to MapLayer (implies overloading of constructor and
adding a setter I guess)
Note that this Query, when passed in from geoserver, will already contain
the BBOX filter and the requested attributes. Wich worries me if how to
determine the needed attributes of an SLD Style, I think they will be needed
at rendering time?
- check id maxfeatures is actually being included in the query, if not, do
it
- use this stuff from inside JAIMapResponse

the bounding box is not being included in literenderer yet?

I think the point is I don't know how LiteRenderer works. May be I should
investigate a bit first, but any help will be welcomed

best regards,

Gabriel

> > > The best way with the current classes is, IMHO, to get the
> > > FeatureSources
> > > and use a LiteRenderer, then the lite renderer should load only
> the
> > > features in
> > > the requested bounding box and the requested attributes. I can
> add
> > > the
> > > bbox bit, and also make it read only the attributes needed for
> > > rendering (it does
> > > not do it now since the shapefile did load every attribute into
> > > memory anyway, and
> > > I was working with shapefiles) so that you get good performance
> on
> > > it.
> >
> > Ok, can I also get MaxFeatures? And can I get more filtering than
> just
> > the bbox? In short, can I get a full on query object, instead of
> just
> > a bbox? We do a decent bit of processing to make the Query (and we
> can
> > add the logic for only getting the needed attributes, though I
> think
> > Gabriel may have already done that...), so we'd prefer to just use
> that
> > directly, to get the full FeatureResults that we do. My first
> > preference is to just allow FeatureResults in the Renderer (as that
> > will lead to less duplicated logic and refactoring for GeoServer),
> but
> > if that's not possible (which I can understand), then can you at
> least
> > take my full Query along with the FeatureSource?
>
> Well, there is a reason for creating MapLayer from FeatureSource
> instead from FeatureResult. In general, in an interactive editor:
> - the bbox changes as the user explores the map
> - the attributes you really need to read from the data source depend
> on the current style, which may change as the user changes the
> styles around.
> For the two above, you are definitely not willing to rebuild the
> MapLayer
> every time, so I expect that the renderer is dealing with those.
> Now, about taking a full query, erm... we should think to attach it
> to the
> layer, which is sensible in my opinion. I mean, even the interactive
> user
> may be willing to filter out the data. So, the map layer will be
> attached to a
> query object, defaulting to Query.ALL, and the renderer will attach
> to this
> query filter another one that takes into account the current bbox and
> style.
> What do you think, do you like this design?
Cool, it should work for us. Will have to do a bit of refactoring, but
I think that should be fine. Gabriel? Any thoughts? We can just pass
a Query and a FeatureSource to the SVGDelegate and move down the code
to create the FeatureResults there, right?

>
>
> > > No, as far as I know, but I can add it quite easily to
> LiteRenderer
> > > if you need
> > > it. Doing the same for j2d is way more complex since there are
> many
> > > classes involved.
> >
> > If it's easy to add that'd be great. It's a nice capability,
> freeing up
> > the resources when clients don't really want them.
>
> Ok, I will add it to the list of things I need to do (the pile is
> getting
> pretty high lately...)
Thanks a ton for doing this Andrea, they'll definitely be in the next
version of GeoServer. Hopefully the refractions team will start to
pick up some of the slack on gui and rendering, you've definitely been
doing more than your share of the work. Sometime soon I hope to learn
the wms side of geoserver better and hopefully be able to contribute to
rendering instead of just leveraging your great work to make geoserver
even better (I'm actually itching to try to somehow integrate your
legend builder code, maybe into an applet or something. I don't know
how possible it is, but I want it to be super easy for users to style
and make pretty maps).

thanks again!

Chris

>
> Best regards
> Andrea Aime
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

[Chris_Holmes1]

> Sometime soon I hope to learn
> the wms side of geoserver better and hopefully be able to
contribute to
> rendering instead of just leveraging your great work to make
geoserver
> even better (I'm actually itching to try to somehow integrate your
> legend builder code, maybe into an applet or something. I don't
know
> how possible it is, but I want it to be super easy for users to
style
> and make pretty maps).

Ah-hem.. not so fast bud... the legend module is not finished.
Problems:
* javadocs are missing;
* preview is missing;
* grid coverage styling is missing;
* bugs, bugs, bugs
* Ian S. complained that the user interface does not use property
editors...

Unfortunately it has sucked a lot of time and I did had to switch to
some more
important topics. For the moment, I won't work on it until I've
finished the
tutorials, the jdbc fid handling code and the geotiff reader/writer.
Unless
something happens that makes me raise its priority...

He he, you definitely underestimate my own personal queue of stuff I
need to get done before I could even start to touch something like
legend builder in an applet. Probably should have mentioned how far
off it is for me, but basically you're not in too much trouble of me
moving so fast. Though if I were to go there I'd definitely help you
iron out bugs. First priorities for me are definitely getting
geoserver to have full support for sld wms, but before that I also want
to work on a half decent light weight client for geoserver. So yeah,
legend builder in an applet is simple an apple in my eye, it'll be ages
till I get to it, I'm just psyched on the possibilities. From a
selfish geoserver perspective I'd much prefer your work on fid handling
and geotiff reader writer, and to a lesser extent gui and tutorials.

So just keep up the good work on whatever your priorities all, it's all
good for me, I'm just psyched you managed to get me my abort so
quickly.

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

[Chris_Holmes1]

> Hi,
> how those of you who use eclipse to develop geosever run the
applicatio=
n?
> there exists any free tomcat launcher with debug capabilities?
> I'm just trying to leave JBuilder after many years.

Eclipse has nice ant intergration - we just run the ant test-ext
target (=
you
need to point the external entry in your ant build.xml file to tomcat
web=
apps
directory first.

But as of yesterday chris has the test targtet working (it usses
jetty?).=
It ran
for me inside eclipse and was quite squiffy.

If you actually want to use the eclipse debugger you can make an
EmbeddedJetty class that starts the application. It's on my list of
things todo, but I don't use a debugger much, so I probably won't get
to it really soon. But it should be really easy, as Jetty's xml files
are essentially a translation of thier java classes. The EmbeddedJetty
will just add the war programmatically, and I think then you should be
able to get more real debugging capabilities, since it's all actually
run through eclipse, not through ant. I haven't tried it out myself
yet though. Also, the test target _will_ work now, if you tried it out
before it didn't, because I once again forgot the -kb tag. But yes, I
think most of us would highly recommend moving to eclipse, it's really
a great tool.

Chris

Jody=20

> thanks a lot.
>=20
> Gabriel
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO
of
> GenToo technologies. Learn everything from fundamentals to system
>

administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=

lick
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>=20

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/