add d3.geoNaturalEarth, please about d3-geo HOT 13 CLOSED

Fixed in #107. Will release shortly.

from d3-geo.

I really like this solution. Also looking forward to geoNaturalEarth2.

The other solution I was thinking of was to just bundle geoNaturalEarth into the d3 build without including it in d3-geo. But geoNaturalEarth1 makes more sense.

from d3-geo.

Natural Earth Data is wholly unrelated to the Natural Earth projection, so the proposed change here would little effect on world-atlas or similar pipelines for producing TopoJSON.

It’s already the case that geoproject has access to all projections in d3-geo-projection, so you can say geoproject 'd3.geoNaturalEarth()'. The only implied change here is that, since d3.geoNaturalEarth would be deprecated, you’re recommended but not required to say geoproject 'd3.geoNaturalEarth1()' instead.

from d3-geo.

How would you feel about the Patterson projection?

from d3-geo.

well, to me this projection falls into the same bucket as plate carrée. I get that it's supposed to be better, but we still wouldn't use it in a nyt map, for instance.

when I said cylindrical projections above, I actually meant pseudocylindrical. I think there should be at least one acceptable pseudocylindrical projection in D3 core.

otherwise every user will have to go to d3-geo-projections and have to fiddle through the daunting task of creating their own custom d3 build, which isn't exactly fun at this point.

any of these would be nice, I guess. but I prefer natural earth, both because it looks really good and the forward transformation is pretty fast, compared to some of the others in that list.

• Natural Earth
• Eckert IV
• Robinson
• Wagner VI
• Winkel tripel

from d3-geo.

I tend to think that Robinson is more common that NaturalEarth, but the difference is very small (http://bl.ocks.org/Fil/641de759a2294387c7d414b2ac749243), and NaturalEarth has much less code.

And all that time I thought the Times used the Times projection https://github.com/d3/d3-geo-projection#geoTimes 😂

from d3-geo.

Related d3/d3-geo-projection#84, we could implement Natural Earth II as d3.geoNaturalEarth2:

The nice thing about that is there wouldn’t be a conflict or duplicating in moving d3.geoNaturalEarth from d3-geo-projection to d3-geo.

Though to be fair, according to the research paper, “general map-readers rated the Natural Earth II projection lower than the Robinson and Natural Earth projections”.

from d3-geo.

It is appealing.

A bit sad, though, that the inverse isn't a formula (see d3/d3-geo-projection#85).

In any case I think it is more important to offer what is "best" for users rather than what is more convenient for developers.

from d3-geo.

The only ones in Gregor’s list that have closed-form inverses are Eckert IV and Wagner VI, but Eckert IV uses numerical integration for the forward projection… Anyway. I think all of them are viable as a default compromise world projection, but that probably the Natural Earth I is the “best”.

While the implementations of all these candidates seem reasonable for inclusion in d3-geo (and by extension the default d3 bundle), there is still an important developer issue which is whether including the symbol geoNaturalEarth in both d3-geo and d3-geo-projection will cause a conflict such as a build error. It’s hard to say because it’s probably dependent on the build environment, which varies wildly in the current JavaScript ecosystem.

So… some options:

1. Implement d3.geoNaturalEarth2 in d3-geo, under the argument that it’s good enough (and avoids some of the issues in alternative approaches below).

2. Keep d3.geoNaturalEarth in d3-geo-projection, add d3-geo-projection as a (dev-) dependency to the default d3 core bundle, and re-export only d3.geoNaturalEarth. This makes it available to consumers of the default bundle, and changes nothing for people that consume the modules directly. However it would cause some duplication for people that load the d3 core bundle and the d3-geo-projection bundle.

3. Move d3.geoNaturalEarth from d3-geo-projection to d3-geo, and bump the major version number of d3-geo-projection to 2.0.

4. Move d3.geoNaturalEarth from d3-geo-projection to d3-geo, and re-export geoNaturalEarth from d3-geo-projection. (Unclear whether having two D3 modules export a symbol with the same name, even if it resolves to the same definition, will cause a developer headache.)

5. Move d3.geoNaturalEarth to d3-geo, but export it under a new name like d3.geoNaturalEarth1. But this is probably confusing.

6. Move the standard projections to d3-geo-projection (geoAzimuthalEqualArea, geoAzimuthalEquidistant, geoGnomonic, geoOrthographic, geoStereographic, geoAlbersUsa, geoAlbers, geoConicEqualArea, geoConicEquidistant, geoEquirectangular, geoMercator, geoTransverseMercator; but leave the projection system, i.e., d3.geoProjection, d3.geoProjectionMutator, d3.geoPath in d3-geo), bump d3-geo to 2.0, add d3-geo-projection as a (dev-)dependency of d3, and then have the d3 default bundle decide what projections it wants to export. But this makes d3-geo pretty useless on its own.

Not an exhaustive list of options.

from d3-geo.

I think implementing Natural Earth I as d3.geoNaturalEarth1 in d3-geo, and then re-exporting it as a deprecated alias d3.geoNaturalEarth from d3-geo-projection is probably the best option moving forward. That should avoid any build issues and work well with implementing Natural Earth II as d3.geoNaturalEarth2 in d3-geo-projection in the future.

from d3-geo.

If implemented, how would this ultimately impact the ongoing use of Natural Earth's geometry vis converting from Esri Shapefile to TopoJSON? If I were using a workflow like that in topojson/world-atlas/prepublish, would this in any way change how I generate or use the resulting TopoJSON?

I ask because I'm working on a blog post explaining how to use the current generation of tools and am wondering whether this will change that workflow at all.

from d3-geo.

@mbostock Excellent; thank you!

from d3-geo.

Fixed in 1.7.0.

from d3-geo.