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

Horizontal Lines in World Examples #242

Closed
j0hj0h opened this Issue May 27, 2015 · 13 comments

Comments

Projects
None yet
5 participants
@j0hj0h

j0hj0h commented May 27, 2015

Both world examples (world-50m.json and world-110m.json) are displayed like this in the GitHub Preview:

bildschirmfoto 2015-05-27 um 10 42 18

The same problem occurs, using the files with OpenLayers 3, and with Leaflet, with the topojson converted to GeoJSON via topojson.js.

Only D3 displays it correctly. But there I had the same problem before – I don't remember under which circumstances, I guess it was with topojson files, I converted myself from Natural Earth shapefiles.

@rajanski

This comment has been minimized.

Show comment
Hide comment
@rajanski

rajanski May 27, 2015

Was already mention in a different visual expression here #164 (comment)
Workaround proposed here #164 (comment)
Cheers @j0hj0h ;-)

rajanski commented May 27, 2015

Was already mention in a different visual expression here #164 (comment)
Workaround proposed here #164 (comment)
Cheers @j0hj0h ;-)

@j0hj0h

This comment has been minimized.

Show comment
Hide comment
@j0hj0h

j0hj0h May 27, 2015

Are the parameters --q0 0 and --q0 1e6 meant for the topojson command line converter?
I tried it, but no success ... still the same lines. This is my command:

topojson \
  -o world.topo.json \
  --id-property iso_a2 \
  --q0 1e6 \
  -- \
  world.geo.json

j0hj0h commented May 27, 2015

Are the parameters --q0 0 and --q0 1e6 meant for the topojson command line converter?
I tried it, but no success ... still the same lines. This is my command:

topojson \
  -o world.topo.json \
  --id-property iso_a2 \
  --q0 1e6 \
  -- \
  world.geo.json
@rajanski

This comment has been minimized.

Show comment
Hide comment
@rajanski

rajanski May 27, 2015

It is definitely connected with the northeastern part of Russia being a separate polygon (split at 180 degrees east/west line) . If I remove Russia from the topojson it shows fine:
image

rajanski commented May 27, 2015

It is definitely connected with the northeastern part of Russia being a separate polygon (split at 180 degrees east/west line) . If I remove Russia from the topojson it shows fine:
image

@j0hj0h j0hj0h changed the title from Lines in World Examples to Horizontal Lines in World Examples May 27, 2015

@j0hj0h

This comment has been minimized.

Show comment
Hide comment
@j0hj0h

j0hj0h May 27, 2015

Yes, that is what we've tested also. Russia and Fiji, the two features crossing the date line are causing this.

Here is an issue adressing the problem in Leaflet: Leaflet/Leaflet#82
... it's closed, but I don't get the last comment. Is there some manual conversion/wrapping required now?

j0hj0h commented May 27, 2015

Yes, that is what we've tested also. Russia and Fiji, the two features crossing the date line are causing this.

Here is an issue adressing the problem in Leaflet: Leaflet/Leaflet#82
... it's closed, but I don't get the last comment. Is there some manual conversion/wrapping required now?

@j0hj0h

This comment has been minimized.

Show comment
Hide comment
@j0hj0h

j0hj0h Jun 3, 2015

When converting with --stitch-poles false the problem disappears. Then Antarctica get's messed up. We don't need Antarctica for the current project, so we deleted it.

j0hj0h commented Jun 3, 2015

When converting with --stitch-poles false the problem disappears. Then Antarctica get's messed up. We don't need Antarctica for the current project, so we deleted it.

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Aug 6, 2015

I'm having the same issue, converting natural earth's .shp files via topojson.

Setting --q0 0 or --q0 1e6 did not seem to make a difference, but --stitch-poles false fixed it at the expense of Antartica.

filipesilva commented Aug 6, 2015

I'm having the same issue, converting natural earth's .shp files via topojson.

Setting --q0 0 or --q0 1e6 did not seem to make a difference, but --stitch-poles false fixed it at the expense of Antartica.

@mbostock

This comment has been minimized.

Show comment
Hide comment
@mbostock

mbostock Aug 7, 2015

Member

The issue is that the software you are using to display this geometry doesn’t truly understand spherical coordinates, or more specifically, spherical topology. These artifacts appears most prominently in Russia because it is a large country and it crosses the antimeridian (±180° longitude). To display spherical geometry correctly you need rendering software that applies antimeridian cutting, such as D3.

Alternatively, you must “bake-in” an antimeridian cut (typically at ±180° longitude, but it depends on the rotation you desire), so that it can be rendered correctly in software that does not understand spherical topology, such as OpenLayers and Leaflet. Most GeoJSON files include a baked-in antimeridian cut, but this was explicitly rejected for D3 and TopoJSON so that it could properly handle projections with any aspect and rotation.

(This issue is unrelated to #164, which is a different type of artifact not related to the antimeridian.)

Member

mbostock commented Aug 7, 2015

The issue is that the software you are using to display this geometry doesn’t truly understand spherical coordinates, or more specifically, spherical topology. These artifacts appears most prominently in Russia because it is a large country and it crosses the antimeridian (±180° longitude). To display spherical geometry correctly you need rendering software that applies antimeridian cutting, such as D3.

Alternatively, you must “bake-in” an antimeridian cut (typically at ±180° longitude, but it depends on the rotation you desire), so that it can be rendered correctly in software that does not understand spherical topology, such as OpenLayers and Leaflet. Most GeoJSON files include a baked-in antimeridian cut, but this was explicitly rejected for D3 and TopoJSON so that it could properly handle projections with any aspect and rotation.

(This issue is unrelated to #164, which is a different type of artifact not related to the antimeridian.)

@mbostock mbostock closed this Aug 7, 2015

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Aug 8, 2015

Ah, that makes sense. Thank you for the explanation Mike!

filipesilva commented Aug 8, 2015

Ah, that makes sense. Thank you for the explanation Mike!

@chrisregner

This comment has been minimized.

Show comment
Hide comment
@chrisregner

chrisregner Sep 7, 2017

How do I "'bake-in' an antimeridian cut"? Can you share some resources where I can learn doing it?

chrisregner commented Sep 7, 2017

How do I "'bake-in' an antimeridian cut"? Can you share some resources where I can learn doing it?

@mbostock

This comment has been minimized.

Show comment
Hide comment
@mbostock

mbostock Sep 7, 2017

Member

@chrisregner Typically you would bake in a planar projection rather than just baking in the antimeridian cut. See Command-Line Cartography for an example of geoproject.

That said, you can reproduce (at least if you are willing to treat the Earth as a sphere) the WGS84 coordinate system used in GeoJSON using d3.geoEquirectangular. Whereas D3 and TopoJSON use spherical coordinates to represent spherical geometry, GeoJSON uses planar equirectangular (plate carrée) coordinates. The difference between WGS84 and d3.geoEquirectangular is that the latter has +y pointing down consistent with Canvas and SVG, whereas WGS84 has +y (latitude) pointing up representing north.

So, to approximate WGS84, you first need to project to d3.geoEquirectangular, and then you need to use d3.geoIdentity to flip the y-axis. Here’s an example using the world-atlas as input:

topo2geo countries=- -i world/110m.json \
  | geoproject 'd3.geoEquirectangular().scale(180 / Math.PI).translate([0, 0])' \
  | geoproject 'd3.geoIdentity().reflectY(true)' \
  > countries.json

(The scale factor of 180 / π converts radians to degrees.)

Here’s the result:

screen shot 2017-09-07 at 7 49 14 am

Member

mbostock commented Sep 7, 2017

@chrisregner Typically you would bake in a planar projection rather than just baking in the antimeridian cut. See Command-Line Cartography for an example of geoproject.

That said, you can reproduce (at least if you are willing to treat the Earth as a sphere) the WGS84 coordinate system used in GeoJSON using d3.geoEquirectangular. Whereas D3 and TopoJSON use spherical coordinates to represent spherical geometry, GeoJSON uses planar equirectangular (plate carrée) coordinates. The difference between WGS84 and d3.geoEquirectangular is that the latter has +y pointing down consistent with Canvas and SVG, whereas WGS84 has +y (latitude) pointing up representing north.

So, to approximate WGS84, you first need to project to d3.geoEquirectangular, and then you need to use d3.geoIdentity to flip the y-axis. Here’s an example using the world-atlas as input:

topo2geo countries=- -i world/110m.json \
  | geoproject 'd3.geoEquirectangular().scale(180 / Math.PI).translate([0, 0])' \
  | geoproject 'd3.geoIdentity().reflectY(true)' \
  > countries.json

(The scale factor of 180 / π converts radians to degrees.)

Here’s the result:

screen shot 2017-09-07 at 7 49 14 am

@chrisregner

This comment has been minimized.

Show comment
Hide comment
@chrisregner

chrisregner Sep 9, 2017

@mbostock Thank you. Actually, I'm trying to incorporate this with a reproduction of your tutorial, which is done in the browser and not in command-line. I'll continue tinkering with existing code until I get the result I need but actually, I have no idea how to do it.

Also, to be honest, I don't understand most of the terms you've mentioned. I'm genuinely trying and I've read some of your articles already. If you have any, can you share some more introductory resources which can make my journey in programming cartography smoother? These are what I've read so far:

chrisregner commented Sep 9, 2017

@mbostock Thank you. Actually, I'm trying to incorporate this with a reproduction of your tutorial, which is done in the browser and not in command-line. I'll continue tinkering with existing code until I get the result I need but actually, I have no idea how to do it.

Also, to be honest, I don't understand most of the terms you've mentioned. I'm genuinely trying and I've read some of your articles already. If you have any, can you share some more introductory resources which can make my journey in programming cartography smoother? These are what I've read so far:

@mbostock

This comment has been minimized.

Show comment
Hide comment
@mbostock

mbostock Sep 9, 2017

Member

@chrisregner If you want to use Leaflet or another display library that expects planar input (rather than spherical input as d3-geo expects), then the easiest thing is probably to avoid running geostitch on your GeoJSON and to keep your data in planar coordinates. In other words, you probably don’t want to consume the TopoJSON world-atlas as-is, because it is in spherical rather than planar coordinates. You could edit its prepublish script to remove the call to geostitch.

Yes, you can undo the effect of geostitch on the command-line using the above code, or you can likely achieve the same result directly in the browser using d3.geoProject, but it’s easier if you avoid the conversion to spherical coordinates in the first place. Most shapefiles and GeoJSON you’ll find on the internet are in a planar format.

D3 uses spherical coordinates to allow the geometry to be rotated for arbitrary aspects. This only works because D3 treats the Earth as a sphere, which is generally fine for thematic mapping but not for producing accurate large-scale reference maps.

Member

mbostock commented Sep 9, 2017

@chrisregner If you want to use Leaflet or another display library that expects planar input (rather than spherical input as d3-geo expects), then the easiest thing is probably to avoid running geostitch on your GeoJSON and to keep your data in planar coordinates. In other words, you probably don’t want to consume the TopoJSON world-atlas as-is, because it is in spherical rather than planar coordinates. You could edit its prepublish script to remove the call to geostitch.

Yes, you can undo the effect of geostitch on the command-line using the above code, or you can likely achieve the same result directly in the browser using d3.geoProject, but it’s easier if you avoid the conversion to spherical coordinates in the first place. Most shapefiles and GeoJSON you’ll find on the internet are in a planar format.

D3 uses spherical coordinates to allow the geometry to be rotated for arbitrary aspects. This only works because D3 treats the Earth as a sphere, which is generally fine for thematic mapping but not for producing accurate large-scale reference maps.

@chrisregner

This comment has been minimized.

Show comment
Hide comment
@chrisregner

chrisregner Sep 11, 2017

I reproduced the TopoJSON just as how you instructed and it did it! I'm very grateful, @mbostock.

chrisregner commented Sep 11, 2017

I reproduced the TopoJSON just as how you instructed and it did it! I'm very grateful, @mbostock.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment