Census: create nested routed panels

[rperlin-ela]

Jason edits

this was originally about census legend and some content stuff but evolved into routing and structure, so i want to preserve the thread below. basically just follow the stuff we settled on in there.

broke this out into #203 and others. anything w/census in the issue title is related.

definitely need to complete #206 first. And don't forget about auto-zoom to selected polygon!

[abettermap]

@rperlin-ela instead of popup crammage, how would you feel about a dedicated route and view?

1. "Bengali" in the census dropdown, it would take you to /census/PUMA/Bengali
2. the map would auto-zoom as usual by default
3. the panel title would be "Bengali (PUMA-level census)" or whatever makes sense
4. some kind of intro text if needed.
5. the gradient legend would be shown rather than below the census dropdown like we'd planned. i think this would help reinforce that the legend only applies to the current language rather than promoting possible confusion as to why the numbers keep changing on a legend that we were going to show in a consistent panel view at the "/census" level.
6. A < Back btn or whatever we call it, that takes you either to /census/PUMA which could have some PUMA-specific text and perhaps all the fields as a list rather than a dropdown
7. OR, skip the /census/PUMA level and have Back go up to /census (i don't like this since it's one of those edge cases while the other 98% of the app doesn't do that).
8. IF TIME AND IF I FEEL THERE'S ENOUGH SOW AMBIGUITY TO ALLOW IT, after the gradient legend, a list of links to other Languages which are also covered by the current census category. I'll see your cross-panel navigation request, and raise you one related nav list.

the fact that everything is in Airtable makes it easier, so let me know what you think. hopefully you can imagine some of the concepts w/o a visual, those babies take time!

[abettermap]

oh and one level deeper would be when the user clicks a census polygon, e.g.

/census/PUMA/Bengali/3603701

or if you want to make it easier on me airtable-wise, use the field name:

/census/PUMA/F3112_Bengali/3603701

(the number is just the GEOID field, which is the unique id for that table)

There wouldn't be much to the panel view for that level, but it would be nice and consistent with the whole "map, views, and URLs are all super-related" for every layer in the project (except Counties). the same behavior would occur on click or selection: map opens popup and zooms to extent of the selected feature, or at least as close as it still makes sense to, like probably not allll the way down to the tract outline. we could have a cutoff zoom like we're using for points currently instead of zooming allllll the way in to them.

as for the panel view content at /census/PUMA/F3112_Bengali/3603701, it would mainly just be the GEOID i guess (which is not very useful for PUMA, but tracts are better), a Back btn to /census/PUMA/F3112_Bengali, and whatever census blurb/s you need. Oh and of course the numeric value (aka number of speakers) of that particular polygon.

it would be cool if it could provide a list of ELA points which fall within that polygon, but we don't really have a tie between that data and the polygon level in airtable, it's mostly just "this Language uses this census category", and without some kind of geospatial server I'm not sure how we could query the AT data for a list of points.

total overkill anyway, but the main thing here is that i'd like /census/:granularity/:field_name/:GEOID to be a route and view, so that it's consistent w/the rest.

if you're on board w/the "list of links to other Languages" i suggested above, that's my price: one more level of route depth for consistency. ☝️

[rperlin-ela]

This sounds pretty good to me— I don’t love pop-ups for pop-ups’ sake, and routing is a handy addition, especially for things like /census/PUMA/Bengali.

I don’t want people to get lost in the likes of /census/PUMA/ or /census/PUMA/Bengali/3603701, but I understand consistency, and if you’re open to it, maybe I can think of some relative simple things to make those a little more interesting :) The "list of links to other Languages” is of course a pretty interesting proposition. So all in all sounds like a good direction to me, but definitely gonna be some things to work out, and I can’t say I can picture all of it yet.

On Mar 20, 2021, at 4:44 PM, Jason Lampel @.***> wrote:

oh and one level deeper would be when the user clicks a census polygon, e.g.

/census/PUMA/Bengali/3603701

or if you want to make it easier on me airtable-wise, use the field name:

/census/PUMA/F3112_Bengali/3603701

(the number is just the GEOID field, which is the unique id for that table)

There wouldn't be much to the panel view for that level, but it would be nice and consistent with the whole "map, views, and URLs are all super-related" for every layer in the project (except Counties). the same behavior would occur on click or selection: map opens popup and zooms to extent of the selected feature, or at least as close as it still makes sense to, like probably not allll the way down to the tract outline. we could have a cutoff zoom like we're using for points currently instead of zooming allllll the way in to them.

as for the panel view content at /census/PUMA/F3112_Bengali/3603701, it would mainly just be the GEOID i guess (which is not very useful for PUMA, but tracts are better), a Back btn to /census/PUMA/F3112_Bengali, and whatever census blurb/s you need. Oh and of course the numeric value (aka number of speakers) of that particular polygon.

it would be cool if it could provide a list of ELA points which fall within that polygon, but we don't really have a tie between that data and the polygon level in airtable, it's mostly just "this Language uses this census category", and without some kind of geospatial server I'm not sure how we could query the AT data for a list of points.

total overkill anyway, but the main thing here is that i'd like /census/:granularity/:field_name/:GEOID to be a route and view, so that it's consistent w/the rest.

if you're on board w/the "list of links to other Languages" i suggested above, that's my price: one more level of route depth for consistency. ☝️

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/202#issuecomment-803460618, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5BEQ75FXG6E2IRDIALTEUCKVANCNFSM4ZP5BVLQ.

[abettermap]

i'm open if it's not crazy hard. i'm planning on just using the data we already have to work with (# of speakers, tract/puma name, etc.).

if you're not into the mid-level censusing though, how about this:

1. the /census/PUMA/Bengali/3603701 level has the legend, the current # of speakers value for that tract or puma polygon, AND (if you want) the "list of links to other Languages”. the title for the view would be an unintuitive 3603701 but +1 for consistency. the subtitle would either be 'X number of speakers', or 'Bengali (PUMA)' or something similar. the map auto-zooms to the polygon extent or pretty close.
2. the Back btn for that 3603701 level does what you'd expect: goes to /census/PUMA/Bengali. this view also gets the legend, links list, has "Bengali" as title, "PUMA" as subtitle, buuuuut
3. ...for the Back btn instead of taking you to /census/PUMA, do a redirect (i think the routing lib i'm using does this) to skip over it and go straight to /census since i don't imagine your average user will care about the distinction between /census/PUMA and /census/tract (plus we already have a nice dropdown with a comprehensive set for both.

my take on that:

1. would 1 and 2 above be different enough? should we not have language links list in 3603701 level?
2. i think 3 is straightforward code-wise for the redirect, but i don't want to get into the mess of the "Back" split btn timeline, where the keen user spots the /census/PUMA level in the timeline and wonders why they've been shorted when they click Back at /census/PUMA/Bengali.
3. emphasis on "keen user". many will not spot and/or understand it. plus it's technically not wrong- if you click "PUMA" in timeline, it would just redirect to... /census, which in fact just happens to have a dropdown w/pumage in it.

WHEW. much stuff. heavy UI-ness. let me know thoughtsssss

[rperlin-ela]

good. I like all 3 points a lot, but just checking for Point 1 (just re: PUMAs, not census tracts) whether we’ve ever talked about putting in the corresponding neighborhood-based “PUMA names” somewhere, as opposed to just the opaque numerical code? If not, that would be a good addition.

I feel like I’ve sent this map before at least to Maya (https://www1.nyc.gov/assets/planning/download/pdf/data-maps/nyc-population/census2010/puma_cd_map.pdf) — it does get updated every 10 years (including later this year). What I’m imagining for 1 is that we’d have also (linked?) nabes in or near the subtitle. Hopefully just a column we can fill on on AT (in the NYC Census base?) or maybe it’s something needed in Mapbox? It’s true that these “PUMA names” won’t correspond very exactly to our Neighborhoods layer, but they would make the whole thing a little friendlier and more dynamic, no? I could see it both ways in terms of whether “List of links to other Langs” should also be at the deepest level.

[abettermap]

My bad, I forgot about the friendly names for the puma polygons. Yes I'll use those. I think it's only the census tracts that have opaque numbers?

I will definitely use the neighborhood name for puma, but it won't be linkable to our neighborhoods views due to the naming discrepancies, and we won't have time in this scope to link them up somehow. So you'll have to settle for no links to neighborhoods panel views.

[rperlin-ela]

Ok, I can live without the links, and hopefully it'll be quick to add the names in the right place when the time comes. Yeah, nothing to do about the census tracts, numbers seems fine.

[abettermap]

Sounds good. If you want the puma thing down the road, create an issue so we don't lose track. You can even use the … button top right of this comment to reference in a new issue. Then just clean up a little the text it suggests.

[rperlin-ela]

Matt or I can do this ASAP if it's as simple as I'm hoping on the AT end — just create a column called "PUMA name" next to GEOID in NYC Census Data base > PUMA?

[abettermap]

I'm actually going to rename GEOID to name for consistency with other tables. Can you call the new column Neighborhood? I'm not sure I understand how puma would correspond with neighborhood since their geometry is not the same and they may not overlap correctly, but at the end of the day it's just a new column for me so go for it.

No promises I'll be able to add this in this scope though, I feel like we've just added about 15 new features to the scope in the last 24 hours, but feel free to make the column and populate it, it's not hurting anything.

[rperlin-ela]

Ok, we've got the new Neighborhood column in the Census base, next to GEOID (or name or whatever you want to call it). Hopefully straightforward and something nice we can drop into the PUMA pages.

[abettermap]

ok cool. my head still isn't in the neighborhood/census space yet, i think next week will be the shifting of gears. column looks good though, for displaying it in the app at least, but i wouldn't lean on it for querying down the road.

The old name?

just to confirm, we are not using NAMELSAD for anything either in AT or MB? your custom Neighborhoods column is all we need?

if so i think that's fine. i'll need to think through the dreaded popups, but i think all i need is the "GEOID" in MB, and i'll use that to hit AT.

just to confirm how we're using your new column:

/Census/PUMA/F3112__Bengali/3603701 would take you to a view with:

1. Riverdale, Fieldston & Kingsbridge as the panel title
2. PUMA census data or similar as the subtitle or maybe the friendly language name of the census language that's currently selected?
3. some kind of blurb/info below that in the panel intro maybe, nice and generic for all

below all that would be the polygon-specific stuff, along with the "friendly" name:

1. "There are 178 speakers of Bengali"
2. What else?

[rperlin-ela]

Yep, Neighborhoods can replace NAMELSAD

And yes, I can picture something simple like, might be all we need:

Riverdale, Fieldston & Kingsbridge Census data (PUMA-level)

178 speakers of Bengali are estimated to live in PUMA #XXX.

On Mar 25, 2021, at 11:52 AM, Jason Lampel @.***> wrote:

ok cool. my head still isn't in the neighborhood/census space yet, i think next week will be the shifting of gears. column looks good though, for displaying it in the app at least, but i wouldn't lean on it for querying down the road.

The old name?

just to confirm, we are not using NAMELSAD for anything either in AT or MB? your custom Neighborhoods column is all we need?

https://user-images.githubusercontent.com/4974087/112501233-b0510f80-8d4e-11eb-9a28-b2bee4854d16.png if so i think that's fine. i'll need to think through the dreaded popups, but i think all i need is the "GEOID" in MB, and i'll use that to hit AT.

just to confirm how we're using your new column:

/Census/PUMA/F3112__Bengali/3603701 would take you to a view with:

Riverdale, Fieldston & Kingsbridge as the panel title PUMA census data or similar as the subtitle or maybe the friendly language name of the census language that's currently selected? some kind of blurb/info below that in the panel intro maybe, nice and generic for all below all that would be the polygon-specific stuff, along with the "friendly" name:

"There are 178 speakers of Bengali" What else? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/202#issuecomment-806987058, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5CJTE7XLJXH32UKOQDTFNL2NANCNFSM4ZP5BVLQ.

[abettermap]

cool, i think on Maya's next puma upload to mb we should:

1. rename GEOID to id for simplicity
2. remove the NAMELSAD field.
3. add the bounds fields

and in AT rename puma -> Neighborhood to name. you can add a column description to mention Neighborhood if you want, but this makes it consistent w/pretty much all our other tables.

then i'll lean on AT for 100% of the info for popups and all things census.

[abettermap]

thought i punted this to next week, but guess not. doing so now.

[abettermap]

@rperlin-ela got some options for popups...

tracts

whatever you go with, remember there are some monsters:

puma

my take

i could see 1000 different variations of this, but the "number of speakers" part is probably the most important bit, followed by the pretty language name. so those things should be the heading and we just suck it up for the few big guys:

the tract ID is not meaningful to anyone so

yours

supply me:

• puma heading
• tract heading
• puma subhead
• tract subhead

...exact wording and i'll wire them up. easy to customize.

[abettermap]

(supply me in GH, that is. too dynamic for AT i think)

[abettermap]

also not terrible:

i'm not married to any of these, several good options, just let me know

[rperlin-ela]

I think I like "also not terrible" the best, but I'll take any of "your take". good?

On Fri, Apr 2, 2021 at 12:55 PM Jason Lampel @.***> wrote:

also not terrible:

[image: image] https://user-images.githubusercontent.com/4974087/113436341-c770ac80-93a1-11eb-9ce2-65219eb254d7.png

i'm not married to any of these, several good options, just let me know

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Language-Mapping/language-map/issues/202#issuecomment-812614370, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNKB5A3NTH5WJWDPNPGO73TGXZG5ANCNFSM4ZP5BVLQ .

[abettermap]

works for me