[Geoserver-users] Styling with the CSS module

Matthias_Uden · December 6, 2012, 12:53pm

Hi all,

I've recently discovered the CSS module as an alternative to SLD styling and I'm quite enthusiastic about it. Still, I cannot accomplish everything I used to do with SLD before...

Here are two specific questions:

1) When specifying a custom icon for a mark with url(...), is it possible to get a relative path in the generated SLD instead of an absolute one? Also, is there a possibility to specify the format of that image correctly? Currently, it is always converted to jpeg, even when I put in a png...

Example:
CSS:
mark: url('icons/entry.png');

SLD:
<sld:ExternalGraphic>
<sld:OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png"/> <sld:Format>image/jpeg</sld:Format>
</sld:ExternalGraphic>

2) Specifying an attributes value dynamically using a column of the underlying DB table works fine for e.g. labels. However, it doesn't work for colors.

Example (working):
CSS:
label: [key];

SLD:
<sld:Label>
<ogc:PropertyName>key</ogc:PropertyName>
</sld:Label>

Example (not working):
CSS:
fill: [color];

SLD:
<sld:Fill/>

Any help is appreciated!
Thanks in advance and all the best,
Matthias

David_Winslow · December 6, 2012, 3:14pm

Relative Paths for Icons
The short answer is, no, you can’t make it do that. The problem is that the CSS-SLD converter actually uses GeoTools’ SLD writing code to generate the SLD files, and GeoTools’ SLD support is not symmetric (I mean it cannot write everything that it can read.) Resolving relative paths into absolute ones is a compromise between the actually desired behavior and not supporting relative paths at all. This could probably be fixed at the GeoTools level, but I haven’t taken the time to inquire into why this asymmetry was built in in the first place.

Why are relative paths a problem for you? Maybe there is a workaround that could be used (for example, if it’s a problem with relocating data directories, I could add a tool to re-convert all CSS styles which would re-resolve the paths.)

Icon Media Types
The image type logic is not as sophisticated as you might expect - things like dynamic symbolizers1 make it impossible to know the media type for the image in general, so I just threw my hands up and made it literally ‘image/jpeg’ if you don’t specify. You can provide the media type explicitly with the fill-mime, stroke-mime, mark-mime, or shield-mime property. For example:

{
fill: url(pattern.png);
fill-mime: “image/png”;
}

I don’t guess it would be too hard to make the CSS-SLD converter try to look up the icon and inspect it to provide the default, but this is not as big a priority to me as rendering transformations. If you want to look into it let me know and I can give you some pointers on what’s needed.

Dynamic Color
This is simply a bug (the color handling is a bit more complex than the label handling, to allow for rgb() color syntax.) Again, this is probably easily fixable given the time to work on it; I’d say even easier than smart defaults for the icon mime-type property.

If you’d like to file bugs against GeoScript-Scala2 I’ll keep them up-to-date if and when I get around to working on these problems.

···

On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden <matthias.uden@anonymised.com> wrote:

Hi all,

I’ve recently discovered the CSS module as an alternative to SLD styling
and I’m quite enthusiastic about it. Still, I cannot accomplish
everything I used to do with SLD before…

Here are two specific questions:

When specifying a custom icon for a mark with url(…), is it
possible to get a relative path in the generated SLD instead of an
absolute one? Also, is there a possibility to specify the format of that
image correctly? Currently, it is always converted to jpeg, even when I
put in a png…

Example:
CSS:
mark: url(‘icons/entry.png’);

SLD:
sld:ExternalGraphic
<sld:OnlineResource xmlns:xlink=“http://www.w3.org/1999/xlink”
xlink:type=“simple”
xlink:href=“file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png”/>
sld:Formatimage/jpeg</sld:Format>
</sld:ExternalGraphic>

Specifying an attributes value dynamically using a column of the
underlying DB table works fine for e.g. labels. However, it doesn’t work
for colors.

Example (working):
CSS:
label: [key];

SLD:
sld:Label
ogc:PropertyNamekey</ogc:PropertyName>
</sld:Label>

Example (not working):
CSS:
fill: [color];

SLD:
sld:Fill/

Any help is appreciated!
Thanks in advance and all the best,
Matthias

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Matthias_Uden · December 7, 2012, 11:12am

David,

thanks a lot for the quick answer and clarification!
I didn't know about the CSS property "mark-mime", since it is not part of the CSS Property Listing (http://docs.geoserver.org/stable/en/user/community/css/properties.html). This at least fixed the Icon Media Type issue.
It's a pity that dynamic colors are not yet supported. I suppose that the CSS Module is currently not actively developed anymore due to lack of time. Are you the only developer?

Cheers,
Matthias

Am 06.12.2012 16:14, schrieb David Winslow:

*Relative Paths for Icons
*The short answer is, no, you can't make it do that. The problem is
that the CSS-SLD converter actually uses GeoTools' SLD writing code to
generate the SLD files, and GeoTools' SLD support is not symmetric (I
mean it cannot write everything that it can read.) Resolving relative
paths into absolute ones is a compromise between the actually desired
behavior and not supporting relative paths at all. This could probably
be fixed at the GeoTools level, but I haven't taken the time to inquire
into why this asymmetry was built in in the first place.

Why are relative paths a problem for you? Maybe there is a workaround
that could be used (for example, if it's a problem with relocating data
directories, I could add a tool to re-convert all CSS styles which would
re-resolve the paths.)
*
Icon Media Types*
The image type logic is not as sophisticated as you might expect -
things like dynamic symbolizers[1] make it impossible to know the media
type for the image in general, so I just threw my hands up and made it
literally 'image/jpeg' if you don't specify. You can provide the media
type explicitly with the *fill-mime*, *stroke-mime*, *mark-mime*, or
*shield-mime* property. For example:

* {
   fill: url(pattern.png);
   fill-mime: "image/png";
}

I don't guess it would be too hard to make the CSS-SLD converter try to
look up the icon and inspect it to provide the default, but this is not
as big a priority to me as rendering transformations. If you want to
look into it let me know and I can give you some pointers on what's needed.

*Dynamic Color*
This is simply a bug (the color handling is a bit more complex than the
label handling, to allow for rgb() color syntax.) Again, this is
probably easily fixable given the time to work on it; I'd say even
easier than smart defaults for the icon mime-type property.

If you'd like to file bugs against GeoScript-Scala[2] I'll keep them
up-to-date if and when I get around to working on these problems.

[1]: http://blog.geoserver.org/2008/12/08/dynamic-symbolizers-part-1/
[2]: https://github.com/dwins/geoscript.scala/issues

On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden <matthias.uden@anonymised.com
<mailto:matthias.uden@anonymised.com>> wrote:

    Hi all,

    I've recently discovered the CSS module as an alternative to SLD styling
    and I'm quite enthusiastic about it. Still, I cannot accomplish
    everything I used to do with SLD before...

    Here are two specific questions:

    1) When specifying a custom icon for a mark with url(...), is it
    possible to get a relative path in the generated SLD instead of an
    absolute one? Also, is there a possibility to specify the format of that
    image correctly? Currently, it is always converted to jpeg, even when I
    put in a png...

    Example:
    CSS:
    mark: url('icons/entry.png');

    SLD:
    <sld:ExternalGraphic>
    <sld:OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
    xlink:type="simple"
    xlink:href="file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png"/>
    <sld:Format>image/jpeg</sld:Format>
    </sld:ExternalGraphic>

    2) Specifying an attributes value dynamically using a column of the
    underlying DB table works fine for e.g. labels. However, it doesn't work
    for colors.

    Example (working):
    CSS:
    label: [key];

    SLD:
    <sld:Label>
    <ogc:PropertyName>key</ogc:PropertyName>
    </sld:Label>

    Example (not working):
    CSS:
    fill: [color];

    SLD:
    <sld:Fill/>

    Any help is appreciated!
    Thanks in advance and all the best,
    Matthias

    ------------------------------------------------------------------------------
    LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
    Remotely access PCs and mobile devices and provide instant support
    Improve your efficiency, and focus on delivering more value-add services
    Discover what IT Professionals Know. Rescue delivers
    http://p.sf.net/sfu/logmein_12329d2d
    _______________________________________________
    Geoserver-users mailing list
    Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

David_Winslow · December 7, 2012, 2:49pm

You’re right, the docs are incorrect wrt the MIME information. I’ll go ahead and update them so they will be correct after the next automated rebuild.

I am indeed the only developer on the CSS module. It’s not under frequent development but I do try to keep up with bugs reported on this mailing list (and the github issue list.) Actually I resolved the dynamic color bug last night. I haven’t updated the plugin in the community build yet (maybe this weekend) but if you want an early peak you can just grab the JAR file from http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/ and overwrite the one that you already installed.

···

On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden <matthias.uden@anonymised.com> wrote:

David,

thanks a lot for the quick answer and clarification!
I didn’t know about the CSS property “mark-mime”, since it is not part
of the CSS Property Listing
(http://docs.geoserver.org/stable/en/user/community/css/properties.html). This
at least fixed the Icon Media Type issue.
It’s a pity that dynamic colors are not yet supported. I suppose that
the CSS Module is currently not actively developed anymore due to lack
of time. Are you the only developer?

Cheers,
Matthias

Am 06.12.2012 16:14, schrieb David Winslow:

*Relative Paths for Icons
*The short answer is, no, you can’t make it do that. The problem is

that the CSS-SLD converter actually uses GeoTools’ SLD writing code to
generate the SLD files, and GeoTools’ SLD support is not symmetric (I
mean it cannot write everything that it can read.) Resolving relative
paths into absolute ones is a compromise between the actually desired
behavior and not supporting relative paths at all. This could probably
be fixed at the GeoTools level, but I haven’t taken the time to inquire
into why this asymmetry was built in in the first place.

Why are relative paths a problem for you? Maybe there is a workaround
that could be used (for example, if it’s a problem with relocating data
directories, I could add a tool to re-convert all CSS styles which would
re-resolve the paths.)

Icon Media Types*

The image type logic is not as sophisticated as you might expect -
things like dynamic symbolizers1 make it impossible to know the media
type for the image in general, so I just threw my hands up and made it
literally ‘image/jpeg’ if you don’t specify. You can provide the media

type explicitly with the fill-mime, stroke-mime, mark-mime, or
shield-mime property. For example:

{
fill: url(pattern.png);
fill-mime: “image/png”;
}

I don’t guess it would be too hard to make the CSS-SLD converter try to
look up the icon and inspect it to provide the default, but this is not
as big a priority to me as rendering transformations. If you want to
look into it let me know and I can give you some pointers on what’s needed.

Dynamic Color

This is simply a bug (the color handling is a bit more complex than the
label handling, to allow for rgb() color syntax.) Again, this is
probably easily fixable given the time to work on it; I’d say even
easier than smart defaults for the icon mime-type property.

If you’d like to file bugs against GeoScript-Scala2 I’ll keep them
up-to-date if and when I get around to working on these problems.

On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden <matthias.uden@anonymised.com

mailto:[matthias.uden@anonymised.com](mailto:matthias.uden@anonymised.com)> wrote:

Hi all,

I’ve recently discovered the CSS module as an alternative to SLD styling
and I’m quite enthusiastic about it. Still, I cannot accomplish
everything I used to do with SLD before…

Here are two specific questions:

When specifying a custom icon for a mark with url(…), is it
possible to get a relative path in the generated SLD instead of an
absolute one? Also, is there a possibility to specify the format of that
image correctly? Currently, it is always converted to jpeg, even when I
put in a png…

Example:
CSS:
mark: url(‘icons/entry.png’);

SLD:
sld:ExternalGraphic
<sld:OnlineResource xmlns:xlink=“http://www.w3.org/1999/xlink”
xlink:type=“simple”
xlink:href=“file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png”/>
sld:Formatimage/jpeg</sld:Format>
</sld:ExternalGraphic>

Specifying an attributes value dynamically using a column of the
underlying DB table works fine for e.g. labels. However, it doesn’t work
for colors.

Example (working):
CSS:
label: [key];

SLD:
sld:Label
ogc:PropertyNamekey</ogc:PropertyName>
</sld:Label>

Example (not working):
CSS:
fill: [color];

SLD:
sld:Fill/

Any help is appreciated!
Thanks in advance and all the best,
Matthias

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net

mailto:[Geoserver-users@lists.sourceforge.net](mailto:Geoserver-users@anonymised.com.sourceforge.net)
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Matthias_Uden · December 11, 2012, 2:06pm

Hi David,

sorry for the late reply. Thanks a lot for the quick fix!
I will definitely have a look at the sources myself someday if I find the time.. For now I can achieve most of the desired styling with the CSS module. Thanks for your good work.

Cheers,
Matthias

Am 07.12.2012 15:49, schrieb David Winslow:

You're right, the docs are incorrect wrt the MIME information. I'll go
ahead and update them so they will be correct after the next automated
rebuild.

I am indeed the only developer on the CSS module. It's not under
frequent development but I do try to keep up with bugs reported on this
mailing list (and the github issue list.) Actually I resolved the
dynamic color bug last night. I haven't updated the plugin in the
community build yet (maybe this weekend) but if you want an early peak
you can just grab the JAR file from
http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/
and overwrite the one that you already installed.

--
David Winslow
OpenGeo - http://opengeo.org/

On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden <matthias.uden@anonymised.com
<mailto:matthias.uden@anonymised.com>> wrote:

    David,

    thanks a lot for the quick answer and clarification!
    I didn't know about the CSS property "mark-mime", since it is not part
    of the CSS Property Listing
    (http://docs.geoserver.org/stable/en/user/community/css/properties.html).
    This
    at least fixed the Icon Media Type issue.
    It's a pity that dynamic colors are not yet supported. I suppose that
    the CSS Module is currently not actively developed anymore due to lack
    of time. Are you the only developer?

    Cheers,
    Matthias

    Am 06.12.2012 16:14, schrieb David Winslow:
     > *Relative Paths for Icons
     > *The short answer is, no, you can't make it do that. The problem is
     > that the CSS-SLD converter actually uses GeoTools' SLD writing
    code to
     > generate the SLD files, and GeoTools' SLD support is not symmetric (I
     > mean it cannot write everything that it can read.) Resolving
    relative
     > paths into absolute ones is a compromise between the actually desired
     > behavior and not supporting relative paths at all. This could
    probably
     > be fixed at the GeoTools level, but I haven't taken the time to
    inquire
     > into why this asymmetry was built in in the first place.
     >
     > Why are relative paths a problem for you? Maybe there is a workaround
     > that could be used (for example, if it's a problem with
    relocating data
     > directories, I could add a tool to re-convert all CSS styles
    which would
     > re-resolve the paths.)
     > *
     > Icon Media Types*
     > The image type logic is not as sophisticated as you might expect -
     > things like dynamic symbolizers[1] make it impossible to know the
    media
     > type for the image in general, so I just threw my hands up and
    made it
     > literally 'image/jpeg' if you don't specify. You can provide the
    media
     > type explicitly with the *fill-mime*, *stroke-mime*, *mark-mime*, or
     > *shield-mime* property. For example:
     >
     > * {
     > fill: url(pattern.png);
     > fill-mime: "image/png";
     > }
     >
     > I don't guess it would be too hard to make the CSS-SLD converter
    try to
     > look up the icon and inspect it to provide the default, but this
    is not
     > as big a priority to me as rendering transformations. If you want to
     > look into it let me know and I can give you some pointers on
    what's needed.
     >
     > *Dynamic Color*
     > This is simply a bug (the color handling is a bit more complex
    than the
     > label handling, to allow for rgb() color syntax.) Again, this is
     > probably easily fixable given the time to work on it; I'd say even
     > easier than smart defaults for the icon mime-type property.
     >
     > If you'd like to file bugs against GeoScript-Scala[2] I'll keep them
     > up-to-date if and when I get around to working on these problems.
     >
     > [1]: http://blog.geoserver.org/2008/12/08/dynamic-symbolizers-part-1/
     > [2]: https://github.com/dwins/geoscript.scala/issues
     >
     > On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden
    <matthias.uden@anonymised.com <mailto:matthias.uden@anonymised.com>
     > <mailto:matthias.uden@anonymised.com
    <mailto:matthias.uden@anonymised.com>>> wrote:
     >
     > Hi all,
     >
     > I've recently discovered the CSS module as an alternative to
    SLD styling
     > and I'm quite enthusiastic about it. Still, I cannot accomplish
     > everything I used to do with SLD before...
     >
     > Here are two specific questions:
     >
     > 1) When specifying a custom icon for a mark with url(...), is it
     > possible to get a relative path in the generated SLD instead
    of an
     > absolute one? Also, is there a possibility to specify the
    format of that
     > image correctly? Currently, it is always converted to jpeg,
    even when I
     > put in a png...
     >
     > Example:
     > CSS:
     > mark: url('icons/entry.png');
     >
     > SLD:
     > <sld:ExternalGraphic>
     > <sld:OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
     > xlink:type="simple"
     >
    xlink:href="file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png"/>
     > <sld:Format>image/jpeg</sld:Format>
     > </sld:ExternalGraphic>
     >
     > 2) Specifying an attributes value dynamically using a column
    of the
     > underlying DB table works fine for e.g. labels. However, it
    doesn't work
     > for colors.
     >
     > Example (working):
     > CSS:
     > label: [key];
     >
     > SLD:
     > <sld:Label>
     > <ogc:PropertyName>key</ogc:PropertyName>
     > </sld:Label>
     >
     > Example (not working):
     > CSS:
     > fill: [color];
     >
     > SLD:
     > <sld:Fill/>
     >
     > Any help is appreciated!
     > Thanks in advance and all the best,
     > Matthias
     >
    ------------------------------------------------------------------------------
     > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free
    Trial
     > Remotely access PCs and mobile devices and provide instant
    support
     > Improve your efficiency, and focus on delivering more
    value-add services
     > Discover what IT Professionals Know. Rescue delivers
     > http://p.sf.net/sfu/logmein_12329d2d
     > _______________________________________________
     > Geoserver-users mailing list
     > Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>
     > <mailto:Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>>
     > https://lists.sourceforge.net/lists/listinfo/geoserver-users
     >
    ------------------------------------------------------------------------------
     > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
     > Remotely access PCs and mobile devices and provide instant support
     > Improve your efficiency, and focus on delivering more value-add
    services
     > Discover what IT Professionals Know. Rescue delivers
     > http://p.sf.net/sfu/logmein_12329d2d
     >
     > _______________________________________________
     > Geoserver-users mailing list
     > Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>
     > https://lists.sourceforge.net/lists/listinfo/geoserver-users
     >

    ------------------------------------------------------------------------------
    LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
    Remotely access PCs and mobile devices and provide instant support
    Improve your efficiency, and focus on delivering more value-add services
    Discover what IT Professionals Know. Rescue delivers
    http://p.sf.net/sfu/logmein_12329d2d
    _______________________________________________
    Geoserver-users mailing list
    Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Matthias_Uden · December 11, 2012, 2:07pm

Hi David,

sorry for the late reply. Thanks a lot for the quick fix!
I will definitely have a look at the sources myself someday if I find the time.. For now I can do achieve most th

Cheers,
Matthias

Am 07.12.2012 15:49, schrieb David Winslow:

You're right, the docs are incorrect wrt the MIME information. I'll go
ahead and update them so they will be correct after the next automated
rebuild.

I am indeed the only developer on the CSS module. It's not under
frequent development but I do try to keep up with bugs reported on this
mailing list (and the github issue list.) Actually I resolved the
dynamic color bug last night. I haven't updated the plugin in the
community build yet (maybe this weekend) but if you want an early peak
you can just grab the JAR file from
http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/
and overwrite the one that you already installed.

--
David Winslow
OpenGeo - http://opengeo.org/

On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden <matthias.uden@anonymised.com
<mailto:matthias.uden@anonymised.com>> wrote:

    David,

    thanks a lot for the quick answer and clarification!
    I didn't know about the CSS property "mark-mime", since it is not part
    of the CSS Property Listing
    (http://docs.geoserver.org/stable/en/user/community/css/properties.html).
    This
    at least fixed the Icon Media Type issue.
    It's a pity that dynamic colors are not yet supported. I suppose that
    the CSS Module is currently not actively developed anymore due to lack
    of time. Are you the only developer?

    Cheers,
    Matthias

    Am 06.12.2012 16:14, schrieb David Winslow:
     > *Relative Paths for Icons
     > *The short answer is, no, you can't make it do that. The problem is
     > that the CSS-SLD converter actually uses GeoTools' SLD writing
    code to
     > generate the SLD files, and GeoTools' SLD support is not symmetric (I
     > mean it cannot write everything that it can read.) Resolving
    relative
     > paths into absolute ones is a compromise between the actually desired
     > behavior and not supporting relative paths at all. This could
    probably
     > be fixed at the GeoTools level, but I haven't taken the time to
    inquire
     > into why this asymmetry was built in in the first place.
     >
     > Why are relative paths a problem for you? Maybe there is a workaround
     > that could be used (for example, if it's a problem with
    relocating data
     > directories, I could add a tool to re-convert all CSS styles
    which would
     > re-resolve the paths.)
     > *
     > Icon Media Types*
     > The image type logic is not as sophisticated as you might expect -
     > things like dynamic symbolizers[1] make it impossible to know the
    media
     > type for the image in general, so I just threw my hands up and
    made it
     > literally 'image/jpeg' if you don't specify. You can provide the
    media
     > type explicitly with the *fill-mime*, *stroke-mime*, *mark-mime*, or
     > *shield-mime* property. For example:
     >
     > * {
     > fill: url(pattern.png);
     > fill-mime: "image/png";
     > }
     >
     > I don't guess it would be too hard to make the CSS-SLD converter
    try to
     > look up the icon and inspect it to provide the default, but this
    is not
     > as big a priority to me as rendering transformations. If you want to
     > look into it let me know and I can give you some pointers on
    what's needed.
     >
     > *Dynamic Color*
     > This is simply a bug (the color handling is a bit more complex
    than the
     > label handling, to allow for rgb() color syntax.) Again, this is
     > probably easily fixable given the time to work on it; I'd say even
     > easier than smart defaults for the icon mime-type property.
     >
     > If you'd like to file bugs against GeoScript-Scala[2] I'll keep them
     > up-to-date if and when I get around to working on these problems.
     >
     > [1]: http://blog.geoserver.org/2008/12/08/dynamic-symbolizers-part-1/
     > [2]: https://github.com/dwins/geoscript.scala/issues
     >
     > On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden
    <matthias.uden@anonymised.com <mailto:matthias.uden@anonymised.com>
     > <mailto:matthias.uden@anonymised.com
    <mailto:matthias.uden@anonymised.com>>> wrote:
     >
     > Hi all,
     >
     > I've recently discovered the CSS module as an alternative to
    SLD styling
     > and I'm quite enthusiastic about it. Still, I cannot accomplish
     > everything I used to do with SLD before...
     >
     > Here are two specific questions:
     >
     > 1) When specifying a custom icon for a mark with url(...), is it
     > possible to get a relative path in the generated SLD instead
    of an
     > absolute one? Also, is there a possibility to specify the
    format of that
     > image correctly? Currently, it is always converted to jpeg,
    even when I
     > put in a png...
     >
     > Example:
     > CSS:
     > mark: url('icons/entry.png');
     >
     > SLD:
     > <sld:ExternalGraphic>
     > <sld:OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
     > xlink:type="simple"
     >
    xlink:href="file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png"/>
     > <sld:Format>image/jpeg</sld:Format>
     > </sld:ExternalGraphic>
     >
     > 2) Specifying an attributes value dynamically using a column
    of the
     > underlying DB table works fine for e.g. labels. However, it
    doesn't work
     > for colors.
     >
     > Example (working):
     > CSS:
     > label: [key];
     >
     > SLD:
     > <sld:Label>
     > <ogc:PropertyName>key</ogc:PropertyName>
     > </sld:Label>
     >
     > Example (not working):
     > CSS:
     > fill: [color];
     >
     > SLD:
     > <sld:Fill/>
     >
     > Any help is appreciated!
     > Thanks in advance and all the best,
     > Matthias
     >
    ------------------------------------------------------------------------------
     > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free
    Trial
     > Remotely access PCs and mobile devices and provide instant
    support
     > Improve your efficiency, and focus on delivering more
    value-add services
     > Discover what IT Professionals Know. Rescue delivers
     > http://p.sf.net/sfu/logmein_12329d2d
     > _______________________________________________
     > Geoserver-users mailing list
     > Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>
     > <mailto:Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>>
     > https://lists.sourceforge.net/lists/listinfo/geoserver-users
     >
    ------------------------------------------------------------------------------
     > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
     > Remotely access PCs and mobile devices and provide instant support
     > Improve your efficiency, and focus on delivering more value-add
    services
     > Discover what IT Professionals Know. Rescue delivers
     > http://p.sf.net/sfu/logmein_12329d2d
     >
     > _______________________________________________
     > Geoserver-users mailing list
     > Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>
     > https://lists.sourceforge.net/lists/listinfo/geoserver-users
     >

    ------------------------------------------------------------------------------
    LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
    Remotely access PCs and mobile devices and provide instant support
    Improve your efficiency, and focus on delivering more value-add services
    Discover what IT Professionals Know. Rescue delivers
    http://p.sf.net/sfu/logmein_12329d2d
    _______________________________________________
    Geoserver-users mailing list
    Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Matthias_Uden · December 11, 2012, 2:07pm

Hi David,

sorry for the late reply. Thanks a lot for the quick fix!
I will definitely have a look at the sources myself someday if I find the time.. For now I can do achieve most th

Cheers,
Matthias

Am 07.12.2012 15:49, schrieb David Winslow:

You're right, the docs are incorrect wrt the MIME information. I'll go
ahead and update them so they will be correct after the next automated
rebuild.

I am indeed the only developer on the CSS module. It's not under
frequent development but I do try to keep up with bugs reported on this
mailing list (and the github issue list.) Actually I resolved the
dynamic color bug last night. I haven't updated the plugin in the
community build yet (maybe this weekend) but if you want an early peak
you can just grab the JAR file from
http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/
and overwrite the one that you already installed.

--
David Winslow
OpenGeo - http://opengeo.org/

On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden <matthias.uden@anonymised.com
<mailto:matthias.uden@anonymised.com>> wrote:

    David,

    thanks a lot for the quick answer and clarification!
    I didn't know about the CSS property "mark-mime", since it is not part
    of the CSS Property Listing
    (http://docs.geoserver.org/stable/en/user/community/css/properties.html).
    This
    at least fixed the Icon Media Type issue.
    It's a pity that dynamic colors are not yet supported. I suppose that
    the CSS Module is currently not actively developed anymore due to lack
    of time. Are you the only developer?

    Cheers,
    Matthias

    Am 06.12.2012 16:14, schrieb David Winslow:
     > *Relative Paths for Icons
     > *The short answer is, no, you can't make it do that. The problem is
     > that the CSS-SLD converter actually uses GeoTools' SLD writing
    code to
     > generate the SLD files, and GeoTools' SLD support is not symmetric (I
     > mean it cannot write everything that it can read.) Resolving
    relative
     > paths into absolute ones is a compromise between the actually desired
     > behavior and not supporting relative paths at all. This could
    probably
     > be fixed at the GeoTools level, but I haven't taken the time to
    inquire
     > into why this asymmetry was built in in the first place.
     >
     > Why are relative paths a problem for you? Maybe there is a workaround
     > that could be used (for example, if it's a problem with
    relocating data
     > directories, I could add a tool to re-convert all CSS styles
    which would
     > re-resolve the paths.)
     > *
     > Icon Media Types*
     > The image type logic is not as sophisticated as you might expect -
     > things like dynamic symbolizers[1] make it impossible to know the
    media
     > type for the image in general, so I just threw my hands up and
    made it
     > literally 'image/jpeg' if you don't specify. You can provide the
    media
     > type explicitly with the *fill-mime*, *stroke-mime*, *mark-mime*, or
     > *shield-mime* property. For example:
     >
     > * {
     > fill: url(pattern.png);
     > fill-mime: "image/png";
     > }
     >
     > I don't guess it would be too hard to make the CSS-SLD converter
    try to
     > look up the icon and inspect it to provide the default, but this
    is not
     > as big a priority to me as rendering transformations. If you want to
     > look into it let me know and I can give you some pointers on
    what's needed.
     >
     > *Dynamic Color*
     > This is simply a bug (the color handling is a bit more complex
    than the
     > label handling, to allow for rgb() color syntax.) Again, this is
     > probably easily fixable given the time to work on it; I'd say even
     > easier than smart defaults for the icon mime-type property.
     >
     > If you'd like to file bugs against GeoScript-Scala[2] I'll keep them
     > up-to-date if and when I get around to working on these problems.
     >
     > [1]: http://blog.geoserver.org/2008/12/08/dynamic-symbolizers-part-1/
     > [2]: https://github.com/dwins/geoscript.scala/issues
     >
     > On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden
    <matthias.uden@anonymised.com <mailto:matthias.uden@anonymised.com>
     > <mailto:matthias.uden@anonymised.com
    <mailto:matthias.uden@anonymised.com>>> wrote:
     >
     > Hi all,
     >
     > I've recently discovered the CSS module as an alternative to
    SLD styling
     > and I'm quite enthusiastic about it. Still, I cannot accomplish
     > everything I used to do with SLD before...
     >
     > Here are two specific questions:
     >
     > 1) When specifying a custom icon for a mark with url(...), is it
     > possible to get a relative path in the generated SLD instead
    of an
     > absolute one? Also, is there a possibility to specify the
    format of that
     > image correctly? Currently, it is always converted to jpeg,
    even when I
     > put in a png...
     >
     > Example:
     > CSS:
     > mark: url('icons/entry.png');
     >
     > SLD:
     > <sld:ExternalGraphic>
     > <sld:OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
     > xlink:type="simple"
     >
    xlink:href="file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png"/>
     > <sld:Format>image/jpeg</sld:Format>
     > </sld:ExternalGraphic>
     >
     > 2) Specifying an attributes value dynamically using a column
    of the
     > underlying DB table works fine for e.g. labels. However, it
    doesn't work
     > for colors.
     >
     > Example (working):
     > CSS:
     > label: [key];
     >
     > SLD:
     > <sld:Label>
     > <ogc:PropertyName>key</ogc:PropertyName>
     > </sld:Label>
     >
     > Example (not working):
     > CSS:
     > fill: [color];
     >
     > SLD:
     > <sld:Fill/>
     >
     > Any help is appreciated!
     > Thanks in advance and all the best,
     > Matthias
     >
    ------------------------------------------------------------------------------
     > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free
    Trial
     > Remotely access PCs and mobile devices and provide instant
    support
     > Improve your efficiency, and focus on delivering more
    value-add services
     > Discover what IT Professionals Know. Rescue delivers
     > http://p.sf.net/sfu/logmein_12329d2d
     > _______________________________________________
     > Geoserver-users mailing list
     > Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>
     > <mailto:Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>>
     > https://lists.sourceforge.net/lists/listinfo/geoserver-users
     >
    ------------------------------------------------------------------------------
     > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
     > Remotely access PCs and mobile devices and provide instant support
     > Improve your efficiency, and focus on delivering more value-add
    services
     > Discover what IT Professionals Know. Rescue delivers
     > http://p.sf.net/sfu/logmein_12329d2d
     >
     > _______________________________________________
     > Geoserver-users mailing list
     > Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>
     > https://lists.sourceforge.net/lists/listinfo/geoserver-users
     >

    ------------------------------------------------------------------------------
    LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
    Remotely access PCs and mobile devices and provide instant support
    Improve your efficiency, and focus on delivering more value-add services
    Discover what IT Professionals Know. Rescue delivers
    http://p.sf.net/sfu/logmein_12329d2d
    _______________________________________________
    Geoserver-users mailing list
    Geoserver-users@lists.sourceforge.net
    <mailto:Geoserver-users@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Matthias_Uden · January 15, 2013, 1:27pm

Hi David / all,

I'm sorry to bother you again with the CSS Module dynamic coloring issue.
I still can't use dynamic color attributes in my CSS. Is it possible that it only works for GeoServer 2.2.x? I'm still using 2.1.3 and it seems that the geocss .jar has only been updated for 2.2.x
Is there a way to make it working for 2.1.x too?

Thanks for your time and advice,
Matthias

Am 11.12.2012 15:06, schrieb Matthias Uden:

Hi David,

sorry for the late reply. Thanks a lot for the quick fix!
I will definitely have a look at the sources myself someday if I find
the time.. For now I can achieve most of the desired styling with the
CSS module. Thanks for your good work.

Cheers,
Matthias

Am 07.12.2012 15:49, schrieb David Winslow:

You're right, the docs are incorrect wrt the MIME information. I'll go
ahead and update them so they will be correct after the next automated
rebuild.

I am indeed the only developer on the CSS module. It's not under
frequent development but I do try to keep up with bugs reported on this
mailing list (and the github issue list.) Actually I resolved the
dynamic color bug last night. I haven't updated the plugin in the
community build yet (maybe this weekend) but if you want an early peak
you can just grab the JAR file from
http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/
and overwrite the one that you already installed.

--
David Winslow
OpenGeo - http://opengeo.org/

On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden <matthias.uden@anonymised.com
<mailto:matthias.uden@anonymised.com>> wrote:

     David,

     thanks a lot for the quick answer and clarification!
     I didn't know about the CSS property "mark-mime", since it is not part
     of the CSS Property Listing
     (http://docs.geoserver.org/stable/en/user/community/css/properties.html).
     This
     at least fixed the Icon Media Type issue.
     It's a pity that dynamic colors are not yet supported. I suppose that
     the CSS Module is currently not actively developed anymore due to lack
     of time. Are you the only developer?

     Cheers,
     Matthias

     Am 06.12.2012 16:14, schrieb David Winslow:
      > *Relative Paths for Icons
      > *The short answer is, no, you can't make it do that. The problem is
      > that the CSS-SLD converter actually uses GeoTools' SLD writing
     code to
      > generate the SLD files, and GeoTools' SLD support is not symmetric (I
      > mean it cannot write everything that it can read.) Resolving
     relative
      > paths into absolute ones is a compromise between the actually desired
      > behavior and not supporting relative paths at all. This could
     probably
      > be fixed at the GeoTools level, but I haven't taken the time to
     inquire
      > into why this asymmetry was built in in the first place.
      >
      > Why are relative paths a problem for you? Maybe there is a workaround
      > that could be used (for example, if it's a problem with
     relocating data
      > directories, I could add a tool to re-convert all CSS styles
     which would
      > re-resolve the paths.)
      > *
      > Icon Media Types*
      > The image type logic is not as sophisticated as you might expect -
      > things like dynamic symbolizers[1] make it impossible to know the
     media
      > type for the image in general, so I just threw my hands up and
     made it
      > literally 'image/jpeg' if you don't specify. You can provide the
     media
      > type explicitly with the *fill-mime*, *stroke-mime*, *mark-mime*, or
      > *shield-mime* property. For example:
      >
      > * {
      > fill: url(pattern.png);
      > fill-mime: "image/png";
      > }
      >
      > I don't guess it would be too hard to make the CSS-SLD converter
     try to
      > look up the icon and inspect it to provide the default, but this
     is not
      > as big a priority to me as rendering transformations. If you want to
      > look into it let me know and I can give you some pointers on
     what's needed.
      >
      > *Dynamic Color*
      > This is simply a bug (the color handling is a bit more complex
     than the
      > label handling, to allow for rgb() color syntax.) Again, this is
      > probably easily fixable given the time to work on it; I'd say even
      > easier than smart defaults for the icon mime-type property.
      >
      > If you'd like to file bugs against GeoScript-Scala[2] I'll keep them
      > up-to-date if and when I get around to working on these problems.
      >
      > [1]: http://blog.geoserver.org/2008/12/08/dynamic-symbolizers-part-1/
      > [2]: https://github.com/dwins/geoscript.scala/issues
      >
      > On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden
     <matthias.uden@anonymised.com <mailto:matthias.uden@anonymised.com>
      > <mailto:matthias.uden@anonymised.com
     <mailto:matthias.uden@anonymised.com>>> wrote:
      >
      > Hi all,
      >
      > I've recently discovered the CSS module as an alternative to
     SLD styling
      > and I'm quite enthusiastic about it. Still, I cannot accomplish
      > everything I used to do with SLD before...
      >
      > Here are two specific questions:
      >
      > 1) When specifying a custom icon for a mark with url(...), is it
      > possible to get a relative path in the generated SLD instead
     of an
      > absolute one? Also, is there a possibility to specify the
     format of that
      > image correctly? Currently, it is always converted to jpeg,
     even when I
      > put in a png...
      >
      > Example:
      > CSS:
      > mark: url('icons/entry.png');
      >
      > SLD:
      > <sld:ExternalGraphic>
      > <sld:OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
      > xlink:type="simple"
      >
     xlink:href="file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png"/>
      > <sld:Format>image/jpeg</sld:Format>
      > </sld:ExternalGraphic>
      >
      > 2) Specifying an attributes value dynamically using a column
     of the
      > underlying DB table works fine for e.g. labels. However, it
     doesn't work
      > for colors.
      >
      > Example (working):
      > CSS:
      > label: [key];
      >
      > SLD:
      > <sld:Label>
      > <ogc:PropertyName>key</ogc:PropertyName>
      > </sld:Label>
      >
      > Example (not working):
      > CSS:
      > fill: [color];
      >
      > SLD:
      > <sld:Fill/>
      >
      > Any help is appreciated!
      > Thanks in advance and all the best,
      > Matthias
      >
     ------------------------------------------------------------------------------
      > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free
     Trial
      > Remotely access PCs and mobile devices and provide instant
     support
      > Improve your efficiency, and focus on delivering more
     value-add services
      > Discover what IT Professionals Know. Rescue delivers
      > http://p.sf.net/sfu/logmein_12329d2d
      > _______________________________________________
      > Geoserver-users mailing list
      > Geoserver-users@lists.sourceforge.net
     <mailto:Geoserver-users@lists.sourceforge.net>
      > <mailto:Geoserver-users@lists.sourceforge.net
     <mailto:Geoserver-users@lists.sourceforge.net>>
      > https://lists.sourceforge.net/lists/listinfo/geoserver-users
      >
     ------------------------------------------------------------------------------
      > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
      > Remotely access PCs and mobile devices and provide instant support
      > Improve your efficiency, and focus on delivering more value-add
     services
      > Discover what IT Professionals Know. Rescue delivers
      > http://p.sf.net/sfu/logmein_12329d2d
      >
      > _______________________________________________
      > Geoserver-users mailing list
      > Geoserver-users@lists.sourceforge.net
     <mailto:Geoserver-users@lists.sourceforge.net>
      > https://lists.sourceforge.net/lists/listinfo/geoserver-users
      >

     ------------------------------------------------------------------------------
     LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
     Remotely access PCs and mobile devices and provide instant support
     Improve your efficiency, and focus on delivering more value-add services
     Discover what IT Professionals Know. Rescue delivers
     http://p.sf.net/sfu/logmein_12329d2d
     _______________________________________________
     Geoserver-users mailing list
     Geoserver-users@lists.sourceforge.net
     <mailto:Geoserver-users@lists.sourceforge.net>
     https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

David_Winslow · January 15, 2013, 2:34pm

The update hasn’t been included for any GeoServer release yet - I had hoped to get another feature or two in before updating the builds. However, the geocss JAR that I linked to should work in any GeoServer version (I think.) Here’s that link again for reference: http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/geocss_2.9.1-0.7.4.jar

When I do get around to updating the build I won’t be updating 2.1.x as it is no longer a supported version of GeoServer. However, SLDs generated with 2.2.x and later should continue to be compatible with earlier versions of GeoServer.

···

On Tue, Jan 15, 2013 at 8:27 AM, Matthias Uden <matthias.uden@anonymised.com> wrote:

Hi David / all,

I’m sorry to bother you again with the CSS Module dynamic coloring issue.
I still can’t use dynamic color attributes in my CSS. Is it possible that it only works for GeoServer 2.2.x? I’m still using 2.1.3 and it seems that the geocss .jar has only been updated for 2.2.x
Is there a way to make it working for 2.1.x too?

Thanks for your time and advice,
Matthias

Am 11.12.2012 15:06, schrieb Matthias Uden:

Hi David,

sorry for the late reply. Thanks a lot for the quick fix!
I will definitely have a look at the sources myself someday if I find
the time… For now I can achieve most of the desired styling with the
CSS module. Thanks for your good work.

Cheers,
Matthias

Am 07.12.2012 15:49, schrieb David Winslow:

You’re right, the docs are incorrect wrt the MIME information. I’ll go
ahead and update them so they will be correct after the next automated
rebuild.

I am indeed the only developer on the CSS module. It’s not under
frequent development but I do try to keep up with bugs reported on this
mailing list (and the github issue list.) Actually I resolved the
dynamic color bug last night. I haven’t updated the plugin in the
community build yet (maybe this weekend) but if you want an early peak
you can just grab the JAR file from
http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/
and overwrite the one that you already installed.

–
David Winslow
OpenGeo - http://opengeo.org/

On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden <matthias.uden@anonymised.com
mailto:[matthias.uden@anonymised.comcom](mailto:matthias.uden@anonymised.com)> wrote:

David,

thanks a lot for the quick answer and clarification!
I didn’t know about the CSS property “mark-mime”, since it is not part
of the CSS Property Listing
(http://docs.geoserver.org/stable/en/user/community/css/properties.html).
This
at least fixed the Icon Media Type issue.
It’s a pity that dynamic colors are not yet supported. I suppose that
the CSS Module is currently not actively developed anymore due to lack
of time. Are you the only developer?

Cheers,
Matthias

Am 06.12.2012 16:14, schrieb David Winslow:

*Relative Paths for Icons
*The short answer is, no, you can’t make it do that. The problem is
that the CSS-SLD converter actually uses GeoTools’ SLD writing
code to
generate the SLD files, and GeoTools’ SLD support is not symmetric (I
mean it cannot write everything that it can read.) Resolving
relative
paths into absolute ones is a compromise between the actually desired
behavior and not supporting relative paths at all. This could
probably
be fixed at the GeoTools level, but I haven’t taken the time to
inquire
into why this asymmetry was built in in the first place.

Why are relative paths a problem for you? Maybe there is a workaround
that could be used (for example, if it’s a problem with
relocating data
directories, I could add a tool to re-convert all CSS styles
which would
re-resolve the paths.)
*
Icon Media Types*
The image type logic is not as sophisticated as you might expect -
things like dynamic symbolizers1 make it impossible to know the
media
type for the image in general, so I just threw my hands up and
made it
literally ‘image/jpeg’ if you don’t specify. You can provide the
media
type explicitly with the fill-mime, stroke-mime, mark-mime, or
shield-mime property. For example:

{
fill: url(pattern.png);
fill-mime: “image/png”;
}

I don’t guess it would be too hard to make the CSS-SLD converter
try to
look up the icon and inspect it to provide the default, but this
is not
as big a priority to me as rendering transformations. If you want to
look into it let me know and I can give you some pointers on
what’s needed.

Dynamic Color
This is simply a bug (the color handling is a bit more complex
than the
label handling, to allow for rgb() color syntax.) Again, this is
probably easily fixable given the time to work on it; I’d say even
easier than smart defaults for the icon mime-type property.

If you’d like to file bugs against GeoScript-Scala2 I’ll keep them
up-to-date if and when I get around to working on these problems.

On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden
<matthias.uden@anonymised.com mailto:[matthias.uden@anonymised.comcom](mailto:matthias.uden@anonymised.com...)
<mailto:matthias.uden@anonymised.comcom
mailto:[matthias.uden@anonymised.comcom](mailto:matthias.uden@anonymised.com)>> wrote:

Hi all,

I’ve recently discovered the CSS module as an alternative to
SLD styling
and I’m quite enthusiastic about it. Still, I cannot accomplish
everything I used to do with SLD before…

Here are two specific questions:

When specifying a custom icon for a mark with url(…), is it
possible to get a relative path in the generated SLD instead
of an
absolute one? Also, is there a possibility to specify the
format of that
image correctly? Currently, it is always converted to jpeg,
even when I
put in a png…

Example:
CSS:
mark: url(‘icons/entry.png’);

SLD:
sld:ExternalGraphic
<sld:OnlineResource xmlns:xlink=“http://www.w3.org/1999/xlink”
xlink:type=“simple”

xlink:href=“file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png”/>

sld:Formatimage/jpeg</sld:Format>
</sld:ExternalGraphic>

Specifying an attributes value dynamically using a column
of the
underlying DB table works fine for e.g. labels. However, it
doesn’t work
for colors.

Example (working):
CSS:
label: [key];

SLD:
sld:Label
ogc:PropertyNamekey</ogc:PropertyName>
</sld:Label>

Example (not working):
CSS:
fill: [color];

SLD:
sld:Fill/

Any help is appreciated!
Thanks in advance and all the best,
Matthias

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free
Trial
Remotely access PCs and mobile devices and provide instant
support
Improve your efficiency, and focus on delivering more
value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@anonymised.comsourceforge.net
mailto:[Geoserver-users@anonymised.comsourceforge.net](mailto:Geoserver-users@anonymised.comet)
<mailto:Geoserver-users@anonymised.comsourceforge.net
mailto:[Geoserver-users@anonymised.comsourceforge.net](mailto:Geoserver-users@anonymised.comet)>
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add
services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@anonymised.comsourceforge.net
mailto:[Geoserver-users@anonymised.comsourceforge.net](mailto:Geoserver-users@anonymised.comet)
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@anonymised.comsourceforge.net
mailto:[Geoserver-users@anonymised.comsourceforge.net](mailto:Geoserver-users@anonymised.comet)
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@anonymised.comsourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Matthias_Uden · January 16, 2013, 9:37am

Hi David,

in order to get the expression based dynamic coloring to work I tried the custom .jar with both GeoServer versions (2.1.3 and 2.2.3) - unfortunately without success.
Here is what happens with several different configurations:

GS 2.1.3 + CSS Module 2.1.x w/ your custom geocss .jar:

The CSS Module doesn't seem to work properly with this combination. I cannot even create a new CSS style in the interface.
Once I try that, it gives me this exception:

org.apache.wicket.WicketRuntimeException: Method onFormSubmitted of interface org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component [MarkupContainer [Component id = layer-selection]] threw an exception
(...)
Caused by: java.lang.reflect.InvocationTargetException
(...)
Caused by: java.lang.NoClassDefFoundError: scala/Serializable
(...)
Caused by: java.lang.ClassNotFoundException: scala.Serializable

GS 2.2.1 + "standard" CSS Module 2.2.x:

Once I click on the "CSS Demo" link in the web interface, everything becomes very slow and in the console I keep getting these errors:
OutOfMemoryError: PermGen space

I've found some other threads in the internet dealing with this problem.
Of course I could give the tomcat more PermGen memory space, but still I wonder why this is happening, since it wasn't a problem at all in GS 2.1.3

GS 2.2.1 + CSS Module 2.2.x w/ your custom geocss .jar:

Also memory issues. Some more specific error messages I get include:

ERROR [lang.Objects] - Error serializing object class org.geoserver.community.css.web.CssDemoPage [object=[Page class = org.geoserver.community.css.web.CssDemoPage, id = 4, version = 0]]
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: Unable to serialize class: org.geoserver.config.GeoServerDataDirectory
(...)
ERROR [wicket.Session] - Exception when detaching/serializing page

So, apart from the dynamic color issue I seem to have some serious problems with my freshly set up GeoServer 2.2.3 w/ CSS Module...
Any hints on what could go wrong here are appreciated, although I will have to put some more effort in getting a working configuration once I find the time.

Btw, in which combination did you get the dynamic coloring to work?

Thanks again for your continued help! Apart from this issue I am very enthusiastic about the CSS Module.

Cheers,
Matthias

Am 15.01.2013 15:34, schrieb David Winslow:

The update hasn't been included for any GeoServer release yet - I had hoped to get another feature or two in before updating the builds. However, the geocss JAR that I linked to should work in any GeoServer version (I think.) Here's that link again for reference: http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/geocss_2.9.1-0.7.4.jar

When I do get around to updating the build I won't be updating 2.1.x as it is no longer a supported version of GeoServer. However, SLDs generated with 2.2.x and later should continue to be compatible with earlier versions of GeoServer.

--
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Jan 15, 2013 at 8:27 AM, Matthias Uden <matthias.uden@anonymised.com <mailto:matthias.uden@anonymised.com>> wrote:

    Hi David / all,

    I'm sorry to bother you again with the CSS Module dynamic coloring
    issue.
    I still can't use dynamic color attributes in my CSS. Is it
    possible that it only works for GeoServer 2.2.x? I'm still using
    2.1.3 and it seems that the geocss .jar has only been updated for
    2.2.x
    Is there a way to make it working for 2.1.x too?

    Thanks for your time and advice,
    Matthias

    Am 11.12.2012 15:06, schrieb Matthias Uden:

        Hi David,

        sorry for the late reply. Thanks a lot for the quick fix!
        I will definitely have a look at the sources myself someday if
        I find
        the time.. For now I can achieve most of the desired styling
        with the
        CSS module. Thanks for your good work.

        Cheers,
        Matthias

        Am 07.12.2012 15:49, schrieb David Winslow:

            You're right, the docs are incorrect wrt the MIME
            information. I'll go
            ahead and update them so they will be correct after the
            next automated
            rebuild.

            I am indeed the only developer on the CSS module. It's
            not under
            frequent development but I do try to keep up with bugs
            reported on this
            mailing list (and the github issue list.) Actually I
            resolved the
            dynamic color bug last night. I haven't updated the
            plugin in the
            community build yet (maybe this weekend) but if you want
            an early peak
            you can just grab the JAR file from
            http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/
            and overwrite the one that you already installed.

            --
            David Winslow
            OpenGeo - http://opengeo.org/

            On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden
            <matthias.uden@anonymised.com <mailto:matthias.uden@anonymised.com>
            <mailto:matthias.uden@anonymised.com
            <mailto:matthias.uden@anonymised.com>>> wrote:

                 David,

                 thanks a lot for the quick answer and clarification!
                 I didn't know about the CSS property "mark-mime",
            since it is not part
                 of the CSS Property Listing
                            (http://docs.geoserver.org/stable/en/user/community/css/properties.html).
                 This
                 at least fixed the Icon Media Type issue.
                 It's a pity that dynamic colors are not yet
            supported. I suppose that
                 the CSS Module is currently not actively developed
            anymore due to lack
                 of time. Are you the only developer?

                 Cheers,
                 Matthias

                 Am 06.12.2012 16:14, schrieb David Winslow:
                  > *Relative Paths for Icons
                  > *The short answer is, no, you can't make it do
            that. The problem is
                  > that the CSS-SLD converter actually uses GeoTools'
            SLD writing
                 code to
                  > generate the SLD files, and GeoTools' SLD support
            is not symmetric (I
                  > mean it cannot write everything that it can read.)
             Resolving
                 relative
                  > paths into absolute ones is a compromise between
            the actually desired
                  > behavior and not supporting relative paths at all.
             This could
                 probably
                  > be fixed at the GeoTools level, but I haven't
            taken the time to
                 inquire
                  > into why this asymmetry was built in in the first
            place.
                  >
                  > Why are relative paths a problem for you? Maybe
            there is a workaround
                  > that could be used (for example, if it's a problem
            with
                 relocating data
                  > directories, I could add a tool to re-convert all
            CSS styles
                 which would
                  > re-resolve the paths.)
                  > *
                  > Icon Media Types*
                  > The image type logic is not as sophisticated as
            you might expect -
                  > things like dynamic symbolizers[1] make it
            impossible to know the
                 media
                  > type for the image in general, so I just threw my
            hands up and
                 made it
                  > literally 'image/jpeg' if you don't specify. You
            can provide the
                 media
                  > type explicitly with the *fill-mime*,
            *stroke-mime*, *mark-mime*, or
                  > *shield-mime* property. For example:
                  >
                  > * {
                  > fill: url(pattern.png);
                  > fill-mime: "image/png";
                  > }
                  >
                  > I don't guess it would be too hard to make the
            CSS-SLD converter
                 try to
                  > look up the icon and inspect it to provide the
            default, but this
                 is not
                  > as big a priority to me as rendering
            transformations. If you want to
                  > look into it let me know and I can give you some
            pointers on
                 what's needed.
                  >
                  > *Dynamic Color*
                  > This is simply a bug (the color handling is a bit
            more complex
                 than the
                  > label handling, to allow for rgb() color syntax.)
             Again, this is
                  > probably easily fixable given the time to work on
            it; I'd say even
                  > easier than smart defaults for the icon mime-type
            property.
                  >
                  > If you'd like to file bugs against
            GeoScript-Scala[2] I'll keep them
                  > up-to-date if and when I get around to working on
            these problems.
                  >
                  > [1]:
            http://blog.geoserver.org/2008/12/08/dynamic-symbolizers-part-1/
                  > [2]: https://github.com/dwins/geoscript.scala/issues
                  >
                  > On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden
                 <matthias.uden@anonymised.com
            <mailto:matthias.uden@anonymised.com>
            <mailto:matthias.uden@anonymised.com
            <mailto:matthias.uden@anonymised.com>>
                  > <mailto:matthias.uden@anonymised.com
            <mailto:matthias.uden@anonymised.com>
                 <mailto:matthias.uden@anonymised.com
            <mailto:matthias.uden@anonymised.com>>>> wrote:
                  >
                  > Hi all,
                  >
                  > I've recently discovered the CSS module as an
            alternative to
                 SLD styling
                  > and I'm quite enthusiastic about it. Still, I
            cannot accomplish
                  > everything I used to do with SLD before...
                  >
                  > Here are two specific questions:
                  >
                  > 1) When specifying a custom icon for a mark
            with url(...), is it
                  > possible to get a relative path in the
            generated SLD instead
                 of an
                  > absolute one? Also, is there a possibility to
            specify the
                 format of that
                  > image correctly? Currently, it is always
            converted to jpeg,
                 even when I
                  > put in a png...
                  >
                  > Example:
                  > CSS:
                  > mark: url('icons/entry.png');
                  >
                  > SLD:
                  > <sld:ExternalGraphic>
                  > <sld:OnlineResource
            xmlns:xlink="http://www.w3.org/1999/xlink"
                  > xlink:type="simple"
                  >
                            xlink:href="file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png"/>
                  > <sld:Format>image/jpeg</sld:Format>
                  > </sld:ExternalGraphic>
                  >
                  > 2) Specifying an attributes value dynamically
            using a column
                 of the
                  > underlying DB table works fine for e.g.
            labels. However, it
                 doesn't work
                  > for colors.
                  >
                  > Example (working):
                  > CSS:
                  > label: [key];
                  >
                  > SLD:
                  > <sld:Label>
                  > <ogc:PropertyName>key</ogc:PropertyName>
                  > </sld:Label>
                  >
                  > Example (not working):
                  > CSS:
                  > fill: [color];
                  >
                  > SLD:
                  > <sld:Fill/>
                  >
                  > Any help is appreciated!
                  > Thanks in advance and all the best,
                  > Matthias
                  >
                            ------------------------------------------------------------------------------
                  > LogMeIn Rescue: Anywhere, Anytime Remote
            support for IT. Free
                 Trial
                  > Remotely access PCs and mobile devices and
            provide instant
                 support
                  > Improve your efficiency, and focus on
            delivering more
                 value-add services
                  > Discover what IT Professionals Know. Rescue
            delivers
                  > http://p.sf.net/sfu/logmein_12329d2d
                  > _______________________________________________
                  > Geoserver-users mailing list
                  > Geoserver-users@lists.sourceforge.net
            <mailto:Geoserver-users@lists.sourceforge.net>
                 <mailto:Geoserver-users@lists.sourceforge.net
            <mailto:Geoserver-users@lists.sourceforge.net>>
                  > <mailto:Geoserver-users@lists.sourceforge.net
            <mailto:Geoserver-users@lists.sourceforge.net>
                 <mailto:Geoserver-users@lists.sourceforge.net
            <mailto:Geoserver-users@lists.sourceforge.net>>>
                  >
            https://lists.sourceforge.net/lists/listinfo/geoserver-users
                  >
                            ------------------------------------------------------------------------------
                  > LogMeIn Rescue: Anywhere, Anytime Remote support
            for IT. Free Trial
                  > Remotely access PCs and mobile devices and provide
            instant support
                  > Improve your efficiency, and focus on delivering
            more value-add
                 services
                  > Discover what IT Professionals Know. Rescue delivers
                  > http://p.sf.net/sfu/logmein_12329d2d
                  >
                  > _______________________________________________
                  > Geoserver-users mailing list
                  > Geoserver-users@lists.sourceforge.net
            <mailto:Geoserver-users@lists.sourceforge.net>
                 <mailto:Geoserver-users@lists.sourceforge.net
            <mailto:Geoserver-users@lists.sourceforge.net>>
                  >
            https://lists.sourceforge.net/lists/listinfo/geoserver-users
                  >

                            ------------------------------------------------------------------------------
                 LogMeIn Rescue: Anywhere, Anytime Remote support for
            IT. Free Trial
                 Remotely access PCs and mobile devices and provide
            instant support
                 Improve your efficiency, and focus on delivering more
            value-add services
                 Discover what IT Professionals Know. Rescue delivers
            http://p.sf.net/sfu/logmein_12329d2d
                 _______________________________________________
                 Geoserver-users mailing list
            Geoserver-users@lists.sourceforge.net
            <mailto:Geoserver-users@lists.sourceforge.net>
                 <mailto:Geoserver-users@lists.sourceforge.net
            <mailto:Geoserver-users@lists.sourceforge.net>>
            https://lists.sourceforge.net/lists/listinfo/geoserver-users

            ------------------------------------------------------------------------------
            LogMeIn Rescue: Anywhere, Anytime Remote support for IT.
            Free Trial
            Remotely access PCs and mobile devices and provide instant
            support
            Improve your efficiency, and focus on delivering more
            value-add services
            Discover what IT Professionals Know. Rescue delivers
            http://p.sf.net/sfu/logmein_12329d2d

            _______________________________________________
            Geoserver-users mailing list
            Geoserver-users@lists.sourceforge.net
            <mailto:Geoserver-users@lists.sourceforge.net>
            https://lists.sourceforge.net/lists/listinfo/geoserver-users

        ------------------------------------------------------------------------------
        LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free
        Trial
        Remotely access PCs and mobile devices and provide instant support
        Improve your efficiency, and focus on delivering more
        value-add services
        Discover what IT Professionals Know. Rescue delivers
        http://p.sf.net/sfu/logmein_12329d2d

David_Winslow · January 16, 2013, 3:39pm

I’ve only tested dynamic coloring in the geocss library, not with the GeoServer web interface. It should have been a drop-in replacement (no API changes) but I guess you never know.

The WicketNotSerializableException looks like an issue I already fixed. The geocss jar does not interact with Wicket at all so I would not expect it to introduce this type of problem.

Permgen errors are pretty common in GeoServer - GeoServer uses many class libraries and this leads to PermGen pressure. The CSS module brings in a different parsing library and collections framework from the ones used in GeoServer already so it is fairly “heavy” in this regard. I generally set -XX:PermSize=256M when running with the CSS module and I don’t encounter PermGen issues. But I don’t manage any long-running GeoServer instances with the CSS module enabled, so it’s possible there is a problem that I haven’t noticed.

In short, it seems that mixing and matching jar files is not working well here. I’ll look into updating the GeoServer build so that you can just use a nightly build of the community module instead.

···

On Wed, Jan 16, 2013 at 4:37 AM, Matthias Uden <matthias.uden@anonymised.com> wrote:

Hi David,

in order to get the expression based dynamic coloring to work I tried the custom .jar with both GeoServer versions (2.1.3 and 2.2.3) - unfortunately without success.
Here is what happens with several different configurations:

GS 2.1.3 + CSS Module 2.1.x w/ your custom geocss .jar:

The CSS Module doesn’t seem to work properly with this combination. I cannot even create a new CSS style in the interface.
Once I try that, it gives me this exception:

org.apache.wicket.WicketRuntimeException: Method onFormSubmitted of interface org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component [MarkupContainer [Component id = layer-selection]] threw an exception
(…)
Caused by: java.lang.reflect.InvocationTargetException
(…)
Caused by: java.lang.NoClassDefFoundError: scala/Serializable
(…)
Caused by: java.lang.ClassNotFoundException: scala.Serializable

GS 2.2.1 + “standard” CSS Module 2.2.x:

Once I click on the “CSS Demo” link in the web interface, everything becomes very slow and in the console I keep getting these errors:
OutOfMemoryError: PermGen space

I’ve found some other threads in the internet dealing with this problem.
Of course I could give the tomcat more PermGen memory space, but still I wonder why this is happening, since it wasn’t a problem at all in GS 2.1.3

GS 2.2.1 + CSS Module 2.2.x w/ your custom geocss .jar:

Also memory issues. Some more specific error messages I get include:

ERROR [lang.Objects] - Error serializing object class org.geoserver.community.css.web.CssDemoPage [object=[Page class = org.geoserver.community.css.web.CssDemoPage, id = 4, version = 0]]
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: Unable to serialize class: org.geoserver.config.GeoServerDataDirectory
(…)
ERROR [wicket.Session] - Exception when detaching/serializing page

So, apart from the dynamic color issue I seem to have some serious problems with my freshly set up GeoServer 2.2.3 w/ CSS Module…
Any hints on what could go wrong here are appreciated, although I will have to put some more effort in getting a working configuration once I find the time.

Btw, in which combination did you get the dynamic coloring to work?

Thanks again for your continued help! Apart from this issue I am very enthusiastic about the CSS Module.

Cheers,
Matthias

Am 15.01.2013 15:34, schrieb David Winslow:

The update hasn’t been included for any GeoServer release yet - I had hoped to get another feature or two in before updating the builds. However, the geocss JAR that I linked to should work in any GeoServer version (I think.) Here’s that link again for reference: http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/geocss_2.9.1-0.7.4.jar

When I do get around to updating the build I won’t be updating 2.1.x as it is no longer a supported version of GeoServer. However, SLDs generated with 2.2.x and later should continue to be compatible with earlier versions of GeoServer.

–
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Jan 15, 2013 at 8:27 AM, Matthias Uden <matthias.uden@anonymised.com> wrote:

Hi David / all,

I’m sorry to bother you again with the CSS Module dynamic coloring issue.
I still can’t use dynamic color attributes in my CSS. Is it possible that it only works for GeoServer 2.2.x? I’m still using 2.1.3 and it seems that the geocss .jar has only been updated for 2.2.x
Is there a way to make it working for 2.1.x too?

Thanks for your time and advice,
Matthias

Am 11.12.2012 15:06, schrieb Matthias Uden:

Hi David,

sorry for the late reply. Thanks a lot for the quick fix!
I will definitely have a look at the sources myself someday if I find
the time… For now I can achieve most of the desired styling with the
CSS module. Thanks for your good work.

Cheers,
Matthias

Am 07.12.2012 15:49, schrieb David Winslow:

You’re right, the docs are incorrect wrt the MIME information. I’ll go
ahead and update them so they will be correct after the next automated
rebuild.

I am indeed the only developer on the CSS module. It’s not under
frequent development but I do try to keep up with bugs reported on this
mailing list (and the github issue list.) Actually I resolved the
dynamic color bug last night. I haven’t updated the plugin in the
community build yet (maybe this weekend) but if you want an early peak
you can just grab the JAR file from
http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/
and overwrite the one that you already installed.

–
David Winslow
OpenGeo - http://opengeo.org/

On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden <matthias.uden@anonymised.com…
mailto:[matthias.uden@anonymised.com](mailto:matthias.uden@anonymised.com)> wrote:

David,

thanks a lot for the quick answer and clarification!
I didn’t know about the CSS property “mark-mime”, since it is not part
of the CSS Property Listing
(http://docs.geoserver.org/stable/en/user/community/css/properties.html).
This
at least fixed the Icon Media Type issue.
It’s a pity that dynamic colors are not yet supported. I suppose that
the CSS Module is currently not actively developed anymore due to lack
of time. Are you the only developer?

Cheers,
Matthias

Am 06.12.2012 16:14, schrieb David Winslow:

*Relative Paths for Icons
*The short answer is, no, you can’t make it do that. The problem is
that the CSS-SLD converter actually uses GeoTools’ SLD writing
code to
generate the SLD files, and GeoTools’ SLD support is not symmetric (I
mean it cannot write everything that it can read.) Resolving
relative
paths into absolute ones is a compromise between the actually desired
behavior and not supporting relative paths at all. This could
probably
be fixed at the GeoTools level, but I haven’t taken the time to
inquire
into why this asymmetry was built in in the first place.

Why are relative paths a problem for you? Maybe there is a workaround
that could be used (for example, if it’s a problem with
relocating data
directories, I could add a tool to re-convert all CSS styles
which would
re-resolve the paths.)
*
Icon Media Types*
The image type logic is not as sophisticated as you might expect -
things like dynamic symbolizers1 make it impossible to know the
media
type for the image in general, so I just threw my hands up and
made it
literally ‘image/jpeg’ if you don’t specify. You can provide the
media
type explicitly with the fill-mime, stroke-mime, mark-mime, or
shield-mime property. For example:

{
fill: url(pattern.png);
fill-mime: “image/png”;
}

I don’t guess it would be too hard to make the CSS-SLD converter
try to
look up the icon and inspect it to provide the default, but this
is not
as big a priority to me as rendering transformations. If you want to
look into it let me know and I can give you some pointers on
what’s needed.

Dynamic Color
This is simply a bug (the color handling is a bit more complex
than the
label handling, to allow for rgb() color syntax.) Again, this is
probably easily fixable given the time to work on it; I’d say even
easier than smart defaults for the icon mime-type property.

If you’d like to file bugs against GeoScript-Scala2 I’ll keep them
up-to-date if and when I get around to working on these problems.

On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden
<matthias.uden@anonymised.com mailto:[matthias.uden@anonymised.com](mailto:matthias.uden@anonymised.com)
<mailto:matthias.uden@anonymised.com
mailto:[matthias.uden@anonymised.com](mailto:matthias.uden@anonymised.com..84...)>> wrote:

Hi all,

I’ve recently discovered the CSS module as an alternative to
SLD styling
and I’m quite enthusiastic about it. Still, I cannot accomplish
everything I used to do with SLD before…

Here are two specific questions:

When specifying a custom icon for a mark with url(…), is it
possible to get a relative path in the generated SLD instead
of an
absolute one? Also, is there a possibility to specify the
format of that
image correctly? Currently, it is always converted to jpeg,
even when I
put in a png…

Example:
CSS:
mark: url(‘icons/entry.png’);

SLD:
sld:ExternalGraphic
<sld:OnlineResource xmlns:xlink=“http://www.w3.org/1999/xlink”
xlink:type=“simple”

xlink:href=“file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png”/>

sld:Formatimage/jpeg</sld:Format>
</sld:ExternalGraphic>

Specifying an attributes value dynamically using a column
of the
underlying DB table works fine for e.g. labels. However, it
doesn’t work
for colors.

Example (working):
CSS:
label: [key];

SLD:
sld:Label
ogc:PropertyNamekey</ogc:PropertyName>
</sld:Label>

Example (not working):
CSS:
fill: [color];

SLD:
sld:Fill/

Any help is appreciated!
Thanks in advance and all the best,
Matthias

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free
Trial
Remotely access PCs and mobile devices and provide instant
support
Improve your efficiency, and focus on delivering more
value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
mailto:[Geoserver-users@anonymised.com.net](mailto:Geoserver-users@lists.sourceforge.net)
<mailto:Geoserver-users@anonymised.comts.sourceforge.net
mailto:[Geoserver-users@anonymised.com.net](mailto:Geoserver-users@lists.sourceforge.net)>
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add
services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
mailto:[Geoserver-users@anonymised.com.net](mailto:Geoserver-users@lists.sourceforge.net)
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
mailto:[Geoserver-users@anonymised.com.net](mailto:Geoserver-users@lists.sourceforge.net)
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

David_Winslow · January 17, 2013, 2:59pm

Ok, i’ve updated the community module on the 2.2.x and master (2.3.x) branches. I was wrong about having fixed the WicketNotSerializableException issue so that is resolved on 2.2.x as well. The build server seems to have a pretty deep backlog right now, so if you are able to build from sources it might be faster to pull the latest from git and rebuild. Either way, the packages will be available in the next set of nightlies.

···

On Wed, Jan 16, 2013 at 10:39 AM, David Winslow <dwinslow@anonymised.com> wrote:

I’ve only tested dynamic coloring in the geocss library, not with the GeoServer web interface. It should have been a drop-in replacement (no API changes) but I guess you never know.

The WicketNotSerializableException looks like an issue I already fixed. The geocss jar does not interact with Wicket at all so I would not expect it to introduce this type of problem.

Permgen errors are pretty common in GeoServer - GeoServer uses many class libraries and this leads to PermGen pressure. The CSS module brings in a different parsing library and collections framework from the ones used in GeoServer already so it is fairly “heavy” in this regard. I generally set -XX:PermSize=256M when running with the CSS module and I don’t encounter PermGen issues. But I don’t manage any long-running GeoServer instances with the CSS module enabled, so it’s possible there is a problem that I haven’t noticed.

In short, it seems that mixing and matching jar files is not working well here. I’ll look into updating the GeoServer build so that you can just use a nightly build of the community module instead.

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jan 16, 2013 at 4:37 AM, Matthias Uden <matthias.uden@anonymised.com> wrote:

Hi David,

in order to get the expression based dynamic coloring to work I tried the custom .jar with both GeoServer versions (2.1.3 and 2.2.3) - unfortunately without success.
Here is what happens with several different configurations:

GS 2.1.3 + CSS Module 2.1.x w/ your custom geocss .jar:

The CSS Module doesn’t seem to work properly with this combination. I cannot even create a new CSS style in the interface.
Once I try that, it gives me this exception:

org.apache.wicket.WicketRuntimeException: Method onFormSubmitted of interface org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component [MarkupContainer [Component id = layer-selection]] threw an exception
(…)
Caused by: java.lang.reflect.InvocationTargetException
(…)
Caused by: java.lang.NoClassDefFoundError: scala/Serializable
(…)
Caused by: java.lang.ClassNotFoundException: scala.Serializable

GS 2.2.1 + “standard” CSS Module 2.2.x:

Once I click on the “CSS Demo” link in the web interface, everything becomes very slow and in the console I keep getting these errors:
OutOfMemoryError: PermGen space

I’ve found some other threads in the internet dealing with this problem.
Of course I could give the tomcat more PermGen memory space, but still I wonder why this is happening, since it wasn’t a problem at all in GS 2.1.3

GS 2.2.1 + CSS Module 2.2.x w/ your custom geocss .jar:

Also memory issues. Some more specific error messages I get include:

ERROR [lang.Objects] - Error serializing object class org.geoserver.community.css.web.CssDemoPage [object=[Page class = org.geoserver.community.css.web.CssDemoPage, id = 4, version = 0]]
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: Unable to serialize class: org.geoserver.config.GeoServerDataDirectory
(…)
ERROR [wicket.Session] - Exception when detaching/serializing page

So, apart from the dynamic color issue I seem to have some serious problems with my freshly set up GeoServer 2.2.3 w/ CSS Module…
Any hints on what could go wrong here are appreciated, although I will have to put some more effort in getting a working configuration once I find the time.

Btw, in which combination did you get the dynamic coloring to work?

Thanks again for your continued help! Apart from this issue I am very enthusiastic about the CSS Module.

Cheers,
Matthias

Am 15.01.2013 15:34, schrieb David Winslow:

The update hasn’t been included for any GeoServer release yet - I had hoped to get another feature or two in before updating the builds. However, the geocss JAR that I linked to should work in any GeoServer version (I think.) Here’s that link again for reference: http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/geocss_2.9.1-0.7.4.jar

When I do get around to updating the build I won’t be updating 2.1.x as it is no longer a supported version of GeoServer. However, SLDs generated with 2.2.x and later should continue to be compatible with earlier versions of GeoServer.

–
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Jan 15, 2013 at 8:27 AM, Matthias Uden <matthias.uden@anonymised.com> wrote:

Hi David / all,

I’m sorry to bother you again with the CSS Module dynamic coloring issue.
I still can’t use dynamic color attributes in my CSS. Is it possible that it only works for GeoServer 2.2.x? I’m still using 2.1.3 and it seems that the geocss .jar has only been updated for 2.2.x
Is there a way to make it working for 2.1.x too?

Thanks for your time and advice,
Matthias

Am 11.12.2012 15:06, schrieb Matthias Uden:

Hi David,

sorry for the late reply. Thanks a lot for the quick fix!
I will definitely have a look at the sources myself someday if I find
the time… For now I can achieve most of the desired styling with the
CSS module. Thanks for your good work.

Cheers,
Matthias

Am 07.12.2012 15:49, schrieb David Winslow:

You’re right, the docs are incorrect wrt the MIME information. I’ll go
ahead and update them so they will be correct after the next automated
rebuild.

I am indeed the only developer on the CSS module. It’s not under
frequent development but I do try to keep up with bugs reported on this
mailing list (and the github issue list.) Actually I resolved the
dynamic color bug last night. I haven’t updated the plugin in the
community build yet (maybe this weekend) but if you want an early peak
you can just grab the JAR file from
http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/
and overwrite the one that you already installed.

–
David Winslow
OpenGeo - http://opengeo.org/

On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden <matthias.uden@anonymised.com…
mailto:[matthias.uden@anonymised.com](mailto:matthias.uden@anonymised.com)> wrote:

David,

thanks a lot for the quick answer and clarification!
I didn’t know about the CSS property “mark-mime”, since it is not part
of the CSS Property Listing
(http://docs.geoserver.org/stable/en/user/community/css/properties.html).
This
at least fixed the Icon Media Type issue.
It’s a pity that dynamic colors are not yet supported. I suppose that
the CSS Module is currently not actively developed anymore due to lack
of time. Are you the only developer?

Cheers,
Matthias

Am 06.12.2012 16:14, schrieb David Winslow:

*Relative Paths for Icons
*The short answer is, no, you can’t make it do that. The problem is
that the CSS-SLD converter actually uses GeoTools’ SLD writing
code to
generate the SLD files, and GeoTools’ SLD support is not symmetric (I
mean it cannot write everything that it can read.) Resolving
relative
paths into absolute ones is a compromise between the actually desired
behavior and not supporting relative paths at all. This could
probably
be fixed at the GeoTools level, but I haven’t taken the time to
inquire
into why this asymmetry was built in in the first place.

Why are relative paths a problem for you? Maybe there is a workaround
that could be used (for example, if it’s a problem with
relocating data
directories, I could add a tool to re-convert all CSS styles
which would
re-resolve the paths.)
*
Icon Media Types*
The image type logic is not as sophisticated as you might expect -
things like dynamic symbolizers1 make it impossible to know the
media
type for the image in general, so I just threw my hands up and
made it
literally ‘image/jpeg’ if you don’t specify. You can provide the
media
type explicitly with the fill-mime, stroke-mime, mark-mime, or
shield-mime property. For example:

{
fill: url(pattern.png);
fill-mime: “image/png”;
}

I don’t guess it would be too hard to make the CSS-SLD converter
try to
look up the icon and inspect it to provide the default, but this
is not
as big a priority to me as rendering transformations. If you want to
look into it let me know and I can give you some pointers on
what’s needed.

Dynamic Color
This is simply a bug (the color handling is a bit more complex
than the
label handling, to allow for rgb() color syntax.) Again, this is
probably easily fixable given the time to work on it; I’d say even
easier than smart defaults for the icon mime-type property.

If you’d like to file bugs against GeoScript-Scala2 I’ll keep them
up-to-date if and when I get around to working on these problems.

On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden
<matthias.uden@anonymised.com mailto:[matthias.uden@anonymised.com](mailto:matthias.uden@anonymised.com)
<mailto:matthias.uden@anonymised.com
mailto:[matthias.uden@anonymised.com](mailto:matthias.uden@anonymised.com..84...)>> wrote:

Hi all,

I’ve recently discovered the CSS module as an alternative to
SLD styling
and I’m quite enthusiastic about it. Still, I cannot accomplish
everything I used to do with SLD before…

Here are two specific questions:

When specifying a custom icon for a mark with url(…), is it
possible to get a relative path in the generated SLD instead
of an
absolute one? Also, is there a possibility to specify the
format of that
image correctly? Currently, it is always converted to jpeg,
even when I
put in a png…

Example:
CSS:
mark: url(‘icons/entry.png’);

SLD:
sld:ExternalGraphic
<sld:OnlineResource xmlns:xlink=“http://www.w3.org/1999/xlink”
xlink:type=“simple”

xlink:href=“file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png”/>

sld:Formatimage/jpeg</sld:Format>
</sld:ExternalGraphic>

Specifying an attributes value dynamically using a column
of the
underlying DB table works fine for e.g. labels. However, it
doesn’t work
for colors.

Example (working):
CSS:
label: [key];

SLD:
sld:Label
ogc:PropertyNamekey</ogc:PropertyName>
</sld:Label>

Example (not working):
CSS:
fill: [color];

SLD:
sld:Fill/

Any help is appreciated!
Thanks in advance and all the best,
Matthias

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free
Trial
Remotely access PCs and mobile devices and provide instant
support
Improve your efficiency, and focus on delivering more
value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
mailto:[Geoserver-users@anonymised.com.net](mailto:Geoserver-users@lists.sourceforge.net)
<mailto:Geoserver-users@anonymised.comts.sourceforge.net
mailto:[Geoserver-users@anonymised.com.net](mailto:Geoserver-users@lists.sourceforge.net)>
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add
services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
mailto:[Geoserver-users@anonymised.com.net](mailto:Geoserver-users@lists.sourceforge.net)
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
mailto:[Geoserver-users@anonymised.com.net](mailto:Geoserver-users@lists.sourceforge.net)
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Matthias_Uden · January 22, 2013, 10:56am

Hi David,

thanks, I tried the new build for 2.2.x
Unfortunately, I still get the PermGen space OutOfMemory exception, even when I increase the PermSize to 512m.
The interface freezes once I try to create a new CSS style, sometimes already when I only click on the "CSS Demo" link.
The exact error I get in the log says:

22 Jan 11:32:13 ERROR [wicket.Session] - Exception when detaching/serializing page
java.lang.OutOfMemoryError: PermGen space

I'm still wondering why this happens in 2.2.x, while it never occurred in 2.1.x.

Any ideas on what could cause this problem?
Thanks a lot...

Cheers,
Matthias

Am 17.01.2013 15:59, schrieb David Winslow:

Ok, i've updated the community module on the 2.2.x and master (2.3.x) branches. I was wrong about having fixed the WicketNotSerializableException issue so that is resolved on 2.2.x as well. The build server seems to have a pretty deep backlog right now, so if you are able to build from sources it might be faster to pull the latest from git and rebuild. Either way, the packages will be available in the next set of nightlies.

--
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jan 16, 2013 at 10:39 AM, David Winslow <dwinslow@anonymised.com <mailto:dwinslow@anonymised.com>> wrote:

    I've only tested dynamic coloring in the geocss library, not with
    the GeoServer web interface. It should have been a drop-in
    replacement (no API changes) but I guess you never know.

    The WicketNotSerializableException looks like an issue I already
    fixed. The geocss jar does not interact with Wicket at all so I
    would not expect it to introduce this type of problem.

    Permgen errors are pretty common in GeoServer - GeoServer uses
    many class libraries and this leads to PermGen pressure. The CSS
    module brings in a different parsing library and collections
    framework from the ones used in GeoServer already so it is fairly
    "heavy" in this regard. I generally set -XX:PermSize=256M when
    running with the CSS module and I don't encounter PermGen issues.
     But I don't manage any long-running GeoServer instances with the
    CSS module enabled, so it's possible there is a problem that I
    haven't noticed.

    In short, it seems that mixing and matching jar files is not
    working well here. I'll look into updating the GeoServer build so
    that you can just use a nightly build of the community module instead.

    --
    David Winslow
    OpenGeo - http://opengeo.org/

    On Wed, Jan 16, 2013 at 4:37 AM, Matthias Uden
    <matthias.uden@anonymised.com
    <mailto:matthias.uden@anonymised.com>> wrote:

        Hi David,

        in order to get the expression based dynamic coloring to work
        I tried the custom .jar with both GeoServer versions (2.1.3
        and 2.2.3) - unfortunately without success.
        Here is what happens with several different configurations:

        GS 2.1.3 + CSS Module 2.1.x w/ your custom geocss .jar:

        The CSS Module doesn't seem to work properly with this
        combination. I cannot even create a new CSS style in the
        interface.
        Once I try that, it gives me this exception:

        org.apache.wicket.WicketRuntimeException: Method
        onFormSubmitted of interface
        org.apache.wicket.markup.html.form.IFormSubmitListener
        targeted at component [MarkupContainer [Component id =
        layer-selection]] threw an exception
        (...)
        Caused by: java.lang.reflect.InvocationTargetException
        (...)
        Caused by: java.lang.NoClassDefFoundError: scala/Serializable
        (...)
        Caused by: java.lang.ClassNotFoundException: scala.Serializable

        GS 2.2.1 + "standard" CSS Module 2.2.x:

        Once I click on the "CSS Demo" link in the web interface,
        everything becomes very slow and in the console I keep getting
        these errors:
        OutOfMemoryError: PermGen space

        I've found some other threads in the internet dealing with
        this problem.
        Of course I could give the tomcat more PermGen memory space,
        but still I wonder why this is happening, since it wasn't a
        problem at all in GS 2.1.3

        GS 2.2.1 + CSS Module 2.2.x w/ your custom geocss .jar:

        Also memory issues. Some more specific error messages I get
        include:

        ERROR [lang.Objects] - Error serializing object class
        org.geoserver.community.css.web.CssDemoPage [object=[Page
        class = org.geoserver.community.css.web.CssDemoPage, id = 4,
        version = 0]]
        org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
        Unable to serialize class:
        org.geoserver.config.GeoServerDataDirectory
        (...)
        ERROR [wicket.Session] - Exception when detaching/serializing page

        So, apart from the dynamic color issue I seem to have some
        serious problems with my freshly set up GeoServer 2.2.3 w/ CSS
        Module...
        Any hints on what could go wrong here are appreciated,
        although I will have to put some more effort in getting a
        working configuration once I find the time.

        Btw, in which combination did you get the dynamic coloring to
        work?

        Thanks again for your continued help! Apart from this issue I
        am very enthusiastic about the CSS Module.

        Cheers,
        Matthias

        Am 15.01.2013 15:34, schrieb David Winslow:

        The update hasn't been included for any GeoServer release yet
        - I had hoped to get another feature or two in before
        updating the builds. However, the geocss JAR that I linked
        to should work in any GeoServer version (I think.) Here's
        that link again for reference:
        http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/geocss_2.9.1-0.7.4.jar

        When I do get around to updating the build I won't be
        updating 2.1.x as it is no longer a supported version of
        GeoServer. However, SLDs generated with 2.2.x and later
        should continue to be compatible with earlier versions of
        GeoServer.

        --
        David Winslow
        OpenGeo - http://opengeo.org/

        On Tue, Jan 15, 2013 at 8:27 AM, Matthias Uden
        <matthias.uden@anonymised.com
        <mailto:matthias.uden@anonymised.com>> wrote:

            Hi David / all,

            I'm sorry to bother you again with the CSS Module dynamic
            coloring issue.
            I still can't use dynamic color attributes in my CSS. Is
            it possible that it only works for GeoServer 2.2.x? I'm
            still using 2.1.3 and it seems that the geocss .jar has
            only been updated for 2.2.x
            Is there a way to make it working for 2.1.x too?

            Thanks for your time and advice,
            Matthias

            Am 11.12.2012 15:06, schrieb Matthias Uden:

                Hi David,

                sorry for the late reply. Thanks a lot for the quick fix!
                I will definitely have a look at the sources myself
                someday if I find
                the time.. For now I can achieve most of the desired
                styling with the
                CSS module. Thanks for your good work.

                Cheers,
                Matthias

                Am 07.12.2012 15:49, schrieb David Winslow:

                    You're right, the docs are incorrect wrt the MIME
                    information. I'll go
                    ahead and update them so they will be correct
                    after the next automated
                    rebuild.

                    I am indeed the only developer on the CSS module.
                     It's not under
                    frequent development but I do try to keep up with
                    bugs reported on this
                    mailing list (and the github issue list.)
                     Actually I resolved the
                    dynamic color bug last night. I haven't updated
                    the plugin in the
                    community build yet (maybe this weekend) but if
                    you want an early peak
                    you can just grab the JAR file from
                    http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/
                    and overwrite the one that you already installed.

                    --
                    David Winslow
                    OpenGeo - http://opengeo.org/

                    On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden
                    <matthias.uden@anonymised.com
                    <mailto:matthias.uden@anonymised.com>
                    <mailto:matthias.uden@anonymised.com
                    <mailto:matthias.uden@anonymised.com>>> wrote:

                         David,

                         thanks a lot for the quick answer and
                    clarification!
                         I didn't know about the CSS property
                    "mark-mime", since it is not part
                         of the CSS Property Listing
                                            (http://docs.geoserver.org/stable/en/user/community/css/properties.html).
                         This
                         at least fixed the Icon Media Type issue.
                         It's a pity that dynamic colors are not yet
                    supported. I suppose that
                         the CSS Module is currently not actively
                    developed anymore due to lack
                         of time. Are you the only developer?

                         Cheers,
                         Matthias

                         Am 06.12.2012 16:14, schrieb David Winslow:
                          > *Relative Paths for Icons
                          > *The short answer is, no, you can't make
                    it do that. The problem is
                          > that the CSS-SLD converter actually uses
                    GeoTools' SLD writing
                         code to
                          > generate the SLD files, and GeoTools' SLD
                    support is not symmetric (I
                          > mean it cannot write everything that it
                    can read.) Resolving
                         relative
                          > paths into absolute ones is a compromise
                    between the actually desired
                          > behavior and not supporting relative
                    paths at all. This could
                         probably
                          > be fixed at the GeoTools level, but I
                    haven't taken the time to
                         inquire
                          > into why this asymmetry was built in in
                    the first place.
                          >
                          > Why are relative paths a problem for you?
                    Maybe there is a workaround
                          > that could be used (for example, if it's
                    a problem with
                         relocating data
                          > directories, I could add a tool to
                    re-convert all CSS styles
                         which would
                          > re-resolve the paths.)
                          > *
                          > Icon Media Types*
                          > The image type logic is not as
                    sophisticated as you might expect -
                          > things like dynamic symbolizers[1] make
                    it impossible to know the
                         media
                          > type for the image in general, so I just
                    threw my hands up and
                         made it
                          > literally 'image/jpeg' if you don't
                    specify. You can provide the
                         media
                          > type explicitly with the *fill-mime*,
                    *stroke-mime*, *mark-mime*, or
                          > *shield-mime* property. For example:
                          >
                          > * {
                          > fill: url(pattern.png);
                          > fill-mime: "image/png";
                          > }
                          >
                          > I don't guess it would be too hard to
                    make the CSS-SLD converter
                         try to
                          > look up the icon and inspect it to
                    provide the default, but this
                         is not
                          > as big a priority to me as rendering
                    transformations. If you want to
                          > look into it let me know and I can give
                    you some pointers on
                         what's needed.
                          >
                          > *Dynamic Color*
                          > This is simply a bug (the color handling
                    is a bit more complex
                         than the
                          > label handling, to allow for rgb() color
                    syntax.) Again, this is
                          > probably easily fixable given the time to
                    work on it; I'd say even
                          > easier than smart defaults for the icon
                    mime-type property.
                          >
                          > If you'd like to file bugs against
                    GeoScript-Scala[2] I'll keep them
                          > up-to-date if and when I get around to
                    working on these problems.
                          >
                          > [1]:
                    http://blog.geoserver.org/2008/12/08/dynamic-symbolizers-part-1/
                          > [2]:
                    https://github.com/dwins/geoscript.scala/issues
                          >
                          > On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden
                         <matthias.uden@anonymised.com
                    <mailto:matthias.uden@anonymised.com>
                    <mailto:matthias.uden@anonymised.com
                    <mailto:matthias.uden@anonymised.com>>
                          > <mailto:matthias.uden@anonymised.com
                    <mailto:matthias.uden@anonymised.com>
                         <mailto:matthias.uden@anonymised.com
                    <mailto:matthias.uden@anonymised.com>>>> wrote:
                          >
                          > Hi all,
                          >
                          > I've recently discovered the CSS
                    module as an alternative to
                         SLD styling
                          > and I'm quite enthusiastic about it.
                    Still, I cannot accomplish
                          > everything I used to do with SLD
                    before...
                          >
                          > Here are two specific questions:
                          >
                          > 1) When specifying a custom icon for
                    a mark with url(...), is it
                          > possible to get a relative path in
                    the generated SLD instead
                         of an
                          > absolute one? Also, is there a
                    possibility to specify the
                         format of that
                          > image correctly? Currently, it is
                    always converted to jpeg,
                         even when I
                          > put in a png...
                          >
                          > Example:
                          > CSS:
                          > mark: url('icons/entry.png');
                          >
                          > SLD:
                          > <sld:ExternalGraphic>
                          > <sld:OnlineResource
                    xmlns:xlink="http://www.w3.org/1999/xlink"
                          > xlink:type="simple"
                          >
                                            xlink:href="file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png"/>
                          > <sld:Format>image/jpeg</sld:Format>
                          > </sld:ExternalGraphic>
                          >
                          > 2) Specifying an attributes value
                    dynamically using a column
                         of the
                          > underlying DB table works fine for
                    e.g. labels. However, it
                         doesn't work
                          > for colors.
                          >
                          > Example (working):
                          > CSS:
                          > label: [key];
                          >
                          > SLD:
                          > <sld:Label>
                          > <ogc:PropertyName>key</ogc:PropertyName>
                          > </sld:Label>
                          >
                          > Example (not working):
                          > CSS:
                          > fill: [color];
                          >
                          > SLD:
                          > <sld:Fill/>
                          >
                          > Any help is appreciated!
                          > Thanks in advance and all the best,
                          > Matthias
                          >
                     ------------------------------------------------------------------------------
                          > LogMeIn Rescue: Anywhere, Anytime
                    Remote support for IT. Free
                         Trial
                          > Remotely access PCs and mobile
                    devices and provide instant
                         support
                          > Improve your efficiency, and focus on
                    delivering more
                         value-add services
                          > Discover what IT Professionals Know.
                    Rescue delivers
                          > http://p.sf.net/sfu/logmein_12329d2d
                          >
                    _______________________________________________
                          > Geoserver-users mailing list
                          > Geoserver-users@lists.sourceforge.net
                    <mailto:Geoserver-users@lists.sourceforge.net>
                                            <mailto:Geoserver-users@lists.sourceforge.net
                    <mailto:Geoserver-users@lists.sourceforge.net>>
                          > <mailto:Geoserver-users@lists.sourceforge.net
                    <mailto:Geoserver-users@lists.sourceforge.net>
                                            <mailto:Geoserver-users@lists.sourceforge.net
                    <mailto:Geoserver-users@lists.sourceforge.net>>>
                          >
                    https://lists.sourceforge.net/lists/listinfo/geoserver-users
                          >
                     ------------------------------------------------------------------------------
                          > LogMeIn Rescue: Anywhere, Anytime Remote
                    support for IT. Free Trial
                          > Remotely access PCs and mobile devices
                    and provide instant support
                          > Improve your efficiency, and focus on
                    delivering more value-add
                         services
                          > Discover what IT Professionals Know.
                    Rescue delivers
                          > http://p.sf.net/sfu/logmein_12329d2d
                          >
                    _______________________________________________
                          > Geoserver-users mailing list
                          > Geoserver-users@lists.sourceforge.net
                    <mailto:Geoserver-users@lists.sourceforge.net>
                                            <mailto:Geoserver-users@lists.sourceforge.net
                    <mailto:Geoserver-users@lists.sourceforge.net>>
                          >
                    https://lists.sourceforge.net/lists/listinfo/geoserver-users
                          >

                     ------------------------------------------------------------------------------
                         LogMeIn Rescue: Anywhere, Anytime Remote
                    support for IT. Free Trial
                         Remotely access PCs and mobile devices and
                    provide instant support
                         Improve your efficiency, and focus on
                    delivering more value-add services
                         Discover what IT Professionals Know. Rescue
                    delivers
                    http://p.sf.net/sfu/logmein_12329d2d
                     _______________________________________________
                         Geoserver-users mailing list
                    Geoserver-users@lists.sourceforge.net
                    <mailto:Geoserver-users@lists.sourceforge.net>
                                            <mailto:Geoserver-users@lists.sourceforge.net
                    <mailto:Geoserver-users@lists.sourceforge.net>>
                    https://lists.sourceforge.net/lists/listinfo/geoserver-users

                    ------------------------------------------------------------------------------
                    LogMeIn Rescue: Anywhere, Anytime Remote support
                    for IT. Free Trial
                    Remotely access PCs and mobile devices and
                    provide instant support
                    Improve your efficiency, and focus on delivering
                    more value-add services
                    Discover what IT Professionals Know. Rescue delivers
                    http://p.sf.net/sfu/logmein_12329d2d

                    _______________________________________________
                    Geoserver-users mailing list
                    Geoserver-users@lists.sourceforge.net
                    <mailto:Geoserver-users@lists.sourceforge.net>
                    https://lists.sourceforge.net/lists/listinfo/geoserver-users

                ------------------------------------------------------------------------------
                LogMeIn Rescue: Anywhere, Anytime Remote support for
                IT. Free Trial
                Remotely access PCs and mobile devices and provide
                instant support
                Improve your efficiency, and focus on delivering more
                value-add services
                Discover what IT Professionals Know. Rescue delivers
                http://p.sf.net/sfu/logmein_12329d2d

David_Winslow · January 22, 2013, 3:51pm

Well, it does not cause a PermGen error on my machine. When I run GeoServer with the CSS module in development, I usually run it like so:

GEOSERVER_DATA_DIR=…/…/…/data/release/ MAVEN_OPTS=“-Xmx1024M -XX:PermSize=384M” mvn jetty:run -o -Pcss

If you are not also increasing the heap space with ‘-Xmx’ then it is possible that general memory pressure is increasing the PermGen usage. Otherwise, I’m not sure, but maybe a review of the Wicket code would turn something up which is being unnecessarily serialized.

···

On Tue, Jan 22, 2013 at 5:56 AM, Matthias Uden <matthias.uden@anonymised.com…> wrote:

Hi David,

thanks, I tried the new build for 2.2.x
Unfortunately, I still get the PermGen space OutOfMemory exception, even when I increase the PermSize to 512m.
The interface freezes once I try to create a new CSS style, sometimes already when I only click on the “CSS Demo” link.
The exact error I get in the log says:

22 Jan 11:32:13 ERROR [wicket.Session] - Exception when detaching/serializing page
java.lang.OutOfMemoryError: PermGen space

I’m still wondering why this happens in 2.2.x, while it never occurred in 2.1.x.

Any ideas on what could cause this problem?
Thanks a lot…

Cheers,
Matthias

Am 17.01.2013 15:59, schrieb David Winslow:

Ok, i’ve updated the community module on the 2.2.x and master (2.3.x) branches. I was wrong about having fixed the WicketNotSerializableException issue so that is resolved on 2.2.x as well. The build server seems to have a pretty deep backlog right now, so if you are able to build from sources it might be faster to pull the latest from git and rebuild. Either way, the packages will be available in the next set of nightlies.

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jan 16, 2013 at 10:39 AM, David Winslow <dwinslow@anonymised.com> wrote:

I’ve only tested dynamic coloring in the geocss library, not with the GeoServer web interface. It should have been a drop-in replacement (no API changes) but I guess you never know.

The WicketNotSerializableException looks like an issue I already fixed. The geocss jar does not interact with Wicket at all so I would not expect it to introduce this type of problem.

Permgen errors are pretty common in GeoServer - GeoServer uses many class libraries and this leads to PermGen pressure. The CSS module brings in a different parsing library and collections framework from the ones used in GeoServer already so it is fairly “heavy” in this regard. I generally set -XX:PermSize=256M when running with the CSS module and I don’t encounter PermGen issues. But I don’t manage any long-running GeoServer instances with the CSS module enabled, so it’s possible there is a problem that I haven’t noticed.

In short, it seems that mixing and matching jar files is not working well here. I’ll look into updating the GeoServer build so that you can just use a nightly build of the community module instead.

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jan 16, 2013 at 4:37 AM, Matthias Uden <matthias.uden@anonymised.com> wrote:

Hi David,

in order to get the expression based dynamic coloring to work I tried the custom .jar with both GeoServer versions (2.1.3 and 2.2.3) - unfortunately without success.
Here is what happens with several different configurations:

GS 2.1.3 + CSS Module 2.1.x w/ your custom geocss .jar:

The CSS Module doesn’t seem to work properly with this combination. I cannot even create a new CSS style in the interface.
Once I try that, it gives me this exception:

org.apache.wicket.WicketRuntimeException: Method onFormSubmitted of interface org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component [MarkupContainer [Component id = layer-selection]] threw an exception
(…)
Caused by: java.lang.reflect.InvocationTargetException
(…)
Caused by: java.lang.NoClassDefFoundError: scala/Serializable
(…)
Caused by: java.lang.ClassNotFoundException: scala.Serializable

GS 2.2.1 + “standard” CSS Module 2.2.x:

Once I click on the “CSS Demo” link in the web interface, everything becomes very slow and in the console I keep getting these errors:
OutOfMemoryError: PermGen space

I’ve found some other threads in the internet dealing with this problem.
Of course I could give the tomcat more PermGen memory space, but still I wonder why this is happening, since it wasn’t a problem at all in GS 2.1.3

GS 2.2.1 + CSS Module 2.2.x w/ your custom geocss .jar:

Also memory issues. Some more specific error messages I get include:

ERROR [lang.Objects] - Error serializing object class org.geoserver.community.css.web.CssDemoPage [object=[Page class = org.geoserver.community.css.web.CssDemoPage, id = 4, version = 0]]
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: Unable to serialize class: org.geoserver.config.GeoServerDataDirectory
(…)
ERROR [wicket.Session] - Exception when detaching/serializing page

So, apart from the dynamic color issue I seem to have some serious problems with my freshly set up GeoServer 2.2.3 w/ CSS Module…
Any hints on what could go wrong here are appreciated, although I will have to put some more effort in getting a working configuration once I find the time.

Btw, in which combination did you get the dynamic coloring to work?

Thanks again for your continued help! Apart from this issue I am very enthusiastic about the CSS Module.

Cheers,
Matthias

Am 15.01.2013 15:34, schrieb David Winslow:

The update hasn’t been included for any GeoServer release yet - I had hoped to get another feature or two in before updating the builds. However, the geocss JAR that I linked to should work in any GeoServer version (I think.) Here’s that link again for reference: http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/geocss_2.9.1-0.7.4.jar

When I do get around to updating the build I won’t be updating 2.1.x as it is no longer a supported version of GeoServer. However, SLDs generated with 2.2.x and later should continue to be compatible with earlier versions of GeoServer.

–
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Jan 15, 2013 at 8:27 AM, Matthias Uden <matthias.uden@anonymised.com> wrote:

Hi David / all,

I’m sorry to bother you again with the CSS Module dynamic coloring issue.
I still can’t use dynamic color attributes in my CSS. Is it possible that it only works for GeoServer 2.2.x? I’m still using 2.1.3 and it seems that the geocss .jar has only been updated for 2.2.x
Is there a way to make it working for 2.1.x too?

Thanks for your time and advice,
Matthias

Am 11.12.2012 15:06, schrieb Matthias Uden:

Hi David,

sorry for the late reply. Thanks a lot for the quick fix!
I will definitely have a look at the sources myself someday if I find
the time… For now I can achieve most of the desired styling with the
CSS module. Thanks for your good work.

Cheers,
Matthias

Am 07.12.2012 15:49, schrieb David Winslow:

You’re right, the docs are incorrect wrt the MIME information. I’ll go
ahead and update them so they will be correct after the next automated
rebuild.

I am indeed the only developer on the CSS module. It’s not under
frequent development but I do try to keep up with bugs reported on this
mailing list (and the github issue list.) Actually I resolved the
dynamic color bug last night. I haven’t updated the plugin in the
community build yet (maybe this weekend) but if you want an early peak
you can just grab the JAR file from
http://gridlock.opengeo.org:8080/hudson/view/geoscript/job/geoscript-scala/ws/geocss/target/scala-2.9.1/
and overwrite the one that you already installed.

–
David Winslow
OpenGeo - http://opengeo.org/

On Fri, Dec 7, 2012 at 6:12 AM, Matthias Uden <matthias.uden@anonymised.com
mailto:[matthias.uden@anonymised.com](mailto:matthias.uden@anonymised.com)> wrote:

David,

thanks a lot for the quick answer and clarification!
I didn’t know about the CSS property “mark-mime”, since it is not part
of the CSS Property Listing
(http://docs.geoserver.org/stable/en/user/community/css/properties.html).
This
at least fixed the Icon Media Type issue.
It’s a pity that dynamic colors are not yet supported. I suppose that
the CSS Module is currently not actively developed anymore due to lack
of time. Are you the only developer?

Cheers,
Matthias

Am 06.12.2012 16:14, schrieb David Winslow:

*Relative Paths for Icons
*The short answer is, no, you can’t make it do that. The problem is
that the CSS-SLD converter actually uses GeoTools’ SLD writing
code to
generate the SLD files, and GeoTools’ SLD support is not symmetric (I
mean it cannot write everything that it can read.) Resolving
relative
paths into absolute ones is a compromise between the actually desired
behavior and not supporting relative paths at all. This could
probably
be fixed at the GeoTools level, but I haven’t taken the time to
inquire
into why this asymmetry was built in in the first place.

Why are relative paths a problem for you? Maybe there is a workaround
that could be used (for example, if it’s a problem with
relocating data
directories, I could add a tool to re-convert all CSS styles
which would
re-resolve the paths.)
*
Icon Media Types*
The image type logic is not as sophisticated as you might expect -
things like dynamic symbolizers1 make it impossible to know the
media
type for the image in general, so I just threw my hands up and
made it
literally ‘image/jpeg’ if you don’t specify. You can provide the
media
type explicitly with the fill-mime, stroke-mime, mark-mime, or
shield-mime property. For example:

{
fill: url(pattern.png);
fill-mime: “image/png”;
}

I don’t guess it would be too hard to make the CSS-SLD converter
try to
look up the icon and inspect it to provide the default, but this
is not
as big a priority to me as rendering transformations. If you want to
look into it let me know and I can give you some pointers on
what’s needed.

Dynamic Color
This is simply a bug (the color handling is a bit more complex
than the
label handling, to allow for rgb() color syntax.) Again, this is
probably easily fixable given the time to work on it; I’d say even
easier than smart defaults for the icon mime-type property.

If you’d like to file bugs against GeoScript-Scala2 I’ll keep them
up-to-date if and when I get around to working on these problems.

On Thu, Dec 6, 2012 at 7:53 AM, Matthias Uden
<matthias.uden@anonymised.com mailto:[matthias.uden@anonymised.com](mailto:matthias.uden@anonymised.com)
<mailto:matthias.uden@anonymised.com4…
mailto:[matthias.uden@anonymised.com](mailto:matthias.uden@anonymised.com)>> wrote:

Hi all,

I’ve recently discovered the CSS module as an alternative to
SLD styling
and I’m quite enthusiastic about it. Still, I cannot accomplish
everything I used to do with SLD before…

Here are two specific questions:

When specifying a custom icon for a mark with url(…), is it
possible to get a relative path in the generated SLD instead
of an
absolute one? Also, is there a possibility to specify the
format of that
image correctly? Currently, it is always converted to jpeg,
even when I
put in a png…

Example:
CSS:
mark: url(‘icons/entry.png’);

SLD:
sld:ExternalGraphic
<sld:OnlineResource xmlns:xlink=“http://www.w3.org/1999/xlink”
xlink:type=“simple”

xlink:href=“file:/home/muden/test_geoserver/wms/map/geoserver/test_geoserver/styles/icons/entry.png”/>

sld:Formatimage/jpeg</sld:Format>
</sld:ExternalGraphic>

Specifying an attributes value dynamically using a column
of the
underlying DB table works fine for e.g. labels. However, it
doesn’t work
for colors.

Example (working):
CSS:
label: [key];

SLD:
sld:Label
ogc:PropertyNamekey</ogc:PropertyName>
</sld:Label>

Example (not working):
CSS:
fill: [color];

SLD:
sld:Fill/

Any help is appreciated!
Thanks in advance and all the best,
Matthias

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free
Trial
Remotely access PCs and mobile devices and provide instant
support
Improve your efficiency, and focus on delivering more
value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
mailto:[Geoserver-users@lists.sourceforge.net](mailto:Geoserver-users@lists.sourceforge.net)
<mailto:Geoserver-users@lists.sourceforge.net
mailto:[Geoserver-users@lists.sourceforge.net](mailto:Geoserver-users@lists.sourceforge.net)>
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add
services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
mailto:[Geoserver-users@lists.sourceforge.net](mailto:Geoserver-users@lists.sourceforge.net)
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@anonymised.coms.sourceforge.net
mailto:[Geoserver-users@lists.sourceforge.net](mailto:Geoserver-users@lists.sourceforge.net)
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-users mailing list
Geoserver-users@anonymised.comge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d