Enhance time to close calculation to distinguish between pre- or post-2015 ward boundaries

[cgansen]

Allow for the time-to-close endpoint to calculate the time to close based on the pre- or post-2015 ward boundaries.

This allows us to say: SR in Ward 50 average 4.5 days TTC. SR in future Ward 50 average 4.1 days TTC.

@santheo is this adequate? I am wary of trying to calculate the TTC for anything but wards.

[santheo]

I hate to say it, but I don't think it is. I think a comparison like this isn't that meaningful. Meaning comes from seeing how your alderman currently treats those parts of her ward that are going to leave.

If we show numbers about post-2015 wards, I don't see what there is to gain from it. We'd be seeing numbers for how a bunch of currently unrelated aldermen (or citizens) performed, in aggregate.

Could we come up with arbitrary numbers for each of the transition blobs, and then note for each request, which blob # it's in? (If it is in one.) Then we could do calculations to see TTC averages on those requests that are in Ward N (but moving) vs those in Ward N (and moving to a new Ward in 2015).

I mean, easy for me to say, I know.

[cgansen]

In short, you want to:

• show each individual transition blob
• show the average time to close for SR located within each chunk
• compare the TTC of a given blob with its containing ward

Yes?

[santheo]

The second bullet can be:

• show the average time-to-close for all the SRs located within all the chunks
• compare the TTC of all the Ward blobs to the TTC of the rest of the Ward

That is, there's two numbers: TTCs for those SRs attached to addresses that are staying, vs those that aren't.