Propose site structure

[swashcap]

👋 Hello! We don't yet have a way of tracking conversations or project decisions. GitHub issues seem like a lightweight, accessible solution?

I'm creating this issue to start discussion on the site's structure. Currently:

• Home page
• Air Reports: http://pdxcleanair.org/files/pcapubs.html
• Data: http://pdxcleanair.org/files/pcadata.html
• Detail files: http://www.portlandcleanair.org/files/detailed_co_info/
  • Drill down to individual sites, referenced by home page map
• Some other dangling pages (probably)

Things to keep in mind:

• The records on http://pdxcleanair.org/ weren't publicly accessible until Cascade Action requested them. This site is (likely?) the only place these records exist.
• The primary goal is to surface records and data to site visitors. We want to visualize the data in meaningful ways to visitors.

[swashcap]

Given current structure, I propose this new structure:

Name	URL	Description
Home	/	Index of site, link to other sections
About Us	/about/	Info on organization, on going work
Data	/data/	Link to retrieved data
Location details	/locations/:id/	DEQ, chem storage info for a location
Map	/map/	Interactive map linking to locations
Neighborhoods	/neighborhoods/	Link to neighborhood-specific reports
Reports	/reports/	List of all reports, link to reports' data

• portlandcleanair.org and pdxcleanair.org URLs used interchangeably, which is confusing to visitors. Suggest we pick 1 and set up 301 redirects on the other domain.
• We should put put in the following 301s:
  • /files/pcapubs.html → /reports/
  • /files/pcadata.html → /data/
  • /files/detailed_co_info/(.*) → /locations/$1
• I propose not changing the location of PDFs, at least in the short term. I noticed PDFs reference other PDFs by hard-coded URL (example here: http://pdxcleanair.org/files/reports/polluter%20health%20risk%20PCA%202020.pdf).

[cdaringe]

Yes, I think these are great ideas. I'm tempted to map /locations/:id => /{polluters,emitters,dischargers,etc}/:id. What's your take

[swashcap]

I'm tempted to map /locations/:id => /{polluters,emitters,dischargers,etc}/:id

Just because a location is tracked doesn't necessarily mean it corresponds to a polluter, right? A business may have a DEQ permit onsite chemical storage permit, but the business doesn't emit any nasties. Is this correct?

[swashcap]

Some designs to go along with this structure conversation.

Location details

Goals:

• Add visual interest by showing location on map
• Bring useful location metadata found in current map's panel
• Tidy up text, tables

Reports

Goals:

• Improve hierarchy to support browse-ability
  • This structure would work for the "Data" page, too
• Indicate that links navigate to PDFs (or external sources for the Collaborative section)
• Explore footer

Neighborhoods

Goals:

• Present a map for folks to visually identify their area
• Have some text fallback for visitors who prefer/need text
• Indicate that links navigate to PDFs or external sources

[cdaringe]

Is this correct?

I forwarded it onto Greg. Hopefully he can pipe in! :)

[cdaringe]

From Greg,

• Cascadia Action, a 501(c)(3) can make no statement in support of PCA, a 501(c)(4). PCA can and does support Cascadia Action
• All industries on the map on front page are emitters of industrial air pollution. If they have a DEQ ACDP then they all emit. If it is EPA data such as airports and rail yards then they all emit. If the data is only Oregon Fire Marshall (red dots on map) then we removed NAICS coded industries denoting hazardous chemical storage and warehousing so all hazardous chemicals are in use, thus they emit
• permit linked twice, only once needed
• Add risk (cancers per million or hazard index) for each chemical line item. I will do a wrote up in the next week.

So, pretty straight forward stuff/remarks. Green light, let's get a POC of these designs goin. Next, 11ty, whichever! www repo is available now with some of these source datas. In some cases it's a bit to untangle, but otherwise content is present! The big missing big is that the scans PDFs from DEQ need to be auto-generated post clone. Will need to come up w/ a reproducibility strategy--docker, (nixpkgs)[https://nixos.org/], etc. I found my mac yielded slightly different outcomes, and further, versions of the commands had evolved, so the OCR parse was different. I may focus on that aspect next.

Let me know if you'd like to pair on any of this!