CTA bus ridership dataset is visualized on wrong field

[stevevance]

The CTA bus ridership dataset is visualized by the number of bus stops per grid, and not the number of boardings at stops in that grid.

There are definitely more than 62 boardings in this grid!

[WillEngler]

Hi Steve, thanks for bringing this to our attention. That map is very misleading!

Generating a map that depicted the number of riders per grid would require that we add a feature to sum (or apply aggregation functions more generally) to arbitrary columns within a boundary. That could be useful in many cases.

Our development time now (and for the coming months) is focused on features for Array of Things, so this will go on the backburner. However, as a short-term fix, we might consider blacklisting some datasets such that they are still available to discover and download, but they wouldn't display this kind of heat map when it doesn't make sense or is flat-out misleading.

[stevevance]

"they wouldn't display this kind of heat map when it doesn't make sense or is flat-out misleading"
Can you please do this?

This came to my attention because the Better Transit breakout group wanted to visualize more recent data about where people are boarding and alighting buses in Chicago. We throught that Plenario would be a good place to do that since it already had a process to take in submitted datasets and automatically visualize them. Before we submitted our new data we were going to take a look at this already-established CTA ridership dataset.

I stared at this dataset for a while before realizing why the map "felt" wrong.

[brlodi]

I'm removing the "front end" label from this, as there's not really anything that can be done there without a significant backend change.

/grid returns grid objects in the form

{
  "geometry": {
    "coordinates": [ ... ], 
    "type": "Polygon"
  },
  "properties": {
    "count": 3
  }, 
  "type": "Feature"
}

with only a single, non-semantic "count" property. The front-end has to assume the backend is making the correct decision re: that value.

At such time the API bug is fixed (perhaps by supplying named fields instead of just the single "count" property) we'll handle it as UrbanCCD-UChicago/plenario-explorer#15 about implementing the more detailed display as a front-end feature.