[Geoserver-devel] Some thoughts on SLD management and palettes

Hi,
trying to implement palette support I stopped by thinking
the way we handle SLD....

For palettes I would like to have a palette manager class,
that is able to locate palette files, load them, and cache the
loaded palette in an in memory cache (a good cache, not just
an hashmap). Caching should deal with palette file changes,
so that a change on the file is picked up immediatly.

It struck me that SLD handling should be exactly the same.
At the moment, we do have a hard cache (a hashmap), no
link to the file, and we have quite a bizantine way of
handling SLD, with a list configured in catalog.xml, where
the names of the styles can be different from the file name
and so on. Wouldn't it be a lot simpler to rely directly
on the /styles directory content, list whatever is in that
folder, and use the file names as style names (since most
modern operating system have no trouble handling fancy named files)?

Finally, a question about code. Data is the current provider
of SLD styls (Data.getStyle()). Is that the right place to handle
this, since SLD are the business of just WMS? If so, then also
palette handling should be wrapped by Data. Otherwise, we may want
to move SLD handling onto the WMS module...

Cheers
Andrea

Hi Andrea,

You have hit on some good issues. Ones to note as we design the new
configuration.

For palettes I would like to have a palette manager class,
that is able to locate palette files, load them, and cache the
loaded palette in an in memory cache (a good cache, not just
an hashmap). Caching should deal with palette file changes,
so that a change on the file is picked up immediatly.

It seems to be me that this caching problem comes up quite frequently
with all our config objects no? Another requirement of a new config
system could be a good cache, possibly one that could be reused for all
config objects.

It struck me that SLD handling should be exactly the same.
At the moment, we do have a hard cache (a hashmap), no
link to the file, and we have quite a bizantine way of
handling SLD, with a list configured in catalog.xml, where
the names of the styles can be different from the file name
and so on. Wouldn't it be a lot simpler to rely directly
on the /styles directory content, list whatever is in that
folder, and use the file names as style names (since most
modern operating system have no trouble handling fancy named files)?

I agree, however this would diverge from the rest of the configuration
as we currently don't serve any "resources" straight from the disk, its
all about what has been configured.

Finally, a question about code. Data is the current provider
of SLD styls (Data.getStyle()). Is that the right place to handle
this, since SLD are the business of just WMS? If so, then also
palette handling should be wrapped by Data. Otherwise, we may want
to move SLD handling onto the WMS module...

Good question... I guess it boils down to can we think of a need for
styles with any other services. Cant think of any off the top of my head.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Justin Deoliveira ha scritto:

Hi Andrea,

You have hit on some good issues. Ones to note as we design the new
configuration.

For palettes I would like to have a palette manager class,
that is able to locate palette files, load them, and cache the
loaded palette in an in memory cache (a good cache, not just
an hashmap). Caching should deal with palette file changes,
so that a change on the file is picked up immediatly.

It seems to be me that this caching problem comes up quite frequently
with all our config objects no? Another requirement of a new config
system could be a good cache, possibly one that could be reused for all
config objects.

For the palettes I'm using the SoftValueHashMap created by Simone and Martin, works really fine. Hard caches a few references, soft caches
the rest, and provides a LRU policy. Simple and effective.
I just added the ability to check for expiration, which has to be
added separately anyways since what defines an element as expired
is domain dependent.

It struck me that SLD handling should be exactly the same.
At the moment, we do have a hard cache (a hashmap), no
link to the file, and we have quite a bizantine way of
handling SLD, with a list configured in catalog.xml, where
the names of the styles can be different from the file name
and so on. Wouldn't it be a lot simpler to rely directly
on the /styles directory content, list whatever is in that
folder, and use the file names as style names (since most
modern operating system have no trouble handling fancy named files)?

I agree, however this would diverge from the rest of the configuration
as we currently don't serve any "resources" straight from the disk, its
all about what has been configured.

Hmm... I don't see the disadvantage. From the user point of view it
seems to me it would just make things simpler (the user interface would
not change anyways). I've seen people put the SLD in a CMS to make
it easier to handle them, and the refer them with the sld= parameter
to work around the hard to deal with configuration (and the inability to edit sld, too).
I understand not willing to serve a specific feature type or coverage,
but not serving an SLD that's in the styles directory?

Palettes are not grabbed right out of the palettes directory... shall
I build a configuration system around them too then? (glab...)
I would have liked consistency drive thing in the "simpler to manage"
direction :slight_smile:

Cheers
Andrea

Andrea Aime wrote:

Hi,
trying to implement palette support I stopped by thinking
the way we handle SLD....

For palettes I would like to have a palette manager class,
that is able to locate palette files, load them, and cache the
loaded palette in an in memory cache (a good cache, not just
an hashmap). Caching should deal with palette file changes,
so that a change on the file is picked up immediatly.

It struck me that SLD handling should be exactly the same.
At the moment, we do have a hard cache (a hashmap), no
link to the file, and we have quite a bizantine way of
handling SLD, with a list configured in catalog.xml, where
the names of the styles can be different from the file name
and so on. Wouldn't it be a lot simpler to rely directly
on the /styles directory content, list whatever is in that
folder, and use the file names as style names (since most
modern operating system have no trouble handling fancy named files)?

Yes. The reason we have them listed in catalog is actually because when we ported from gt2wms I had no idea there was another way to do it. SLD's actually should all have names, so that should be the first choice for what we call them - right now we actually hack to over-ride that. The filename would be a good fallback choice, but first should be what's in the SLD file.

The whole SLD management needs improvement, from the editing of SLD's in the web admin (even just a big text box) to properly deleting the files when they are removed.

Finally, a question about code. Data is the current provider
of SLD styls (Data.getStyle()). Is that the right place to handle
this, since SLD are the business of just WMS? If so, then also
palette handling should be wrapped by Data. Otherwise, we may want
to move SLD handling onto the WMS module...

Yeah, I think SLD handling in the WMS module makes sense. It is a WMS concern.

Chris

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Chris Holmes ha scritto:

modern operating system have no trouble handling fancy named files)?

Yes. The reason we have them listed in catalog is actually because when we ported from gt2wms I had no idea there was another way to do it. SLD's actually should all have names, so that should be the first choice for what we call them - right now we actually hack to over-ride that. The filename would be a good fallback choice, but first should be what's in the SLD file.

Hmm... I would not trust the user to really put different names inside
the sld file, whilst with filenames you have the filesystem to keep the
user at bay (well, on unix it can play with character case, but that
would be a minor issue).

The whole SLD management needs improvement, from the editing of SLD's in the web admin (even just a big text box) to properly deleting the files when they are removed.

That would be a lot simpler if we had a 1-1 relation with style names
and file names. (think the issue we have now when the user tries to upload the a file that's already there under a different id...)

Cheers
Andrea