In Chicago, we initially split up the city based on neighborhoods. But since that time, we've started working with the offices for different Wards in the city, as opposed to neighborhoods or the larger city government. This leads to a few problems:
When we start working with a ward and want to audit their streets, they can be spread across multiple neighborhoods, and not include all the streets in those neighborhoods. Even worse is when we've already opened up a different part of a neighborhood for a different purpose... Now if users want to audit in their ward, they might have to use RouteBuilder to ensure that they're auditing where they want to, or risk working on a different ward that happens to share the neighborhood.
Viewing the data has a similar issue. I recently added the ability to filter on neighborhood in Gallery, at the request of folks in Chicago. But if a neighborhood has data from multiple wards, users in that ward won't know if the data is from the correct ward! This is also a problem in LabelMap, of course less so because you have a map as context. But our Results map and Access Score API are tied to the neighborhood boundaries that we have in our system.
Potential solution(s)
On the back end, we need to add the ability to add different types of "region" boundaries. We would add a column with the type of boundary that is stored there, and a way to denote the "primary" boundary set. This should be straightforward.
For our maps (and Gallery), in the cities where there are multiple types of boundaries, we could add some sort of widget to the maps that will switch between the boundary types.
Maybe users can set a default view of the data in their profile? Or just keep whatever they used last?
I could see this being useful outside of our experience in Chicago. For example, we could add in boundaries for things like census blocks, land use, etc. We usually have easy access to a lot of those datasets on open data websites, and it would be easy to add them into our database once this is set up. And then users could visually analyze data based on things like census block without needing to use our APIs and find those other data source themselves.
The problem of auditing outside the ward you're trying to audit in is harder to fix because of how our system works, but it could be done in a somewhat hacky way in the very least! Similar to how auditing a Route from RouteBuilder only sends a subset of the streets to the front end. This would probably be easiest to do after we add the ability to audit routes that spread across multiple neighborhoods (#3488)!
Brief description of problem/feature
In Chicago, we initially split up the city based on neighborhoods. But since that time, we've started working with the offices for different Wards in the city, as opposed to neighborhoods or the larger city government. This leads to a few problems:
Potential solution(s)
On the back end, we need to add the ability to add different types of "region" boundaries. We would add a column with the type of boundary that is stored there, and a way to denote the "primary" boundary set. This should be straightforward.
For our maps (and Gallery), in the cities where there are multiple types of boundaries, we could add some sort of widget to the maps that will switch between the boundary types.
Maybe users can set a default view of the data in their profile? Or just keep whatever they used last?
I could see this being useful outside of our experience in Chicago. For example, we could add in boundaries for things like census blocks, land use, etc. We usually have easy access to a lot of those datasets on open data websites, and it would be easy to add them into our database once this is set up. And then users could visually analyze data based on things like census block without needing to use our APIs and find those other data source themselves.
The problem of auditing outside the ward you're trying to audit in is harder to fix because of how our system works, but it could be done in a somewhat hacky way in the very least! Similar to how auditing a Route from RouteBuilder only sends a subset of the streets to the front end. This would probably be easiest to do after we add the ability to audit routes that spread across multiple neighborhoods (#3488)!