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

Overlapping Voronoi polygons #22

Open
duynguyen158 opened this issue Nov 3, 2020 · 6 comments
Open

Overlapping Voronoi polygons #22

duynguyen158 opened this issue Nov 3, 2020 · 6 comments

Comments

@duynguyen158
Copy link

When I tried to create a Voronoi diagram from a gridded dataset of 4 points (±90, ±45) using geoVoronoi(), the cells seem to overlap. @Fil has graciously pointed out that this is because the polygons have some 180° edges but no intermediate points.

Here's a minimal, reproducible example: https://observablehq.com/d/1433b09bb55a4807. Ideally, each Voronoi cell should be colored either orange or blue. Would love for a way to fix this. Thanks!

screen_cap

@Fil
Copy link
Owner

Fil commented Nov 15, 2020

I believe this shows two distinct issues:

  1. when we have 2 columns (and whatever the number of rows), geoVoronoi returns ill-defined polygons.

  2. when you request more than two columns, the polygons are OK, but d3.geoEquirectangular (and, it seems, all the projections that rely on antimeridian clipping) fail to display them properly. (You can see that by switching to d3.geoAzimuthalEqualArea in your notebook.)

@Fil
Copy link
Owner

Fil commented Nov 17, 2020

With "2 columns", the points are in fact collinear (all belong to the great circle that passes through the poles and [-90;0]). It's one of these situations where the (planar) Delaunay triangulation also tends to fail.

A "solution" in that case can be to introduce a supplementary point that is very close to the first point, but not aligned on the same grand circle. (It's frustrating that the code can't compute this case on its own, tho.)

@duynguyen158
Copy link
Author

duynguyen158 commented Nov 17, 2020

Yes. Adding the supplementary point works. Thanks @Fil!

In my original use case, I had a gridded dataset of more than 2 columns, and I took up d3.geoEquirectangular because it didn't seem like it was stretching/squeezing Vietnam, the country I wanted to visualize, by a whole lot (though I hadn't given that a lot of thought and could be totally wrong). What would you recommend as a replacement for geoEquirectangular?

@Fil
Copy link
Owner

Fil commented Nov 17, 2020

It's hard to give a generic recommendation for a projection, it depends so much on the total area you're interested to show (the world or the region), and on the features that are the focus of interest.

Sometimes you will want to follow an "official" or usual projection, especially if you have data that comes already projected. Sometimes you will have to use WebMercator, if you use raster tiles. Sometimes a projection designed to be good on land at the expense of the ocean, or the other way around.

In any case, I'd say that Equirectangular is a very boring projection, with not many interesting features, and a tendency to vertically "crush" everything that is not on the equator, distorting both the angles and the areas. I would definitely recommend against it, except in very specific cases where you need to align a grid.

You can play with http://www.cartography.oregonstate.edu/demos/AdaptiveCompositeMapProjections/ and use the projection that it recommends for the scale you're optimizing for. (They are all available in D3).

A transverse Mercator can also be very nice if your focus is on a medium-sized region (or a country), for example https://observablehq.com/@fil/corees-koreas

@duynguyen158
Copy link
Author

Yes! This is exactly what I needed. Thanks!

@martinfrances107
Copy link
Collaborator

I believe this shows two distinct issues:

  1. when we have 2 columns (and whatever the number of rows), geoVoronoi returns ill-defined polygons.
  2. when you request more than two columns, the polygons are OK, but d3.geoEquirectangular (and, it seems, all the projections that rely on antimeridian clipping) fail to display them properly. (You can see that by switching to d3.geoAzimuthalEqualArea in your notebook.)

Just reading this issue looking for common ground and differences - In comparison to #42.

The problems exposed in 42 are found using the orthographic projection ...
which uses circle clipping not antimeridian ... so my only comment is if 1 and 2 are true
then 42 maybe a way to focus on 1.

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

No branches or pull requests

3 participants