d3 topojson maps breaking on chrome 33?

[Eric Dodge]

Hi everyone,

I have a couple different d3 topojson maps that were working fine until the Chrome 33 update. Now they are breaking in Chrome but are still fine in other browsers.

The problem seems to be that a lot of the points are being dropped from one of the regions, and the fill for that region is "leaking out" onto the rest of the svg.

You can see this issue here:

http://bcure.hmdc.harvard.edu/mh-cities/topo-issue-demo.html

Link to the source topojson file here:

http://bcure.hmdc.harvard.edu/mh-cities/maps/mh-districts-topo-05.json

Any help would be appreciated!

Best,

Eric

[marc fawzi]

confirmed behavior in Canary

https://support.google.com/chrome/answer/95315?hl=en

--
You received this message because you are subscribed to the Google Groups "d3-js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to d3-js+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Eric Dodge]

Reported the issue to Chrome

--
You received this message because you are subscribed to a topic in the Google Groups "d3-js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/d3-js/cw2cyzdc3Jw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to d3-js+un...@googlegroups.com.

[Bill Badeaux]

I'm having the same problem with a world mercator map.  It seems to be that in the new Chrome, SVG <path>'s that exceed their container are causing weird draw/flood issues.

For example, if you inspect your map's <svg><g> and hover over each of the <path>'s, you see that one of them (about the 13th one down, <path d="M140.784...,80.948.....">) floods the whole window.  If you click on it, and hit delete, your map seems to appear correct.

I'm having a similar issue with Antarctica. I've tried a few various Geo and Topo JSON files, and they all seem to make Antarctica flood the <svg>'s width/height, and seems to make it draw craziness.

My temporary fix is to edit my .json source, and delete Antarctica lol.  Not sure if this will hold you over in the mean time, but it's a really crappy band-aid ,that my company is temporarily okay with...

[Bill Badeaux]

Just got this new topo, from this example and everything (even Antarctica) works fine.  Maybe try to either A) delete your offending region/<path>, or B) find or generate a new topo json.  Read the second paragraph of that example for a reasonable starting point for making your own topo; specifically: "The geography is pulled from a Natural Earth shapefile, converted to TopoJSON, and it comes with ISO 3166-1 numeric codes to identify each country."

Good Luck!!!

On Monday, February 24, 2014 5:14:37 AM UTC-6, Eric Dodge wrote:

[Mike Bostock]

What version of TopoJSON did you use to generate that file?

If the problem still occurs after you regenerate the TopoJSON using the latest release 1.4.6, can you post the original data (Shapefile or GeoJSON) you used to generate this file so that I can investigate?

I am aware of a few numerical instabilities in the projection code [2] that were triggered by a new implementation of trigonometric functions in Chrome 33 [1], but as far as I am aware it is limited to the Guyou projection and by extension the Pierce Quincuncial projection. 

Mike

[1] https://code.google.com/p/v8/issues/detail?id=3006

[2] https://github.com/d3/d3-geo-projection/issues/10

[Bill Badeaux]

I was originally using the attached world-110m.json with d3 v3.4.0, which I found in several http://bl.ocks.org/ examples, which sporadically would and would not work depending on solar flares... When it DID (mostly) work, console would log errors against setting the "d" attribute of a path, which I found was Antarctica, which was trying to set a path string with a NaN as one of the very last L coords. Conversely, when it did NOT work, there were no console errors.

I found this new JSON from this example, who states that "The geography is pulled from a Natural Earth shapefile, converted to TopoJSON, and it comes with ISO 3166-1 numeric codes to identify each country." Using d3 v3.4.0 with this new topo json consistently did NOT work as expected, however, upgrading to d3 v3.4.2 with that new JSON DID produce expected results.

I'll try to mock up a fiddle for you if I have a little extra time at the end of the day.  THANKS for looking in to this!!!

[Mike Bostock]

The world-110m.json file you linked was generated by me on March 21, 2013 [1], and predates the mentioned fixes.

This file is one of the TopoJSON example files, so I suggest getting them from the source, here:

https://github.com/mbostock/topojson/tree/master/examples

Alternatively, many of my examples on bl.ocks.org refer to these files using gist 4090846, e.g., /mbostock/raw/4090846/world-110m.json. For example, spherical Mercator:

http://bl.ocks.org/mbostock/3757132

You can also build these files from scratch using my us-atlas and world-atlas repositories:

https://github.com/mbostock/us-atlas

https://github.com/mbostock/world-atlas

Mike

[1] Specifically, commit 8c227ce32a706aa725823d7da99e8e1fe8a82231 to gist 4090846.

[Eric Dodge]

I used v1.2.3 to generate this file. I'll update and see if that fixes the issue.

--

[Eric Dodge]

The problem seems to be with the --allow-empty option. I updated topojson to 1.4.6 and generated the file again using the --allow-empty option, still getting the same issue with fill color covering the whole svg. I generated the file a second time without the --allow-empty option and that fixed the problem. Any idea why Chrome would now be giving empty regions a fill that covers the whole page?

Thanks,

Eric

[Kevin Dean]

I am running into the same kind of problem with Chrome 33 (see the problem here). My topojson is generated from Eric Muller's tz_world_map along with an external file of properties. I tried rebuilding the topojson using version 1.4.6, but it created an identical file. I also attempted adding the --allow-empty option, but that made things worse.

Here is the command I have been using thus far to generate my topojson:

topojson -o tz_world.topojson --id-property TZID -e tzidToUtcOffset.csv -p Offset --no-stitch-poles tz_world_mp.shp

Does this help? Please let me know if I can offer any more information!

Best,

Kevin

[Mike Bostock]

Yep, this is the Chrome 33 bug [1,2]. Unfortunately I don’t have an immediate solution for you, but I am trying to see if we can fix it in D3.

For now, you can workaround it by pre-projecting the data in Node, which uses the old implementation of the core trigonometric functions. As shown here:

http://bl.ocks.org/mbostock/9234731

An additional benefit of pre-projecting your data is that it’s typically smaller (because it can be simplified to screen pixels rather than using steradians) and faster to render. On the other hand, you can’t change the projection dynamically.

Mike

[1] https://github.com/mbostock/d3/issues/1753

[2] https://code.google.com/p/v8/issues/detail?id=3006

[marc fawzi]

Does this affect the Albers projection? (I assume it's a generic issue) and does that mean that every (most, or some) geo mapping app we've built in the past need to update to the upcoming D3 fix?

It seems like some of the Chromium.org guys don't really get it.

--

You received this message because you are subscribed to the Google Groups "d3-js" group.

To unsubscribe from this group and stop receiving emails from it, send an email to d3-js+un...@googlegroups.com.

[Mike Bostock]

The timezones bug was actually unrelated to the Chrome 33 bug; it was a bug in the TopoJSON command-line utility and it has been fixed in version 1.4.7:

  https://github.com/mbostock/topojson/releases

You can install the latest release via `npm install topojson`. (The client library, topojson.js, is unchanged in this release other than the version number. The only change is in the command-line topojson utility.)

At the same time, Jason Davies has contributed a workaround for the asymmetric behavior of Math.sin and Math.cos in Chrome 33. D3 version 3.4.3 is now available on GitHub and d3js.org:

  https://github.com/mbostock/d3/releases

You can see the fixed timezones example here:

  http://bl.ocks.org/mbostock/9234731

Cheers,

Mike

[Kevin Dean]

Thanks so much, Mike!

Just one thing. npm is still installing 1.4.6 even when I request version 1.4.7. I'm not that familiar with npm -- do you have to push the latest version to the registry?

Thanks for all your hard work!

-Kevin

[Mike Bostock]

You can check the latest version known to NPM here:

https://www.npmjs.org/package/topojson

For me, that says 1.4.8. (There was another small bug fix pushed yesterday.) If you’re getting an older version when you `npm install topojson`, check your package.json dependencies.

Mike

[Kevin Dean]

Interesting. It was actually the D3 update that fixed my timezone map rather than the topojson command line update, which didn't end up altering my topojson file at all.

Also, I think you may have to push your updates to npm's registry manually. No matter what I did, including uninstalling topojson completely, npm install -g topojson would only ever install 1.4.6. I eventually just did npm install -g https://github.com/mbostock/topojson/archive/v1.4.9.tar.gz in order to bypass npm's registry and that worked.

If you just search for topojson on npm's site, this is what you see, leading me to believe the latest versions aren't actually getting to its registry.

Thanks again for all your effort!

-Kevin

[Mike Bostock]

NPM knows the latest version. The search results are stale but you can visit the page directly:

https://www.npmjs.org/package/topojson

Are you sure you don’t have a package.json in the current directory that specifies a dependency on a specific version of TopoJSON? Otherwise, it might be a caching issue for you, but I’m not that familiar with how NPM caches packages.

https://www.npmjs.org/doc/cache.html

Mike