VS issueshttps://gitlab.eox.at/esa/prism/vs/-/issues2020-11-11T11:53:37+01:00https://gitlab.eox.at/esa/prism/vs/-/issues/6Create script to bootstrap collections (docker-compose, configs, env)2020-11-11T11:53:37+01:00Fabian SchindlerCreate script to bootstrap collections (docker-compose, configs, env)Baseline evolutionFabian SchindlerFabian Schindlerhttps://gitlab.eox.at/esa/prism/vs/-/issues/71Mapcache rendering issues2020-12-03T09:43:14+01:00Lubomir DoležalMapcache rendering issuesFollowing tile has a row of transparent pixels 1 pixel wide on top, right and bottom of the tile.
https://emg.pass.copernicus.eu/cache/ows/wmts?layer=Emergency__TRUE_COLOR&style=default&tilematrixset=WGS84&Service=WMTS&Request=GetTile&Ve...Following tile has a row of transparent pixels 1 pixel wide on top, right and bottom of the tile.
https://emg.pass.copernicus.eu/cache/ows/wmts?layer=Emergency__TRUE_COLOR&style=default&tilematrixset=WGS84&Service=WMTS&Request=GetTile&Version=1.0.0&Format=image%2Fpng&TileMatrix=13&TileCol=9392&TileRow=2298&time=2020-01-24T09%3A26%3A34Z%2F2020-01-24T09%3A26%3A43Z
This produces unpleasant artifacts while viewing the layer in client.
It was confirmed on other collections as well, but only for new tiles, therefore I suspect mapcache update to 1.10 to be culprit, as there have not been any other cache/renderer related updates on production machines since then?
Not sure how to fix this. @fabian.schindler says, that this problem was already observed before on NDVI rendering.
![image](/uploads/7e0c9b46683f12f3da8f3bfff57c9cc0/image.png)
![image](/uploads/6814878b4f7a81965b11caf9cb166347/image.png)Baseline evolution v2https://gitlab.eox.at/esa/prism/vs/-/issues/69Registrar updates2020-11-27T18:40:31+01:00Lubomir DoležalRegistrar updates- [x] it would be great to extend registrar to allow more coverage types per product type - extend to list and try more until one passes
- [x] update emg init db config, removing different product types per band count, but adding differe...- [x] it would be great to extend registrar to allow more coverage types per product type - extend to list and try more until one passes
- [x] update emg init db config, removing different product types per band count, but adding different coverage types
- [x] deploy changes on prod (migrate products from _bandcount product types to single product type (EW03_3 -> EW03)
summary:
- create new coverage type: BGRNir, sar_hh_hv_vh_vv_gray
- create new product types
- migrate all products from RGBNir to BGRNir cov type (GE01_4, GY01_4, EQ02_4, EW02_4, EW03_4) and change prod type
- migrate RGB product types to shared one (GE01_3, EQ02, EW02, EW03)
- remove sar_hh_hv_vh_vv_rgb, purge it to oblivion, TX01_7, RS02_7
- make just hh_hv_vh_vv from it
- reprocess sar_hh_hv_vh_vv_rgb -> ideally by downloading IMG, removing last 3 bands and reuploading it to same name
- Migrate TX01_3 and TX01_2 to TX01
- Migrate RS02_3 and RS02_2 to RS02
- Migrate EW02_8 and EW03_8 to EW02, EW03
- clean emg cache afterwardsBaseline evolution v2Lubomir DoležalLubomir Doležalhttps://gitlab.eox.at/esa/prism/vs/-/issues/621.0.0 release2020-11-12T21:41:07+01:00Lubomir Doležal1.0.0 release- [x] close #20 - Fabian
- [x] fix registrar test to make build pass and merge registrar-modularization branch - Fabian
- [x] update WO TN v3.0.0 - SM
- [x] prepare SRN - MA
- [x] update training material pres v1.1.0 - LB
- [x] create gi...- [x] close #20 - Fabian
- [x] fix registrar test to make build pass and merge registrar-modularization branch - Fabian
- [x] update WO TN v3.0.0 - SM
- [x] prepare SRN - MA
- [x] update training material pres v1.1.0 - LB
- [x] create git tag (bumpversion) - LB
- [x] git archive at 1.0.0 - LB
- [x] build pdf for operator guide - new version v1.1.0 - LB
- [x] build pdf for user guide - new version v1.1.1 - LBBaseline evolution v2https://gitlab.eox.at/esa/prism/vs/-/issues/60Define version release procedure2020-11-11T11:42:11+01:00Lubomir DoležalDefine version release procedure- an official release procedure of vs components should be defined and implemented
- currently each Dockerfile has got a version, which is used by gitlab ci to tag images in the registry
- on production servers :latest tag is pulled
An ...- an official release procedure of vs components should be defined and implemented
- currently each Dockerfile has got a version, which is used by gitlab ci to tag images in the registry
- on production servers :latest tag is pulled
An option would be https://github.com/c4urself/bump2version for manually updating VERSION in Dockerfiles. In order to avoid having different "commits" as one version, gitlab.ci would push a tagged version only if the tag does not exist yet (as eoxserver travis.ci does it?)
Pros:
- we have control over releases manually
Cons:
- someone has to do itBaseline evolution v2Lubomir DoležalLubomir Doležalhttps://gitlab.eox.at/esa/prism/vs/-/issues/59Documentation & readme updates2021-02-10T11:38:18+01:00Lubomir DoležalDocumentation & readme updates- [x] logging stack readme
- [x] logging stack operator guide (kibana screenshot, etc.)
- [x] auth service operator guide (login, add auth rules, etc.)
- [x] auth service readme
- [x] shibauth parts - where to go from pvs_starter output ...- [x] logging stack readme
- [x] logging stack operator guide (kibana screenshot, etc.)
- [x] auth service operator guide (login, add auth rules, etc.)
- [x] auth service readme
- [x] shibauth parts - where to go from pvs_starter output to working state
- [x] traefik reverse-proxy operators guide
- [ ] local reverse-proxy readme - *left for later*
- [x] reporting operators guide
- [x] reporting readme
- [x] ingestor readme
- [x] ingestor operators guide
- [x] sftp service operators guide
- [x] docker secrets creating in operators guide & readme
- [x] document preprocessor metadata / browse report handling
- [x] document direct registration usage to close #35
- [x] preprocessor operators guide
- [x] preprocessor configurationBaseline evolution v2https://gitlab.eox.at/esa/prism/vs/-/issues/57Generalize registrar2020-10-12T11:19:06+02:00Lubomir DoležalGeneralize registrarIdeally have a simplified configuration as a yaml in a similar way as new preprocessor has it.
Mainly targetting the XML paths to get product / level / collection from
Currently it is hardcodedIdeally have a simplified configuration as a yaml in a similar way as new preprocessor has it.
Mainly targetting the XML paths to get product / level / collection from
Currently it is hardcodedBaseline evolution v2https://gitlab.eox.at/esa/prism/vs/-/issues/37Support for compressed ingest files according to the OAR / BRG IPRISM2020-11-11T12:08:29+01:00Fabian SchindlerSupport for compressed ingest files according to the OAR / BRG IPRISMPRISMBRW-INT-020030PRISMBRW-INT-020030Baseline evolution v2https://gitlab.eox.at/esa/prism/vs/-/issues/34Support for OAR metadata2020-11-11T12:08:24+01:00Fabian SchindlerSupport for OAR metadataPRISMBRW-FUN-000020
PRISMBRW-DES-050020
[OAR-OPTICD]PRISMBRW-FUN-000020
PRISMBRW-DES-050020
[OAR-OPTICD]Baseline evolution v2https://gitlab.eox.at/esa/prism/vs/-/issues/31Cascaded WMS2021-11-21T15:25:45+01:00Fabian SchindlerCascaded WMS* [ ] Figure out what Cascaded WMS entails (ECSYS413/SYSAD-240)
* [ ] Implement Cascaded WMS* [ ] Figure out what Cascaded WMS entails (ECSYS413/SYSAD-240)
* [ ] Implement Cascaded WMSBaseline evolution v2https://gitlab.eox.at/esa/prism/vs/-/issues/145fix 2D-3D harmonization + style + attribution2021-11-10T22:21:58+01:00Mussab Abdallafix 2D-3D harmonization + style + attributionDEM First ReleaseMussab AbdallaMussab Abdallahttps://gitlab.eox.at/esa/prism/vs/-/issues/105Django admin is not accessible when more renderers spawned2021-04-27T11:46:03+02:00Lubomir DoležalDjango admin is not accessible when more renderers spawned- as secret key is different for each instance of renderer- as secret key is different for each instance of rendererDEM First ReleaseNikola JankovicNikola Jankovichttps://gitlab.eox.at/esa/prism/vs/-/issues/98investigate NO-DATA processing policy2021-08-03T11:06:45+02:00Mussab Abdallainvestigate NO-DATA processing policycurrently the DEM data is pre-processed by assigning Nodata pixels to zero, this could lead to some issues regarding:
- visualizing sea areas, some lakes.
- generating of the terrain mesh data to be visualized in cesium.
A possibility ...currently the DEM data is pre-processed by assigning Nodata pixels to zero, this could lead to some issues regarding:
- visualizing sea areas, some lakes.
- generating of the terrain mesh data to be visualized in cesium.
A possibility of using an interpolation smoothing filter ( using `gdal_fillnodata.py` ) can be considered, however a workaround that avoids re-pre-processing data would be recommended.DEM First ReleaseMussab AbdallaMussab Abdallahttps://gitlab.eox.at/esa/prism/vs/-/issues/91Add support of retrieving subsets of multiple products with one request - DEM...2021-11-10T22:22:45+01:00Lubomir DoležalAdd support of retrieving subsets of multiple products with one request - DEM-032- The PASS needs to be extended to support retrieving subsets of multiple products with one request. The WCS service included in the PASS shall be extended to support the GetEOCoverageSet request defined in the Earth Observation Applicat...- The PASS needs to be extended to support retrieving subsets of multiple products with one request. The WCS service included in the PASS shall be extended to support the GetEOCoverageSet request defined in the Earth Observation Application Profile of WCS (EO-WCS, OGC 10-140r2). This request allows specifying a package format like ZIP and multiple coverages to subset.
- [x] adapt Renderer (EOxServer with above change) ...
- [x] adapt client to allow to configure if more than 1 product selected, use another request
- [x] extend User Guide with information how to use this
- [x] GetEOCoveragesSet response is not as expected: in each product folder are multiple equal GeoTIFFs
- [ ] GetEOCoveragesSet response is not as expected: no all selected products are included in the package although they overlap the crop areaDEM First ReleaseMussab AbdallaMussab Abdallahttps://gitlab.eox.at/esa/prism/vs/-/issues/88Test latest stable ArcMap and QGIS clients against our OGC services - DEM-0252021-09-17T20:52:23+02:00Lubomir DoležalTest latest stable ArcMap and QGIS clients against our OGC services - DEM-025- testing of the latest stable versions of QGIS and ArcMap to be done and thoroughly documented
- WMS, WMTS, WCS
- updating of user-guide accordingly- testing of the latest stable versions of QGIS and ArcMap to be done and thoroughly documented
- WMS, WMTS, WCS
- updating of user-guide accordinglyDEM First ReleaseNikola JankovicNikola Jankovichttps://gitlab.eox.at/esa/prism/vs/-/issues/85Add rendering of DEM tile number to client - DEM-0222021-05-17T19:37:11+02:00Lubomir DoležalAdd rendering of DEM tile number to client - DEM-022- Simply add a Text label into center of polygon in `eoxc`
- Check if we have needed metadata ingested into db, if not adapt registrar and reingest
Example how this could look like ![image](/uploads/5bcba8e0ffa59c7aee0ea34fe000057e/image...- Simply add a Text label into center of polygon in `eoxc`
- Check if we have needed metadata ingested into db, if not adapt registrar and reingest
Example how this could look like ![image](/uploads/5bcba8e0ffa59c7aee0ea34fe000057e/image.png)DEM First ReleaseLubomir DoležalLubomir Doležalhttps://gitlab.eox.at/esa/prism/vs/-/issues/84Add 3D to client - DEM-0262021-09-14T15:55:53+02:00Lubomir DoležalAdd 3D to client - DEM-026- The task is to add a 3D viewer option for our eoxc client with "sensible default of 3d functionality"
- needs at least sample prepared DEM data from #82
- Integrate the selected solution from #83 into https://github.com/eoxc/eoxc & htt...- The task is to add a 3D viewer option for our eoxc client with "sensible default of 3d functionality"
- needs at least sample prepared DEM data from #82
- Integrate the selected solution from #83 into https://github.com/eoxc/eoxc & https://github.com/eoxc/prism - wait for #80
**Non-exhaustive list of things to take in consideration:**
1- for showing correct search results (individual products): Convert current camera view into polygon for area search.
2- Ensure that product footprints are correctly drawn on map.
3- Allow switch between with and without 3D.
4- watch bundle size, already quite large, with cesium might need bundle splitting (different webpack config).
5- Ensure draw area functionality works in 3D.
6- Will 3D viewer be possible even for DetailsDisplay? (same used component) -> no need to.DEM First ReleaseLubomir DoležalLubomir Doležalhttps://gitlab.eox.at/esa/prism/vs/-/issues/83Decide on 3D viewer for viewing DEM products in our eoxc client - DEM-0262021-03-05T11:53:37+01:00Lubomir DoležalDecide on 3D viewer for viewing DEM products in our eoxc client - DEM-026- The task is to add a 3D viewer option for our eoxc client with "sensible default of 3d functionality"
- zoom in/out, pan, control “camera position” and “viewing direction”, and select perspective projection.
- One of the candidates is ...- The task is to add a 3D viewer option for our eoxc client with "sensible default of 3d functionality"
- zoom in/out, pan, control “camera position” and “viewing direction”, and select perspective projection.
- One of the candidates is using Cesium.js via https://openlayers.org/ol-cesium/
- COGs are natively not yet supported in cesium https://github.com/CesiumGS/cesium/issues/6332
- In current form (Because COGs are not supported yet) it feels much easier to use Digitized mesh terrain format used in Cesium - see https://gitlab.eox.at/esa/prism/vs/-/issues/82
- are there really any alternatives for inbrowser 3D map viewing? - swisstopo also uses cesium for https://map.geo.admin.ch/?layers=ch.swisstopo.swissnames3d&lon=8.24528&lat=46.04722&elevation=87928&heading=360.000&pitch=-44.188DEM First Releasehttps://gitlab.eox.at/esa/prism/vs/-/issues/82terrain data processing for visualization in Cesium2021-09-10T14:53:16+02:00Mussab Abdallaterrain data processing for visualization in CesiumAs discussed earlier, terrain data needs to be converted into a cesium acceptable format ( either Height maps, or [quantize mesh ](https://github.com/CesiumGS/quantized-mesh)).
It's strongly recommended to use the quantize mesh format si...As discussed earlier, terrain data needs to be converted into a cesium acceptable format ( either Height maps, or [quantize mesh ](https://github.com/CesiumGS/quantized-mesh)).
It's strongly recommended to use the quantize mesh format since it's provides better performance and results.
Doing a quick scan , I ran into 3 candidate opensource tools to use :
- [Tin-terrain](https://github.com/heremaps/tin-terrain) written in C++ - more maintained fork in [cognitive-earth/tin-terrain](https://github.com/cognitive-earth/tin-terrain)
- [cesium terrain builder (docker)](https://github.com/tum-gis/cesium-terrain-builder-docker) docker image built in c++
- [quantize mesh tile](https://github.com/loicgasser/quantized-mesh-tile) written in python
I would recommend to explore in depth, to clarify performance of these tools ( performance with large size tiffs, high resolution tiffs, large extent..... etc)DEM First ReleaseLubomir DoležalLubomir Doležalhttps://gitlab.eox.at/esa/prism/vs/-/issues/80Move client repository eoxc/prism here2021-05-06T09:57:28+02:00Lubomir DoležalMove client repository eoxc/prism here- To allow development on actual data from renderer without the CORS plugin, the https://github.com/eoxc/prism `update-eoxc` checked out to branch should be moved to `vs` repository
- Build of the client docker image will include buildin...- To allow development on actual data from renderer without the CORS plugin, the https://github.com/eoxc/prism `update-eoxc` checked out to branch should be moved to `vs` repository
- Build of the client docker image will include building the js client
- remove hardcoded docs pdf and html links from https://github.com/eoxc/prism/blob/update-eoxc/src/languages/en.json#L23DEM First ReleaseLubomir DoležalLubomir Doležal