It would be really useful (for new users who are unfamiliar with map simplification etc.) if there were some example commands in the documentation, especially showing the usage of --simplify, --simplify-proportion, and --quantization.

Obviously I can experiment with random numbers, but it would be good if the documentation gave some indication of sane value ranges for these options.

This lib is fantastic - thanks a lot !

I am trying to rebuild parent-geometries from sub-geometry boundaries (e.g. sub-continent or continent from countries).
The filter function for the mesh looks like :

var m = -- // an id for the parent geometry
   prop = // properties of geometry objects, including a parent id
topojson.mesh(obj, obj.countries, function(a,b) {
                   if(prop[a.id] && prop[a.id].parent == m || prop[b.id] && prop[b.id].parent == m ) { 
                          return (a.id === b.id) || (a.id !== b.id && ((prop[b.id] && prop[b.id].parent != m ) || (prop[a.id] && prop[a.id].parent != m ) ))   
                    }
                 })

It is working quite well, except for the eastern-Siberia bit, where I have the impression that there are some problems with the geometry.
Christophe

Looking a bit closer at a generated path for the area interest, we have something like this (points have been dragged to allow differentiate the shapes):

Could it be that the extra line between the two shapes is creating the problem ?

For example, in this screenshot, all the little dots represent islands that were removed by topojson.filter, but whose arcs were not removed from the topology.

I'm running into an error similar to Issue #47 when converting a shapefile:

C:\Users\...\Roaming\npm\node_modules\topojson\lib\topojson\type.js:74
var i = -1, n = coordinates.length;
                           ^
TypeError: Cannot read property 'length' of undefined at Object.typeDefaults.polygon (C:\Users\...\Roaming\npm\node_modules\topojson\lib\topojson\type.js:74:32)
     at Object.typeDefaults.Polygon (C:\Users\...\Roaming\npm\node_modules\topojson\lib\topojson\type.js:51:10)
     at Object.typeDefaults.geometry (C:\Users\...\Roaming\npm\node_modules\topojson\lib\topojson\type.js:62:77)
     at Object.typeDefaults.Feature (C:\Users\...\Roaming\npm\node_modules\topojson\lib\topojson\type.js:14:32)
     at Object.typeDefaults.FeatureCollection (C:\Users\...\Roaming\npm\node_modules\topojson\lib\topojson\type.js:19:26)
     at Object.typeDefaults.object (C:\Users...\Roaming\npm\node_modules\topojson\lib\topojson\type.js:56:70)
     at each (C:\Users\...\Roaming\npm\node_modules\topojson\lib\topojson\topology.js:33:37)
     at Object.module.exports [as topology] (C:\Users\...\Roaming\npm\node_modules\topojson\lib\topojson\topology.js:38:3)
     at output (C:\Users\...\Roaming\npm\node_modules\topojson\bin\topojson:177:25)
     at notify (C:\Users\...\Roaming\npm\node_modules\topojson\node_modules\queue-async\queue.js:77:18)

The error occurs in version 0.0.32, and can be replicated using this shapefile.

If I convert some data from geojson to topojson and back, sometimes I end up with null geometries. That may well be correct topology (I'm not positive), but I believe the GeoJSON it emits is incorrect. Here's a snippet of output from the geojson tool

    {
      "geometry": {
        "id": "180500021001",
        "type": null
      },
      "properties": {},
      "id": "180500021001",
      "type": "Feature"
    }

If I read the geojson spec correctly a type of null is not allowed. The geometry object is allowed to be null itself though. This may be related to issue #37; that ID field may not belong on the geometry object either.

The reference topojson implementation should report the loss of precision due to quantization. This can be calculated by computing the maximum great arc distance between each input vertex and the resulting quantized output vertex, and assuming a spherical Earth with radius 6,378.1km.

When running topojson.topology({geo:geoJSON},{quantization:1e6,verbose:true} on in input geoJSON file whose bounding box is 0 0 1442.3991489362245 2763.9276595744636 (cartesian) the object returns just fine except transform.translate is [NaN,NaN].

Have been able to replicate this with multiple files but can't track down the bug in the source code. Its possible that I am doing something wrong but I thought I would post it here in case someone else could confirm the bug.

Hi, I was surprised to discover that the Server side API topology call actually overwrites/restructures the passed-in GeoJSON feature collection to TopoJSON in-place.

This was a nasty surprise because the documentation makes no mention (that I can find) of this side-effect of calling topology, and because topology _returns_ the TopoJSON output (which would strongly suggest that it is not altering its input).

Details: my application is using select subsets of the Features of a pre-built master GeoJSON FeatureCollection to perform geoqueries to a geoindexed MongoDB collection. The returned results (counting intersecting Points that meet certain criteria) are then added (cached) in the in-memory GeoJSON and the queried subset features are then collected into a new GeoJSON Feature collection and serialized to construct a response to the RESTful API call that initiated the query.

Adding conversion to TopoJSON of the new "response" GeoJSON FeatureCollection (which shares Features with the master FeatureCollection) silently corrupts some of the entries (the query subset) of the master GeoJSON collection as side-effect of calling topojson.topology.

In my opinion, a API method that converts one object type to another, and returns the "new" object as its output, should not simultaneously alter/destroy the input object in the process. This would not be the commonly expected behavior, and so is likely to lead to error prone uses of the call. At a minimum, this behavior should be well documented; but ideally, the default behavior of thetopology call should be "safe", building-up a new object for its output rather than working in-place within the input datastructure. It is perhaps a good option to have in-place conversion for extremely memory intensive edge cases, but the default behavior should be free of unexpected side-effects on the input(s).

BTW, TopoJSON is great, thanks for the hard work on it, this is just a rough edge on the API, IMO.

The following code reproduces the problem for a minimal case:

 (function() {
 var geojson_data, topojson, topojson_data;
 topojson = require('topojson');
 geojson_data = {
     "type": "FeatureCollection",
     "crs": {
       "type": "name",
       "properties": {
         "name": "urn:ogc:def:crs:OGC:1.3:CRS84"
       }
     },
     "features": [
       {
         "type": "Feature",
         "geometry": {
           "type": "Polygon",
           "coordinates": [[[12.908659734899926, 52.258453749997294], [12.910137089614084, 52.256896081728044], [12.908659734899926, 52.255338413458794], [12.905705025471613, 52.255338413458794], [12.904227670757455, 52.256896081728044], [12.905705025471613, 52.258453749997294], [12.908659734899926, 52.258453749997294]]]
         },
         "properties": {
           "type": "hexagon",
           "intersects": false
         }
       }, {
         "type": "Feature",
         "geometry": {
           "type": "Polygon",
           "coordinates": [[[12.908659734899926, 52.26156908653579], [12.910137089614084, 52.260011418266544], [12.908659734899926, 52.258453749997294], [12.905705025471613, 52.258453749997294], [12.904227670757455, 52.260011418266544], [12.905705025471613, 52.26156908653579], [12.908659734899926, 52.26156908653579]]]
         },
         "properties": {
           "type": "hexagon",
           "intersects": false
         }
       }
     ]
   };

   console.log("Before:");
   console.log(JSON.stringify(geojson_data.features[0], null, 1));

   topojson_data = topojson.topology({'collection': geojson_data});

   console.log("After:");
   /*
   # The line below fails because topojson.topoology call above actually
   # changed the geojson_data structure in-place rather than creating
   # a new datastructure, so the features array is gone and the index [0] is
   # invalid.
   */
   console.log(JSON.stringify(geojson_data.features[0], null, 1));

 }).call(this);

Well, dunno exactly when the change occurred, but with 0.0.39 I don't get the "property-filter" function called anymore. Here's the code (it worked fine with 0.0.8):
https://github.com/Vizzuality/CartoDB-SQL-API/blob/develop/app/controllers/app.js#L392

This is related to the world tour, and the natural earth countries dataset. Is it possible for the simplification to retain at least one geometry for a feature

For example, when simplifying with --simplify 1e-20
the feature is
{"type":"MultiPolygon","id":"AG","arcs":[[[285]],[[286]]]}

In an attempt to bring down the file size from 2.2 MB down to <200Kb, I tried --simplify 1e-5. The same feature now appears without any geometry
{"type":"MultiPolygon","id":"AG","arcs":[]}

Perhaps there an alternate automated mechanism to merge missing data from the original feature set, which I attempted to do manually and it does work, except it is quite tedious :) !

Great work, appreciate it.

Thanks
Suneet

I'm trying to simplify some geometries in the Chesapeake bay, but I can't seem to give the --simplify argument a value small enough to preserve their basic shape. It seems like a precision problem, because I've tried very small values: --simplify .000000001 or --simplify 10E-10, but the shapes are always mangled beyond recognition.

Any ideas?

When I try to convert a geojson (or shp) created with gdal_contour, topojson fails with the following error:

/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/lib/topojson/type.js:70
    var i = -1, n = coordinates.length;
                               ^
TypeError: Cannot read property 'length' of undefined
    at Object.typeDefaults.line (/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/lib/topojson/type.js:70:32)
    at Object.typeDefaults.LineString (/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/lib/topojson/type.js:29:10)
    at Object.typeDefaults.geometry (/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/lib/topojson/type.js:63:77)
    at Object.typeDefaults.GeometryCollection (/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/lib/topojson/type.js:24:26)
    at Object.typeDefaults.object (/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/lib/topojson/type.js:57:70)
    at Object.module.exports [as filter] (/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/lib/topojson/filter.js:52:12)
    at output (/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/bin/topojson:136:12)
    at notify (/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/node_modules/queue-async/queue.js:77:18)
    at Object.queue.await (/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/node_modules/queue-async/queue.js:34:23)
    at Object.<anonymous> (/Users/jeremy/Code/IXT/swiss-maps/node_modules/topojson/bin/topojson:81:3)

Somehow already converted geometries get passed to filter.object which look like { type: 'LineString', arcs: [ 0 ] }, and thus don't have a coordinates property anymore. This happens for versions >=0.0.17.

You can use this geojson file to reproduce the error. Oddly, other source files are working fine.

I think there's a bug in the Visvalingam simplification. Need tests & verification.

While steradians is a physically plausible unit for topological simplification, it seems like it would be also good to provide target simplification rates. The reason for this is that I can't seem to pick good precision thresholds for some files (specifically, zcta boundaries for the tiger shapefiles). Consider the following (78.topojson is the result of converting the 2010 census Virgin Islands boundaries through ogr2ogr and then topojson with no simplification):

$ node_modules/topojson/bin/topojson -s 1e-2 -p -o test.topojson topojson/78.topojson
retained 102 / 25869 points (0%)
$ node_modules/topojson/bin/topojson -s 1e-5 -p -o test.topojson topojson/78.topojson
retained 102 / 25869 points (0%)
$ node_modules/topojson/bin/topojson -s 1e-8 -p -o test.topojson topojson/78.topojson
retained 203 / 25869 points (1%)
$ node_modules/topojson/bin/topojson -s 1e-10 -p -o test.topojson topojson/78.topojson
retained 480 / 25869 points (2%)
$ node_modules/topojson/bin/topojson -s 1e-20 -p -o test.topojson topojson/78.topojson
retained 480 / 25869 points (2%)
$ node_modules/topojson/bin/topojson -s 1e-50 -p -o test.topojson topojson/78.topojson
retained 480 / 25869 points (2%)

I suspect something in the code is hitting floating-point precision limits. Is this a known limitation, or is there a way around it?

It'd be nice to have a --cartesian mode (or --no-spherical) which uses Cartesian rather than spherical coordinates. This would allow topojson to process geometry in local coordinate systems and UTM as-is, treating everything as planar rather than spherical.

This might require clarification in the TopoJSON specification, however, as the specification currently requires spherical coordinates.

While writing a testcase for a topojson output routine I was surprised to see a scale of

   { scale: [ 0.001000100010001, 0.001000100010001 ],

For an input where the extent is -5,-5 .. 5,5 (so 10x10)
Reading the code I see that the default precision is 1e4
but the actual scale factors are computed after perturbating
that nice round number by substracting 1, which introduces
the slightly off scale number:

  // Compute quantization scaling factors.
  kx = (Q - 1) / (x1 - x0);
  ky = (Q - 1) / (y1 - y0);

What's the rationale of that?

TopoJSON seems to deliberately convert FeatureCollection to GeometryCollection, see the code in topology.js. Is there a reason for that? ogr2ogr seems to be creating a FeatureCollection from my .SHP file whereas topojson generates a GeometryCollection. (Source data file is NHDPlusV21_CA_18_WBDSnapshot_01.7z

The reason I'm asking is Leaflet treats the two types of collections differently. The GeoJSON layer code has some nice affordances for FeatureCollections where it will let you set per-Feature styles and popups which it doesn't do for a GeometryCollection. I don't know the details and niceties of FeatureCollection vs GeometryCollection in the GeoJSON spec, but for my use case with Leaflet I'd prefer a FeatureCollection. Also it seems odd that ogr2ogr does the opposite.

I've noticed that repeating property names often make a big difference in the uncompressed sizes of TopoJSON files. One way to eliminate the property name redundancy is to introduce an array of property names in the top-level object and a similarly ordered array of values in each object (a la CSV), then expand those into "properties" objects when decoding to GeoJSON. E.g.:

var topology = {
  "type": "Topology",
  "transform": {...},
  "properties": ["name", "area"],
  "objects": {
    "foo": [
      {
        "geometries": [
          {
            "type": "Polygon",
            "arcs": [...],
            "properties": ["Some Place", 10.24]
          }
        ]
      }
    }
  }
};

var feature = topojson.object(topology, topology.objects.foo.geometries[0]);
console.log(feature.properties.name); // "Some Place"

The resulting files would compress better and eliminate the need for pushing feature data into CSVs, which would also preserve the property value data types.

I am having trouble converting a county shapefile file into a topojson.

The issue appears to be quantization taking too much memory (even with a 64 G RAM machine).

$topojson -q quantization "1e6" -o output "shapefiles/counties/tl_2012_us_county.shp"

returns

FATAL ERROR: JS Allocation failed - process out of memory

URL to county input shapefile:

http://www2.census.gov/geo/tiger/TIGER2012/COUNTY/tl_2012_us_county.zip

When attempting to convert a sizeable (14MB) topojson to geojson via the bin/geojson tool, I get the following error:

/usr/lib/node_modules/topojson/bin/geojson:41
        this[geometry.type](geometry);
                           ^
TypeError: Property 'null' of object #<Object> is not a function
    at Object.argv._.forEach.type.geometry (/usr/lib/node_modules/topojson/bin/geojson:41:28)
    at Object.typeDefaults.GeometryCollection (/usr/lib/node_modules/topojson/lib/topojson/type.js:24:26)
    at Object.argv._.forEach.type.geometry (/usr/lib/node_modules/topojson/bin/geojson:41:28)
    at Object.typeDefaults.object (/usr/lib/node_modules/topojson/lib/topojson/type.js:57:16)
    at /usr/lib/node_modules/topojson/bin/geojson:47:8
    at Array.forEach (native)
    at Object.<anonymous> (/usr/lib/node_modules/topojson/bin/geojson:33:8)
    at Module._compile (module.js:449:26)
    at Object.Module._extensions..js (module.js:467:10)
    at Module.load (module.js:356:32)

Does this have the ring of an inherent geometry error, or did I miss a key switch in the executable? Either way I'm sure the error is mine, I'd just like to know where to look to unravel it.

Thanks!

For example, if someone passes in UTM grid coordinates rather than WGS84.

It'd be nice to have a mode where topojson outputs the computed area of each arc's triangle, for client-side simplification. Although, I guess this could be done on the client, too.

E.g., from world-atlas:

#!/usr/bin/env node

var fs = require("fs");

var topology = JSON.parse(fs.readFileSync("/dev/stdin")),
    object = topology.objects[process.argv[2]],
    splice = +process.argv[3],
    geometryId = {},
    args = [],
    type;

object.geometries.forEach(function(g, i) {
  if (i === splice) return;
  switch (type = g.type) {
    case "MultiPolygon": case "MultiLineString": g.arcs.forEach(function(c) { args.push(c); }); break;
    case "Polygon": case "LineString": args.push(g.arcs); break;
    default: throw new Error("unsupported type: " + g.type); break;
  }
});

object.type = /^Multi/.test(type) ? type : "Multi" + type;
object.arcs = args;
delete object.geometries;

// TODO garbage collect arcs

console.log(JSON.stringify(topology));

Would be nice to enable this with a --merge layer flag.

I've gotten a lot of mileage out of the type() function exported by lib/topojson/type.js, and I think that other people doing interesting things with topology (and GeoJSON geometry in general) would too. Could it be included in topojson.js? E.g.:

topojson.each(features, {
  arc: function(arc) {
  }
});

Since TopoJSON data doesn't degrade to GeoJSON for code that is ignorant of the topology, is there anything to gain by repurposing the "coordinates" member? A shorter "arcs" could also be a usability win because the length and verbosity of "coordinates" has bugged a lot of folks.

The change that broke this is 40d7fff.

My topojson command:

./node_modules/topojson/bin/topojson \
    -e build/cri-codes.tsv \
    --id-property=+ID_2 \
    -p code=+code \
    -p name=NAME_2 \
    -p province=NAME_1 \
    -q 1e4 \
    -o cri-topo.json \
    cri.json

cri-codes.tsv:

id  code
11408   403
11409   410
11410   706
...

The code property is imported correctly in 1.1.0. As of 1.1.1, it isn't.

The --properties flag should accommodate a list of property names separated by commas. For instance, ogr2ogr allows you to specify multiple properties with the -select argument:

$ ogr2ogr -select name,area,district -f CSV foo.csv foo.shp

This is much easier than having to specify each property name separately, which is how -p/--properties works now.

Some points seem to all connect to the origin point. Please see url for reference:
http://lonelydatum.com/staging/temp/topo/topo.html

How can I fix this?
PS. This tool is a live saver. I reduced my file from 9 mb to 1mb. THANK YOU!

Gar

Currently TopoJSON parses GeoJSON with JSON.parse(). That in turn seems to load the whole file into memory at once, failing on giant input files. It'd be nice if TopoJSON could use a streaming JSON parser on inputs.

A quick Google search turns up several streaming JSON parsers for Node. Ie:

https://github.com/dscape/clarinet
https://github.com/creationix/jsonparse

I'm sorry for the newbie question but I'm new to node and I'd really like to use topojson to reduce my geojson.

This is what I've done so far:

1. I've installed the modules ( npm install )
2. I ran the index.js ( node index.js )

Can someone tell me the convert my current.geojson please?

Thanks!
Gar

This is the typical method of constructing boundaries between countries:

topojson.mesh(world, world.objects.countries, function(a, b) { return a !== b; })

However, this appears to fail in the case of Lesotho (surrounded entirely by South Africa).

Hi Mike,

I tried to topoJSON this:
http://www.saltaku.com/static/data/lsoa.json

topojson/bin$ ./topojson ./topojson ../../lsoa.json

and this is what I get:

   /home/dimi/tmp/topojs/topojson/lib/topojson/topology.js:113
      x = (point[0] - x0) * kx | 0,
                ^
TypeError: Cannot read property '0' of undefined
 at line (/home/dimi/tmp/topojs/topojson/lib/topojson/topology.js:113:21)
 at Array.map (native)
 at Object.module.exports.each.Polygon (/home/dimi/tmp/topojs/topojson/lib/topojson/topology.js:84:42)
 at Object.typeDefaults.geometry (/home/dimi/tmp/topojs/topojson/lib/topojson/type.js:62:30)
 at Object.module.exports.each.geometry (/home/dimi/tmp/topojs/topojson/lib/topojson/topology.js:88:30)
 at Object.module.exports.each.Feature (/home/dimi/tmp/topojs/topojson/lib/topojson/topology.js:60:12)
 at Array.map (native)
 at Object.module.exports.each.FeatureCollection     (/home/dimi/tmp/topojs/topojson/lib/topojson/topology.js:68:41)
 at Object.typeDefaults.object (/home/dimi/tmp/topojs/topojson/lib/topojson/type.js:56:28)
 at module.exports.each.point.x (/home/dimi/tmp/topojs/topojson/lib/topojson/topology.js:18:47)

My node version is 0.8.14

Is there anything wrong with my json file?

Thanks
Dimi.

Related topojson/world-atlas#2. Previously this was done by hand (e.g., c268c95), but it would be nice to do it automatically. It would be even better to piece together split features such as the eastmost polygon of Russia.

If you pass a geojson object containing records with null geometries, the topology builder chokes.

Here's an example input:

{ type: 'FeatureCollection',
  features:
   [{ type: 'Feature',
    properties: { gid: 2, name: 'D' },
    geometry: null }]

And here's the error message:

Cannot read property 'type' of null
topojson/lib/topojson/type.js:61
topojson/lib/topojson/type.js:14
topojson/lib/topojson/type.js:56

Also, I think it’s possible that for very small features, when reversed, still have negative area. Or perhaps these are degenerate features (e.g., polygons collapsed to lines).

sudo npm install -g topojson is failing for me.

gyp ERR! configure error 
gyp ERR! stack Error: Python executable "python" is v3.3.0, which is not supported by        gyp.
gyp ERR! stack You can pass the --python switch to point to Python >= v2.5.0 & < 3.0.0.
gyp ERR! stack     at failPythonVersion   (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:118:14)
gyp ERR! stack     at /usr/lib/node_modules/npm/node_modules/node-    gyp/lib/configure.js:107:9
gyp ERR! stack     at ChildProcess.exithandler (child_process.js:538:7)
gyp ERR! stack     at ChildProcess.EventEmitter.emit (events.js:99:17)
gyp ERR! stack     at maybeClose (child_process.js:638:16)
gyp ERR! stack     at Process._handle.onexit (child_process.js:680:5)
gyp ERR! System Linux 3.7.10-1-ARCH
gyp ERR! command "node" "/usr/lib/node_modules/npm/node_modules/node-    gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd   /usr/lib/node_modules/topojson/node_modules/shapefile/node_modules/iconv
gyp ERR! node -v v0.8.21
gyp ERR! node-gyp -v v0.8.5
gyp ERR! not ok 
npm ERR! [email protected] install: `node-gyp rebuild`
npm ERR! `sh "-c" "node-gyp rebuild"` failed with 1
npm ERR! 
npm ERR! Failed at the [email protected] install script.
npm ERR! This is most likely a problem with the iconv package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls iconv
npm ERR! There is likely additional logging output above.

npm ERR! System Linux 3.7.10-1-ARCH
npm ERR! command "node" "/usr/bin/npm" "install" "-g" "topojson"
npm ERR! cwd /home/jacques
npm ERR! node -v v0.8.21
npm ERR! npm -v 1.2.14
npm ERR! code ELIFECYCLE
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/jacques/npm-debug.log
npm ERR! not ok code 0

I'm assuming this is because Archlinux's uses python 3.3 instead of 2.7.

the only way I can get topojson.topology to return valid output is to pass it a feature collections features. If I pass the entire object, it does not convert properly, BBOX values are all null, transforms are NAN and and the feature collection gets written verbatim into objects.

The following code returns all of the objects in my geoJSON in objects but with no Geometry collection or geometries. If I pass simple GeoJSON it returns as described above.

var http = require('http');
var util = require('util');
var qs = require('querystring');
var topojson = require("topojson");

http.createServer(function (req, res) {

console.log('Request received: ');
var body = '';
req.on('data', function (chunk) {
    body +=chunk;

});
req.on('end', function () {
    var POST = qs.parse(body);
    var geoJSON = JSON.parse(POST.layers);
    var topo = topojson.topology(geoJSON.features,{quantization:6});
    res.setHeader('Access-Control-Allow-Origin', "*");
    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.write(JSON.stringify(topo));
    res.end('');
    console.log('success');
});

}).listen(7090);
console.log('Server running on port 8080');

The wiki should contain information about browser compatibility. IE8 doesn't seem to work.

There are a bunch of cases where quantization seems to corrupt topologically-valid input. For example, tiny islands near the coast might get merged with the coastline. So, rather than rely on an exact match post-quantization, it would be nice if the topojson reference implementation could instead derive the topology from non-quantized inputs.

Note: this is non-trivial to implement, since the current implementation requires quantized inputs to create an efficient hashtable keyed by point. We’ll need a way to create a hashtable from floating point locations to support this feature.

Once this feature is added, it probably makes sense to have it be the default behavior, since it is safer than doing fuzzy matching.

Using the following command
....................
topojson -s 50 -o data/30419_61831.topojson data/30419_61831.geojson
....................

to process the following geojson (filename: 30419_61831.geojson)
....................
{"type":"FeatureCollection","generator":"Folge 3 OsmJson2GeoJson Generator","copyright":"The data included in this document is from www.openstreetmap.org. The data is made available under ODbL.","timestamp":"2013-05-19T09:35:18.310Z","features":[{"type":"Feature","properties":{"@type":"relation","@id":61831,"postal_code":"30419","type":"enforcement","@relations":[]},"geometry":{"type":"MultiPolygon","coordinates":[[]]}}]}
....................

leads to the following exception
....................
{ type: 'Polygon', arcs: [ undefined ] }

undefined:193
for (var i = 0, n = arcs.length; i < n; ++i) arc(arcs[i], points);
^
TypeError: Cannot read property 'length' of undefined
at line (eval at (/usr/local/lib/node_modules/topojson/index.js:3:33), :193:27)
at ring (eval at (/usr/local/lib/node_modules/topojson/index.js:3:33), :199:20)
at Array.map (native)
at polygon (eval at (/usr/local/lib/node_modules/topojson/index.js:3:33), :205:19)
at Object.geometryType.Polygon (eval at (/usr/local/lib/node_modules/topojson/index.js:3:33), :220:37)
at geometry (eval at (/usr/local/lib/node_modules/topojson/index.js:3:33), :211:71)
at object (eval at (/usr/local/lib/node_modules/topojson/index.js:3:33), :224:12)
at feature (eval at (/usr/local/lib/node_modules/topojson/index.js:3:33), :164:17)
at Object.featureOrCollection [as feature](eval at %28/usr/local/lib/node_modules/topojson/index.js:3:33%29, :156:9)
at ringArea (/usr/local/lib/node_modules/topojson/lib/topojson/clockwise.js:32:37)
....................

While the geojson is clearly useless and maybe even invalid, it would be great to see more context in the error description. I was processing 12000 boundaries when the error occurs and had a hard time to identify the one that causes the error.

Maybe it is possible to catch the error some levels above and put some more context in the description?

Thanks & Regards
Christoph

Using a geojson input file from here, topojson throws an error when no properties are given:

topojson geojson/state.json 

/usr/local/share/npm/lib/node_modules/topojson/bin/topojson:76
 o = {}; [].concat(argv.properties).forEach(function(k) { var i = k.indexOf("=
                                                                    ^
TypeError: Cannot call method 'indexOf' of null
    at topojson.topology.property-filter (/usr/local/share/npm/lib/node_modules/topojson/bin/topojson:76:94)
    at Array.forEach (native)
    at topojson.topology.property-filter (/usr/local/share/npm/lib/node_modules/topojson/bin/topojson:76:62)
    at Object.<anonymous> (/usr/local/share/npm/lib/node_modules/topojson/bin/topojson:76:219)
    at Module._compile (module.js:449:26)
    at Object.Module._extensions..js (module.js:467:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.runMain (module.js:492:10)
    at process.startup.processNextTick.process._tickCallback (node.js:244:9)

If -p null is provided, it works:

topojson -p null geojson/state.json

If -p is optional, then this seems like a bug in the node wrapper script that does the parsing.

You've got a few. Shawn just published one.

If you pass an empty object as the "options" argument to topology constructor you get a different behavior than not passing an argument at all. I would expect only explicitly listed members of those options overriding the defaults instead.

updating topojson to version 1.1.3 (from 0.0.8) revealed global variables "leakage" for variables called x2 and y2 (no idea where the are)

It would be nice if you could customize the transform’s scale and translate to specify the viewport. This would eliminate the need to compute the bounding box on the client and then readjust the transform (as in this example).

var bounds = path.bounds(topojson.feature(ca, ca.objects.counties)),
    dx = bounds[1][0] - bounds[0][0],
    dy = bounds[1][1] - bounds[0][1],
    k = .95 * Math.min(width / dx, height / dy);

ca.transform.scale[0] *= k;
ca.transform.scale[1] *= -k;
ca.transform.translate[0] = (width - dx * k) / 2;
ca.transform.translate[1] = height - (height - dy * k) / 2;

Perhaps a --width 960 --height 500 argument to topojson could do the same thing, scaling to fit the specified viewport, and translating the bounding box center to the viewport center?

The TopoJSON area implementation is no longer consistent with d3.geo.area due to an optimization by @jasondavies. Ideally, I’d like to keep these consistent (so that TopoJSON never disagrees with D3 as to what constitutes a counterclockwise polygon). However, when I tried porting the latest d3.geo.area implementation, I think it introduced some bugs, and so needs further investigation.

Would it be possible to introduce a flag to topojson commandline application, that causes topojson to catch and log errors while further processing the dataset? Currently, the entire process fails if an error occurs.

Sometimes you are not interested in detail accuracy but just want to get a feeling for what is inside a dataset.

So, it would be great to see that errors occur while topojson is converting data, but being nevertheless able to further work with the rest of the dataset. Maybe it would be meaningful to catch the error on the feature level?

I am getting the following errors when trying to compile(?) on windows:

C:\Users\rindahb>npm install -g topojson
npm http GET https://registry.npmjs.org/topojson
npm http 304 https://registry.npmjs.org/topojson
npm http GET https://registry.npmjs.org/shapefile
npm http GET https://registry.npmjs.org/queue-async
npm http GET https://registry.npmjs.org/optimist
npm http 304 https://registry.npmjs.org/shapefile
npm http 304 https://registry.npmjs.org/optimist
npm http 304 https://registry.npmjs.org/queue-async
npm http GET https://registry.npmjs.org/wordwrap
npm http GET https://registry.npmjs.org/iconv
npm http 304 https://registry.npmjs.org/wordwrap
npm http 304 https://registry.npmjs.org/iconv

[email protected] install C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson
\node_modules\shapefile\node_modules\iconv
node-gyp rebuild

C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefil
e\node_modules\iconv>node "C:\Program Files\nodejs\node_modules\npm\bin\node-gyp
-bin....\node_modules\node-gyp\bin\node-gyp.js" rebuild
iconv.cc
..\src\iconv.cc(132): warning C4267: 'argument' : conversion from 'size_t' to '
uint32_t', possible loss of data [C:\Users\rindahb\AppData\Roaming\npm\node_mod
ules\topojson\node_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
..\src\iconv.cc(133): warning C4267: 'argument' : conversion from 'size_t' to '
uint32_t', possible loss of data [C:\Users\rindahb\AppData\Roaming\npm\node_mod
ules\topojson\node_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
C:\Users\rindahb.node-gyp\0.8.21\deps\v8\include\v8.h(183): warning C4506: no
definition for inline function 'v8::Persistent v8::Persistent::New(v8::Ha
ndle)' [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\node_modu
les\shapefile\node_modules\iconv\build\iconv.vcxproj]
with
[
T=v8::Object
]
localcharset.c
iconv.c
..\deps\libiconv\libcharset\lib\localcharset.c(38): warning C4005: 'WIN32_NATIV
E' : macro redefinition [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topo
json\node_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
command-line arguments : see previous definition of 'WIN32_NATIVE'
..\deps\libiconv\lib\iconv.c(53): warning C4005: 'USE_DOS' : macro redefinition
[C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shape
file\node_modules\iconv\build\iconv.vcxproj]
command-line arguments : see previous definition of 'USE_DOS'
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\utf7.h(162): warning C4018: '<' : signe
d/unsigned mismatch [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson
\node_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\utf7.h(331): warning C4018: '<' : signe
d/unsigned mismatch [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson
\node_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\johab_hangul.h(253): warning C4244: 're
turn' : conversion from '__int64' to 'int', possible loss of data [C:\Users\rin
dahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_modu
les\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\hz.h(39): warning C4018: '<' : signed/u
nsigned mismatch [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\no
de_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\hz.h(51): warning C4018: '<' : signed/u
nsigned mismatch [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\no
de_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\hz.h(57): warning C4018: '<' : signed/u
nsigned mismatch [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\no
de_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\hz.h(65): warning C4018: '<' : signed/u
nsigned mismatch [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\no
de_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\hz.h(80): warning C4018: '<' : signed/u
nsigned mismatch [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\no
de_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(44): warning C4267: 'fun
ction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\rin
dahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_modu
les\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(50): warning C4244: 'ret
urn' : conversion from '__int64' to 'int', possible loss of data [C:\Users\rind
ahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_modul
es\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(88): warning C4267: 'fun
ction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\rin
dahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_modu
les\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(94): warning C4244: 'ret
urn' : conversion from '__int64' to 'int', possible loss of data [C:\Users\rind
ahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_modul
es\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(116): warning C4267: 'fu
nction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\ri
ndahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_mod
ules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(136): warning C4267: 'fu
nction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\ri
ndahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_mod
ules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(145): warning C4244: 're
turn' : conversion from '__int64' to 'int', possible loss of data [C:\Users\rin
dahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_modu
les\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(208): warning C4267: 'fu
nction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\ri
ndahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_mod
ules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(244): warning C4267: 'fu
nction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\ri
ndahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_mod
ules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(284): warning C4267: 'fu
nction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\ri
ndahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_mod
ules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(362): warning C4267: 'fu
nction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\ri
ndahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_mod
ules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(400): warning C4267: 'fu
nction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\ri
ndahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_mod
ules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(449): warning C4267: 'fu
nction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\ri
ndahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_mod
ules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(487): warning C4267: 'fu
nction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\ri
ndahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_mod
ules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\loop_unicode.h(514): warning C4267: 'fu
nction' : conversion from 'size_t' to 'int', possible loss of data [C:\Users\ri
ndahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile\node_mod
ules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\iconv_open1.h(84): warning C4244: 'func
tion' : conversion from '__int64' to 'unsigned int', possible loss of data [C:
Users\rindahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile
node_modules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\iconv_open1.h(174): warning C4244: 'fun
ction' : conversion from '__int64' to 'unsigned int', possible loss of data [C:
\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile
\node_modules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\iconv_open1.h(84): warning C4244: 'func
tion' : conversion from '__int64' to 'unsigned int', possible loss of data [C:
Users\rindahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile
node_modules\iconv\build\iconv.vcxproj]
c:\users\rindahb\appdata\roaming\npm\node_modules\topojson\node_modules\shapefi
le\node_modules\iconv\deps\libiconv\lib\iconv_open1.h(174): warning C4244: 'fun
ction' : conversion from '__int64' to 'unsigned int', possible loss of data [C:
\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\node_modules\shapefile
\node_modules\iconv\build\iconv.vcxproj]
..\deps\libiconv\lib\iconv.c(427): warning C4090: 'function' : different 'const
' qualifiers [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\node_m
odules\shapefile\node_modules\iconv\build\iconv.vcxproj]
..\deps\libiconv\lib\iconv.c(429): warning C4267: 'function' : conversion from
'size_t' to 'unsigned int', possible loss of data [C:\Users\rindahb\AppData\Roa
ming\npm\node_modules\topojson\node_modules\shapefile\node_modules\iconv\build
iconv.vcxproj]
..\deps\libiconv\lib\iconv.c(539): warning C4244: 'function' : conversion from
'__int64' to 'unsigned int', possible loss of data [C:\Users\rindahb\AppData\Ro
aming\npm\node_modules\topojson\node_modules\shapefile\node_modules\iconv\build
\iconv.vcxproj]
Release\obj\iconv\iconv.obj : warning LNK4042: object specified more than once;
extras ignored [C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\nod
e_modules\shapefile\node_modules\iconv\build\iconv.vcxproj]
Generating code
Finished generating code
iconv.vcxproj -> C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson\n
ode_modules\shapefile\node_modules\iconv\build\Release\iconv.node
C:\Users\rindahb\AppData\Roaming\npm\topojson -> C:\Users\rindahb\AppData\Roamin
g\npm\node_modules\topojson\bin\topojson
[email protected] C:\Users\rindahb\AppData\Roaming\npm\node_modules\topojson
├── [email protected]
├── [email protected] ([email protected])
└── [email protected] ([email protected])

C:\Users\rindahb>topojson --help

module.js:340
throw err;
^
Error: Cannot find module '../build/Debug/iconv.node'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:362:17)
at require (module.js:378:17)
at Object. (C:\Users\rindahb\AppData\Roaming\npm\node_modules\top
ojson\node_modules\shapefile\node_modules\iconv\lib\iconv.js:27:14)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:362:17)

Any ideas on what I am doing wring?
Thanks
Bruce