Hi all,
I'm developing a restlet service to manage sld, I would like to share
with community (ideas and code).
The idea is to develop a geoserver community module ables to serve an
sld userStyle in a retfull way, (divided in multiple resource):
Example:
http://domain:8080/geoserver/sldservice/\{featureType\}
-> List of available styles in geoserver for a featuretype or coverage
name link to resource
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}
-> UserStyle: Name Title Abstract IsDefault List of FeatureTypeStyle
(only name, id and link to the resource)
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}
-> FeatureTypeStyle Name Title Abstract featureTypeName ruleslength
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/rules/
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/rules/\{fisrtRuleId\}/\{lastRuleID\}
-> Rule list: As in sld spec. (using the first will return all rules)
A live example is available at
http://test.ominiverdi.org:8080/geoserverSld/sldservice/topp:states (try
also with other layers)
I will add also the capabilities to generate rules based on
classification system
example:
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/quantileclassification/\{property\}/\{classNum\}
-> Rule list generated server side
(not yet added in the live example)
Later I wish to develop a javascript sld editor,
ables to work with a great number of rules and to create classified style.
Any comments and ideas are welcome!
Ciao kappu
Hi Andrea Cappugi.
I think a good idea and has my support.
I am developing a system for an institution here in Brazil and really have difficulties to implement the solutions that the user wants with the legends and styles of maps.
Congratulations on your initiative and I hope it is successful in the GeoServer.
I think many will like to have this resource in GeoServer.
Best regards,
Carlos Fernando Gonçalves
2007/11/9, Andrea Cappugi <kappu72@anonymised.com>:
Hi all,
I’m developing a restlet service to manage sld, I would like to share
with community (ideas and code).
The idea is to develop a geoserver community module ables to serve an
sld userStyle in a retfull way, (divided in multiple resource):
Example:
http://domain:8080/geoserver/sldservice/{featureType}
→ List of available styles in geoserver for a featuretype or coverage
name link to resource
http://domain:8080/geoserver/sldservice/{featureType}/{UserStyleID}
→ UserStyle: Name Title Abstract IsDefault List of FeatureTypeStyle
(only name, id and link to the resource)
http://domain:8080/geoserver/sldservice/{featureType}/{UserStyleID}/{FeatureTypeStyleID}
→ FeatureTypeStyle Name Title Abstract featureTypeName ruleslength
http://domain:8080/geoserver/sldservice/{featureType}/{UserStyleID}/{FeatureTypeStyleID}/rules/
http://domain:8080/geoserver/sldservice/{featureType}/{UserStyleID}/{FeatureTypeStyleID}/rules/{fisrtRuleId}/{lastRuleID}
→ Rule list: As in sld spec. (using the first will return all rules)
A live example is available at
http://test.ominiverdi.org:8080/geoserverSld/sldservice/topp:states (try
also with other layers)
I will add also the capabilities to generate rules based on
classification system
example:
http://domain:8080/geoserver/sldservice/{featureType}/{UserStyleID}/{FeatureTypeStyleID}/quantileclassification/{property}/{classNum}
→ Rule list generated server side
(not yet added in the live example)
Later I wish to develop a javascript sld editor,
ables to work with a great number of rules and to create classified style.
Any comments and ideas are welcome!
Ciao kappu
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Geoserver-devel mailing list
Geoserver-devel@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Carlos FG
Looks good kappu. We are definitely interested in a javascript sld editor as well (though lack funding for it right now). I think the main thing I'd like to see in it is having set zoom levels that you can set styles for, make a nice UI to tell which zooms you want your SLD apply to.
The service looks great, the one thing I wonder about is how it should play with the REST configuration stuff Arne and David are working on. Like it might make sense to just have one general resource location for styles. Which I think would be as simple as adding to your stuff the ability to just GET and PUT/POST the full SLD, in addition to just portions (unless you already have that and I'm missing it), as an alternate resource representation. I'm not sure which should be the default...
But this doesn't have to happen immediately, just something to think about, what our whole REST api picture should be.
best regards,
Chris
Andrea Cappugi wrote:
Hi all,
I'm developing a restlet service to manage sld, I would like to share
with community (ideas and code).
The idea is to develop a geoserver community module ables to serve an
sld userStyle in a retfull way, (divided in multiple resource):
Example:
http://domain:8080/geoserver/sldservice/\{featureType\}
-> List of available styles in geoserver for a featuretype or coverage
name link to resource
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}
-> UserStyle: Name Title Abstract IsDefault List of FeatureTypeStyle
(only name, id and link to the resource)
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}
-> FeatureTypeStyle Name Title Abstract featureTypeName ruleslength
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/rules/
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/rules/\{fisrtRuleId\}/\{lastRuleID\}
-> Rule list: As in sld spec. (using the first will return all rules)
A live example is available at
http://test.ominiverdi.org:8080/geoserverSld/sldservice/topp:states (try
also with other layers)
I will add also the capabilities to generate rules based on
classification system
example:
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/quantileclassification/\{property\}/\{classNum\}
-> Rule list generated server side
(not yet added in the live example)
Later I wish to develop a javascript sld editor,
ables to work with a great number of rules and to create classified style.
Any comments and ideas are welcome!
Ciao kappu
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,47345498308313362379201!
Oh, right. And the next step is to make a wiki page describing the module, you could start by mostly just copying the email you wrote and adding a bit of background. Add it as a subpage here: http://docs.codehaus.org/display/GEOSDOC/Community Let me know if you have trouble, as Mauro wasn't able to add stuff to GEOSDOC, had to do it in GEOS.
Once that's there we can get you set up to commit the module.
Chris
Chris Holmes wrote:
Looks good kappu. We are definitely interested in a javascript sld editor as well (though lack funding for it right now). I think the main thing I'd like to see in it is having set zoom levels that you can set styles for, make a nice UI to tell which zooms you want your SLD apply to.
The service looks great, the one thing I wonder about is how it should play with the REST configuration stuff Arne and David are working on. Like it might make sense to just have one general resource location for styles. Which I think would be as simple as adding to your stuff the ability to just GET and PUT/POST the full SLD, in addition to just portions (unless you already have that and I'm missing it), as an alternate resource representation. I'm not sure which should be the default...
But this doesn't have to happen immediately, just something to think about, what our whole REST api picture should be.
best regards,
Chris
Andrea Cappugi wrote:
Hi all,
I'm developing a restlet service to manage sld, I would like to share
with community (ideas and code).
The idea is to develop a geoserver community module ables to serve an
sld userStyle in a retfull way, (divided in multiple resource):
Example:
http://domain:8080/geoserver/sldservice/\{featureType\}
-> List of available styles in geoserver for a featuretype or coverage
name link to resource
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}
-> UserStyle: Name Title Abstract IsDefault List of FeatureTypeStyle
(only name, id and link to the resource)
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}
-> FeatureTypeStyle Name Title Abstract featureTypeName ruleslength
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/rules/
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/rules/\{fisrtRuleId\}/\{lastRuleID\}
-> Rule list: As in sld spec. (using the first will return all rules)
A live example is available at
http://test.ominiverdi.org:8080/geoserverSld/sldservice/topp:states (try
also with other layers)
I will add also the capabilities to generate rules based on
classification system
example:
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/quantileclassification/\{property\}/\{classNum\}
-> Rule list generated server side
(not yet added in the live example)
Later I wish to develop a javascript sld editor,
ables to work with a great number of rules and to create classified style.
Any comments and ideas are welcome!
Ciao kappu
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,47345498308313362379201!
Andrea Cappugi wrote:
Hi Carlos,
thanks for your support!
I think the main
thing I'd like to see in it is having set zoom levels that you can set
styles for, make a nice UI to tell which zooms you want your SLD apply to.
Chris if you mean the capabilities to define rules with max and min
scale denominator, is one of my first goals too.
Cool. I think there's a UI that could be really nice for it, I have some ideas but there not fully thought out. We have a good interaction designer that I can probably tap to help look at things.
The service looks great, the one thing I wonder about is how it should
play with the REST configuration stuff Arne and David are working on.
It should, I think that I'll just have to change the url mapping in
Wrappingcontroller class to integrate with RESTLETConfig
Yeah, the mechanics shouldn't be too hard, I'm just more thinking about the general rest interface for changing style information, as both let you do some, in different ways.
I have got problems trying to set up the wiki page.
http://docs.codehaus.org/display/GEOSDOC/Community
Doesn't respond.
Yeah, it just came up for me, but took like a minute. We really should probably move off of codehaus infrastructure, we have a few servers at TOPP, but I fear confluence is fairly resource intensive. Though I could be wrong.
Chris
Regs kappu
!DSPAM:4005,47361da5101247082231907!
Andrea Cappugi ha scritto:
Hi all,
I'm developing a restlet service to manage sld, I would like to share
with community (ideas and code).
The idea is to develop a geoserver community module ables to serve an
sld userStyle in a retfull way, (divided in multiple resource):
Example:
http://domain:8080/geoserver/sldservice/\{featureType\}
-> List of available styles in geoserver for a featuretype or coverage
name link to resource
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}
-> UserStyle: Name Title Abstract IsDefault List of FeatureTypeStyle
(only name, id and link to the resource)
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}
-> FeatureTypeStyle Name Title Abstract featureTypeName ruleslength
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/rules/
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/rules/\{fisrtRuleId\}/\{lastRuleID\}
-> Rule list: As in sld spec. (using the first will return all rules)
A live example is available at
http://test.ominiverdi.org:8080/geoserverSld/sldservice/topp:states (try
also with other layers)
I will add also the capabilities to generate rules based on
classification system
example:
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}/quantileclassification/\{property\}/\{classNum\}
-> Rule list generated server side
(not yet added in the live example)
Later I wish to develop a javascript sld editor,
ables to work with a great number of rules and to create classified style.
Any comments and ideas are welcome!
Hi Andrea,
first of all, sorry for the very very late answer.
The idea of serving SLD piece wise to a javascript client seems interesting, and the implementation you're proposing is ok. I see
a few issues thought:
* a client might want to grab a full subtree without having to
do 50 calls. If the SLD is big, there is a trade off between
the amount of data you can deal with in a javascrict client,
and the amount of network delay one has to pay for each call.
I'd suggest to stop the splitting at the rule level, and
to allow full download on the upper levels by using a parameter
(for example, &content=full)
* the idea of having services generate resources server side
seems fine, thought the url does not look right to me. Given
that you're calling an algorithm, the url should be something
like:
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}?quantileclassification&property=\{property\}&classNum=\{num\}
I'm also not sure about the type of method, but since it's
creating resources I guess it should be a POST
* the split does work well on the read side, but seems to
fall on the write side. When you create an SLD server side
it must be valid, not an incomplete document.
So I'd say writing wise:
* the creation of a new sld is a put or a post that specifies
a valid SLD
* each item can be modified using PUT
* new elements can be added dynamically using either POST or PUT,
but each time this occurs the element must be complete and valid
(think adding a rule or a feature type style)
What do you think?
Cheers
Andrea
Hi Andrea,
first of all, sorry for the very very late answer.
Hi Andrea,
I have to apologize too for my very very very late answer.
I'd suggest to stop the splitting at the rule level, and
to allow full download on the upper levels by using a parameter
(for example, &content=full)
I agree, but I think is better to avoid the use of parameters in restlet
We can find a different url mapping this request. Maybe we can return
all the content rules excluded at
-> http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}
* the idea of having services generate resources server side
seems fine, thought the url does not look right to me. Given
that you're calling an algorithm, the url should be something
like:
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}?quantileclassification&property=\{property\}&classNum=\{num\}
I'm also not sure about the type of method, but since it's
creating resources I guess it should be a POST
As before, I'm not a great expert of Rest but I think that in a Rest
architecture we have to avoid the use of parameters, but I'm not sure. 
* the split does work well on the read side, but seems to
fall on the write side. When you create an SLD server side
it must be valid, not an incomplete document.
is an SLD domcunmet without any rule a valide one?
Thanks for your comments
kappu
Andrea Cappugi ha scritto:
...
* the idea of having services generate resources server side
seems fine, thought the url does not look right to me. Given
that you're calling an algorithm, the url should be something
like:
http://domain:8080/geoserver/sldservice/\{featureType\}/\{UserStyleID\}/\{FeatureTypeStyleID\}?quantileclassification&property=\{property\}&classNum=\{num\}
I'm also not sure about the type of method, but since it's
creating resources I guess it should be a POST
As before, I'm not a great expert of Rest but I think that in a Rest
architecture we have to avoid the use of parameters, but I'm not sure.
That's not my understanding, you have to avoid them to
refer to resources, but you have to use them when calling algorithms
server side. Someone suggest its usage for format specification
too:
http://groups.google.com/group/geo-web-rest/browse_frm/thread/b75e831aaaedc7a3
Cheers
Andrea