Re: [Geoserver-devel] Re: SVG Rendering

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Geoserver-devel] Re: SVG Rendering

Justin Deoliveira-3
Hi Efrin,

This is great, please feel free to update any documentation that you
feel is insufficient.

Efren Serra wrote:
> Justin,
>
> Yes, I would be interested in adding some documentation.  I have figured out
> a lot of stuff that other folks may be trying to figure out.
> Also, some folks in my community are sort of doing stuff that you are doing
> but without geoserver.
>
Thanks for the links, I will definitley check them out. We are always
interested in the things that other organizations are doing and are
always game to talk about collaboration.

> This document explains how to resolve the differences between GML and the
> netCDF data model of which GRIB is of these.
> http://www.gmldays.com/gml2005/presentations/ncML-GML%20v.0.3.2,%20Ben%20Dom
> enico.pdf
>
> This URL is an interoperability experiment between a WCS and a THREDDS
> server:
> http://www.unidata.ucar.edu/projects/THREDDS/GALEON/GALEON-Activity-Plan.htm
>

> v/r,
> Efren
> -----Original Message-----
> From: Justin Deoliveira [mailto:[hidden email]]
> Sent: Friday, October 21, 2005 10:11 AM
> To: [hidden email]
> Subject: Re: [Geoserver-devel] Re: SVG Rendering
>
>
> Hi Efrin,
>
> Yes it does seem like the tortoise svn docs are in correct. Would you be
> interested in changing the docs so that they are correct?
>
> Yes it is too bad that the wiki doesn't come up first. However the more
> it gets used the better chance it has at beeing number 1.
>
> -Justin
>
> Efren Serra wrote:
>
>>Justin,
>>
>>I am using these instructions:
>>
>>http://docs.codehaus.org/display/GEOSDOC/Source+Code
>>
>>Also, note that when one googles goeserver
>
> http://geoserver.sourceforge.net
>
>>comes up first.  Thank you.
>>
>>v/r,
>>Efren
>>
>>-----Original Message-----
>>From: Justin Deoliveira [mailto:[hidden email]]
>>Sent: Friday, October 21, 2005 9:54 AM
>>To: [hidden email]
>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>
>>
>>Hi Efrin,
>>
>>
>>
>>Efren Serra wrote:
>>
>>
>>>Justin,
>>>
>>>I followed the instructions for TortoiseSVN:
>>>
>>>Create a folder for GeoSrever to live in
>>>C:\java\geoserver
>>>Navigate to the folder, and right-click
>>>Select "Checkout ..."
>>>URL of Repository: svn://svn.codehaus.org/geoserver/scm/trunk/geoserver
>>>Checkout directory: C:\java\geoserver
>>>Revision: Head Revision
>>>Press OK
>>>
>>>But got the following error for above URL; however, it works for
>>>"https://svn.codehaus.org/geoserver/trunk/geoserver".  The error
>>>is:
>>>
>>>Error: Can't connect to host 'svn.codehaus.org': No connection could be
>>
>>made
>>
>>
>>>because
>>>Error: the target machine actively refused it.
>>>
>>
>>What docs were you following, perhaps they are out of date.
>>
>>
>>
>>>Assuming that I want to run the cite test suite with my PostGIS datastore,
>>>where do I specify the hostname for the cite database?  Thank you.
>>
>>So you want to run cite tests against your geoserver instance? There is
>>documentation on how to do this available here:
>>
>>http://docs.codehaus.org/display/GEOSDOC/Running+Cite+Tests
>>
>>
>>
>>>v/r,
>>>Efren
>>>-----Original Message-----
>>>From: Justin Deoliveira [mailto:[hidden email]]
>>>Sent: Wednesday, October 19, 2005 10:24 AM
>>>To: [hidden email]
>>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>>
>>>
>>>The latest 1.3.x release. Which is 1.3.RC4.SC1. It is available from
>>>http://dist.codehaus.org/geoserver
>>>
>>>-Justin
>>>
>>>Efren Serra wrote:
>>>
>>>
>>>
>>>>Justin,
>>>>
>>>>Which version of GeoServer should I be using?  I am using geoserver
>>>
>>><1.2.4>.
>>>
>>>
>>>
>>>>Thank you.
>>>>
>>>>v/r,
>>>>Efren
>>>>
>>>>-----Original Message-----
>>>>From: [hidden email]
>>>>[mailto:[hidden email]]On Behalf Of Justin
>>>>Deoliveira
>>>>Sent: Tuesday, October 18, 2005 7:25 PM
>>>>To: 'Geoserver-devel'
>>>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>>>
>>>>
>>>>I have added the new SVG renderer based on batik. There is now a
>>>>configuration option under Config->WMS->Rendering in order to switch
>>>>between the two. The default is the fast svg renderer.
>>>>
>>>>-Justin
>>>>
>>>>Randy George wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Justin, Gabriel,
>>>>>
>>>>> I haven't thought about this too long either, but was intrigued with
>>>>>the external .sld capability that allows the consumer to override
>
> default
>
>>>>>server styling and was wondering about that possibility in an svg event
>>>>>listener sense.
>>>>>
>>>>> Like styling it involves adding attributes to elements. A javascript
>>>>>href would have to point to an external .js which lets a consumer
>
> control
>
>>>>>behavior without reprocessing the svg. A default js reference could have
>>>>
>>>>an
>>>>
>>>>
>>>>
>>>>
>>>>>empty function for each event type.
>>>>>
>>>>> &script=http://myserver/js/test.js
>>>>><script xlink:href="http://myserver/js/test.js" />
>>>>>
>>>>>But this does complicate things more then necessary and probably extends
>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>OGC spec, so I think Gabriel is right, not a good idea.
>>>>>
>>>>> It would be better to set up a pass through servlet in front of the
>>>>>WFS with an xsl or SAX ContentHandler to add the event listener
>>
>>attributes
>>
>>
>>>>>and href js, perhaps using an additional event field from the data store
>>>>>record.
>>>>>
>>>>> At least with &format=image/svg+xml the gml2svg.xsl step is skipped
>>>>>
>>>>>Thanks
>>>>>Randy
>>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]
>>>>>[mailto:[hidden email]] On Behalf Of Justin
>>>>>Deoliveira
>>>>>Sent: Tuesday, October 18, 2005 11:23 AM
>>>>>To: Randy George
>>>>>Cc: 'Gabriel Roldán'; 'Geoserver-devel'
>>>>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>>>>
>>>>>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:[hidden email]]
>>>>>>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: [hidden email]
>>>>>>>[mailto:[hidden email]] 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
>>>>>>>[hidden email]
>>>>>>>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
>>>>>>[hidden email]
>>>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>Justin Deoliveira
>>>>The Open Planning Project
>>>>http://topp.openplans.org
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>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
>>>>[hidden email]
>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>--
>>>Justin Deoliveira
>>>The Open Planning Project
>>>http://topp.openplans.org
>>>
>>>
>>>
>>
>>
>>
>>--
>>Justin Deoliveira
>>The Open Planning Project
>>http://topp.openplans.org
>>
>>
>>
>
>
>
> --
> Justin Deoliveira
> The Open Planning Project
> http://topp.openplans.org
>
>
>


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


-------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

RE: [Geoserver-devel] Re: SVG Rendering

Efren Serra
Justin,

These guys are addressing the type miss-match between scientific data
representation for weather forecasting and the OGC GML data representation.
I am not aware whether or not they are using GeoServer WCS but it would be
good if they were since all of their work is being done in Java like
GeoServer.

v/r,
Efren

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Justin
Deoliveira
Sent: Friday, October 21, 2005 10:33 AM
To: [hidden email]
Cc: Geoserver-devel; [hidden email]
Subject: Re: [Geoserver-devel] Re: SVG Rendering


Hi Efrin,

This is great, please feel free to update any documentation that you
feel is insufficient.

Efren Serra wrote:
> Justin,
>
> Yes, I would be interested in adding some documentation.  I have figured
out
> a lot of stuff that other folks may be trying to figure out.
> Also, some folks in my community are sort of doing stuff that you are
doing
> but without geoserver.
>
Thanks for the links, I will definitley check them out. We are always
interested in the things that other organizations are doing and are
always game to talk about collaboration.

> This document explains how to resolve the differences between GML and the
> netCDF data model of which GRIB is of these.
>
http://www.gmldays.com/gml2005/presentations/ncML-GML%20v.0.3.2,%20Ben%20Dom
> enico.pdf
>
> This URL is an interoperability experiment between a WCS and a THREDDS
> server:
>
http://www.unidata.ucar.edu/projects/THREDDS/GALEON/GALEON-Activity-Plan.htm
>

> v/r,
> Efren
> -----Original Message-----
> From: Justin Deoliveira [mailto:[hidden email]]
> Sent: Friday, October 21, 2005 10:11 AM
> To: [hidden email]
> Subject: Re: [Geoserver-devel] Re: SVG Rendering
>
>
> Hi Efrin,
>
> Yes it does seem like the tortoise svn docs are in correct. Would you be
> interested in changing the docs so that they are correct?
>
> Yes it is too bad that the wiki doesn't come up first. However the more
> it gets used the better chance it has at beeing number 1.
>
> -Justin
>
> Efren Serra wrote:
>
>>Justin,
>>
>>I am using these instructions:
>>
>>http://docs.codehaus.org/display/GEOSDOC/Source+Code
>>
>>Also, note that when one googles goeserver
>
> http://geoserver.sourceforge.net
>
>>comes up first.  Thank you.
>>
>>v/r,
>>Efren
>>
>>-----Original Message-----
>>From: Justin Deoliveira [mailto:[hidden email]]
>>Sent: Friday, October 21, 2005 9:54 AM
>>To: [hidden email]
>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>
>>
>>Hi Efrin,
>>
>>
>>
>>Efren Serra wrote:
>>
>>
>>>Justin,
>>>
>>>I followed the instructions for TortoiseSVN:
>>>
>>>Create a folder for GeoSrever to live in
>>>C:\java\geoserver
>>>Navigate to the folder, and right-click
>>>Select "Checkout ..."
>>>URL of Repository: svn://svn.codehaus.org/geoserver/scm/trunk/geoserver
>>>Checkout directory: C:\java\geoserver
>>>Revision: Head Revision
>>>Press OK
>>>
>>>But got the following error for above URL; however, it works for
>>>"https://svn.codehaus.org/geoserver/trunk/geoserver".  The error
>>>is:
>>>
>>>Error: Can't connect to host 'svn.codehaus.org': No connection could be
>>
>>made
>>
>>
>>>because
>>>Error: the target machine actively refused it.
>>>
>>
>>What docs were you following, perhaps they are out of date.
>>
>>
>>
>>>Assuming that I want to run the cite test suite with my PostGIS
datastore,

>>>where do I specify the hostname for the cite database?  Thank you.
>>
>>So you want to run cite tests against your geoserver instance? There is
>>documentation on how to do this available here:
>>
>>http://docs.codehaus.org/display/GEOSDOC/Running+Cite+Tests
>>
>>
>>
>>>v/r,
>>>Efren
>>>-----Original Message-----
>>>From: Justin Deoliveira [mailto:[hidden email]]
>>>Sent: Wednesday, October 19, 2005 10:24 AM
>>>To: [hidden email]
>>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>>
>>>
>>>The latest 1.3.x release. Which is 1.3.RC4.SC1. It is available from
>>>http://dist.codehaus.org/geoserver
>>>
>>>-Justin
>>>
>>>Efren Serra wrote:
>>>
>>>
>>>
>>>>Justin,
>>>>
>>>>Which version of GeoServer should I be using?  I am using geoserver
>>>
>>><1.2.4>.
>>>
>>>
>>>
>>>>Thank you.
>>>>
>>>>v/r,
>>>>Efren
>>>>
>>>>-----Original Message-----
>>>>From: [hidden email]
>>>>[mailto:[hidden email]]On Behalf Of Justin
>>>>Deoliveira
>>>>Sent: Tuesday, October 18, 2005 7:25 PM
>>>>To: 'Geoserver-devel'
>>>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>>>
>>>>
>>>>I have added the new SVG renderer based on batik. There is now a
>>>>configuration option under Config->WMS->Rendering in order to switch
>>>>between the two. The default is the fast svg renderer.
>>>>
>>>>-Justin
>>>>
>>>>Randy George wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Justin, Gabriel,
>>>>>
>>>>> I haven't thought about this too long either, but was intrigued with
>>>>>the external .sld capability that allows the consumer to override
>
> default
>
>>>>>server styling and was wondering about that possibility in an svg event
>>>>>listener sense.
>>>>>
>>>>> Like styling it involves adding attributes to elements. A javascript
>>>>>href would have to point to an external .js which lets a consumer
>
> control
>
>>>>>behavior without reprocessing the svg. A default js reference could
have

>>>>
>>>>an
>>>>
>>>>
>>>>
>>>>
>>>>>empty function for each event type.
>>>>>
>>>>> &script=http://myserver/js/test.js
>>>>><script xlink:href="http://myserver/js/test.js" />
>>>>>
>>>>>But this does complicate things more then necessary and probably
extends

>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>OGC spec, so I think Gabriel is right, not a good idea.
>>>>>
>>>>> It would be better to set up a pass through servlet in front of the
>>>>>WFS with an xsl or SAX ContentHandler to add the event listener
>>
>>attributes
>>
>>
>>>>>and href js, perhaps using an additional event field from the data
store

>>>>>record.
>>>>>
>>>>> At least with &format=image/svg+xml the gml2svg.xsl step is skipped
>>>>>
>>>>>Thanks
>>>>>Randy
>>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]
>>>>>[mailto:[hidden email]] On Behalf Of
Justin

>>>>>Deoliveira
>>>>>Sent: Tuesday, October 18, 2005 11:23 AM
>>>>>To: Randy George
>>>>>Cc: 'Gabriel Roldán'; 'Geoserver-devel'
>>>>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>>>>
>>>>>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:[hidden email]]
>>>>>>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: [hidden email]
>>>>>>>[mailto:[hidden email]] 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
>>>>>>>[hidden email]
>>>>>>>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
>>>>>>[hidden email]
>>>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>Justin Deoliveira
>>>>The Open Planning Project
>>>>http://topp.openplans.org
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>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
>>>>[hidden email]
>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>--
>>>Justin Deoliveira
>>>The Open Planning Project
>>>http://topp.openplans.org
>>>
>>>
>>>
>>
>>
>>
>>--
>>Justin Deoliveira
>>The Open Planning Project
>>http://topp.openplans.org
>>
>>
>>
>
>
>
> --
> Justin Deoliveira
> The Open Planning Project
> http://topp.openplans.org
>
>
>


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


-------------------------------------------------------
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
[hidden email]
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-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: [Geoserver-devel] Re: SVG Rendering

Justin Deoliveira-3
Hi Efrin,

Yes I agree, we always want to promote collaboration, and the work being
done in Java really enables this possiblity.

 From what I know WCS support is coming along quite nicley. Alessio
should be able to comment further.

-Justin

Efren Serra wrote:

> Justin,
>
> These guys are addressing the type miss-match between scientific data
> representation for weather forecasting and the OGC GML data representation.
> I am not aware whether or not they are using GeoServer WCS but it would be
> good if they were since all of their work is being done in Java like
> GeoServer.
>
> v/r,
> Efren
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Justin
> Deoliveira
> Sent: Friday, October 21, 2005 10:33 AM
> To: [hidden email]
> Cc: Geoserver-devel; [hidden email]
> Subject: Re: [Geoserver-devel] Re: SVG Rendering
>
>
> Hi Efrin,
>
> This is great, please feel free to update any documentation that you
> feel is insufficient.
>
> Efren Serra wrote:
>
>>Justin,
>>
>>Yes, I would be interested in adding some documentation.  I have figured
>
> out
>
>>a lot of stuff that other folks may be trying to figure out.
>>Also, some folks in my community are sort of doing stuff that you are
>
> doing
>
>>but without geoserver.
>>
>
> Thanks for the links, I will definitley check them out. We are always
> interested in the things that other organizations are doing and are
> always game to talk about collaboration.
>
>
>>This document explains how to resolve the differences between GML and the
>>netCDF data model of which GRIB is of these.
>>
>
> http://www.gmldays.com/gml2005/presentations/ncML-GML%20v.0.3.2,%20Ben%20Dom
>
>>enico.pdf
>>
>>This URL is an interoperability experiment between a WCS and a THREDDS
>>server:
>>
>
> http://www.unidata.ucar.edu/projects/THREDDS/GALEON/GALEON-Activity-Plan.htm
>
>
>>v/r,
>>Efren
>>-----Original Message-----
>>From: Justin Deoliveira [mailto:[hidden email]]
>>Sent: Friday, October 21, 2005 10:11 AM
>>To: [hidden email]
>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>
>>
>>Hi Efrin,
>>
>>Yes it does seem like the tortoise svn docs are in correct. Would you be
>>interested in changing the docs so that they are correct?
>>
>>Yes it is too bad that the wiki doesn't come up first. However the more
>>it gets used the better chance it has at beeing number 1.
>>
>>-Justin
>>
>>Efren Serra wrote:
>>
>>
>>>Justin,
>>>
>>>I am using these instructions:
>>>
>>>http://docs.codehaus.org/display/GEOSDOC/Source+Code
>>>
>>>Also, note that when one googles goeserver
>>
>>http://geoserver.sourceforge.net
>>
>>
>>>comes up first.  Thank you.
>>>
>>>v/r,
>>>Efren
>>>
>>>-----Original Message-----
>>>From: Justin Deoliveira [mailto:[hidden email]]
>>>Sent: Friday, October 21, 2005 9:54 AM
>>>To: [hidden email]
>>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>>
>>>
>>>Hi Efrin,
>>>
>>>
>>>
>>>Efren Serra wrote:
>>>
>>>
>>>
>>>>Justin,
>>>>
>>>>I followed the instructions for TortoiseSVN:
>>>>
>>>>Create a folder for GeoSrever to live in
>>>>C:\java\geoserver
>>>>Navigate to the folder, and right-click
>>>>Select "Checkout ..."
>>>>URL of Repository: svn://svn.codehaus.org/geoserver/scm/trunk/geoserver
>>>>Checkout directory: C:\java\geoserver
>>>>Revision: Head Revision
>>>>Press OK
>>>>
>>>>But got the following error for above URL; however, it works for
>>>>"https://svn.codehaus.org/geoserver/trunk/geoserver".  The error
>>>>is:
>>>>
>>>>Error: Can't connect to host 'svn.codehaus.org': No connection could be
>>>
>>>made
>>>
>>>
>>>
>>>>because
>>>>Error: the target machine actively refused it.
>>>>
>>>
>>>What docs were you following, perhaps they are out of date.
>>>
>>>
>>>
>>>
>>>>Assuming that I want to run the cite test suite with my PostGIS
>
> datastore,
>
>>>>where do I specify the hostname for the cite database?  Thank you.
>>>
>>>So you want to run cite tests against your geoserver instance? There is
>>>documentation on how to do this available here:
>>>
>>>http://docs.codehaus.org/display/GEOSDOC/Running+Cite+Tests
>>>
>>>
>>>
>>>
>>>>v/r,
>>>>Efren
>>>>-----Original Message-----
>>>>From: Justin Deoliveira [mailto:[hidden email]]
>>>>Sent: Wednesday, October 19, 2005 10:24 AM
>>>>To: [hidden email]
>>>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>>>
>>>>
>>>>The latest 1.3.x release. Which is 1.3.RC4.SC1. It is available from
>>>>http://dist.codehaus.org/geoserver
>>>>
>>>>-Justin
>>>>
>>>>Efren Serra wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Justin,
>>>>>
>>>>>Which version of GeoServer should I be using?  I am using geoserver
>>>>
>>>><1.2.4>.
>>>>
>>>>
>>>>
>>>>
>>>>>Thank you.
>>>>>
>>>>>v/r,
>>>>>Efren
>>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email]
>>>>>[mailto:[hidden email]]On Behalf Of Justin
>>>>>Deoliveira
>>>>>Sent: Tuesday, October 18, 2005 7:25 PM
>>>>>To: 'Geoserver-devel'
>>>>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>>>>
>>>>>
>>>>>I have added the new SVG renderer based on batik. There is now a
>>>>>configuration option under Config->WMS->Rendering in order to switch
>>>>>between the two. The default is the fast svg renderer.
>>>>>
>>>>>-Justin
>>>>>
>>>>>Randy George wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi Justin, Gabriel,
>>>>>>
>>>>>> I haven't thought about this too long either, but was intrigued with
>>>>>>the external .sld capability that allows the consumer to override
>>
>>default
>>
>>
>>>>>>server styling and was wondering about that possibility in an svg event
>>>>>>listener sense.
>>>>>>
>>>>>> Like styling it involves adding attributes to elements. A javascript
>>>>>>href would have to point to an external .js which lets a consumer
>>
>>control
>>
>>
>>>>>>behavior without reprocessing the svg. A default js reference could
>
> have
>
>>>>>an
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>empty function for each event type.
>>>>>>
>>>>>>&script=http://myserver/js/test.js
>>>>>><script xlink:href="http://myserver/js/test.js" />
>>>>>>
>>>>>>But this does complicate things more then necessary and probably
>
> extends
>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>OGC spec, so I think Gabriel is right, not a good idea.
>>>>>>
>>>>>> It would be better to set up a pass through servlet in front of the
>>>>>>WFS with an xsl or SAX ContentHandler to add the event listener
>>>
>>>attributes
>>>
>>>
>>>
>>>>>>and href js, perhaps using an additional event field from the data
>
> store
>
>>>>>>record.
>>>>>>
>>>>>> At least with &format=image/svg+xml the gml2svg.xsl step is skipped
>>>>>>
>>>>>>Thanks
>>>>>>Randy
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [hidden email]
>>>>>>[mailto:[hidden email]] On Behalf Of
>
> Justin
>
>>>>>>Deoliveira
>>>>>>Sent: Tuesday, October 18, 2005 11:23 AM
>>>>>>To: Randy George
>>>>>>Cc: 'Gabriel Roldán'; 'Geoserver-devel'
>>>>>>Subject: Re: [Geoserver-devel] Re: SVG Rendering
>>>>>>
>>>>>>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:[hidden email]]
>>>>>>>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: [hidden email]
>>>>>>>>[mailto:[hidden email]] 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
>>>>>>>>[hidden email]
>>>>>>>>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
>>>>>>>[hidden email]
>>>>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>--
>>>>>Justin Deoliveira
>>>>>The Open Planning Project
>>>>>http://topp.openplans.org
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>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
>>>>>[hidden email]
>>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>Justin Deoliveira
>>>>The Open Planning Project
>>>>http://topp.openplans.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>--
>>>Justin Deoliveira
>>>The Open Planning Project
>>>http://topp.openplans.org
>>>
>>>
>>>
>>
>>
>>
>>--
>>Justin Deoliveira
>>The Open Planning Project
>>http://topp.openplans.org
>>
>>
>>
>
>
>
> --
> Justin Deoliveira
> The Open Planning Project
> http://topp.openplans.org
>
>
> -------------------------------------------------------
> 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
> [hidden email]
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


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


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