Open makc opened 10 years ago
I suspect this is because MapShaper does not support antimeridian cutting.
Mike's right, mapshaper doesn't do antimeridian cutting or splicing.
The TopoJSON file you're showing was generated using topojson, which stitches together shapes that have been split across the antimeridian.
You can run topojson
with --no-stitch-poles to suppress this behavior.
(Removing antimeridian cuts is useful if you're doing fun things with world map projections.)
mapshaper is importing the file correctly as far as I can tell. You see a long line wherever a linestring jumps between -180 and 180 degrees. It isn't pretty, but at least it shows you what's going on in the file.
Intersection detection is a separate issue. mapshaper uses 2D Cartesian coordinates to detect intersections, which is why you see hits all along those wraparound lines. I'm inclined to keep using 2D math, because it's fast and probably good enough, but the crossing lines should be excluded from hit detection.
If there's a general consensus that mapshaper should change the way these files are rendered, then we can find a better alternative.
Here's a screengrab of ne_110m_ocean.shp from Natural Earth, converted using topojson
and imported into mapshaper with intersection repair turned off:
Here's the same TopoJSON file, converted to GeoJSON using mbostock's geojson
utility and displayed in QGIS.
Here's ne_110m_ocean.shp, converted using topojson --no-stitch-poles
and displayed in mapshaper:
wait, wait. I did not read the code that does "antimeridian cutting" thing, but from the pictures it looks like it connects +180 points to -180 points, right? so, it is possible in theory to detect this kind of arc and add 360 to these coordinates to put chuckotka on the right side and so on, right? I think the result would be more useful than what we see on any of the screenshots above.
...or, do you mean that mapshaper could cut these arcs in two, but does not?
A different way of looking at this is that MapShaper operates in Cartesian coordinates, whereas TopoJSON and D3 operate in either spherical or Cartesian coordinates. (By default, the topojson
command-line tool infers the coordinate system from the bounding box, so in this case it will use spherical coordinates by default. This behavior can be controlled using the --cartesian
and --spherical
flags. Splicing antimeridian cuts is only available in spherical coordinates, for reasons that are hopefully obvious.)
It would be nice if MapShaper performed antimeridian cutting (see my For Example talk for more on this topic) to properly handle spherical polygons, but this is a lot of work. So many geographic tools assume a particular aspect, bake-in antimeridian cuts, and then operate in Cartesian coordinates using plate carrée.
It's true that mapshaper uses Cartesian coordinates; but if an input dataset appears to have units of decimal degrees, mapshaper converts the lat, lng coordinates into x, y, z coordinates around a world sphere before calculating simplification thresholds. I think topojson computes the area of three dimensional curved surfaces for simplification, whereas mapshaper uses the area of flat triangles and straight-line distances in 3-space.
I should add the equivalent to topojson's --cartesian and --spherical flags to the mapshaper
command line tool :) Maybe --flat and --spherical, since the x,y,z coordinate space that mapshaper uses is commonly referred to as "Cartesian."
Sorry, I forgot you added support for 3D triangle area. And yes, topojson
uses spherical excess when simplifying in spherical coordinates. I imagine they are nearly indistinguishable for small triangles.
The main difference would be in rendering, where you need antimeridian cutting to handle arbitrary aspects.
I'd be more inclined to do antimeridian cutting than adding or subtracting 360 degrees (not a bad suggestion, though, makc), mostly because it is applicable to a wider range of datasets. For example, you can display the oceans layer shown above.
topojson
is probably going to be the preferred tool for people working with uncut world datasets, so it might take some time before mapshaper gets support for cutting and splicing across the 180th meridian.
basicaly I hoped for mapshaper to serve as one-click (well, few-clicks) tool to convert and/or simplify topojson to geojson, as I use geojson for my own script to produce this that's why unhappy with these artefacts. maybe I could use another tool, or maybe I could come up with some hack to make mapshaper work for me... I will look into this again this weekend and close the issue either way.
+1 for antimeridian cutting.
On Tue, Nov 19, 2013 at 1:34 PM, makc notifications@github.com wrote:
basicaly I hoped for mapshaper to serve as one-click (well, few-clicks) tool to convert and/or simplify topojson to geojson, as I use geojson for my own script to produce thishttps://pbs.twimg.com/media/BZSqX_OCUAIF2Ie.png:largethat's why unhappy with these artefacts. maybe I could use another tool, or maybe I could come up with some hack to make mapshaper work for me... I will look into this again this weekend and close the issue either way.
— Reply to this email directly or view it on GitHubhttps://github.com/mbloch/mapshaper/issues/20#issuecomment-28838050 .
I have not seen this reported, so you might be unaware of this. Currently, if I import this file, for example, I get this: