Hi Alessio,
thanks for the useful feedback. Notes inline.
On Thu, Jul 12, 2018 at 12:30 PM, Alessio Fabiani <
alessio.fabi...@geo-solutions.it> wrote:
>
> *Executions List*
> At a first glance I was thinking to the possibility of having some
> "public" executions, somehow, but digging a bit more on the proposal this
> does not make much sense.
>
> The new operation should return only the list of available Executions the
> logged in user has started, except in the case it is an Administrator. In
> that case he will be able to get the whole list.
>
Yep, makes sense.
>
> *StatusInfo Response*
> Yes, roughly it should return what we see on the GUI, possibly with a bit
> more information (when/if available) as detailed in the table below
>
> *NamesDefinitionData type and valuesMultiplicity and useJobIDUnambiguously
> identifier of a execution job within a WPS instance.Character String aOne
> (mandatory)IdentifierUnambiguously identifier of a process within a WPS
> instance.ows:IdentifierOne (mandatory)StatusWell-known identifier
> describing the status of the job.Character String bOne
> (mandatory)ExpirationDateDate and time by which the job and its results
> will be no longer accessible. cISO-8601 date/time string in the form
> YYYY-MM-DDTHH:MM:SS.SSSZ with T separator character and Z suffix for
> coordinated universal time (UTC)Zero or one (optional) Include if
> available.EstimatedCompletionDate and time by which the processing job will
> be finished.ISO-8601 date/time string in the form YYYY-MM-DDTHH:MM:SS.SSSZ
> with T separator character and Z suffix for coordinated universal time
> (UTC)Zero or one (optional) Include if available.NextPollDate and time for
> the next suggested status polling.ISO-8601 date/time string in the form
> YYYY-MM-DDTHH:MM:SS.SSSZ with T separator character and Z suffix for
> coordinated universal time (UTC)Zero or one (optional) Include if
> available.PercentCompletedPercentage of process that has been
> completed.Integer{0..100} dZero or one (optional) Include if available.a)
> Particularly suitable JobIDs are UUIDs or monotonic identifiers such as
> unique timestamps. If the privacy of a Processing Job is imperative, the
> JobID should be non-guessable.b) The basic status set is defined in
> http://docs.opengeospatial.org/is/14-065/14-065.html
> <http://docs.opengeospatial.org/is/14-065/14-065.html> Table 3. Additional
> states may be defined by certain operations or extensions of this
> standard.c) This element will usually become available when the execution
> has finished (Status = “finished”). d) Zero (0) means the execution has
> just started, and 100 means the job is complete. This value is informative
> only without any accuracy guarantees.*
>
How will you guess the estimated completion? Elapsed time vs percentage
complete?
In general GeoServer has a hard time with the percentage complete
calculation, as the overall process execution
goes through 3 phases:
- Parsing the inputs and turning them into Java classes suitable for
process consumption. This part is given a fixed percentage. If all the
inputs are simple (string, number, dates) the % is small, if the inputs are
complexes (have to be parsed and may be large or retrieved from remote) I
think it's something like 30%, but you'd have to check in the code.
- Actual execution, consuming java objects and producing other java
objects. This is all over the place, some processes are streaming and give
you back a GridCoverage2D backed by a deferred execution or a
FeatureCollection that will compute the results when traversed (both to
avoid storing a ton of memory), others have no progress support at all,
only a subset are actually doing the computation during execute and with
reasonable progress support.
- Result encoding. This is similar to input parsing, if the result is
complex the final encoding is given a large-ish percentage of the overall
time, also considering that the real execution might happen here as we
scroll over the feature collection or encode the grid coverage into a tiff.
I believe you're mostly interested in RawInput/RawOutput, not sure how well
they are handled by the above "guessing" machinery, I'd suggest to have a
look.
>
>
> *GetExecutions Request*
> In order to filter and refine the Request, I was wondering about a set of
> simple Request parameters as depicted in the diagram below
>
> [image: image.png]
>
> which are better detailed in the table here below
>
>
>
>
>
> *NamesDefinitionData type and valuesMultiplicity and useOwnerUnambiguous
> identifier of a user within a WPS instance.Filters out all the jobs not
> anonymous or not belonging to the specified user.Character String aZero or
> one (optional).IdentifierUnambiguous identifier of a process within a WPS
> instance.Filters out all the jobs not belonging to the specified process
> identifier.ows:Identifier Value shall be one of the process identifiers
> listed in the ProcessSummary elements in the Capabilities document.Zero or
> one (optional).StatusWell-known identifier describing the status of the
> job.Filters out all the jobs with an Execution Status different from the
> one specified.String{PENDING, RUNNING, FAILED, CANCELED, FINISHED} bZero or
> one (optional).OrderByOne of the OWNER, IDENTIFIER, STATUS.The Response
> Document will be ordered accordingly to the value specified. If not value
> has been specified, the list of Processed will be ordered by Identifier and
> ExecutionDate.String{OWNER, IDENTIFIER, STATUS}Zero or one (optional).a) It
> must match one of the usernames available on the Server, if any available.
> GetStatusesListResponse contents may vary accordingly to security
> constraints.b) The basic status set is defined in
> http://docs.opengeospatial.org/is/14-065/14-065.html
> <http://docs.opengeospatial.org/is/14-065/14-065.html> Table 3. Additional
> states may be defined by certain operations or extensions of this standard.*
>
Makes sense yes.
Cheers
Andrea
==
GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information. == Ing. Andrea Aime @geowolf Technical Lead
GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39
0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
http://www.geo-solutions.it http://twitter.com/geosolutions_it
------------------------------------------------------- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this
list:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html
If you want to request a feature or an improvement, also see this:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
