Layer conflicts for duplicate point geometries (lat/lon)

[timhitchins]

Posting this here assuming PR #21 will be merged or if other point layers are added to the map.
Layer conflicts are occurring where there are duplicate point geometries. This is causing an inability to click on a the layer at the lesser z-index. For example Freemont has records in the rent strike layer and the city moratoriums layer. Since the rent strike layer is above the city layer, the city layer can not be clicked (triggering the popup event) unless the city layer is turned off.

[djbusstop]

I have investigated this a little bit.

I have found that we can increase the distance of "spiderfied" markers using the spiderfyDistanceMultiplier option in the marker cluster definition. This pushes the markers farther away from the centre which would make no marker itself conflict with the underlying city circle. But apparently the dimmed cluster marker is still above the city circle so it catches any click. This is a bit tricky to fix, because the marker layer is always above the shapes layer. There could be some fancy work of pulling all cities above the marker layer when a marker layer is clicked? But that's really fiddly and would probably not be great for interaction.

If it's possible to avoid placing rent strite markers at the same location as cities, that would be an easy solution. Just change the coords of the city circle to another location in the city bounds. I don't think Freemont necessarily needs to exist at that intersection.

Another possibility is to use shapes for cities as well as counties. I haven't look too much in to how the data is stored and linked to geometries, but I would be willing to work on this topic. It seems related to another issue of turning counties in to shapes. I guess we could link city and county specific data to a shape id? This is a bit of a bigger task.

[timhitchins]

@river-honer Thanks for the detailed and thoughtful investigation of this issue! I personally did not know about the spiderfyDistanceMultiplier, although as you point out that would not solve the issue. After the last meeting with other contributors of the project (I believe @clhenrick mentioned there is crew that meets to discuss the future development of this project) , it seems that folks agree that the second or third solutions you mention would be perhaps the best approach. An issue that was raised for the third solution (using city polys) is that at smaller scales (zoomed out) the cities would look bad. A suggestion to solve that would be to set city polys to turn on at larger scales and to turn off at smaller scales and perhaps be visualized at smaller scales with the current circle markers instead.

[clhenrick]

Thanks @river-honer, in addition to what @timhitchins has mentioned another solution could be placing a UX constraint in the map so that rent strikes could not be turned on simultaneously as the policy layers. IMO web maps too often suffer from the problem of "too many layers", and people asking for web maps often want the ability to turn on all the layers at any given time. This makes it difficult to keep the default UX of the map usable when first presented to someone, as when the map first loads how do you know what the user is most interested in?

One way of handling this might be to have a more robust UI that splits out the various categories of data layers into separate tabs. For example a side bar with tabs on the top for "protections" and "rent strikes." When a user clicks on a tab it only shows layers for that category. Below the tabs could be checkboxes for turning any corresponding layers on / off. The advantage of this approach would be that it makes the UX more scalable when adding more categories of data to the map, which we are eventually planning on doing for things like support for the unhoused and utility assistance.

Of course this requires some UI/UX design and planning, but I think ultimately we'll be needing that anyway as this project continues to grow.

[djbusstop]

Thanks for all the feedback. One thing that is already an instance of the "too many layers problem" in my opinion is that the state is always directly behind everything, so it catches all inaccurate clicks. I find it strange that when fully zoomed in the state shape is always there. But like you said @clhenrick fixing these problems would require some UI/UX planning. When there is a spec for that stuff, I'm happy to be involved, if need be.

When it comes to the contstrains on "toggling" the layers that contain points (cities and rent strikes), that would also probably be better off with a toggle component instead of checkboxes where there's no explaination of how the view works. I guess it would also require a bit of ideation and UI fixing.

[clhenrick]

@river-honer agree that a toggle between rent strikes and protections would make sense, that's kind of what I had in mind for separating the layers using tabs in a sidebar.

We could experiment with hiding and showing geographies at certain zoom levels, i.e. at a certain zoom threshold hide the states layer. Given that we'll likely be adding countries at some point to make the map global in scope, we would probably want to do the same for nation polygons. This could get more tricky in parts of the world that have countries with relatively small geographic areas though.

[brett-halperin]

@clhenrick you mentioned the possibility of designing tabs to visually separate housing justice action and legislation. I think that could work, but my hesitation is that it could possibly obscure or make it more complex for some users to find the information amidst so much stimuli already. I can explore/test this and it may look cleaner. But I am also wondering what are your thoughts on using the latest design (one key/tab) with a technical implementation such that housing justice action and legislation cannot be turned on at the same time. For instance, if a user checks the housing justice action box and then a legislation box, then the housing justice action box automatically turns off. I think this would have the same functionality, but without the risk of the user not finding the other tab or having to navigate more buttons.