dogtoothdigital
commented
6 years ago Sorry. I can't delete this because of GitHub's constraints. I'm sorry; these things were present very early on -- I should have taken the hint and shut up about this. Bowing out again; all apologies...
Ex: http://housinginsights.org/tool/#/HI/ml=census_tract&sb=bdng&pu=4_717&ol=cv&cv=1_107
Range defaults to 1..107; in the map view the following ranges are given: 0 - 0 0 - 0 0 - 100 100 - 100 100 - 100 100
The census-tract-based map view shown implies that the underlying data set is being read and range-partitioned correctly into the chloropleth display but the correct range breakdown is not being displayed in the key overlaying the map.
On a related note, if one switches to Neighborhood Cluster (http://housinginsights.org/tool/#/HI/ml=neighborhood_cluster&sb=bdng&pu=4_717&ol=cv),, the range key overlay on the map also shows quirks: 0 - 100 100 - 100 100 - 200 200 - 300 300 - 300 300
This should of course be: 0 - 100 101 - 200 . . .
I'll take a look at the frontend code and see if anything jumps out; obviously it can't be as simple a fix as something rudimentary like this:
for (i=0; i < Math.ceil(max/range); i++) {range_start = (i>0 ? i*range+1 : i);range_end = Math.min((i+1)*range, max);// use each (range_start, range_end) to render any colored partitions// in the map and for the range key overlay}That's old-fashioned straightforward functional-style JS whereas I'm betting most of the frontend code is OO.