eurodatacube / eodash

Software behind the RACE dashboard by ESA and the European Commission (https://race.esa.int), the Green Transition Information Factory - GTIF (https://gtif.esa.int), as well as the Earth Observing Dashboard by NASA, ESA, and JAXA (https://eodashboard.org)
https://race.esa.int
MIT License
94 stars 42 forks source link

May V1.0 release bugs tracking #2203

Closed Patrick1G closed 1 year ago

Patrick1G commented 1 year ago

here we can keep track of smaller issues that we notice in preparation of the V1.0 release end of May

Patrick1G commented 1 year ago

Image

lubojr commented 1 year ago

@patrick-griffiths We were using a radiometric terrain corrected as default visualisation of S1 from sentinelhub - please have a look at https://sentinelshare.page.link/cMqs There are multiple other available options, please pick one which you think would support the cases the best and we shall use that particular evalscript in our layer definition. Thank you.

Patrick1G commented 1 year ago

thanks @lubojr - noted that this comes directly out of SH... will discuss with some SAR experts, it does look somehow exaggerated

aapopescu commented 1 year ago

for visualisation please consider using the orthorecitified or gamma0 layers instead of the RTC

AlessandroScremin commented 1 year ago

@aapopescu @lubojr the layer selectd was already gamma 0, not th RTC...but ortorectification enabled with default DEM. so what I can do is to disable the orthoretification...

@lubojr try now I changed the E8_Sentinel1 with no orthorectification.

AlessandroScremin commented 1 year ago

image

lubojr commented 1 year ago

@AlessandroScremin Thank you for the reconfiguration.

We have looked over several high altitude lakes and indeed the rendering artifacts are now gone - they were caused by the DEM orthorectification. But the DEM orthorectification also had a positive influence on "georeferencing of the images" in high altitude areas (where most of our tracked reservoirs are).

See for example image and image

taken from https://gtif.esa.int/explore?poi=573-REP4_1

The influence of the positional shift varies in magnitude and direction for different scenes/dates.

@patrick-griffiths Is the current S1 visualisation sufficient?

AlessandroScremin commented 1 year ago

@lubojr As it was the same layer used for E8 indicator in race...could you please check if it is affeccted? I looked at one of the finished good inventory and see only the timeseries (no sar image)...I don't remember if it was still used there...if not then we can keep the layer changes

lubojr commented 1 year ago

@AlessandroScremin We use S1 layer (E8_SENTINEL1) for example in following indicators: https://race.esa.int/?poi=UK12-E12b - looks good https://race.esa.int/?poi=ES7-E1 - archived, looks good https://race.esa.int/?poi=PL5-E5 - archived, some dates missing, but looking good

From my point of view, I'd say you can leave that changed for race as well.

AlessandroScremin commented 1 year ago

@lubojr Checked...good...perfect. So let the layer in this way!!

Thanks

Patrick1G commented 1 year ago

@lubojr sorry for missing the above discussion earlier. I agree with @aapopescu suggestion to go for (VH decibel) gamma0. It looks best for these visualization purposes

Example here: https://apps.sentinel-hub.com/eo-browser/?zoom=14&lat=47.23639&lng=10.87758&themeId=DEFAULT-THEME&visualizationUrl=https%3A%2F%2Fservices.sentinel-hub.com%2Fogc%2Fwms%2Ff2068f4f-3c75-42cf-84a1-42948340a846&datasetId=S1_AWS_IW_VVVH&fromTime=2022-12-30T00%3A00%3A00.000Z&toTime=2022-12-30T23%3A59%3A59.999Z&layerId=IW-DV-VH-DECIBEL-GAMMA0&demSource3D=%22MAPZEN%22

image

Patrick1G commented 1 year ago

@santilland @lubojr In the energy tools, could we please rename "filter" to "constraint"

"add filter"--> "add constraint" "reset filter"--> "reset constraints"

image

santilland commented 1 year ago

@patrick-griffiths filter to constraint wording has been done, currently on staging environment will be included in next demonstrator deployment

Patrick1G commented 1 year ago

@santilland @lubojr

Energy > Solar --> Currently the constraint for the Solar irradiance itself only affects the stretch of values, it does not limit the irradiance layers as expected (compare to what happens with wind):

https://gtif.esa.int/explore?x=1742987.39595&y=5965561.33671&z=9.15831&clusterOpen=5&poi=Austria-REP2

Image

Patrick1G commented 1 year ago

Custom Dashboard button shown purposefully (current demo branch)? If so, it should be renamed to "create scrollytelling content"

Image

santilland commented 1 year ago

Custom Dashboard button shown purposefully (current demo branch)? If so, it should be renamed to "create scrollytelling content"

The custom dashboard button is only visible for someone who has opened a custom dashboard edit link, this should only be the case for people adviced on how to creat this content and not for the general public

Patrick1G commented 1 year ago

@santilland & @lubojr - a couple of smaller issues:

Image

Image

Patrick1G commented 1 year ago

@lubojr @santilland

Image

santilland commented 1 year ago

@lubojr @santilland

  • [ ] energy > solar: the constraint slider for Global Horizontal Irradiation currently adjusts the strech, while it should lead to a filtering of value ranges (similar to wind WPD)
  • [ ] energy > solar: also the stretch of the data value ranges does not allow seeing meaningful differences, see screenshot below. @kegro did you guys provide some optimized stretch values?

Hello @patrick-griffiths this was discussed and agreed per email, as the different seasons have completely different range values there is no way to fit everything under one hat, so the slider now alows to change the value range stretch. This is also why the colormap legend shows min / max and not specific values. We could change the title to better reflect this, maybe add "colormap stretch"

Patrick1G commented 1 year ago

@santilland ok but this circumvents / breaks the purpose of the tool, which is to preform site suitability assessment, where the first step is to constrain (filter) the value range of the irradiance layers (analogue to what we do for wind).

If you need to provide dynamic stretch, it needs to be explicitly labeled as that, and we still need the constraint slider for filtering the values!!

santilland commented 1 year ago

@santilland ok but this circumvents / breaks the purpose of the tool, which is to preform site suitability assessment, where the first step is to constrain (filter) the value range of the irradiance layers (analogue to what we do for wind).

If you need to provide dynamic stretch, it needs to be explicitly labeled as that, and we still need the constraint slider for filtering the values!!

ok, we should be able to do the stretch and filter out all values above and below the current range, i will have a look

Patrick1G commented 1 year ago

@santilland I think we need to sliders here:

1) optimize stretch of values 2) constrain Global Horizontal Irradiation layer values

doing both with one slides will not be possible...

kegro commented 1 year ago

@kegro did you guys provide some optimized stretch values?

It is quite difficult to display the annual and seasonal layers with the same stretch and at the same time show the variation within each layer. A stratch between 0.5 and 6 is probably best for this. However, to dsiplay them to show the variation within each layers then different stretches are needed. @santilland we can give you some guidance here if you like?

santilland commented 1 year ago

@patrick-griffiths @kegro on following branch is an option how stretch and filtering would be done at the same time, i think this is the best approach we can do currently, we can consider a more elaborate solution for the future. https://gtif-testing.eox.at/gtif_solar_filter/

Patrick1G commented 1 year ago

@kegro could you give this a try and let us know>?

kegro commented 1 year ago

@santilland @patrick-griffiths I think this works. It doesn't take long to learn that the stretch and filtering is done with the same slider, so from I user I think it is OK. A bit hard to keep track of what values relates to which color, but the value range is quite explicit on the slider. All the other filtering options seem to work fine too.

slumnitz commented 1 year ago

@lubojr @santilland Please advise: in the Sustainable Cities explorer, when a user clicks on the data the "Zeahlsprenger" colour is different to the colour chosen in the scatterplot. Is it possible to match the colours?

Additionally, can non selected Zaehlsprengel still be greyed out as in the previous version? Otherwise, selected ones are hard to see in my version.

image

lubojr commented 1 year ago

@slumnitz Currently the colors are done followingly:

In the map each selected ZSP feature uses a new color from this list https://github.com/eurodatacube/eodash/blob/gtif_staging/app/src/appConfig.js#L315-L318 based on the index of the feature in the list

On the chart, the colors are aggregated per gemeinde (each gemeinde has a new color also from this list), so if you select Graz and some other Gemeinde, then respective ZSP from the other Gemeinde are also drawn by the second color of the array.

Exception to that are all the selected ZSP (which triggered the original gemeinde search) - those are red.

Nonselected ZSP can be changed to grey, but then we lose comparison between 2 gemeinde.

Please advise how to proceed.

slumnitz commented 1 year ago

@santilland and @lubojr we also would need to remove the urban tree tab from the user interface as this data will not be made available soon. (fit @patrick-griffiths )

slumnitz commented 1 year ago

@santilland and @lubojr the sustainable cities datasets load very slow. Are there any possible speedups that could be implemented in future or soon? (@patrick-griffiths )

slumnitz commented 1 year ago

@slumnitz Currently the colors are done followingly:

In the map each selected ZSP feature uses a new color from this list https://github.com/eurodatacube/eodash/blob/gtif_staging/app/src/appConfig.js#L315-L318 based on the index of the feature in the list

On the chart, the colors are aggregated per gemeinde (each gemeinde has a new color also from this list), so if you select Graz and some other Gemeinde, then respective ZSP from the other Gemeinde are also drawn by the second color of the array.

Exception to that are all the selected ZSP (which triggered the original gemeinde search) - those are red.

Nonselected ZSP can be changed to grey, but then we lose comparison between 2 gemeinde.

Please advise how to proceed.

@lubojr thank you for the explanation! I understand, for the release now, to not confuse the user I would: A) Keep the selection on the map to one colour the same one used for highlighting the plots in the Gemein, B) and make the outline of the selected Zeahlsprengel more dominant, i.e. 2x original ZSP. You are also welcome to test different approaches, but currently the selected ZSP is not really visible on a MAC screen. C) currently selected ZSP in different Gemeinde have the same colour can they be made a different colour to distinguish ZSP selected in Gemeinde A from ZSP selected in Gemeinde B?

slumnitz commented 1 year ago

@lubojr perhaps another way could be to additionally to the more dominant outline to make the alpha not white colouring but coloured colouring?

slumnitz commented 1 year ago

@lubojr I would also recommend to make the dot's in the scatterplot a slight alpha=0.7 (slight transparency) so that all dot's are visible even if they overlap.

Patrick1G commented 1 year ago

@santilland @lubojr

This below should replace the beta version disclaimer that is currently shown when the explore tools are opened: Could we provide hyperlinks for these elements to help users discover this new functionality?

Welcome to the V1.0 release of the Green Transition Information Factory – Demonstrator for Austria! What’s new:

- Energy Transition:

formatted basically as below

Image

Patrick1G commented 1 year ago

@santilland @lubojr

For the mobility transition:

Patrick1G commented 1 year ago

@santilland @lubojr for the Alpine Drought Explorer:

Image

Standardised Precipitation Index_12.docx Standardisied Precipitation-Evapotranspiration Index_1.docx Standardisied Precipitation-Evapotranspiration Index_12.docx Standardised Precipitation Index_1.docx

santilland commented 1 year ago

@patrick-griffiths latest state on staging deployment: https://gtif-staging.eox.at/ This has the new welcome message, the aggregated mobility data were some fixes needed to be done, as well as the new daily aggregated mobility pattern. I will then continue on the rest of points and write updates here

Patrick1G commented 1 year ago

@santilland @lubojr Not sure if I have listed these small changes anywhere:

Patrick1G commented 1 year ago

@patrick-griffiths latest state on staging deployment: https://gtif-staging.eox.at/ This has the new welcome message, the aggregated mobility data were some fixes needed to be done, as well as the new daily aggregated mobility pattern. I will then continue on the rest of points and write updates here

Lots of things look very good, thanks!

_In order to better understand how people's movement and mobility affects air quality parameters, this tool allows exploring correlations between Sentinel-5P measurements and human mobility data.

For this both data sources were aggregated to the same spatial grid. For the air quality parameters daily Sentinel-5P Tropomi observations were used. For the mobility data, only observations that preceded the S5P observation by four hours was considered. Four hours is the typical time that NO2 can remain in the atmosphere and thus be detected.

The tool supports users in exploring temporal spatial patterns between both variables and identify potential correlations. The mobility data only captures around 22% of the population and is then calibrated with population presence and density. Thus, it is one form of capturing people’s movement but likely not the most suitable. Consequently, estimates provided for Number of Trajectories, Congestion Index, Speed, Motorized Count, and Motorized Share may not be reflecting the reality of mobility on the ground with very high precision. Nevertheless, this tool is a first attempt in allowing users to explore air quality parameters and mobility statistics interactively._

lubojr commented 1 year ago

@lubojr I would also recommend to make the dot's in the scatterplot a slight alpha=0.7 (slight transparency) so that all dot's are visible even if they overlap.

I have added alpha to the scatterplot items, so the items are a bit more visible

I have also updated the selection logic on the map, so that the currently selected ZSP now do not have a special color (it is not straightforward to match the selected ZSP to the original Gemeinde on the map) but instead the selected ZSP have an increased stroke width, so it is more clear on the map which are selected. The user can then hover on the map to see which one is which. The confusion on different color wrt. the map and the chart should now be gone, as map on SOL1 will now have only 1 color of the ZSP features - dark green.

As for coloured colouring for selected ZSPs - this would essentially hide / completely distort the colors of the original layer style on the green roofs, so we have opted to instead to transparent white background.

Antony-Delavois commented 1 year ago
  • [x] mobility: correlation explorer: update disclaimer on right side with below text

A quick update on the disclaimer:

This tool allows exploring potential correlations between Sentinel-5P/TROPOMI measurements and human mobility data, with the objective to better understand how people's movement and mobility affects air quality parameters.

For this purpose, both data sources were aggregated to the same spatial grid. For the air quality parameters daily S-5P observations were used. For the mobility data, only observations that preceded the S-5P observation by four hours was considered. Four hours is the typical time that NO2 can remain in the atmosphere and thus be detected.

The human mobility dataset is based on High-Frequency Location-Based Data (HFLBD) and capture only around 22% of the population. These data are then calibrated with population presence and density before the ingestion into a Generalized Radiation Model for mobility. This model provides a baseline commuting matrix to inform the trajectories expansion over different areas that can be classified as urban, countryside or highways. Consequently, estimates provided for Number of Trajectories, Congestion Index, Speed, Motorized Count, and Motorized Share may not be reflecting the reality of mobility on the ground with precision. Please not that it is one form of capturing people’s movement but likely not the most suitable.

Being a demonstrator on how to integrate and interactively compare air quality parameters versus mobility statistics, further validation is needed to be able to allow meaningful conclusions.

lubojr commented 1 year ago
  • mobility: remove/deactivate "dynamic human presence", dynamic human presence - we have to evaluate this full time series first a bit more (its the first time we see it) keep it in staging but do nor merge it into demo;

@patrick-griffiths Just for double checking, you meant to disable: Human Mobility Patterns and Dynamic human presence or just dynamic human presence? - if the first option, then it is now done on demo, while these indicators are still enabled on following deployment: https://gtif-testing.eox.at/gtif_mobi1_aq4_deploy/

santilland commented 1 year ago

mobility: remove/deactivate "dynamic human presence", dynamic human presence - we have to evaluate this full time series first a bit more (its the first time we see it) keep it in staging but do nor merge it into demo;

hello @patrick-griffiths about the mobility data, we really put quite some effort in being able to load the data yesterday and over the weekend, i think with the new daily aggregated data at least for human presence it is quite a nice thing to show, at least the time series. Having the disclaimer makes clear that the data needs to be consumed taken possible issue into account. image

I would propose to reactivate them.

Patrick1G commented 1 year ago

hink with the new daily aggregated data at least for human presence it is quite a nice thing to show, at least the time series.

okay @santilland lets keep them in, I was not aware of the time series functionality that is now enabled, nice indeed!

Patrick1G commented 1 year ago

@lubojr @santilland - a few small fixes:

Image

aljacob commented 1 year ago

on the layer selection there is still the wrong label of alpine drought exploratory-> should be Alpine Drought Observatory as well image

Antony-Delavois commented 1 year ago

Mobility disclaimer updated with more info on how mobility dataset is processed

https://github.com/eurodatacube/eodash/issues/2203#issuecomment-1569143310

Patrick1G commented 1 year ago

@santilland @Schpidi

When people post the GTIF URL the RACE preview is down. Very confusing. Please remove this!

ps://www.linkedin.com/posts/eo-eurac_rapid-action-for-citizens-with-earth-observation-activity-7069684242313584640-m0Ku?utm_source=share&utm_medium=member_android

santilland commented 1 year ago

@patrick-griffiths is it a specific url? the main gtif url expands with gtif information, e.g.: image

I see on linkedin it is showing something else, we will investigate tomorrow

Patrick1G commented 1 year ago

@patrick-griffiths is it a specific url? the main gtif url expands with gtif information, e.g.: image

LinkedIn post URL is above, I only see the general links to gtif.. Strange