RE: [Geoserver-devel] Re: SVG Rendering

GeoServer GeoServer Developer
1

Hi Gabriel,

  Yes the data is a valuable part of WFS along with all the filter
query capability. The mixed namespace on attribute retrieval is a good idea.

Any thoughts about an approach to adding event listener attributes on svg
elements as part of the outputstream?

Thanks
Randy

-----Original Message-----
From: Gabriel Roldán [mailto:groldan@anonymised.com]
Sent: Tuesday, October 18, 2005 10:41 AM
To: Randy George
Subject: Re: [Geoserver-devel] Re: SVG Rendering

Hi Randy,

actually I would like SVG as an output format for WFS too, though I would
approach differently the WMS encoding from the WFS encoding.
Both should be streamed, yes, but what I mean is that for WMS we need
styling,
which is a somewhat complicated thing, so the best we can do (afaik) is to
reuse the Batik stuff to the greater extent possible, maintaining, at least
partially, a streamed approach, as described in the previous mail.

WFS is another thing. The valuable part of an WFS SVG output is the data,
not
the styling, and the best approach would be to mix namespaces, for example:
<svg ....>
<svg:path id="road.1" ....>
  <gml:name>featureName</gml:name>
  <topp:length>70</topp:lenght>
</svg:path>

and this can indeed be done fully streamed. We already have a good framework

to do that when encoding gml and also have code to encode JTS geometries to
SVG. So yes, I'm really for it, and just hope to find the time to get a bit
more involved in this kind of issues in the short term. For the moment, all
I
can compromise to is to try my idea of getting batik styling working in a
semi-streamed fashion, and commit it if succesful.

thanks for your support,

Gabriel.

On Tuesday 18 October 2005 17:21, Randy George wrote:

Hi Justin,Gabriel,

  Thanks for digging into this. I am looking forward to having SVG as
a format option. If the outputstream approach works can it also be a

format

option on WFS as well as WMS?

Thanks
Randy

-----Original Message-----
From: geoserver-devel-admin@lists.sourceforge.net
[mailto:geoserver-devel-admin@lists.sourceforge.net] On Behalf Of Gabriel
Roldán
Sent: Tuesday, October 18, 2005 10:11 AM
To: Justin Deoliveira
Cc: Geoserver-devel
Subject: [Geoserver-devel] Re: SVG Rendering

Hi Justin,

looks good.
I don't remember what the cause was for the memory leak problem involving
clearLayerList(), though I'm aware the problem existed and that was the
solution.

By the way, I was investigating a way of streaming Batik, and looks like

we

could be able to get an in-the-middle solution. I mean, writing a subclass
of
Batik's AbstractGraphics2D that instead of making a DOM grow up
indefinitelly
just writes up xml to an outputstream in an element by element basis.
So my plan is first getting that working, then minimizing the verbosity of
generated svg by replacing by-element styling with CSS and class=
attributes.

This would give us a much more memory friendly svg producer with full
styling,
though I don't think I'll have time to dig into it until weekend.

cheers,

Gabriel.

On Tuesday 18 October 2005 07:11, Justin Deoliveira wrote:
> Hi Gabriel,
>
> I have been looking at geoserver's svg rendering as per
> http://jira.codehaus.org/browse/GEOS-400
>
> I tracked the problem down to GetMapResponse. There are two methods of
> interest:
>
> execute(Request), and writeTo(Request).
>
> The GetMapResponse releases resources of the MapContext
> (MapContext#clearLayerList()) at the end of the execute() method, which
> means that when the SVGMapProducer doesn't have any layers to render in
> the writeTo() method.
>
> I changed it so that the resources arent released until the end of the
> writeTo() method, which is the end of the requests life cycle.
>
> The change is pretty simple but i thought I would run it by you first
> since the devil is often in the details.
>
> On another note, I created another GetMapProducer that produces svg
> using batik instead of the render that you wrote. The bad news is it is
> slow (no suprise), however it does all the styling.
>
> So we have a couple of options:
>
> 1. Only use one of working renders, or
> 2. Use both, and make it part of the WMS configuration which one to use.
>
> Any thoughts?

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

2

Randy George wrote:

Hi Gabriel,

  Yes the data is a valuable part of WFS along with all the filter
query capability. The mixed namespace on attribute retrieval is a good idea.

Any thoughts about an approach to adding event listener attributes on svg
elements as part of the outputstream?

This one sounds like a bit of work. Most svg event listening I have seen is all one on the client side. I am not sure what the protocol would like to do this on the server. I have a couple of ideas off the top of my head, but be warned, i am not saying they are good ideas:)

One solution could be be for the svg writer to write out ALL event attributes using a naming convention for listener functions. Not too sure how well this will work though, it could force clients to implement all listener methods. I have seen differnt behaviour from browsers when encountering a javascript function that does not exist.

Another possibilty could be to specify a xsl transform that could add the appropriate event attributes to the svg document before it gets returned to the client.

-Justin

Thanks
Randy

-----Original Message-----
From: Gabriel Roldán [mailto:groldan@anonymised.com] Sent: Tuesday, October 18, 2005 10:41 AM
To: Randy George
Subject: Re: [Geoserver-devel] Re: SVG Rendering

Hi Randy,

actually I would like SVG as an output format for WFS too, though I would approach differently the WMS encoding from the WFS encoding.
Both should be streamed, yes, but what I mean is that for WMS we need
styling, which is a somewhat complicated thing, so the best we can do (afaik) is to reuse the Batik stuff to the greater extent possible, maintaining, at least partially, a streamed approach, as described in the previous mail.

WFS is another thing. The valuable part of an WFS SVG output is the data,
not the styling, and the best approach would be to mix namespaces, for example:
<svg ....>
<svg:path id="road.1" ....>
  <gml:name>featureName</gml:name>
  <topp:length>70</topp:lenght>
</svg:path>

and this can indeed be done fully streamed. We already have a good framework

to do that when encoding gml and also have code to encode JTS geometries to SVG. So yes, I'm really for it, and just hope to find the time to get a bit more involved in this kind of issues in the short term. For the moment, all
I can compromise to is to try my idea of getting batik styling working in a semi-streamed fashion, and commit it if succesful.

thanks for your support,

Gabriel.

On Tuesday 18 October 2005 17:21, Randy George wrote:

Hi Justin,Gabriel,

Thanks for digging into this. I am looking forward to having SVG as
a format option. If the outputstream approach works can it also be a

format

option on WFS as well as WMS?

Thanks
Randy

-----Original Message-----
From: geoserver-devel-admin@lists.sourceforge.net
[mailto:geoserver-devel-admin@lists.sourceforge.net] On Behalf Of Gabriel
Roldán
Sent: Tuesday, October 18, 2005 10:11 AM
To: Justin Deoliveira
Cc: Geoserver-devel
Subject: [Geoserver-devel] Re: SVG Rendering

Hi Justin,

looks good.
I don't remember what the cause was for the memory leak problem involving
clearLayerList(), though I'm aware the problem existed and that was the
solution.

By the way, I was investigating a way of streaming Batik, and looks like

we

could be able to get an in-the-middle solution. I mean, writing a subclass
of
Batik's AbstractGraphics2D that instead of making a DOM grow up
indefinitelly
just writes up xml to an outputstream in an element by element basis.
So my plan is first getting that working, then minimizing the verbosity of
generated svg by replacing by-element styling with CSS and class=
attributes.

This would give us a much more memory friendly svg producer with full
styling,
though I don't think I'll have time to dig into it until weekend.

cheers,

Gabriel.

On Tuesday 18 October 2005 07:11, Justin Deoliveira wrote:

Hi Gabriel,

I have been looking at geoserver's svg rendering as per
http://jira.codehaus.org/browse/GEOS-400

I tracked the problem down to GetMapResponse. There are two methods of
interest:

execute(Request), and writeTo(Request).

The GetMapResponse releases resources of the MapContext
(MapContext#clearLayerList()) at the end of the execute() method, which
means that when the SVGMapProducer doesn't have any layers to render in
the writeTo() method.

I changed it so that the resources arent released until the end of the
writeTo() method, which is the end of the requests life cycle.

The change is pretty simple but i thought I would run it by you first
since the devil is often in the details.

On another note, I created another GetMapProducer that produces svg
using batik instead of the render that you wrote. The bad news is it is
slow (no suprise), however it does all the styling.

So we have a couple of options:

1. Only use one of working renders, or
2. Use both, and make it part of the WMS configuration which one to use.

Any thoughts?

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

3

Randy, I guess I'm against this.
I successfully made a rich client application using svg served by geoserver
and all the styling/event management on the client side.

on your client svg application, you have to first load the svg document as
dom, then append it to your client app internal DOM structure.
in the while, you can traverse it and attach event listeners as required.

should that fit your needs?

Gabriel.

On Tuesday 18 October 2005 19:22, Justin Deoliveira wrote:

Randy George wrote:
> Hi Gabriel,
>
> Yes the data is a valuable part of WFS along with all the filter
> query capability. The mixed namespace on attribute retrieval is a good
> idea.
>
>
> Any thoughts about an approach to adding event listener attributes on svg
> elements as part of the outputstream?

This one sounds like a bit of work. Most svg event listening I have seen
   is all one on the client side. I am not sure what the protocol would
like to do this on the server. I have a couple of ideas off the top of
my head, but be warned, i am not saying they are good ideas:)

One solution could be be for the svg writer to write out ALL event
attributes using a naming convention for listener functions. Not too
sure how well this will work though, it could force clients to implement
all listener methods. I have seen differnt behaviour from browsers when
encountering a javascript function that does not exist.

Another possibilty could be to specify a xsl transform that could add
the appropriate event attributes to the svg document before it gets
returned to the client.

-Justin

> Thanks
> Randy
>
> -----Original Message-----
> From: Gabriel Roldán [mailto:groldan@anonymised.com]
> Sent: Tuesday, October 18, 2005 10:41 AM
> To: Randy George
> Subject: Re: [Geoserver-devel] Re: SVG Rendering
>
> Hi Randy,
>
> actually I would like SVG as an output format for WFS too, though I would
> approach differently the WMS encoding from the WFS encoding.
> Both should be streamed, yes, but what I mean is that for WMS we need
> styling,
> which is a somewhat complicated thing, so the best we can do (afaik) is
> to reuse the Batik stuff to the greater extent possible, maintaining, at
> least partially, a streamed approach, as described in the previous mail.
>
> WFS is another thing. The valuable part of an WFS SVG output is the data,
> not
> the styling, and the best approach would be to mix namespaces, for
> example: <svg ....>
> <svg:path id="road.1" ....>
> <gml:name>featureName</gml:name>
> <topp:length>70</topp:lenght>
> </svg:path>
>
> and this can indeed be done fully streamed. We already have a good
> framework
>
> to do that when encoding gml and also have code to encode JTS geometries
> to SVG. So yes, I'm really for it, and just hope to find the time to get
> a bit more involved in this kind of issues in the short term. For the
> moment, all I
> can compromise to is to try my idea of getting batik styling working in a
> semi-streamed fashion, and commit it if succesful.
>
> thanks for your support,
>
> Gabriel.
>
> On Tuesday 18 October 2005 17:21, Randy George wrote:
>>Hi Justin,Gabriel,
>>
>> Thanks for digging into this. I am looking forward to having SVG as
>>a format option. If the outputstream approach works can it also be a
>
> format
>
>>option on WFS as well as WMS?
>>
>>Thanks
>>Randy
>>
>>-----Original Message-----
>>From: geoserver-devel-admin@lists.sourceforge.net
>>[mailto:geoserver-devel-admin@lists.sourceforge.net] On Behalf Of Gabriel
>>Roldán
>>Sent: Tuesday, October 18, 2005 10:11 AM
>>To: Justin Deoliveira
>>Cc: Geoserver-devel
>>Subject: [Geoserver-devel] Re: SVG Rendering
>>
>>Hi Justin,
>>
>>looks good.
>>I don't remember what the cause was for the memory leak problem involving
>>clearLayerList(), though I'm aware the problem existed and that was the
>>solution.
>>
>>By the way, I was investigating a way of streaming Batik, and looks like
>
> we
>
>>could be able to get an in-the-middle solution. I mean, writing a
>> subclass of
>>Batik's AbstractGraphics2D that instead of making a DOM grow up
>>indefinitelly
>>just writes up xml to an outputstream in an element by element basis.
>>So my plan is first getting that working, then minimizing the verbosity
>> of generated svg by replacing by-element styling with CSS and class=
>> attributes.
>>
>>This would give us a much more memory friendly svg producer with full
>>styling,
>>though I don't think I'll have time to dig into it until weekend.
>>
>>cheers,
>>
>>Gabriel.
>>
>>On Tuesday 18 October 2005 07:11, Justin Deoliveira wrote:
>>>Hi Gabriel,
>>>
>>>I have been looking at geoserver's svg rendering as per
>>>http://jira.codehaus.org/browse/GEOS-400
>>>
>>>I tracked the problem down to GetMapResponse. There are two methods of
>>>interest:
>>>
>>>execute(Request), and writeTo(Request).
>>>
>>>The GetMapResponse releases resources of the MapContext
>>>(MapContext#clearLayerList()) at the end of the execute() method, which
>>>means that when the SVGMapProducer doesn't have any layers to render in
>>>the writeTo() method.
>>>
>>>I changed it so that the resources arent released until the end of the
>>>writeTo() method, which is the end of the requests life cycle.
>>>
>>>The change is pretty simple but i thought I would run it by you first
>>>since the devil is often in the details.
>>>
>>>On another note, I created another GetMapProducer that produces svg
>>>using batik instead of the render that you wrote. The bad news is it is
>>>slow (no suprise), however it does all the styling.
>>>
>>>So we have a couple of options:
>>>
>>>1. Only use one of working renders, or
>>>2. Use both, and make it part of the WMS configuration which one to use.
>>>
>>>Any thoughts?
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Power Architecture Resource Center: Free content, downloads, discussions,
>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>_______________________________________________
>>Geoserver-devel mailing list
>>Geoserver-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel