[Geoserver-devel] Serving SVG to Mozilla

Some questions from a GeoServer and GML newbie:

Geoserver is now the open source OGC reference implementation for WFS, correct?
Doest that mean GeoServer is good at serving GML streams?
Does that mean GeoServer is a good server to an SVG client?
Has anyone played with using GeoServer against an SVG enabled Mozilla build?
What problems might one encounter in attempting to test such an approach?

Thank you for your insights.

- Ben

:::::::::::::::::::::::::::::::::::::
Benjamin Lewis
Advanced Technology Solutions, Inc.
1525 Oregon Pike, Suite 202
Lancaster, Pennsylvania 17601-4372
717.399.7007
blewis@anonymised.com
http://www.atsincorp.com
:::::::::::::::::::::::::::::::::::::

Some questions from a GeoServer and GML newbie:

Geoserver is now the open source OGC reference implementation for WFS, correct?

Yes.

Doest that mean GeoServer is good at serving GML streams?

Yes.

Does that mean GeoServer is a good server to an SVG client?

Well, GeoServer would ideally have a specialized WFS client that uses SVG.
You can't go directly GML -> SVG, so the SVG client is going to have to
know how to transform GML into SVG. This could be done efficiently with
XSLT. A good WFS client would know to send the right requests, and would
transform the GML into SVG for display. Some friends of ours are working
on an open source WFS client, check them out at http://mapbuilder.sf.net.

Has anyone played with using GeoServer against an SVG enabled Mozilla build?
What problems might one encounter in attempting to test such an approach?

If people on this list with experience with SVG and GML could sound in
that'd be great, as I've never actually attempted it myself. If Mozilla
had a way to transform XSLT transformations it might be possible to send
GML straight to it. But I'm not sure.

  Chris

> Does that mean GeoServer is a good server to an SVG client?
Well, GeoServer would ideally have a specialized WFS client that uses SVG.
You can't go directly GML -> SVG, so the SVG client is going to have to
know how to transform GML into SVG. This could be done efficiently with
XSLT.

An alternative approach is to use an SVG enabled WMS server, an extension to the WMS which has just been integrated into GeoServer is under development and may make its way into the code base soon.
(Gabriel if your on this list, what state is that work in now? It would be cool to get it up and running)

The advantage of this approach is that you get to control the styling of the output rather than just having a plain set of vectors.

If people on this list with experience with SVG and GML could sound in
that'd be great, as I've never actually attempted it myself. If Mozilla
had a way to transform XSLT transformations it might be possible to send
GML straight to it. But I'm not sure.

Client side xslt is certainly possible in Mozila so it may be something to experiment with:
http://www.surguy.net/articles/client-side-svg.xml

I'm just not sure how you would handle styling...

James

A while ago I had a bit of play around with transforming GML into SVG. What I did was have a XML Stylesheet that transformed a Styled Layer Descriptor into another XML Stylesheet that would then transform GML into SVG based on the style defined in the SLD. However performance didn't scale. Any sizeable number of features and it would get VERY slow, XSLT is just not made for that amount of data, either that or the transform engine I used (XALAN) couldn't cope..

I think the best solution (performance wise) for producing SVG maps is to use something like the svg support currently available in Geotools.

Sean

> Does that mean GeoServer is a good server to an SVG client?
Well, GeoServer would ideally have a specialized WFS client that uses SVG.
You can't go directly GML -> SVG, so the SVG client is going to have to
know how to transform GML into SVG. This could be done efficiently with
XSLT.

An alternative approach is to use an SVG enabled WMS server, an extension to the WMS which has just been integrated into GeoServer is under development and may make its way into the code base soon.
(Gabriel if your on this list, what state is that work in now? It would be cool to get it up and running)

The advantage of this approach is that you get to control the styling of the output rather than just having a plain set of vectors.

If people on this list with experience with SVG and GML could sound in
that'd be great, as I've never actually attempted it myself. If Mozilla
had a way to transform XSLT transformations it might be possible to send
GML straight to it. But I'm not sure.

Client side xslt is certainly possible in Mozila so it may be something to experiment with:
http://www.surguy.net/articles/client-side-svg.xml

I'm just not sure how you would handle styling...

James

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hi all.
As some of you know, this topic is the one for wich I'm here.
I've just returned from some vacation days in Madrid, now trying to get in
the road again.

Wich we had are some pieces of this puzzle that need to fit together yet.
But yes,
the idea is to have WMS integrated in geoserver and capable of serving SVG
content.

by now, our working prototipe was a gtwms serving SVG using batik.
Once having this working, the effort is in coupling all this with this
priorities:
- get geoserver's WFS and WMS using as common code base as posible.
- get geoserver using streaming feature sources and streaming GML writing
- improving SVG generation with a streaming approach (this is almost done
except for styling)
  our custom SVG encoder produces SVG code a lot cleaner and smallest than
batik.
- sure I'm missing something

unfortunatelly, no integration has been done yet, but I think we can get
something
working as the end of this week, since I'll be more active from now on.

Gabriel

----- Original Message -----
From: "Sean Geoghegan" <sean@anonymised.com>
To: "James Macgill" <jmacgill@anonymised.com>
Cc: "Ben Lewis" <blewis@anonymised.com>;
<geoserver-devel@lists.sourceforge.net>
Sent: Friday, October 10, 2003 5:45 PM
Subject: Re: [Geoserver-devel] Serving SVG to Mozilla

A while ago I had a bit of play around with transforming GML into SVG.
What I did was have a XML Stylesheet that transformed a Styled Layer
Descriptor into another XML Stylesheet that would then transform GML
into SVG based on the style defined in the SLD. However performance
didn't scale. Any sizeable number of features and it would get VERY
slow, XSLT is just not made for that amount of data, either that or the
transform engine I used (XALAN) couldn't cope..

I think the best solution (performance wise) for producing SVG maps is
to use something like the svg support currently available in Geotools.

Sean

>
>>
>> > Does that mean GeoServer is a good server to an SVG client?
>> Well, GeoServer would ideally have a specialized WFS client that uses
>> SVG.
>> You can't go directly GML -> SVG, so the SVG client is going to have to
>> know how to transform GML into SVG. This could be done efficiently

with

>> XSLT.
>
>
> An alternative approach is to use an SVG enabled WMS server, an
> extension to the WMS which has just been integrated into GeoServer is
> under development and may make its way into the code base soon.
> (Gabriel if your on this list, what state is that work in now? It
> would be cool to get it up and running)
>
> The advantage of this approach is that you get to control the styling
> of the output rather than just having a plain set of vectors.
>
>> If people on this list with experience with SVG and GML could sound in
>> that'd be great, as I've never actually attempted it myself. If

Mozilla

>> had a way to transform XSLT transformations it might be possible to

send

>> GML straight to it. But I'm not sure.
>
>
> Client side xslt is certainly possible in Mozila so it may be
> something to experiment with:
> http://www.surguy.net/articles/client-side-svg.xml
>
> I'm just not sure how you would handle styling...
>
> James
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

A late addition to this useful discussion....

In Mapbuilder we are taking a couple of different approaches to SVG
generation: client-side parsing of WFS responses (GML > SVG) and server-side
parsing. The first, client-side track began as GeoClient, an SVG-based WFS
client. A version, usable only with a custom PHP/MySQL WFS, is downloadable
at
http://sourceforge.net/project/showfiles.php?group_id=35246&release_id=18846
7

We're working, slowly, to genericize and enhance this work.

For developers working with Mozilla's (limited) SVG support, a paper I
delivered at this year's SVG Open conference might be of interest as it
includes Mozilla-specific discussion. The application GeoClientXHTML (an
XHTML version of GeoClient, incorporating WMS client functionality) is
designed for Mozilla's native SVG support (as well as the Adobe SVG Viewer
plug-in). The paper "SVG As an Editing Environment for Geographical Data"
is linked at:

http://www.svgopen.org/2003/proceedings.do

(near the bottom of a long page--to find it, search the page after it loads
for my name, Nedjo). GeoClientXHTML is downloadable at:

http://sourceforge.net/project/showfiles.php?group_id=35246&release_id=18846
2

Nedjo Rogers

----- Original Message -----
From: Chris Holmes <cholmes@anonymised.com>
To: Ben Lewis <blewis@anonymised.com>
Cc: <geoserver-devel@lists.sourceforge.net>
Sent: Friday, October 10, 2003 5:55 AM
Subject: Re: [Geoserver-devel] Serving SVG to Mozilla

> Some questions from a GeoServer and GML newbie:
>
> Geoserver is now the open source OGC reference implementation for WFS,

correct?

Yes.

> Doest that mean GeoServer is good at serving GML streams?
Yes.

> Does that mean GeoServer is a good server to an SVG client?
Well, GeoServer would ideally have a specialized WFS client that uses SVG.
You can't go directly GML -> SVG, so the SVG client is going to have to
know how to transform GML into SVG. This could be done efficiently with
XSLT. A good WFS client would know to send the right requests, and would
transform the GML into SVG for display. Some friends of ours are working
on an open source WFS client, check them out at http://mapbuilder.sf.net.

> Has anyone played with using GeoServer against an SVG enabled Mozilla

build?

> What problems might one encounter in attempting to test such an

approach?

If people on this list with experience with SVG and GML could sound in
that'd be great, as I've never actually attempted it myself. If Mozilla
had a way to transform XSLT transformations it might be possible to send
GML straight to it. But I'm not sure.

Chris

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel