Considerations:
PostgreSQL:
- no changes should be necessary here, data already exists
Django:
- search services will need to be parameterized to support include/exclude of retired addresses
- if we show retired data on the map, then the map services will need to be updated.... but how? (see below [Front-end/Map])
Front-end:
- Should we have a "global" control for toggling include/exclude of retired addresses?
- Following widgets will display retired data:
- Search:
- Search uses paging; as such we cannot simply filter these data on the client. Services will need to be parameterized and the widget updated accordingly.
- Search Results:
- Do we clear, refresh or do nothing when include/exclude of retired is toggled? (matters where we put toggle control, I think...)
- Map:
- Do we want to display retired data on the map at all?
- I think that we probably should provide a way to visualize the retired data on the map, but it may suffice to only allow the users to do this via the search results (zoom link and hover over row to show on map)
- Should retired addresses be a separate "layer" (and thus a separate service) or should retired addresses simply be filtered from the current layer?
- If we must show retired data on map, my preference would be to filter in the current layer; the reason that stands out to me is that then we could easily cluster both retired and unretired data, which will likely often be coincident
- If we filter in the current layer, do we filter on client or server?
- In keeping with move towards client side clustering, my preference would be to filter on client
- If shown, retired addresses will need to be distinguishable on the map; styling possibilities:
- "mute" default address point slightly
- use halo or outline to distinguish
- Add graphic (as with invalid addresses)
- Do we want to display retired data on the map at all?
- Address Report:
- Retired data in reports (units/parcels) should probably be filtered on the client
- Do we have an embedded control for toggling include/exclude of inside report?
- Will need to update report to include retired date data (for both base address details and grids)
- Search:
Implementation:
- Parameterize search services to accept a boolean parameter to dictate inclusion/exclusion of retired data
- Add a checkbox or button next to the search combo box to toggle include/exclude of retired data in search; this checkbox will set the new search parameter
- Toggling checkbox will simply clear any existing search results
- The only mechanism for visualizing retired data on the map will be the search results (zoom link and hover to show on map)
- Address report services will need to be updated to return all (retired & un-retired) data
- Address report will have a similar button/checkbox in it's header to toggle inclusion/exclusion of retired data; the state of this control will reflect the state of the control for the search by default.
- Report services will always return all data so the report will need to be updated to filter this data on the client; filtering will only need to take place in grids
- Grids and details tab of report will need to be updated to show retired tms
Extension to Support Lineage
- Support browsing lineage via Address Reports
- Users could browse lineage backwards and forwards using the report
- Perhaps we could just add two tabs (or maybe just one) in report, one to show immediate ancestors and one to show immediate descendants and just display these tab(s) where appropriate when the user shows retired data in the report...
- Support browsing address lineage via Reports/Search Results
- Reports (and maybe search results) contain links to populate search results with either ancestor or descendant addresses; search would then go into "include retired" mode
- Support browsing address lineage via some new specialized widget...?
Add Comment