[Geoserver-devel] Improving Python scripting process parameter declarations

Hi,
currently the Python scripting process lacks a bit behind the Java counterpart
in terms of what metadata can be provided for the process input parameters.
As far a I can see, the syntax only allows for type and description:

@process(
…,
inputs={ ‘geom’: (Geometry, ‘The geometry to buffer’),
‘distance’: (float,‘The buffer distance’)},
outputs={‘result’: (Geometry, ‘The buffered geometry’)}
)

I would like to add more to that, in particular, to get started,
whether the parameter is optional, an eventual default value,
and a list of valid values for that parameter, if any (for those
we’d use the Parameter.OPTIONS key, already in use in datastores
for lists with limited values).

Now, the current setup is positional, the above would add three new
possible elements to add, and more might come in the future (think
ways to describe collections for example).

In that light, I was wondering if for any extra parameter we could break
off the positional approach and use a key value pair approach instead.
Here is a possible example (just to get the discussion started, I’m
open to suggestions and might come up with more approaches later):

@process(
…,
inputs={ ‘geom’: (Geometry, ‘The geometry to buffer’),
‘distance’: (float,‘The buffer distance’),
‘capStyle’: (String, ‘The style of buffer endings’, {‘min’: 0, ‘default’: ‘round’, ‘options’ : ('‘round’, ‘flat’, ‘square’)})
‘quadrangSegments’: (integer, 'Number of segments , {‘min’: 0, ‘default’: 8})
},
outputs={‘result’: (Geometry, ‘The buffered geometry’)}
)

What do you think?

Cheers
Andrea

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


+1 on adding more metadata to the process descriptor. Some thoughts inline.

···

On Wed, May 21, 2014 at 6:27 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
currently the Python scripting process lacks a bit behind the Java counterpart
in terms of what metadata can be provided for the process input parameters.
As far a I can see, the syntax only allows for type and description:

@process(
…,
inputs={ ‘geom’: (Geometry, ‘The geometry to buffer’),
‘distance’: (float,‘The buffer distance’)},
outputs={‘result’: (Geometry, ‘The buffered geometry’)}
)

I would like to add more to that, in particular, to get started,
whether the parameter is optional, an eventual default value,
and a list of valid values for that parameter, if any (for those
we’d use the Parameter.OPTIONS key, already in use in datastores
for lists with limited values).

For default value I wonder if we can just use the normal python mechanism for parameters with a default value? The code that derives the java metadata from the script uses getargspec to analyze the function arguments, and I believe default value is available.

Now, the current setup is positional, the above would add three new
possible elements to add, and more might come in the future (think
ways to describe collections for example).

In that light, I was wondering if for any extra parameter we could break
off the positional approach and use a key value pair approach instead.
Here is a possible example (just to get the discussion started, I’m
open to suggestions and might come up with more approaches later):

@process(
…,
inputs={ ‘geom’: (Geometry, ‘The geometry to buffer’),
‘distance’: (float,‘The buffer distance’),
‘capStyle’: (String, ‘The style of buffer endings’, {‘min’: 0, ‘default’: ‘round’, ‘options’ : ('‘round’, ‘flat’, ‘square’)})
‘quadrangSegments’: (integer, 'Number of segments , {‘min’: 0, ‘default’: 8})
},
outputs={‘result’: (Geometry, ‘The buffered geometry’)}
)

Yup, makes sense to me.

What do you think?

Cheers
Andrea

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



“Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.”
http://p.sf.net/sfu/SauceLabs


Geoserver-devel mailing list
Geoserver-devel@anonymised.comt
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

If python is happy with key/value inputs and outputs it is a much more direct match to the WPS process model.

As for your current inputs, can you go with list or map:

inputs={ ‘geom’: (Geometry, ‘The geometry to buffer’),
‘distance’: (float,‘The buffer distance’),
‘capStyle’: {‘type’ : ‘String, ‘description:’: ‘The style of buffer endings’, ‘min’: 0, ‘default’: ‘round’, ‘options’ : (’‘round’, ‘flat’, ‘square’)}
‘quadrangSegments’: {‘type’ : integer, ‘description’:'Number of segments , ‘min’: 0, ‘default’: 8}
},

···

Jody Garnett

On Wed, May 21, 2014 at 8:27 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
currently the Python scripting process lacks a bit behind the Java counterpart
in terms of what metadata can be provided for the process input parameters.
As far a I can see, the syntax only allows for type and description:

@process(
…,
inputs={ ‘geom’: (Geometry, ‘The geometry to buffer’),
‘distance’: (float,‘The buffer distance’)},
outputs={‘result’: (Geometry, ‘The buffered geometry’)}
)

I would like to add more to that, in particular, to get started,
whether the parameter is optional, an eventual default value,
and a list of valid values for that parameter, if any (for those
we’d use the Parameter.OPTIONS key, already in use in datastores
for lists with limited values).

Now, the current setup is positional, the above would add three new
possible elements to add, and more might come in the future (think
ways to describe collections for example).

In that light, I was wondering if for any extra parameter we could break
off the positional approach and use a key value pair approach instead.
Here is a possible example (just to get the discussion started, I’m
open to suggestions and might come up with more approaches later):

@process(
…,
inputs={ ‘geom’: (Geometry, ‘The geometry to buffer’),
‘distance’: (float,‘The buffer distance’),
‘capStyle’: (String, ‘The style of buffer endings’, {‘min’: 0, ‘default’: ‘round’, ‘options’ : ('‘round’, ‘flat’, ‘square’)})
‘quadrangSegments’: (integer, 'Number of segments , {‘min’: 0, ‘default’: 8})
},
outputs={‘result’: (Geometry, ‘The buffered geometry’)}
)

What do you think?

Cheers
Andrea

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



“Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.”
http://p.sf.net/sfu/SauceLabs


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

We’re already working with a solution „abusing“ the scripting extension a bit which allows us to specify and validate already more advanced input scenarios. Of course we also use JSON to define our processes and stumbled upon JSON-Schema. This is widely supported and provides standardized schemas to provide additional process parameters as suggested. We use JSON schema to validate our input before starting the processing and cancel processes if we detect wrong WPS input. That might be also a good idea for improving the Scripting extension!?

Software for validating JSON-Schema: http://json-schema.org/implementations.html

Naming conventions for additional options like default, min, max values or optional lists: http://json-schema.org/latest/json-schema-validation.html

···

In that light, I was wondering if for any extra parameter we could break

off the positional approach and use a key value pair approach instead.

Here is a possible example (just to get the discussion started, I’m

open to suggestions and might come up with more approaches later):

@process(

…,

inputs={ ‘geom’: (Geometry, ‘The geometry to buffer’),

‘distance’: (float,‘The buffer distance’),

‘capStyle’: (String, ‘The style of buffer endings’, {‘min’: 0, ‘default’: ‘round’, ‘options’ : ('‘round’, ‘flat’, ‘square’)})

‘quadrangSegments’: (integer, 'Number of segments , {‘min’: 0, ‘default’: 8})

},

outputs={‘result’: (Geometry, ‘The buffered geometry’)}

)

What do you think?

On Wed, May 21, 2014 at 4:03 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

@process(

   ...,
   inputs={ 'geom': (Geometry, 'The geometry to buffer'),
                'distance': (float,'The buffer distance'),
                'capStyle': (String, 'The style of buffer endings',
{'min': 0, 'default': 'round', 'options' : (''round', 'flat', 'square')})
                'quadrangSegments': (integer, 'Number of segments ,
{'min': 0, 'default': 8})
             },
   outputs={'result': (Geometry, 'The buffered geometry')}
)

Yup, makes sense to me.

Ah, thinking about naming, would 'enum' sound better than 'options' ?

Also, following Jody's suggestion, would it be better to allow a full
dictionary stile, for also type and description,
also use the tuple style for backwards compatibility?
The one thing that annoys me about that is that one might start with the
tuple start for convenience, and if
any option needs to be added, the construct has to be turned from tuple to
dictionary...

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

On Wed, May 21, 2014 at 10:15 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

On Wed, May 21, 2014 at 4:03 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

@process(

   ...,
   inputs={ 'geom': (Geometry, 'The geometry to buffer'),
                'distance': (float,'The buffer distance'),
                'capStyle': (String, 'The style of buffer endings',
{'min': 0, 'default': 'round', 'options' : (''round', 'flat', 'square')})
                'quadrangSegments': (integer, 'Number of segments ,
{'min': 0, 'default': 8})
             },
   outputs={'result': (Geometry, 'The buffered geometry')}
)

Yup, makes sense to me.

Ah, thinking about naming, would 'enum' sound better than 'options' ?

Hmmm... how about "values" ? Or getting more functional we could go wish
something like "domain".

Also, following Jody's suggestion, would it be better to allow a full
dictionary stile, for also type and description,
also use the tuple style for backwards compatibility?
The one thing that annoys me about that is that one might start with the
tuple start for convenience, and if
any option needs to be added, the construct has to be turned from tuple to
dictionary...

Yeah, I would leave it as is, allowing for both is starting to get to "too
many ways to do it" imo. Also, the tuple style enforces the fact that title
and description are mandatory which i like. Actually I think description
might be optional but we could make it mandatory.

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive&gt;

On Thu, May 22, 2014 at 3:42 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Ah, thinking about naming, would 'enum' sound better than 'options' ?

Hmmm... how about "values" ? Or getting more functional we could go wish
something like "domain".

Domain sounds better to me, but it's just a slight preference.

Also, following Jody's suggestion, would it be better to allow a full
dictionary stile, for also type and description,
also use the tuple style for backwards compatibility?
The one thing that annoys me about that is that one might start with the
tuple start for convenience, and if
any option needs to be added, the construct has to be turned from tuple
to dictionary...

Yeah, I would leave it as is, allowing for both is starting to get to "too
many ways to do it" imo. Also, the tuple style enforces the fact that title
and description are mandatory which i like. Actually I think description
might be optional but we could make it mandatory.

Roger, I'll follow the "dictonary in tuple style". If the description is
optional, I'll check if there are 2 or 3 params, and if 2, check if the
second is a string or a dictionary.

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

On Thu, May 22, 2014 at 10:29 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

On Thu, May 22, 2014 at 3:42 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Ah, thinking about naming, would 'enum' sound better than 'options' ?

Hmmm... how about "values" ? Or getting more functional we could go wish
something like "domain".

Domain sounds better to me, but it's just a slight preference.

Works for me.

Also, following Jody's suggestion, would it be better to allow a full
dictionary stile, for also type and description,
also use the tuple style for backwards compatibility?
The one thing that annoys me about that is that one might start with the
tuple start for convenience, and if
any option needs to be added, the construct has to be turned from tuple
to dictionary...

Yeah, I would leave it as is, allowing for both is starting to get to
"too many ways to do it" imo. Also, the tuple style enforces the fact that
title and description are mandatory which i like. Actually I think
description might be optional but we could make it mandatory.

Roger, I'll follow the "dictonary in tuple style". If the description is
optional, I'll check if there are 2 or 3 params, and if 2, check if the
second is a string or a dictionary.

Awesome. Thanks for the work!

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive&gt;

On Fri, May 23, 2014 at 6:37 AM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Roger, I'll follow the "dictonary in tuple style". If the description is

optional, I'll check if there are 2 or 3 params, and if 2, check if the
second is a string or a dictionary.

Awesome. Thanks for the work!

Here we go: https://github.com/geoserver/geoserver/pull/594
How does it look?

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Hi,
by the way, Jody on geotools-devel asked if the java annotations could use “options”
for the domain values.
Shall we keep python bindings consistent and call it options there too, or have
them live their separate life and confirm using domain?

Cheers
Andrea

···

On Fri, May 23, 2014 at 4:36 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


On Fri, May 23, 2014 at 6:37 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Here we go: https://github.com/geoserver/geoserver/pull/594
How does it look?

Cheers

Andrea

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


Awesome. Thanks for the work!

Roger, I’ll follow the “dictonary in tuple style”. If the description is optional, I’ll check if there are 2 or 3 params, and if 2, check if the second is a string or a dictionary.

You’re call, I think domain is a better name but if it makes life simpler to name it the same as the geotools equivalent I am fine with that too, don’t have too strong an opinion.

···

On Sun, May 25, 2014 at 1:09 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
by the way, Jody on geotools-devel asked if the java annotations could use “options”
for the domain values.
Shall we keep python bindings consistent and call it options there too, or have
them live their separate life and confirm using domain?

Cheers

Andrea

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

On Fri, May 23, 2014 at 4:36 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


On Fri, May 23, 2014 at 6:37 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Here we go: https://github.com/geoserver/geoserver/pull/594
How does it look?

Cheers

Andrea

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


Awesome. Thanks for the work!

Roger, I’ll follow the “dictonary in tuple style”. If the description is optional, I’ll check if there are 2 or 3 params, and if 2, check if the second is a string or a dictionary.