Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#1 ask: click on a place, get the water service provider #96

Closed
Frijol opened this issue Jul 22, 2023 · 5 comments · Fixed by #100
Closed

#1 ask: click on a place, get the water service provider #96

Frijol opened this issue Jul 22, 2023 · 5 comments · Fixed by #100
Assignees

Comments

@Frijol
Copy link
Collaborator

Frijol commented Jul 22, 2023

This is touched on in other issues & existing work, but I wanted to give it its own issue because it was Marianne's number one ask.

ericnost added a commit that referenced this issue Jul 24, 2023
@ericnost
Copy link
Member

@Frijol in #97 I have four different ways of retrieving PSAs and PWSs for a place. This branch should not be merged, but I've drafted a pull request to have a conversation there. The idea is that we pick one and implement it in a separate development.

Here's some description and my own thoughts on advantages/disadvantages. Curious what you think.

First, keep in mind that these are just experiments in the "click on a place" part. There are no additional charts, pages (e.g. EJ, lead lines, etc.), and no default places. I assume those extras would be relatively easy to implement afterwards (though maybe not, especially the "default".) Some error handling is still necessary too. Please finally note the SBU server is currently unable to return relatively large chunks of data, so what we have here is a bit modified and hacked. It works temporarily for the purposes of demonstration. I'll email Gil about a server fix (this has happened before, should be a quick fix).

  • Click Anywhere
    • Click anywhere on the map and we'll return the PWS and PSAs that are nearby. Behind the scenes, we draw a bounding box around the clicked point, a box that is about .1 degrees of latitude and .25 degrees of longitude around the point. This ensures we're not fetching all the data all at once (remember how folium/streamlit struggle to map PWS and PSAs at the same time).
    • One advantage of this approach is that is intuitive - click somewhere on the map and get the data!
    • A disadvantage is that it's "too easy" - users probably wouldn't expect that clicking would reload the map to draw the data. Indeed, unfortunately, I don't think there's a way around the map re-render. I've wracked my brains about it. (But see the "Slippy" approach below). Additionally, any click on the map triggers a reload. Folium has to watch for any click, so even clicking on the PSA/PWS will trigger a reload even if that's not the intention, even if the intention is just to retrieve the popup - which is why I tried hover tooltips.
  • Drop Marker selection
    • Basically, instead of clicking on the map or drawing a box, the user uses the controls on the lefthand side of the map to drop a circle on an area they want to explore. The same behind the scenes work as above happens again. The same disadvantages (map refresh, any click triggers re-render, etc.)
  • Click Marker selection
    • This loads all SDWA points (PWS). For the purposes of this experiment, it only loads those around Trenton. Then, the user clicks on a point/PWS. The map reloads, highlighting the facility and drawing any PSA service areas associated with it.
    • The advantage here is to more clearly associate PWS and PSA. You're also not starting from scratch - there are some puzzle pieces already on the board (markers on the map). The disadvantage is that you aren't clicking on a place per se, you're clicking on a PWS.
  • Slippy selection
    • The user pans and zooms across the map, changing the bounds of the map frame. This triggers a call to go get the data for that area.
    • The advantage here is that it's highly intuitive/high feedback. Move the map, see new data instantaneously. No map redraw!
    • The disadvantage is that to deal with the data management issue (can't draw too many things on Folium at once), we have to limit the zoom levels. If you could zoom out all the way, it'd be trying to load things for all of New Jersey, and we already saw that that's time intensive. So if the map defaults to Patterson NJ but a user wants to get to Atlantic City NJ they'd have to zoom out a bit and scroll down there, adding time, and unnecessary data loading along the way. Initially my idea here was to have a button trigger the data loading, rather than a constant update, but buttons are harder than they look!

Ok, this took all day. I'm about out of time with this project. Unfortunately, I think we'll have to be quite strategic in what we are able to advance moving forward. I think this is the priority though.

@ericnost
Copy link
Member

Just added:

  • Button selection
    • User navigates to area of interest (albeit under limited zoom ability to prevent too large data requests) and clicks get data to return PWS and PSAs
    • Advantages/disadvantages: no real map re-rendering. Technically, behind the scenes, the map is re-rendering on every change of bounds (pan, zoom), but this isn't an issue unless the user has loaded a large amount of data (e.g. NE NJ zoomed out as much as possible). A disadvantage is that clicking a button is another extra step, but it may facilitate navigation to areas of interest compared to "Slippy selection"

@ericnost
Copy link
Member

P.S. As you navigate the experiments, keep in mind that some of them use some of the same st.session_state variables, which can cause some bugginess. When in doubt, clear the cache and re-run. This shouldn't be an issue when live because only one of the pages will be live.

@ericnost
Copy link
Member

This provides a solution to the zoom issues mentioned above! Just give a warning to the user that they should zoom in more.... (on the slippy and button selection options) 143d912

@ericnost
Copy link
Member

ericnost added a commit that referenced this issue Jul 27, 2023
integrates new "slippy" flow control, and #105 as of 7/27
fixes #106
fixes #96 (!)
fixes #92
fixes #84 (mostly; see randyzwitch/streamlit-folium#121)
fixes #70
fixes #65
addresses #63 (using marker clusters, but we still need a context note)
@Frijol Frijol linked a pull request Jul 29, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants