[Zoo-discuss] ZOO-Project version 2.0.0 has been released
Dear community, as the release manager, I am happy to announce that the release of the ZOO-Project version 2.0.0 is available online [1]. Thanks everyone for your contributions to the project and its enhancement! If you'd like to cite this release in your research article, refer to the DOI associated with the release [2]. This new release contains new features and fixes listed below. * Update the remote process support to enable multi-valued processes. * Add option to output log on stderr rather than a dedicated file. * Update relation type to monitor for the status location. * Add support for the conformance class remote processes from the OGC API - Processes - Part 3: Workflow & chaining. Execution of remote processes are automatically run asynchronously in case the root process was invoked asynchronously. * Parse the Location header from ulinet and the cookie if any. * Add schemas to the components and support description stored in the file. * Add a trivial DeployOnHpc service for automating the installation and the deployment of a singularity container using the image parameter provided in the executionUnit used when deploying the process. * Set the key json_response_object with the JSON response that the ZOO-Kernel produced for the request, it can be updated from a filter_out process. * Update filter_in to support returning a response directly by adding a response key in the lenv section (binary is supported for this response) * Provide an initial Dockefile dedicated to the DRU support with remote HPC execution support * Add a USE_HPC_NESTEDOUTPUTS build option to activate the nested inputs and outputs addition (not supported with OGC API - Processes - Part 1: Core) * Update C-API errorException and printExceptionResponse* signatures to handle the main configuration maps memory properly * Build Docker image with DRU supporting OpenEO UDP encoding * Add support for deploying and executing OpenEO User Defined Processes by using an OpenEO graph for the executionUnit * Add support for schema type string for request body, providing a way to include CWL example files in the published OpenAPI * Integrate the OGC API - Processes - Part 2: Deploy, Replace, Undeploy optional support. * Build Docker image based on MDL4EO/OTBTF and the onnx runtime for models sharing * Integrate the TeamEngine and ETS for OGC API - Processes * Add JWT parser in security_service.py as filter_in to allocate resources per authenticated user * Integrate the work done during GSoC 2022 to support Node.js ZOO-Services (cf. updated documentation for NodeJS) * Update support to filter the jobs list using the user_id * Add support for nested processes n OGC API - Processes - Part 3: Workflows & Chaining * Add filter_in and filter_out service array to be invoked previously of and after the service run * Add trivial support for OpenAPI security, basicAuth / openId, and add sample services implementation * Add support for MapServer 8.0 (actually 7.7-dev), including returning result as OGC API -Features * Integrate downloading MapServer 8.0 and building from the dedicated Dockerfile-MS8 * Include basicAuth build instructions in the Dockefile * Add basicAuth service illustrating how to secure access to OGC API - Processes using Basic Authentication * Use the osecurity section to detect secured path, request method from the published OpenAPI * Update the printHeaders function to allow Status definition at runtime * Add a [osecurity] section to secure access to path, method couple from the published OpenAPI * Update the database connection handling to make it independent from instantiation order * Use the RabbitMQ also for OGC API - Processes * Pass the subscriber if any is passed from the original request * Make C OGR base-vect-ops compatible with memory=protect * Add volumes to be shared by the ZOO-Kernel and the ZOO-FPM * Add a RabbitMQ and a ZOO-FPM container to docker-compose * Add documentation for RabbitMQ support and ZOO Fast Process Manager (ZOO-FPM) * Optional use of ZOO-Kernel Fast Process Manager backends to handle asynchronous execution * Partial integration of the code from the Publicamundi_David_integration01-devel branch We appreciate and welcome any feedback. Best regards, [1] https://github.com/ZOO-Project/ZOO-Project/releases/tag/rel-2.0.0 [2] https://zenodo.org/badge/latestdoi/353351321 Gerald Fenoy gerald.fe...@geolabs.fr Chair, ZOO-Project PSC ___ ZOO-discuss mailing list ZOO-discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/zoo-discuss
[Zoo-discuss] ZOO-Project 2.0.0-rc2 now available!
Dear community, As the current release manager, I announce that the latest release of ZOO-Project, version 2.0.0 release candidate 2, has been made available! [1] Modifications compared to release candidate 1 are the following: * Update the remote process support to enable multi-valued processes. * Add configure option to output log on stderr rather than a dedicated file. We will wait for one more week to have the final 2.0.0 release. Best regards, [1] https://github.com/ZOO-Project/ZOO-Project/releases/tag/rel-2.0.0-rc2 Gerald Fenoy gerald.fe...@geolabs.fr Chair, ZOO-Project PSC ___ ZOO-discuss mailing list ZOO-discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/zoo-discuss
[Zoo-discuss] ZOO-Project 2.0.0-rc1 has been released!
Dear community, As the current release manager, I announce the ZOO-Project version 2.0.0 release candidate 1. The release contains new features and fixes listed below. The ZOO-Project has been accepted as part of the Docker-Sponsored Open Source Program [1]. You can now find various Docker images with different flavors on DockerHub [2] under the ZOO-Project organization [3]. This release introduces the support for OGC API - Processes - Part 2: Deploy, Replace, Undeploy draft specification [4] (DRU). You may be interested in the ZOO-Project-DRU Helm Chart [5] published in a dedicated GitHub repository: ZOO-Project/charts [6] for deploying the solution with the DRU and CWL support on Kubernetes. The EOEPCA project [7] supported the development of the DRU with CWL. The ZOO-Project's HPC support has been updated to enable the *deployment* and execution of Singularity containers on remote HPC. The following Engineering Report [8] documents the implementation resulting from the Testbed19 HPGC activity. The ZOO-Project provides a dedicated Docker image named MDL4EO [9] with OTBTF [10] support (the original OTBTF Docker image [11] has proven to be working with the HPC support). New Features and Fixes: * Update relation type to monitor for the status location. * Add support for the conformance class remote processes from the OGC API - Processes - Part 3: Workflow & chaining. Execution of remote processes are automatically run asynchronously in case the root process was invoked asynchronously. * Parse the Location header from ulinet and the cookie if any. * Add schemas to the components and support description stored in the file. * Add a trivial DeployOnHpc service for automating the installation and the deployment of a singularity container using the image parameter provided in the executionUnit used when deploying the process. * Set the key json_response_object with the JSON response that the ZOO-Kernel produced for the request, it can be updated from a filter_out process. * Update filter_in to support returning a response directly by adding a response key in the lenv section (binary is supported for this response) * Provide an initial Dockefile dedicated to the DRU support with remote HPC execution support * Add a USE_HPC_NESTEDOUTPUTS build option to activate the nested inputs and outputs addition (not supported with OGC API - Processes - Part 1: Core) * Update C-API errorException and printExceptionResponse* signatures to handle the main configuration maps memory properly * Build Docker image with DRU supporting OpenEO UDP encoding * Add support for deploying and executing OpenEO User Defined Processes by using an OpenEO graph for the executionUnit * Add support for schema type string for request body, providing a way to include CWL example files in the published OpenAPI * Integrate the OGC API - Processes - Part 2: Deploy, Replace, Undeploy optional support. * Build Docker image based on MDL4EO/OTBTF and the onnx runtime for models sharing * Integrate the TeamEngine and ETS for OGC API - Processes * Add JWT parser in security_service.py as filter_in to allocate resources per authenticated user * Integrate the work done during GSoC 2022 to support Node.js ZOO-Services (cf. updated documentation for NodeJS) * Update support to filter the jobs list using the user_id * Add support for nested processes n OGC API - Processes - Part 3: Workflows & Chaining * Add filter_in and filter_out service array to be invoked previously of and after the service run * Add trivial support for OpenAPI security, basicAuth / openId, and add sample services implementation * Add support for MapServer 8.0 (actually 7.7-dev), including returning result as OGC API -Features * Integrate downloading MapServer 8.0 and building from the dedicated Dockerfile-MS8 * Include basicAuth build instructions in the Dockefile * Add basicAuth service illustrating how to secure access to OGC API - Processes using Basic Authentication * Use the osecurity section to detect secured path, request method from the published OpenAPI * Update the printHeaders function to allow Status definition at runtime * Add a [osecurity] section to secure access to path, method couple from the published OpenAPI * Update the database connection handling to make it independent from instantiation order * Use the RabbitMQ also for OGC API - Processes * Pass the subscriber if any is passed from the original request * Make C OGR base-vect-ops compatible with memory=protect * Add volumes to be shared by the ZOO-Kernel and the ZOO-FPM * Add a RabbitMQ and a ZOO-FPM container to docker-compose * Add documentation for RabbitMQ support and ZOO Fast Process Manager (ZOO-FPM) * Optional use of ZOO-Kernel Fast Process Manager backends to handle asynchronous execution * Partial integration of the code from the
[Zoo-discuss] ZOO-Project has graduated
Dear all, It is a great pleasure for me to come to you today to announce a great achievement for the ZOO-Project. With the OSGeo board approval, the ZOO-Project is now officially an OSGeo Project. I would like to thanks the PSC members for their active support during the incubation period and their patience. We would also like to thank the community for their support all over the years. We invite everyone in the community to update the documentation were needed and push the information about incubation status on different communication channels to celebrate this great achievement. We hope that everyone can celebrate this great event. Best regards, Gerald Fenoy Chair, ZOO-Project PSC ___ ZOO-discuss mailing list ZOO-discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/zoo-discuss
[Zoo-discuss] OGC-OSGeo-ASF Code Sprint 2023 report
Dear all, You can find here: [1] the report about my participation in the OGC-OSGeo-ASF Code Sprint in Lausanne from April 25th to 27th. Any feedbacks, remarks, or requests for modification are welcome. I hope you enjoy the read. Best regards, [1] https://github.com/ZOO-Project/ZOO-Project/wiki/OGC-ASF-OSGeo_Code_Sprint_Report Gerald Fenoy Chair, ZOO-Project PSC ___ ZOO-discuss mailing list ZOO-discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/zoo-discuss
[Zoo-discuss] Fwd: [ZOO-Discuss] ZOO-Project Developper call for agreement
Hi all, This is simply a copy of a very old email 2013 where contributors agreed on the commuter guidelines. I cannot found it on the list archive. Best regards, Gerald Fenoy Chair, ZOO-Project PSC > Début du message réexpédié : > > De: "Clarke, Trevor" > Objet: Rép. : [ZOO-Discuss] ZOO-Project Developper call for agreement > Date: 2 juillet 2013 à 16:51:50 UTC+2 > À: > > Accepted and agreed. > > -- > Trevor R.H. Clarke > Software Engineer, Ball Aerospace > (937)320-7087 > > >> -Original Message- >> From: Fenoy Gérald [mailto:gfe...@gmail.com] >> Sent: Tuesday, July 02, 2013 8:51 AM >> To: Angelos Tzotsos; Clarke, Trevor; David Saggiorato; Jeff McKenna; Luca >> Delucchi; Markus Neteler; Ren√(c)-Luc D'Hont; marco.negre...@polimi.it >> Subject: ZOO-Project Developper call for agreement >> >> Dear ZOO-Project commiters, >> I would like to ask you to send a short email on the ZOO-Discuss mailing list >> saying that you reviewed and agreed on the ZOO-Project Commiter >> Guidelines available at [1]. >> >> I wish to get your confirmation as soon as possible as I would like to >> release >> rc2 quickly and it will depend on your confirmation. >> >> Hope to hear back from you, >> Best regards, >> >> Gérald Fenoy >> ZOO-Project Developper >> >> [1] http://zoo-project.org/docs/community/developper.html > > > > This message and any enclosures are intended only for the addressee. Please > notify the sender by email if you are not the intended recipient. If you are > not the intended recipient, you may not use, copy, disclose, or distribute > this > message or its contents or enclosures to any other person and any such > actions > may be unlawful. Ball reserves the right to monitor and review all messages > and enclosures sent to or from this email address. > ___ > Zoo-discuss mailing list > zoo-disc...@gisws.media.osaka-cu.ac.jp > http://gisws.media.osaka-cu.ac.jp/mailman/listinfo.cgi/zoo-discuss ___ ZOO-discuss mailing list ZOO-discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/zoo-discuss
[Zoo-discuss] Fwd: [ZOO-Discuss] ZOO-Project Developper call for agreement
Hi all, This is again a copy of a very old email 2013 where contributors agreed on the commuter guidelines. I cannot found it on the list archive. Best regards, Gerald Fenoy Chair, ZOO-Project PSC > Début du message réexpédié : > > De: David Saggiorato > Objet: Rép. : [ZOO-Discuss] ZOO-Project Developper call for agreement > Date: 2 juillet 2013 à 16:58:56 UTC+2 > À: zoo-disc...@gisws.media.osaka-cu.ac.jp > > Accepted and agreed. > > > David Saggiorato - CLEOLYS SARL - Tel: 0678983530 > > > > > Le 2 juil. 2013 à 14:50, Fenoy Gérald a écrit : > >> Dear ZOO-Project commiters, >> I would like to ask you to send a short email on the ZOO-Discuss mailing >> list saying that you reviewed and agreed on the ZOO-Project Commiter >> Guidelines available at [1]. >> >> I wish to get your confirmation as soon as possible as I would like to >> release rc2 quickly and it will depend on your confirmation. >> >> Hope to hear back from you, >> Best regards, >> >> Gérald Fenoy >> ZOO-Project Developper >> >> [1] http://zoo-project.org/docs/community/developper.html >> > > ___ > Zoo-discuss mailing list > zoo-disc...@gisws.media.osaka-cu.ac.jp > http://gisws.media.osaka-cu.ac.jp/mailman/listinfo.cgi/zoo-discuss ___ ZOO-discuss mailing list ZOO-discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/zoo-discuss
[Zoo-discuss] 2022 OGC-OSGeo-ASF Code Sprint report
Hello everyone, I am glad to provide a short report about the ZOO-Proect participation during this year OGC-OSGeo-ASF Code Sprint. Number of people from various organisations including the OGC, the OSGeo and the ASF gathered during three days, from March 8th to 10th 2022, to make a joint effort in exploring and investigating the various standards available. On the ZOO-Project specific side, as you already know, we had published an ideas page [1] for this code sprint. As always, we had many goals but we cannot get all of them accomplished only some, some partially, and for some in which we have made big progresses in, we realized that it may have been a wrong way to go. Anyway, let start with the bright side. First of all, the first idea [2] has been partially implemented. Meaning that asynchronous requests are now effectively using RabbitMQ if there is any available. The last point, which is considering the use of such a mechanism in case of synchronous request, we evaluated that the current implementation would require significant modifications and refactoring for handling synchronous request as asynchronous per default. In addition, it would add new steps in the processing implying the run to take longer that it does now. On the other hand, it would add advantages amongst which, we can mention the ability to be able to return a statusInfo of the service in case the execution take longer than a predefined threshold that we may add to the main.cfg or the client would be able to send within a dedicated header parameter associated with the request. This has been discussed in the OGC API - Processes SWG already and this would be a way for us to support this new functionality in case it become a requirement. The second idea [3] in the list was also considered during the code sprint period, and I would like to personally thanks Blasco Brauzzi for joining the Code Sprint and helping us in various way. First of all, he did help me for setting up properly on my platform the ADES software and get it working properly until the stage-out phase which was the one on which we get blocked. But once the min.io S3 bucket was correctly setup and access to it from other pods used by the ADES platform correctly configured, then this step was also working. So, as it is greatly explained on their GitHub repo [4], the ADES platform gives you the opportunity to deploy (and undeploy) new services then execute them. These services are written in Common Workflow Language (CWL), when a client trigger the execution of the CWL « execution unit » (so, a service) ADES do create a namespace with dedicated pods inside it for executing every steps of the service. In case, there are operation that may be run in parallel, then the pods are started at the same time and the execution can run in parallel. Obviously, once the service execution ended, the pods and dedicated namespace is automatically removed by ADES. I would like to mention that I am impressed by the capability offered out of the box by the ADES platform. Still about this third idea, Blasco have implemented the support for automatic workspace creation relying on a shell script and made it available from here [5] in the feature/user-services branch. By investigating this new feature we realized that it may be better to use a similar mechanism but that would not rely on the use of the external shell script but on a directory that would be considerate as a skeleton for creation of the new workspaces. Something very similar to what is used on Unix and GNU/Linux platform when you create a new user and specify a directory to be used as a model for creating the new home directory. We expect this new feature to be available in the coming weeks. About the third idea [6], we did not have enough time to work actively on this. Nevertheless, we have detected some issues in the answer provided by the ZOO-Kernel for the execute request [7], we have extras keys that are not required. So, this has proven that some minimal testing of the OGC API - Processes would be a real asset to the project helping us to detect issues when they are inserted in the code as it is the case for WPS already. So, this is a target we should keep in mind and planned for future work items. For the forth idea [8], we have started by creating a new Dockerfile adding the MapServer latest version available on the official GitHub repository [9]. Nevertheless, by doing so, we realized that when you are willing to use OGC API - Feature, you should use a simplified URLs such as /mapserv/MyMap/ogcapi/ where MyMap should point to the full path of the corresponding MapServer’s mapfile as an entry in the /etc/mapserver.conf (cf. RFC 135 [10]). So, it was a requirement for being able to publish outputs as OGC API - Features, to be able to update the mapserver.conf by adding a new entry for all the created mapfiles. We tried locally to modify the Mapserver source code
[Zoo-discuss] OGC OSGeo ASF Code Sprint
Dear all, I would like to remind you that tomorrow is the first day of the 2022 OGC OSGeo ASF Code Sprint. I hope you will be able to register [1] and to join us for the tasks [2] we have identified to be handled during this 3 days Code Sprint. In case you have other ideas and you want them to be added to the list, please feel free to add them to the GitHub repository specifically made available by the organizers [3]. Wishing all the best to everyone. Best regards, [1] https://portal.ogc.org/public_ogc/register/220225asf_codesprint.php [2] https://github.com/GeoLabs/developer-events/tree/master/2022/Joint-OGC-OSGeo-ASF-Code-Sprint%202022/ideas/ZOO-Project [3] https://github.com/opengeospatial/developer-events Gerald Fenoy Chair, ZOO-Project PSC ___ ZOO-discuss mailing list ZOO-discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/zoo-discuss
[Zoo-discuss] ZOO-Project 1.9.0 release
Dear all, I am pleased to announce the publication of the ZOO-Project 1.9.0 release. You can see the release note and download the source archives from here [1], [2]. Don’t hesitate to share your experience on the mailing list, to report bugs using the GitHub issue tracking [3] or, to request for new feature [4]. Best regards, [1] https://github.com/ZOO-Project/ZOO-Project/releases/tag/rel-1.9.0 [2] https://zenodo.org/record/5940464#.YflhofXMJzU [3] https://github.com/ZOO-Project/ZOO-Project/issues/new?assignees==bug=bug_report.md= [4] https://github.com/ZOO-Project/ZOO-Project/issues/new?assignees==enhancement=feature_request.md= Gerald Fenoy Chair, ZOO-Project PSC ___ ZOO-discuss mailing list ZOO-discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/zoo-discuss
Re: [Zoo-discuss] ZOO-Project 1.9.0 release candidate 1
With the following missing references form the previous mail: [1] https://github.com/ZOO-Project/ZOO-Project/commit/581b8532d4f3bd4480c34adcd9e53ae70b08f3ab [2] https://github.com/ZOO-Project/ZOO-Project/issues/11#issuecomment-1024181397 Gerald Fenoy Chair, ZOO-Project PSC > Le 28 janv. 2022 à 13:52, Gérald Fenoy a écrit : > > Dear Jeff, > Thanks a lot for your feedbacks. > > I used the GitHub Release to publish previous versions of the ZOO-Project and > the brand new 1.9.0-rc1. I updated the corresponding documentation section > [1] and updated the associated ticket [2]. > > Best regards > > > Gerald Fenoy > Chair, ZOO-Project PSC > >> Le 25 janv. 2022 à 20:15, Jeff McKenna > <mailto:jmcke...@gatewaygeomatics.com>> a écrit : >> >> Dear Gérald, >> >> Thank-you for this effort. >> >> Please also add to your release process: creating the RC & releases at >> https://github.com/ZOO-Project/ZOO-Project/releases >> <https://github.com/ZOO-Project/ZOO-Project/releases> >> >> (for example, I like how GRASS GIS team lists the release candidates at >> https://github.com/OSGeo/grass/releases >> <https://github.com/OSGeo/grass/releases> Or you can see how I do it at >> https://github.com/MapServer/MapServer/releases >> <https://github.com/MapServer/MapServer/releases> ) >> >> Once you click the "Create a new release" button there, then GitHub >> automagically notifies the repository's "followers". >> >> Thanks, >> >> -jeff >> >> >> >> -- >> Jeff McKenna >> GatewayGeo: Developers of MS4W, MapServer Consulting and Training >> co-founder of FOSS4G >> http://gatewaygeo.com/ <http://gatewaygeo.com/> >> >> >> >> On 2022-01-25 2:56 p.m., Gérald Fenoy wrote: >>> Dear community, >>> As Release Manager, I am glad to announce the publication of the >>> ZOO-Project 1.9.0 release candidate 1. >>> It can be downloaded from here [1]. >>> This new ZOO-Project release contains new features but also fixes. >>> In November 2021, the Open Geospatial Consortium approved the OGC API - >>> Processes (Part 1: Core) standard. The new ZOO-Project release supports >>> this newly approved version. The MapServer support was integrated with this >>> new standard, even if the output data are only available through WMS, WFS >>> and WCS OGC standards, by now (see issue #1 [2]). >>> =-= New Features and Fixes =-= >>> * Update ZOO-Kernel internal messages natural languages po files >>> * Fix issue with synchronous execution from the HTML UI when requesting >>> something else than raw data output. >>> * Add support for natural languages to be available within the >>> docker-compose setup. >>> * Add support for automatic natural languages support. >>> * Add getValueFromMaps function the C-API to be used from C services >>> requiring to be functional in every memory management mode (load or >>> protected) >>> * Add support for datetime parameter for jobs filtering as defined in OGC >>> API - Processes. >>> * Add support for type parameter for jobs filtering as defined in OGC API - >>> Processes. >>> * Add support for minDuration and maxDuration parameters for jobs filtering >>> as defined in OGC API - Processes. >>> * Change the table structure for storing ongoing execution status >>> informations to add required field for outputing correct statusInfo. >>> * Addition in the C-API: function addToMapA, in case there is already a >>> value, then the value is appended to the string and values are coma >>> separated (reason of the change: support for filtering using processId and >>> status in OGC API - Processes). >>> * Add support for filtering using array of string the jobs list from OGC >>> API - Processes using processId or status parameter >>> * Change docker-compose to use binary docker image published from GitHub >>> action. >>> * Minor updates in docker-compose to target the right arch and potentially >>> cross compile in case you run from another arch >>> * Get back the MapServer automatic publication of outputs/results through >>> OGC Web Services (WMS, WFS, and WCS) >>> * Update the Basic HTML UI to use the Prefer header in case the execution >>> scenario requires to run the execute request asyncrhonously >>> * Support the Prefer header for choosing between execution mode scenarios >>> which
Re: [Zoo-discuss] ZOO-Project 1.9.0 release candidate 1
Dear Jeff, Thanks a lot for your feedbacks. I used the GitHub Release to publish previous versions of the ZOO-Project and the brand new 1.9.0-rc1. I updated the corresponding documentation section [1] and updated the associated ticket [2]. Best regards Gerald Fenoy Chair, ZOO-Project PSC > Le 25 janv. 2022 à 20:15, Jeff McKenna a > écrit : > > Dear Gérald, > > Thank-you for this effort. > > Please also add to your release process: creating the RC & releases at > https://github.com/ZOO-Project/ZOO-Project/releases > <https://github.com/ZOO-Project/ZOO-Project/releases> > > (for example, I like how GRASS GIS team lists the release candidates at > https://github.com/OSGeo/grass/releases > <https://github.com/OSGeo/grass/releases> Or you can see how I do it at > https://github.com/MapServer/MapServer/releases > <https://github.com/MapServer/MapServer/releases> ) > > Once you click the "Create a new release" button there, then GitHub > automagically notifies the repository's "followers". > > Thanks, > > -jeff > > > > -- > Jeff McKenna > GatewayGeo: Developers of MS4W, MapServer Consulting and Training > co-founder of FOSS4G > http://gatewaygeo.com/ <http://gatewaygeo.com/> > > > > On 2022-01-25 2:56 p.m., Gérald Fenoy wrote: >> Dear community, >> As Release Manager, I am glad to announce the publication of the ZOO-Project >> 1.9.0 release candidate 1. >> It can be downloaded from here [1]. >> This new ZOO-Project release contains new features but also fixes. >> In November 2021, the Open Geospatial Consortium approved the OGC API - >> Processes (Part 1: Core) standard. The new ZOO-Project release supports this >> newly approved version. The MapServer support was integrated with this new >> standard, even if the output data are only available through WMS, WFS and >> WCS OGC standards, by now (see issue #1 [2]). >> =-= New Features and Fixes =-= >> * Update ZOO-Kernel internal messages natural languages po files >> * Fix issue with synchronous execution from the HTML UI when requesting >> something else than raw data output. >> * Add support for natural languages to be available within the >> docker-compose setup. >> * Add support for automatic natural languages support. >> * Add getValueFromMaps function the C-API to be used from C services >> requiring to be functional in every memory management mode (load or >> protected) >> * Add support for datetime parameter for jobs filtering as defined in OGC >> API - Processes. >> * Add support for type parameter for jobs filtering as defined in OGC API - >> Processes. >> * Add support for minDuration and maxDuration parameters for jobs filtering >> as defined in OGC API - Processes. >> * Change the table structure for storing ongoing execution status >> informations to add required field for outputing correct statusInfo. >> * Addition in the C-API: function addToMapA, in case there is already a >> value, then the value is appended to the string and values are coma >> separated (reason of the change: support for filtering using processId and >> status in OGC API - Processes). >> * Add support for filtering using array of string the jobs list from OGC API >> - Processes using processId or status parameter >> * Change docker-compose to use binary docker image published from GitHub >> action. >> * Minor updates in docker-compose to target the right arch and potentially >> cross compile in case you run from another arch >> * Get back the MapServer automatic publication of outputs/results through >> OGC Web Services (WMS, WFS, and WCS) >> * Update the Basic HTML UI to use the Prefer header in case the execution >> scenario requires to run the execute request asyncrhonously >> * Support the Prefer header for choosing between execution mode scenarios >> which can be sync/async and raw/document >> * Add support for multiple output requested as Raw for OGC API - Processes >> (why not backport this in WPS?) >> * Automatically add the old format of metadata informations to the inputs >> and outputs to not require a single modification within your existing >> services >> * Update the Basic HTML UI to try to conform to version 1.0-draft.6 >> * Modify both the request parser and response printer functions from the >> C-API to conform to version 1.0-draft.6 >> * Support both the old array of inputs / outputs syntax and the one defined >> in the draft 1.0-draft.6 (array of inputs for the new syntax may not work as >> expected) >> * Move jobs to
[Zoo-discuss] ZOO-Project 1.9.0-rc1 release candidate 1
Dear community,
As Release Manager, I am glad to announce the publication of the ZOO-Project
1.9.0 release candidate 1.
It can be downloaded from here [1].
This new ZOO-Project release contains new features but also fixes.
In November 2021, the Open Geospatial Consortium approved the OGC API -
Processes (Part 1: Core) standard. The new ZOO-Project release supports this
newly approved version. The MapServer support was integrated with this new
standard, even if the output data are only available through WMS, WFS and WCS
OGC standards, by now (see
[#1](https://github.com/ZOO-Project/ZOO-Project/issues/1)).
=-= New Features and Fixes =-=
* Update ZOO-Kernel internal messages natural languages po files
* Fix issue with synchronous execution from the HTML UI when requesting
something else than raw data output.
* Add support for natural languages to be available within the docker-compose
setup.
* Add support for automatic natural languages support.
* Add getValueFromMaps function the C-API to be used from C services requiring
to be functional in every memory management mode (load or protected)
* Add support for datetime parameter for jobs filtering as defined in OGC API -
Processes.
* Add support for type parameter for jobs filtering as defined in OGC API -
Processes.
* Add support for minDuration and maxDuration parameters for jobs filtering as
defined in OGC API - Processes.
* Change the table structure for storing ongoing execution status informations
to add required field for outputing correct statusInfo.
* Addition in the C-API: function addToMapA, in case there is already a value,
then the value is appended to the string and values are coma separated (reason
of the change: support for filtering using processId and status in OGC API -
Processes).
* Add support for filtering using array of string the jobs list from OGC API -
Processes using processId or status parameter
* Change docker-compose to use binary docker image published from GitHub action.
* Minor updates in docker-compose to target the right arch and potentially
cross compile in case you run from another arch
* Get back the MapServer automatic publication of outputs/results through OGC
Web Services (WMS, WFS, and WCS)
* Update the Basic HTML UI to use the Prefer header in case the execution
scenario requires to run the execute request asyncrhonously
* Support the Prefer header for choosing between execution mode scenarios which
can be sync/async and raw/document
* Add support for multiple output requested as Raw for OGC API - Processes (why
not backport this in WPS?)
* Automatically add the old format of metadata informations to the inputs and
outputs to not require a single modification within your existing services
* Update the Basic HTML UI to try to conform to version 1.0-draft.6
* Modify both the request parser and response printer functions from the C-API
to conform to version 1.0-draft.6
* Support both the old array of inputs / outputs syntax and the one defined in
the draft 1.0-draft.6 (array of inputs for the new syntax may not work as
expected)
* Move jobs to root and use /processes/{processID} as execute endpopint
* Make all demos running within docker (including SAGA and OTB)
* Deploy demo HTML UI from github from the Dockerfile
* Add demo ZOO-Services build in the Dockerfile
Please report any issue you may have using this version.
In case no issue is reported in the 7 upcoming days, we will approve this
release candidate.
Have great time with it!
Best regards,
[1] http://zoo-project.org/new/Code/Download
Gerald Fenoy
Chair, ZOO-Project PSC
___
Zoo-discuss mailing list
Zoo-discuss@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/zoo-discuss
[Zoo-discuss] ZOO-Project 1.9.0 release candidate 1
Dear community,
As Release Manager, I am glad to announce the publication of the ZOO-Project
1.9.0 release candidate 1.
It can be downloaded from here [1].
This new ZOO-Project release contains new features but also fixes.
In November 2021, the Open Geospatial Consortium approved the OGC API -
Processes (Part 1: Core) standard. The new ZOO-Project release supports this
newly approved version. The MapServer support was integrated with this new
standard, even if the output data are only available through WMS, WFS and WCS
OGC standards, by now (see issue #1 [2]).
=-= New Features and Fixes =-=
* Update ZOO-Kernel internal messages natural languages po files
* Fix issue with synchronous execution from the HTML UI when requesting
something else than raw data output.
* Add support for natural languages to be available within the docker-compose
setup.
* Add support for automatic natural languages support.
* Add getValueFromMaps function the C-API to be used from C services requiring
to be functional in every memory management mode (load or protected)
* Add support for datetime parameter for jobs filtering as defined in OGC API -
Processes.
* Add support for type parameter for jobs filtering as defined in OGC API -
Processes.
* Add support for minDuration and maxDuration parameters for jobs filtering as
defined in OGC API - Processes.
* Change the table structure for storing ongoing execution status informations
to add required field for outputing correct statusInfo.
* Addition in the C-API: function addToMapA, in case there is already a value,
then the value is appended to the string and values are coma separated (reason
of the change: support for filtering using processId and status in OGC API -
Processes).
* Add support for filtering using array of string the jobs list from OGC API -
Processes using processId or status parameter
* Change docker-compose to use binary docker image published from GitHub action.
* Minor updates in docker-compose to target the right arch and potentially
cross compile in case you run from another arch
* Get back the MapServer automatic publication of outputs/results through OGC
Web Services (WMS, WFS, and WCS)
* Update the Basic HTML UI to use the Prefer header in case the execution
scenario requires to run the execute request asyncrhonously
* Support the Prefer header for choosing between execution mode scenarios which
can be sync/async and raw/document
* Add support for multiple output requested as Raw for OGC API - Processes (why
not backport this in WPS?)
* Automatically add the old format of metadata informations to the inputs and
outputs to not require a single modification within your existing services
* Update the Basic HTML UI to try to conform to version 1.0-draft.6
* Modify both the request parser and response printer functions from the C-API
to conform to version 1.0-draft.6
* Support both the old array of inputs / outputs syntax and the one defined in
the draft 1.0-draft.6 (array of inputs for the new syntax may not work as
expected)
* Move jobs to root and use /processes/{processID} as execute endpopint
* Make all demos running within docker (including SAGA and OTB)
* Deploy demo HTML UI from github from the Dockerfile
* Add demo ZOO-Services build in the Dockerfile
Please report any issue you may have using this version.
In case no issue is reported in the 7 upcoming days, we will approve this
release candidate.
Best regards,
[1] http://zoo-project.org/new/Code/Download
[2] https://github.com/ZOO-Project/ZOO-Project/issues/1
Gerald Fenoy
Chair, ZOO-Project PSC
___
Zoo-discuss mailing list
Zoo-discuss@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/zoo-discuss
[Zoo-discuss] ZOO-Project's Christmass gifts
Dear ZOO-Project community, As a PSC chair I come here today to call for volunteers to make a Christmas gift to the ZOO-Project development team. During the development years, the number of ZOO-Kernel internal messages increased and some existing message were modified. So, we would need help from you, the volunteers, to translate the ZOO-Kernel internal messages in your language. Please refer to this section of the documentation [1] on how to contribute translation. Best regards, [1] https://zoo-project.github.io/docs/contribute/translate.html ___ Zoo-discuss mailing list Zoo-discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/zoo-discuss
