geographic grouping for v2 search results

[josh-chamberlain]

Context

Follows #249
Part of #250

Wireframe: https://www.figma.com/design/UsbyOrgtBnLMyyqlfqIOqm/PDAP-Theming?node-id=6076-734&t=axBdWzOC8o64cX1C-0

This is something that didn't make it into the requirements, but is now being added to the wireframe.

We have agencies.jurisdiction_type, with local county state federal. The other jurisdiction types school military tribal transit port can be considered variations of local too.

Requirements

Front end

• [ ] all geographic groupings start out collapsed by default, except the narrowest searched jurisdiction level

Example: if Pittsburgh, PA is selected we would first show locality-level sources from Pittsburgh, and include county-level sources for Allegheny County, and state-level sources for Pennsylvania. We wouldn't show other local results from the same county and state.

Example: if Allegheny County, PA is selected we would first show county-level sources from Allegheny County, then local sources from anywhere in the county. Grouping them this way should help people "drill down"

Back end

• [x] maybe: adjust the endpoint to show sources from "broader" jurisdiction types as described. It's possible the front end can just make use of the existing endpoints.

[joshuagraber]

maybe: adjust the endpoint to show sources from "broader" jurisdiction types as described. It's possible the front end can just make use of the existing endpoints.

@josh-chamberlain @maxachis I would prefer this, to avoid the kind of data manipulation and nested UI loops client-side that we were doing with the previous search results page. I understand this code because I wrote it, but my guess is that it's pretty opaque if someone else were to need to debug it or something.

So if the server could return something like this, it would be ideal from my perspective:

{
  count: <number>,
  state: {
    count: <number>,
    results: [<data-source-record>]
  },
  county: {
    count: <number>,
    results: [<data-source-record>]
  },
  locality: {
    count: <number>,
    results: [<data-source-record>]
  },
}

My hypothesis is that this can be done more succinctly and with better performance on the server, but if that's not the case, we can always re-shape the data on the client, no problem.

[joshuagraber]

@josh-chamberlain @maxachis Update on my comment above:

I actually can't filter this data on the client currently. There is no way to do it, as I have no means of distinguishing between which sources returned by the search location and record type endpoint are locality-, county-, or state-based.

So either I need a record_location_type property returned from the API, or the data to be returned from the API in the shape that I'm describing above.

In order to make this design work, we would also need broader location results returned by each level (i.e. county and state returned when the search is locality for instance), which isn't currently the case.

[maxachis]

@joshuagraber This is perfectly doable! I can work on addressing this!

[maxachis]

@joshuagraber @josh-chamberlain Search endpoint results updated! Have a looksee and let me know if this is conforming to what you expect.

[joshuagraber]

@maxachis Attempting to test locally this this morning, but I'm getting the following errors from app.py, which appears to be an issue with the bump to psycopg3?

  File "/Users/grabes/code/pdap/data-sources-app-v2/app.py", line 7, in <module>
    from resources.Callback import namespace_auth
  File "/Users/grabes/code/pdap/data-sources-app-v2/resources/Callback.py", line 2, in <module>
    from middleware.callback_primary_logic import (
  File "/Users/grabes/code/pdap/data-sources-app-v2/middleware/callback_primary_logic.py", line 7, in <module>
    from database_client.database_client import DatabaseClient
  File "/Users/grabes/code/pdap/data-sources-app-v2/database_client/database_client.py", line 9, in <module>
    import psycopg
  File "/Users/grabes/code/pdap/data-sources-app-v2/venv/lib/python3.11/site-packages/psycopg/__init__.py", line 9, in <module>
    from . import pq  # noqa: F401 import early to stabilize side effects
    ^^^^^^^^^^^^^^^^
  File "/Users/grabes/code/pdap/data-sources-app-v2/venv/lib/python3.11/site-packages/psycopg/pq/__init__.py", line 118, in <module>
    import_from_libpq()
  File "/Users/grabes/code/pdap/data-sources-app-v2/venv/lib/python3.11/site-packages/psycopg/pq/__init__.py", line 110, in import_from_libpq
    raise ImportError(
ImportError: no pq wrapper available.
Attempts made:
- couldn't import psycopg 'c' implementation: No module named 'psycopg_c'
- couldn't import psycopg 'binary' implementation: No module named 'psycopg_binary'
- couldn't import psycopg 'python' implementation: dlopen(/Users/grabes/opt/anaconda3/lib/libpq.dylib, 0x0006): tried: '/Users/grabes/opt/anaconda3/lib/libpq.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/grabes/opt/anaconda3/lib/libpq.dylib' (no such file), '/Users/grabes/opt/anaconda3/lib/libpq.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), '/Users/grabes/opt/anaconda3/lib/libpq.5.12.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/grabes/opt/anaconda3/lib/libpq.5.12.dylib' (no such file), '/Users/grabes/opt/anaconda3/lib/libpq.5.12.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64'))

EDIT: the first answer here solved it.

Also, looks great! Results are populating as expected, sorted by locality / county / state / federal. Much appreciated ❤️

[joshuagraber]

Hey @maxachis One very minor thing I'm noticing here. I'm no longer getting the state field returned for locality results. That's useful for displaying location in the UI, do you think we could bring it back?

[maxachis]

Hey @maxachis One very minor thing I'm noticing here. I'm no longer getting the state field returned for locality results. That's useful for displaying location in the UI, do you think we could bring it back?

Can do! To confirm: you mean the full name of the state as opposed to state_iso (which is, at least in my code, still present)?

[joshuagraber]

Can do! To confirm: you mean the full name of the state as opposed to state_iso (which is, at least in my code, still present)?

Ah, yeah, state_iso will work, sorry I thought I had seen state there previously. Thanks!