As A22 user I would like to see the traffic predictions on the highway through a specific web-component

[rcavaliere]

• Design of the web-component

On the A22 web-site, forecasts are displayed in this way:

The proposal could be to have two different type of views:

• a similar view as in the A22 web-site, with a configuration value to select the areas to which forecasts should be linked to (i.e. Brennero, Bolzano, Verona).

• a map based view, in which the "stations" are displayed on the map, and once you click on it you can visualize the calendar of the forecasts (just in one direction). From an implementation point of view, it could a web-component that uses another web-component (the calendar).

• Implementation of the web-component -> @rcavaliere will provide here specific details for the implementation

As far as the API call is related, with the following API call: https://mobility.api.opendatahub.com/v2/flat,node/TrafficForecast/* it is possible to get all reference locations with respect to which the traffic forecasts are computed. Locations have coordinates, which means that we could imagine to display everything on a map. We have at the moment:

• Bolzano South
• Bolzano North
• Brennero South
• Brennero North
• Verona South
• Verona North

The forecasts can be requested through a separate API call (link call to be inserted here xxx). Forecasts are related to a specific timestamp in the future, placed at the middle of the time intervals of three hours with which forecasts are computed. In other words:

• time interval 0 - 6 -> timestamp = 3 AM
• time interval 6 - 12 -> timestamp = 9 AM
• time interval 12 - 18 -> timestamp = 3 PM
• time interval 18 - 24 -> timestamp = 9 PM

For each day, we have 4 forecasts values.

In order to get the data, you should make this API call: https://mobility.api.opendatahub.testingmachine.eu/v2/flat,node/TrafficForecast/forecast/2025-01-14/2025-03-01?referer=test&limit=-1 (of course the start and end date should be changed dynamically)

[rcavaliere]

@MaxXx1313 @sh-olmedo please start with the design of this new web-component. The implementation is already possible since the data is here is already open

[rcavaliere]

@MaxXx1313 the Swagger of the Open Data Hub API (mobility) is available here: https://swagger.opendatahub.bz.it/?url=https://mobility.api.opendatahub.bz.it/v2/apispec

[rcavaliere]

@MaxXx1313 @sh-olmedo I have enriched the user story with the information about the API call to be used to retrieve the predictions: https://mobility.api.opendatahub.testingmachine.eu/v2/flat,node/TrafficForecast/forecast/2025-01-14/2025-03-01?referer=test&limit=-1

[danolman]

@rcavaliere I need to confirm if it's needed to add the PDF links present on the web components reference. If the answers is = yes, those links must be dynamic?

[rcavaliere]

@danolman no, this functionality is not necessary in our implementation

[MaxXx1313]

@rcavaliere Hi

I have a question about this part:

time interval 0 - 6 -> timestamp = 3 AM
time interval 6 - 12 -> timestamp = 9 AM
time interval 12 - 18 -> timestamp = 3 PM
time interval 18 - 24 -> timestamp = 9 PM

I guess the desired time field is mvalidtime, but the data from API server is confusing me, because the time values are: 3AM, 6AM, 9AM, 12AM only (Italian time 😉 ). I think this might be a mistake in API.
Here is the link to see:
https://mobility.api.opendatahub.com/v2/flat,node/TrafficForecast/forecast/2025-02-01/2025-02-02?select=mvalidtime

Please, let me know how we can proceed with this

[rcavaliere]

@MaxXx1313 yes, there is something strange here. @clezag can you please check? It is this Data Collector: https://github.com/noi-techpark/bdp-commons/tree/main/data-collectors/traffic-a22-forecast

[MaxXx1313]

Hi @rcavaliere
Is there any example or best practice to make multiple webcomponents in one repository? It could be some hints about where to put wcs-manifest.json, logo, etc.

[rcavaliere]

@clezag can you provide please some hints for @MaxXx1313 ?

[clezag]

@rcavaliere Hi

I have a question about this part:

time interval 0 - 6 -> timestamp = 3 AM
time interval 6 - 12 -> timestamp = 9 AM
time interval 12 - 18 -> timestamp = 3 PM
time interval 18 - 24 -> timestamp = 9 PM

I guess the desired time field is mvalidtime, but the data from API server is confusing me, because the time values are: 3AM, 6AM, 9AM, 12AM only (Italian time 😉 ). I think this might be a mistake in API. Here is the link to see: https://mobility.api.opendatahub.com/v2/flat,node/TrafficForecast/forecast/2025-02-01/2025-02-02?select=mvalidtime

Please, let me know how we can proceed with this

I'm not sure I understand the problem. I've looked at the data collector and it does roughly what Roberto described: It takes the initial timestamp of the 6h windows, and adds 3 hours to compute the timestamp that is then visible on the API.

[MaxXx1313]

From my perspective the result of https://mobility.api.opendatahub.com/v2/flat,node/TrafficForecast/forecast/2025-02-01/2025-02-02?select=mvalidtime should be the following (_timestamp field is removed to reduce text size):

{
  "offset": 0,
  "data": [
    {
      "mvalidtime": "2025-02-01 02:00:00.000+0000"
    },
    {
      "mvalidtime": "2025-02-01 08:00:00.000+0000"
    },
    {
      "mvalidtime": "2025-02-01 14:00:00.000+0000"
    },
    {
      "mvalidtime": "2025-02-01 20:00:00.000+0000"
    }
  ],
  "limit": 200
}

However it's the following (time value is different):

{
  "offset": 0,
  "data": [
    {
      "mvalidtime": "2025-02-01 02:00:00.000+0000"
    },
    {
      "mvalidtime": "2025-02-01 05:00:00.000+0000"
    },
    {
      "mvalidtime": "2025-02-01 08:00:00.000+0000"
    },
    {
      "mvalidtime": "2025-02-01 11:00:00.000+0000"
    }
  ],
  "limit": 200
}

[rcavaliere]

@MaxXx1313 @clezag I think that the timestamps should be different with respect to what you reported above, i.e. they are currently not properly set in our integration in the Open Data Hub, but should be 3 AM, 9 AM, 3 PM and 9 PM. I think @clezag we need to check how these timestamps are currently assigned. However, @MaxXx1313, I don't know if this of particular relevance for your implementation: the important thing is that you have 4 values per day and you can properly visualize them as in the design.

[MaxXx1313]

@rcavaliere
For the implementation it's important to define the way to get a day interval. It's not a blocker for me to implement any of them, but I think any issue should be fixed before the final release.
I see two options here:

1. (current option) define by time value: [0; 6), [6; 12), [12, 18), [18, 24). This is already implemented.
2. we can sort results by time, then take the first four values and assume it's the values for: 3am, 9am, 3pm, 9pm. I personally don't like this approach, because I see it as less stable than the other one.

So, if we stick to the current option - no changes needed from my side.

[rcavaliere]

@MaxXx1313 yes, important thing is that in 1. you assign these time slots with the proper records provided by API. If you make this assigning by an increasing order in the day (i.e. [0; 6) to the record with lowest timestamp, and so on), than also for me there shouldn't be any other necessities for improvements. But let's check this together when the prototype web component is available

[clezag]

Hi @rcavaliere Is there any example or best practice to make multiple webcomponents in one repository? It could be some hints about where to put wcs-manifest.json, logo, etc.

We've consulted internally, and unfortunately multiple components per repo at this time are not and will not be supported. We'd like to keep the standard layout from the boilerplate repo for all webcomponents.

We'll have to set up a second repo. I can create a bare one, fork the current one, or for a repo of yours. Please let me know which way you prefer

[clezag]

@MaxXx1313 @clezag I think that the timestamps should be different with respect to what you reported above, i.e. they are currently not properly set in our integration in the Open Data Hub, but should be 3 AM, 9 AM, 3 PM and 9 PM. I think @clezag we need to check how these timestamps are currently assigned. However, @MaxXx1313, I don't know if this of particular relevance for your implementation: the important thing is that you have 4 values per day and you can properly visualize them as in the design.

Should be fixed now, I've re-imported the whole history with the correct timestamps

[MaxXx1313]

API issue is fixed, thank you!

[MaxXx1313]

Here are some screenshots of the current result.
As soon as a dedicated repo is created for that component - I'll push it and create a pull request.

Also, with CSS it's possible to adjust most of the styles, for example to create dark mode:

Also, mobile view:

[MaxXx1313]

We are waiting for another repo created dedicated to that feature

[clezag]

We are waiting for another repo created dedicated to that feature

Repo is up now, let me know if you need anything else to get started:

https://github.com/noi-techpark/webcomp-a22-traffic-forecast

[MaxXx1313]

Here is pull request: noi-techpark/webcomp-a22-traffic-forecast#1