[Geoserver-devel] SLD - things happening and questions

davidblasby · May 11, 2005, 5:01pm

Here's what I'm planning on doing over the next little while:

1. Adding Spatial DB in a Box functions to Filter ("<Function
name=...>"). James and his crew have done a bunch of infrastructure on
this, so I dont expect this too be too difficult.

2. Add in Geoserver support for <NamedStyle>. Basically, this lets you
"include" another SLD in your SLD.

..
        <NamedStyle>
            <Name>CenterLine</Name> 
        </NamedStyle>
..

There's a bit of Geotools support for this, but its needs quite a bit of
work:
    a) it needs a repository of named styles (already existing in
Geoserver)
    b) it needs support to do the actual include/render properly.
    c) it needs geoserver support for when the user updates one of the
styles (depending on how B is implemented)

Anyone have any ideas on how to do this?

3. SLD post
Anyone have any ideas on how to do this one?

dave

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

Chris_Holmes1 · May 12, 2005, 10:50am

Quoting dblasby@anonymised.com:

Here's what I'm planning on doing over the next little while:

1. Adding Spatial DB in a Box functions to Filter ("<Function
name=...>"). James and his crew have done a bunch of infrastructure
on
this, so I dont expect this too be too difficult.

Cool.

2. Add in Geoserver support for <NamedStyle>. Basically, this lets
you
"include" another SLD in your SLD.

..
        <NamedStyle>
            <Name>CenterLine</Name> 
        </NamedStyle>
..

There's a bit of Geotools support for this, but its needs quite a bit
of
work:
    a) it needs a repository of named styles (already existing in
Geoserver)
    b) it needs support to do the actual include/render properly.
    c) it needs geoserver support for when the user updates one of
the
styles (depending on how B is implemented)

Anyone have any ideas on how to do this?

Well, if we do the repository of named styles in GeoTools (and I don't
really see another way to do it), then I would think that GeoServer
should just use that data structure directly, so that when a style is
updated it updates the geotools repository. And thus when the style is
parsed it will pick up the updated one from the gt2 repository. As for
b) I think the replacement would take place at the Style parsing level,
no? That it would affect the fields in the Style object we make?
Though GeoTools has this difference between SLD and Style which I never
quite understood, and I feel like named styles might be at the SLD
level? And god the error checking for it is so bad.

3. SLD post
Anyone have any ideas on how to do this one?

Er. Your options are figure out XDO and use it. Or else you could use
pure DOM, as that's what the SLD reader is written in. This breaks
habit in GeoServer, as we're all about SAX, but I imagine it'd end up
even nastier if you were to try to do a mixed SAX/DOM parser. And the
fields you need to figure out are pretty trivial anyways. So all you'd
need to do is extend geoserver.util.requests.readers.XmlRequestReader
and implement the read method in a GetMapXmlReader. Get your dom tree,
extract out the GetMap params that you need, put them in the GetMap
request, and then read the SLD with the SLD reader. This should
actually end up working just as well as the Get reader, and thinking on
it shouldn't be too hard to implement. I can't find a schema for the
POST GetMap request, but the sld spec has a sample. Though actually
with DOM the order doesn't even matter so much, you just have to find
them.

Chris

dave

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

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&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/

jive · May 12, 2005, 12:09pm

Chris Holmes wrote:

Anyone have any ideas on how to do this?

Well, if we do the repository of named styles in GeoTools (and I don't
really see another way to do it), then I would think that GeoServer
should just use that data structure directly, so that when a style is
updated it updates the geotools repository.

Guys it seems to me that SMS is being orphaned and slurped up by the Catalog 2.0 spec.
It will be using the same metadata defined by the SMS though (as if that is any help). So implement putStyles and getStyles but don't bother with a fill Style/Symbol Management Service.

3. SLD post
Anyone have any ideas on how to do this one?

Er. Your options are figure out XDO and use it. Or else you could use
pure DOM, as that's what the SLD reader is written in. This breaks
habit in GeoServer, as we're all about SAX, but I imagine it'd end up
even nastier if you were to try to do a mixed SAX/DOM parser. And the
fields you need to figure out are pretty trivial anyways. So all you'd
need to do is extend geoserver.util.requests.readers.XmlRequestReader
and implement the read method in a GetMapXmlReader.

We are also interested in doing the XDO SLD thing. I am trying to decide if it is *in* scope for uDig (basically I don't think I can do a decent theme based editor without better SLD support). If you guys are interested it would tip the balance considerably.

What I have in mind is Richard doing the SLD parser (he has already started an knows what he is doing), and Dblasby providing test cases. Is this a useful arangement?
The one unknown in this is the state of XDO, dzwiers has continued development.

Jody

Chris_Holmes1 · May 12, 2005, 12:40pm

Quoting Jody Garnett <jgarnett@anonymised.com>:

Chris Holmes wrote:

>>Anyone have any ideas on how to do this?
>>
>>
>Well, if we do the repository of named styles in GeoTools (and I
don't
>really see another way to do it), then I would think that GeoServer
>should just use that data structure directly, so that when a style
is
>updated it updates the geotools repository.
>
Guys it seems to me that SMS is being orphaned and slurped up by the
Catalog 2.0 spec.
It will be using the same metadata defined by the SMS though (as if
that
is any help). So implement putStyles and getStyles but don't bother
with
a fill Style/Symbol Management Service.

Cool. We weren't planning on it, so no worries there.

>>3. SLD post
>>Anyone have any ideas on how to do this one?
>>
>>
>Er. Your options are figure out XDO and use it. Or else you could
use
>pure DOM, as that's what the SLD reader is written in. This breaks
>habit in GeoServer, as we're all about SAX, but I imagine it'd end
up
>even nastier if you were to try to do a mixed SAX/DOM parser. And
the
>fields you need to figure out are pretty trivial anyways. So all
you'd
>need to do is extend
geoserver.util.requests.readers.XmlRequestReader
>and implement the read method in a GetMapXmlReader.
>
We are also interested in doing the XDO SLD thing. I am trying to
decide
if it is *in* scope for uDig (basically I don't think I can do a
decent
theme based editor without better SLD support). If you guys are
interested it would tip the balance considerably.

What I have in mind is Richard doing the SLD parser (he has already
started an knows what he is doing), and Dblasby providing test cases.
Is this a useful arangement?

David's call. Would Richard also do our GetMap request? It's just a
few more params, the SLD is the hard part, the GetMap stuff is just the
same as the kvps. But it would take a lot longer if dblasby had to
learn all the XDO stuff just to get those values.

The one unknown in this is the state of XDO, dzwiers has continued
development.

Jody

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