write ADR for Search by Location

[nziemecki]

Hi everyone! I'm Moki I'm working on my capstone for a Master's in GIS at Temple, and for my project I'm hoping to implement this seach by location feature into OpenDataPhilly. Lydia is my supervisor on the project, let me know if you have any feedback- this is my first ADR. I'm excited to be working on the website with you all!

[BryanQuigley]

Welcome! Looking forward to your contribution!

I think taking a few datasets and seeing what data you'd parse would be useful to do with the ADR.

Assuming you are not parsing a datasets actual data, I feel the datasets are generally:

• All of Philadelphia (all of the City of Phila category to my knowledge)
• A bigger region (AKA DVRPC or PATCO)
• State data
• A dataset that's national or bigger (aka WalkScore

In those cases, it makes a lot of sense to just tag them in some way in the dataset definition (the work to do that can be postgres, etc), but I wouldn't expect it to change almost ever.

If you are hoping to parse all the datasets - I'm not sure how feasible that will be. Maybe make it opt-in on a per dataset basis.
Also see concerns from #264

[rcheetham]

I like @BryanQuigley typology of city/county, regional, state, national/global and tagging this in the actual catalog entry and then limit your geo-enrichment process to city/county and regional data sets.

I would add to this by separating City/County datasets into a few categories as well:

• City datasets change daily or some other frequent basis and are stored in CARTO - for example 311 Service Requests at https://opendataphilly.org/datasets/311-service-and-information-requests/ and Crime Incidents at https://opendataphilly.org/datasets/crime-incidents/
• City datasets that are static (don't change much, unless they are re-published) and stored in ArcGIS - for example Air Monitoring Stations at https://opendataphilly.org/datasets/air-monitoring-stations/ and Land Use at https://opendataphilly.org/datasets/land-use/
• City datasets that are imagery - for example Land Cover Raster at https://opendataphilly.org/datasets/philadelphia-land-cover-raster/
• City datasets that are not geospatial - Campaign Finance Reports at https://opendataphilly.org/datasets/campaign-finance-reports/ and many others - some are static CSVs or Excel spreadsheets and others are served via CARTO.
• City datasets that are in other web sites - for example, PhillyHistory at https://opendataphilly.org/datasets/phillyhistoryorg/ and L&I Property History at https://opendataphilly.org/datasets/licenses-and-inspections-property-history/
• data that covers the City/County but is not provided by the City (so it comes in many forms) - here are three of them: https://opendataphilly.org/organizations/opendataphilly/
• probably some other category I'm not considering

I think you'll have to treat each of these differently and probably only address one type in an initial project. Obviously, the non-spatial data can't be done and imagery won't be meaningful. In addition, I think it will be very hard to develop the geographic summaries that you want the dynamic APIs, particularly the very large ones like property assessments and crime - it's not affordable to process them regularly and many of them are probably simply city-wide (in all geographic summary areas).

[lydiascarf]

I think we'll focus on this type of dataset type to start:

City datasets that are static (don't change much, unless they are re-published) and stored in ArcGIS - for example Air Monitoring Stations at https://opendataphilly.org/datasets/air-monitoring-stations/ and Land Use at https://opendataphilly.org/datasets/land-use/

We'll start by seeing what we can pull from a one-time analysis and put off handling updates. I think in general that each dataset's AOI is unlikely to change. We'll get a few datasets together and pull out the administrative boundaries as a proof of concept, then update this PR with our findings.