Re: [Geotools-devel] svgsupport B4 prep

[<GAB...@te...>]

I just forgot to reply to all:

----- Mensaje Original -----
De: ch...@op...
Fecha: Jueves, Abril 15, 2004 9:04 am
Asunto: Re: [Geotools-devel] svgsupport B4 prep

> This reminds me of something I've been meaning to bring up for a bit
> (and which would have the side effect of fixing this problem).
> 
> What would people thinking of replacing the current SVG support stuff
> with the SVG Encoder that Gabriel wrote for GeoServer?  I believe he
> did so because it was faster, and I think it handles everything the
> current SVG support does (the current one doesn't do styling does 
> it? 
> We don't do that in GeoServer yet).

Yes, I wrote it because:
 - Batik builds a DOM, wich is a drawback to our feature streaming approach
 - Batik generates pretty ugly svg code (style and transform applied
directly to every feature, resulting in a huge SVG)
 - "generalizes" geometries, resulting in no zoomable images, and I
needed to load a SVG "layer" once and navigate it withoud reloading.

the drawbacks:
 - Batik does manages styles, through its java.awt.Graphics2D impl.
 - Geoserver's SVGEncoder is pretty uggly written. Anyway this is
important: I choosed to not use JAXP for serialization, since the
geometries in SVG are element attributes (for polygons and linestrings,
it uses a "path" element, wich contains the geometry in the "d"
attribute: <path d="Mx y..."/>). I we use JAXP, performance will be
degradated when creating an AttributeIml for each geometry, mostly with
huge polygons, wich is my case)

the pros: 
 - Geoserver's SVG encoder allows sending feature data with geometry
data. For example, one can request FIDs and any other attribute, wich
will be encoding as an elements attribute. (at this point, we should
 - SVGEncoder writes streamed and _clean_ svg code, using relative
coordinates to compress content.
 - Athough it does not supports styling yet, I managed it with dynamic
CSS style assignation on the client side. It is unoptimal, but a workaround.

all this allows to create feature rich SVG clients. The one I just
created loads layers on demand, with attribute data, wich allows to show
tooltips with attribute text, and the like. Programming an SVG client
with JavaScript allows to travers the map DOM allowing to create
thematic maps without quering the server again, and all that stuff.
> 
> I've also heard reports from other people that batik is slow, at least
> for mapping purposes.  So even if the GeoServer code is not quite
> appropriate I think we should consider doing the svg generation by 
> handinstead of with Batik.  Gabriel, are there any big issues 
> preventing us
> from rolling geoserver's svg encoding into geotools?  I think that it
> would be better there, so more people can make use of it, and I don't
> believe it's super geoserver specific right now.

I think there were be no problem. SVGEncoder is pretty independent of
geoserver.

Anyway, it should need some rework to be a candidate for a geotools
module. I'm far to be proud of it's design, at time of writting it I had
a _really_ adjusted agenda. (and I still have it :(

But with some help we can make a good job with it.

I was thinking of investigating how batik resolves the styling stuff
more than one time, but did not get the time to do it.
What I have in mind is something like traversing the SLDTyle objects and
generate defs in the SVG document mapping that styles to CSS, and at the
time of writting the SVG geometries, with are just XML elements, assing
it the corresponding style with the "class" attribute. This approach
should maintain the SVG content small and still be powerfull, since the
style can be applied to a "group" ("g" element) of SVG geometries.

hope this helps,

Gabriel
> 
> Thoughts?  James, I think you're svg module maintainer?
> 
> Chris
> 
> Quoting Jody Garnett <jga...@re...>:
> 
> > I tried from an empty repository ...
> >
> > > This directory does not contain the links I am looking for (or 
> even> > the jars I see in my maven repository).  I do see the 
> batik-1.5.jar
> > in
> > > the repository (maybe another module downloaded this?). I 
> think if
> > I
> > > cleaned out my repository I would be even worse shape; let me try.
> >
> > The same three modules fail.  The project.xml file did manage to 
> find> a
> > batik-util-1.1.1.jar (I don't know how), and I am not sure how 
> to ask
> > it
> > to use the batik-util.jar from batik-1.5.jar.
> >
> > Changing the project.xml file to the following:
> >
> > >     <dependency>
> > >       <id>batik+svggen</id>
> > >       <version>1.5.1</version>
> > >       <url>" target="l">http://xml.apache.org/batik/dist</url>
> > >     </dependency>
> >
> > resulted in:
> >
> > > Attempting to download batik-util-1.5.1.jar.
> > > WARNING: Failed to download batik-util-1.5.1.jar.
> > > Attempting to download batik-svggen-1.5.1.jar.
> > > WARNING: Failed to download batik-svggen-1.5.1.jar.
> > > Attempting to download batik-awt-util-1.5.1.jar.
> > > WARNING: Failed to download batik-awt-util-1.5.1.jar.
> > > The build cannot continue because of the following unsatisfied
> > > dependencies:
> > >
> > > batik-util-1.5.1.jar (try downloading from
> > > http://xml.apache.org/batik/dist)
> > > batik-svggen-1.5.1.jar (try downloading from
> > > http://xml.apache.org/batik/dist)
> > > batik-awt-util-1.5.1.jar (try downloading from
> > > http://xml.apache.org/batik/dist)
> >
> > Changing the version to 1.5 does compile (!) - it manages to
> > "download"
> > the jars although I don't how since they don't exist at that url.
> > This
> > version (1.5) is still not sufficeint - maven jar:install still 
> fails> with the same error.
> >
> > > Testcase: testGenerateSVG(org.geotools.svg.SVGTest):    Caused an
> > ERROR
> > > or> > java.lang.NoClassDefFoundError:
> > > or>
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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:
> > _______________________________________________
> > Geotools-devel mailing list
> > Geo...@li...
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >
> 
> 
> 
> 
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>