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

District numbers and outlines #210

Merged
merged 22 commits into from
Dec 23, 2024
Merged

Conversation

nofurtherinformation
Copy link
Collaborator

Adds zone numbers to map. Hacky approach, but mostly works

Description

  • If selected, this option grabs the rendered map features, dissolves the geometries based on the zone assignment, and adds labels to the map with the zone numbers

Reviewers

lineWidth * 0.35,
14,
lineWidth,
],
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was just code styling

@nofurtherinformation nofurtherinformation marked this pull request as ready for review November 22, 2024 13:59
@nofurtherinformation nofurtherinformation requested review from raphaellaude and mariogiampieri and removed request for raphaellaude November 22, 2024 13:59
@nofurtherinformation
Copy link
Collaborator Author

I've taken another pass to optimize and clean up the way this works a bit. Previously, this functionality added a bunch of map.queryRenderedFeatures calls, which are generally not very good.

Now, whenever a tile loads in, the event listener (map.on("data")) caches the IDs for painting by county and sends the geometry to the geometry worker (WebWorker, off-main-thread) and that caches the geometries if not already present. We keep track of the x-y-z index of the tile, so there isn't a ton of work duplicated. The only additional work here is some stringification for data sent from the main thread to the worker, but it is relatively minimal.

Whenever the assignments updates, the results get sent to the worker which mutates its copy of the data with the updated zones. When zone districts are toggled on or the viewport changes, the worker uses bboxClip followed by dissolve(by="zone") to get zone geometries and center of mass. The center of mass is checked to make sure its actually in the geometry, and if not a random point in the geometry is chosen.

I think there are some additional use cases that will be good to have this amount of geometric data available on the client, and having it on a separate thread means that UX performance impact is minimal. I'm fairly convinced this is a reasonable direction, especially in the interest of keeping the backend lightweight -- eager to hear feedback from you all @raphaellaude @mariogiampieri !

Copy link
Collaborator

@mariogiampieri mariogiampieri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is super slick- it makes a lot of sense to create that separate thread and the user experience was great in my testing. I agree there could be other use cases for a separate worker like- nice work!

Having the dissolved zone areas is nice- I could see a world where we want to outline the zones.

Only minor issue is removing the unused imports but otherwise g2g!

@@ -10,6 +10,10 @@ import {getBlocksSource} from './sources';
import {DocumentObject} from '../utils/api/apiHandlers';
import {MapStore, useMapStore} from '../store/mapStore';
import {colorScheme} from './colors';
import {map, throttle} from 'lodash';
import {wrap} from 'comlink';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pp: it appears wrap and map from lodash are no longer used here, should be removed

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thank you!

const zone = feature.properties?.zone;
if (!zone) return;
const featureArea = area(feature);
if (!largestDissolvedFeatures[zone] || featureArea > largestDissolvedFeatures[zone].area) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

O: this makes sense for now given that we are not enforcing contiguity on zones, but could likely be refactored later when that rule is enforced

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed! I added this note in a TODO along with a couple other future directions we could add

@nofurtherinformation
Copy link
Collaborator Author

Thank you @mariogiampieri! I just updated the unused imports and added a couple notes to our future selves.

mariogiampieri
mariogiampieri previously approved these changes Dec 19, 2024
Copy link
Collaborator

@mariogiampieri mariogiampieri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, nice work!

Copy link
Collaborator

@mariogiampieri mariogiampieri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm! great work

Copy link
Collaborator

@raphaellaude raphaellaude left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@raphaellaude
Copy link
Collaborator

PS This closes a few issues:

@nofurtherinformation nofurtherinformation merged commit a260a8b into main Dec 23, 2024
1 check passed
@nofurtherinformation nofurtherinformation deleted the district-numbers-and-outlines branch December 23, 2024 16:14
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 this pull request may close these issues.

3 participants