Timeseries UI


The UI mockup shows 6 columns of measurements and counts (roads, buildings, poi, railways, coastlines, waterways) , As you can see below, there are additional measurements and counts available from osmesa (16 actually). Reducing the margins on the report would be a good idea, to make more space. And maybe add a tool for toggling columns on and off? (this is going to come up elsewhere too in Scoreboard, because landuse* and natural* are newly added categories and there should be a separate JIRA issue about adding those new columns to existing reports).
```
# measurements
- 'road_km'
- 'waterway_km'
- 'coastline_km'
- 'railline_km'
- 'landuse_km2'
- 'natural_km2'
# counts
- 'roads'
- 'waterways'
- 'coastlines'
- 'buildings'
- 'railway_features'
- 'raillines'
- 'pois'
- 'landuse'
- 'natural'
- 'other'
```
2. The Country column as shown in the UI mockup does not make sense to me, in this context. I think it was just copy-pasted from a previous User report. I propose strike the Country column because it seems convoluted with the countries dropdown. I think what’s shown in that Country column the user’s home country from the scoreboard profile/ preferences. The country dropdown would, instead, be filter for the timeseries query which is what we want I think.
3. Note in the UI mockup there are Teams and Campaigns dropdown menus in the report!!! That is going to be a heavy-ish lift for the UI dev and perhaps additional scoreboard business logic. Not sure how that’s going to work really. Probably needs discussion to get nailed down. The timeseries api is going to offer a set of filters, based on the osmesa db, but Teams and Campaigns are not among them. The filters will be `userIdsFilter` , `categoriesFilter` , `countriesFilter` , `hashtagsFilter` , `hashtagPrefixFilter` and of course, `startDate` , `endDate`.
In other words UI is going to have to come up with query parameters for these filters, make the timerseries api call, and then come up with the dropdown contents itself. I do not have a clear idea of the UI data flow- whether the dropdown menus would have to be constructed before, or after, making a timeseries query.
Later today I should have the openapi `api.yml` doc updated in scoreboard, which will show the proposed timeseries response data structure. Once that’s agreed upon, then @necoline you can start to build the UI, by mocking the api responses as much as that’s possible, and also deciding what additional business logic will need to be added to scoreboard to supplement what the timeseries api returns.