Initial working version of frontpage map

[garrettdashnelson]

Preview: https://deploy-preview-86--argo-astro-dev.netlify.app

@almontg @hkemp2128 @emilyrbowe - This is a first working version of a properly componentized, clean-data map view for the front page. I recognize that it doesn't look or work exactly like the version on ARGO v0, but it's a place to start.

Right now, the slider will (in real time) scrub through the bounding boxes of maps by size. It's (IMO) actually a really cool way of visualizing the coverage area of ARGO collections at various scales. When you click on the map, you'll either get a "no maps here" alert, or you'll be taken to the first map at the filtered view scale where you've clicked. Ultimately this should be changed so that it opens the "Drawer" component with a list of all the maps at the clicked location.

LMK if you think this is viable for the initial switch-over to nARGO.

An easy todo that I'd like to implement is changing the basemap to something more simple, with fewer modern features like highways and administrative boundaries.

@alexandergknoll After the project team has a chance to weigh in above, feel free to review the code and approve a merge in to main as long as you're OK with it. Everything here should be pretty self contained, though there is definitely a bit of ... ahem idiosyncratic ... choices I made about some of the geospatial stuff, which I'll try to improve down the line. On line 139 of SearchByMap.astro I have indicated where it should eventually get wired up to the "Drawer" component.

[netlify[bot]]

✅ Deploy Preview for argo-astro-dev ready!

Name	Link
🔨 Latest commit	22b870310f33cd372d3ea62cbb76f9e762f33fde
🔍 Latest deploy log	https://app.netlify.com/sites/argo-astro-dev/deploys/65e9b8ac53e5600008bd617a
😎 Deploy Preview	https://deploy-preview-86--argo-astro-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[hkemp2128]

I like the idea of showing general coverage over individual dots (which felt like it would be overwhelming to a neutral observer), but I'm not sure the advantage of showing so many overlapping zones at one time; it feels just as overwhelming to look at. I feel like it needs some sort of further labeling to clear up exactly what is going on. My concern is that I'm not sure I'd know what's going on if I hadn't read your message. I do approve of moving this direction for the future of the map view, though; I think there's a lot of promise here, and if we can get it looking cleaner by launch then I'm all for it. Also completely agree with your thoughts on making the base map a little more simplistic.

Also, just out of curiosity, how are those bounding boxes determined? Clicking around, some of them seem a little (or a lot) off.

[almontg]

I really like the slider! It works really well and accomplishes the goal of the map view of filtering out by scale in a straightforward way so users don't get overwhelmed by maps of all of North America when what they really want is Boston. I think this is a good direction and also agree wholeheartedly with moving to a simpler base map.

To follow up on Henry's question, though, I seem to recall in earlier conversations you telling me that we only have the bounding box info for some of the maps -- do you have a sense of a rough percentage? One thing I did like about the old view was that it had a method for sorting out maps that lacked scale, and I wonder if there's a way to also bring that into the new version in the future to improve the amount of maps which can be browsed in this way.

Overall though I'm very happy with this

[emilyrbowe]

I really like the functionality as well and agree with Ala that eventually it would be nice to have a way to also have dots(?) for maps that don't have bounding boxes in their metadata. (By the way, @hkemp2128, I am 90% sure that the BBs are input by whatever librarian did the cataloging/metadata entry, so we are just receiving that data and then displaying it.)

The one other (nitpicky) thing is that I'm not totally sure "Filtered by size" is the most clear way to articulate that point. Wondering if it's just as simple as saying, "Filtered by scale". It's not huge and if it stayed as is, I think it would be fine, but size/scale seem slightly different here.

[garrettdashnelson]

Couple answers to some of these questions:

1. Bounding boxes are entered by cataloging librarians and are part of the repository metadata, if available. (The field name is subject_bbox_geospatial if you're looking at the repository object metadata API). If they're incorrect, it means that whoever cataloged them entered them incorrectly; we can correct them with a repository metadata correction ticket. I should note, as an aside, that these are strict grid-aligned spatial envelopes—in other words, they mark the farthest north, east, south, and west point that appears on a map. This can mean that the envelope is quite a bit larger than the actual map itself. (One other aside: the terms bounding box, envelope, and extent are essentially interchangeable for this purpose).
2. Currently 1005 ARGO collections records have bounding box metadata.
3. My concern about using "Filtered by scale" is first of all I'm not sure that term is always as legible for non-experts, and especially because there can be confusion around whether we're using the cartographic usage of large/small (where large-scale = small area and small-scale = large area) or the most common vernacular usage (large-scale = large area).
4. I think we should probably have a conversation at the next project checkin about how we might want to represent maps with centroids (i.e., single points) but not bounding boxes.

[garrettdashnelson]

Also, it would be very easy to tighten up the number of maps shown at each point on the scrubber/range bar. Right now it's selecting everything ±20% of the point on the range slider, but I could change it to ±10% or similar; that would make fewer objects appear at any given point on the slider.

[almontg]

@garrettdashnelson that all sounds good to me -- if we can sneak a note in somewhere so users know that the map isn't displaying the entire collection I'm more than happy to kick the can down the road on maps with centroids/no scale and other cases. Also I agree about the language-- I think smaller/larger is more legible than scale for most non-experts.

[hkemp2128]

Thank you for the clarification! This all sounds great to me too; I'm really happy about moving forward with this concept

[emilyrbowe]

Great explanations, @garrettdashnelson. I'm down for keeping the "smaller/larger" terminology, just wanted to check in with you three to see if I was overthinking it (narrator voice: "she was").

This seems like a go to merge in for Milestone 3!

[garrettdashnelson]

OK, @almontg @hkemp2128 @emilyrbowe take a look at the changes I've just added to this preview, which include:

1. Simpler base map style
2. Tweaks to the numerical range function underlying the slider
3. Probably most noticeably/importantly, a shift from "smallest/largest" at either end to instead use some descriptive guidelines for what maps at various scales actually show.

[garrettdashnelson]

Perfect—I had noticed yesterday what I designed wasn't responsive, and your changes look great on mobile. Thank you also for cleaning up my unused imports!