Hi all,
Something I have been inching toward slowly in spare time as of late is a python scripting extension for GeoServer. I think it is a point now where it can be added as a community module.
I wrote up some notes about it on the wiki:
http://geoserver.org/display/GEOS/Python+Scripting+Extension
It is very similar in nature to the scriptlet extension David has been working on.
So if i can get a +1 from the PSC I will gladly add the module.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Hi all,
Something I have been inching toward slowly in spare time as of late is a python scripting extension for GeoServer. I think it is a point now where it can be added as a community module.
I wrote up some notes about it on the wiki:
http://geoserver.org/display/GEOS/Python+Scripting+Extension
It is very similar in nature to the scriptlet extension David has been working on.
So if i can get a +1 from the PSC I will gladly add the module.
+1e(Integer.MAXINT)!!!!
Now, with this, can we:
- add a new output format
- add a transaction listeners
- add a dispatcher callback
- add a WPS process
- add a datastore
- a restful endpoint
- and so on?
What about David's one, which afaik is based on Javascript?
What are the capabilities of each?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 2/15/10 11:32 AM, Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi all,
Something I have been inching toward slowly in spare time as of late
is a python scripting extension for GeoServer. I think it is a point
now where it can be added as a community module.
I wrote up some notes about it on the wiki:
http://geoserver.org/display/GEOS/Python+Scripting+Extension
It is very similar in nature to the scriptlet extension David has been
working on.
So if i can get a +1 from the PSC I will gladly add the module.
+1e(Integer.MAXINT)!!!!
Cool!
Now, with this, can we:
As of now:
- add a new output format
No
- add a transaction listeners
No
- add a dispatcher callback
No
- add a WPS process
No
- add a datastore
Yes
- a restful endpoint
Yes
- and so on?
As you can see as of now it is quite limited. But with some time I hope to handle these use cases. I will throw them on the wiki page as to not lose them.
What about David's one, which afaik is based on Javascript?
What are the capabilities of each?
I will let David chime in on this one.
-Justin
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
As you can see as of now it is quite limited. But with some time I hope to handle these use cases. I will throw them on the wiki page as to not lose them.
Add the ability to create filter functions as well, should be quite
handy. Now that we're documenting them I see more people being interesting in rolling a custom one for label formatting, custom
color choosing, or custom geometry transforming
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 02/15/2010 11:32 AM, Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi all,
Something I have been inching toward slowly in spare time as of late is
a python scripting extension for GeoServer. I think it is a point now
where it can be added as a community module.
I wrote up some notes about it on the wiki:
http://geoserver.org/display/GEOS/Python+Scripting+Extension
It is very similar in nature to the scriptlet extension David has been
working on.
So if i can get a +1 from the PSC I will gladly add the module.
+1e(Integer.MAXINT)!!!!
For JavaScript:
Now, with this, can we:
- add a new output format
no
- add a transaction listeners
no
- add a dispatcher callback
no
- add a WPS process
yes
- add a datastore
- a restful endpoint
yes
- and so on?
What about David's one, which afaik is based on Javascript?
What are the capabilities of each?
Cheers
Andrea
-d
PS: It would probably be a good idea to redo both extensions in terms of JSR 223, merge them, and let both Jython and Rhino take advantage of the integration work.
http://jcp.org/aboutJava/communityprocess/pr/jsr223/
On 02/16/2010 09:41 AM, Andrea Aime wrote:
Justin Deoliveira ha scritto:
As you can see as of now it is quite limited. But with some time I hope
to handle these use cases. I will throw them on the wiki page as to not
lose them.
Add the ability to create filter functions as well, should be quite
handy. Now that we're documenting them I see more people being
interesting in rolling a custom one for label formatting, custom
color choosing, or custom geometry transforming
Cheers
Andrea
I've looked into doing this in javascript and was thwarted by the SPI lookup of filter functions. Although, I suppose we could just have a filter function that calls a script:
<Function name="call_a_script">
<Literal>relative/path/to/filterfunc.js</Literal>
<Literal>arg0</Literal>
</Function>
I haven't looked into the GeoTools machinery to see what would be involved, but redoing the filter functions to use a factory lookup like that used in WPS would be nice for situations like this.
--
David Winslow
OpenGeo - http://opengeo.org/
On 2/16/10 11:02 AM, David Winslow wrote:
On 02/16/2010 09:41 AM, Andrea Aime wrote:
Justin Deoliveira ha scritto:
As you can see as of now it is quite limited. But with some time I hope
to handle these use cases. I will throw them on the wiki page as to not
lose them.
Add the ability to create filter functions as well, should be quite
handy. Now that we're documenting them I see more people being
interesting in rolling a custom one for label formatting, custom
color choosing, or custom geometry transforming
Cheers
Andrea
I've looked into doing this in javascript and was thwarted by the SPI
lookup of filter functions. Although, I suppose we could just have a
filter function that calls a script:
<Function name="call_a_script">
<Literal>relative/path/to/filterfunc.js</Literal>
<Literal>arg0</Literal>
</Function>
I haven't looked into the GeoTools machinery to see what would be
involved, but redoing the filter functions to use a factory lookup like
that used in WPS would be nice for situations like this.
It is undoubtedly the same issue I had with jython and class loaders. the GeoTools SPI lookup makes some assumptions about class loader structure which jython had some issues with in terms of dynamically loading classes.
But that said I have no idea if it is the same issue as I am not sure how Rhino does its thing.
--
David Winslow
OpenGeo - http://opengeo.org/
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On 02/16/2010 11:07 AM, Justin Deoliveira wrote:
On 2/16/10 11:02 AM, David Winslow wrote:
On 02/16/2010 09:41 AM, Andrea Aime wrote:
Justin Deoliveira ha scritto:
As you can see as of now it is quite limited. But with some time I hope
to handle these use cases. I will throw them on the wiki page as to not
lose them.
Add the ability to create filter functions as well, should be quite
handy. Now that we're documenting them I see more people being
interesting in rolling a custom one for label formatting, custom
color choosing, or custom geometry transforming
Cheers
Andrea
I've looked into doing this in javascript and was thwarted by the SPI
lookup of filter functions. Although, I suppose we could just have a
filter function that calls a script:
<Function name="call_a_script">
<Literal>relative/path/to/filterfunc.js</Literal>
<Literal>arg0</Literal>
</Function>
I haven't looked into the GeoTools machinery to see what would be
involved, but redoing the filter functions to use a factory lookup like
that used in WPS would be nice for situations like this.
It is undoubtedly the same issue I had with jython and class loaders. the GeoTools SPI lookup makes some assumptions about class loader structure which jython had some issues with in terms of dynamically loading classes.
But that said I have no idea if it is the same issue as I am not sure how Rhino does its thing.
--
David Winslow
OpenGeo - http://opengeo.org/
Well, JavaScript the language does not have a concept of classes, so basically the way to extend Java classes in Rhino is to instantiate anonymous subclasses (plus, the parent class must have a zero-argument constructor if it is not an interface!). These don't have class names (well, I guess they must at runtime, but I doubt those are reliably consistent.) So in order to instantiate a datastore (or whatever) defined in JavaScript, you would basically need to execute the script for each instantiation. To my knowledge, Jython works similarly in that subclasses defined in Python don't exist until the script has run, although they are actually named subclasses.
So basically, implementing filter functions/datastores/processes in JavaScript would require the ability to *run scripts* when filter functions/datastores/processes are looked up. For datastores, an appropriate factory could be written, and for processes it already has, but since filters are just looked up by classname I don't see a way around it, other than the 'run a script' function I mentioned above.
--
David Winslow
OpenGeo - http://opengeo.org/
David Winslow wrote:
I've looked into doing this in javascript and was thwarted by the SPI lookup of filter functions. Although, I suppose we could just have a filter function that calls a script:
<Function name="call_a_script">
<Literal>relative/path/to/filterfunc.js</Literal>
<Literal>arg0</Literal>
</Function>
I haven't looked into the GeoTools machinery to see what would be involved, but redoing the filter functions to use a factory lookup like that used in WPS would be nice for situations like this.
They are actually using a factory lookup. See FunctionFinder in Geotools.
Isn't it the same as processes? Hum... maybe not, processes have
a factory that can actually generate multiple process instances,
whilst in the case of functions the function is created directly,
no factories involved.
If you don't have the concept of a class in Javascript that will
indeed become a roadblock...
Cheers
Andrea