mclaeysb / simplepolygon Goto Github PK

process.hrtime is not a valid function in the browser.

Have this ever been tested in the browser? Tests are passing fine in NodeJS.

https://github.com/mclaeysb/simplepolygon/search?utf8=%E2%9C%93&q=process.hrtime&type=

Might be handy to set up a simple /docs folder with an index.html and a browser friendly build to simply test this library in the browser. Here's a "minimalistic" approach I've been doing for some of my libraries https://github.com/DenisCarriere/slippy-tile/tree/master/docs.

I can send a PR to include a simple Rollup config that builds the bundle, let me know.

For this type of debugging/timings, you could look into including debug for your internal testing/debugging.

Dear Manuel, I am really excited about integrating simplepolygon into a locus-drawing js browser app I've been developing over the past few months. It draws loci of centers of families of triangles "mounted" on ellipses.

Browserifying simplepolygon worked like a charm.

However I am having a few issues with the results returned by simplepolygon. Consider first of all one 800-long sample polygon (it's actually a curve approximation), you can see it live here: https://bit.ly/2Zg7Mv1

As you can see, the above curve has 6 self intersections and 7 simple subregions. The coloring scheme below reveals the independent subregions returned by simplepolygon. unfortunately, only 3 are returned. Any idea why?

For your own testing I am attaching a zipped json w the 800 vertices:

vtx-X14.zip

Complex polygons should return multiple parts (only return with two parts).

https://gist.github.com/a49494d38ded757824ba1f325bf26940

@mclaeysb Thank you for the library!

I'm quite interested in the Subramaniam algorithm, but the paper is quite vague on details — e.g. it's not clear what order the edges should be processed if there's more than 1 intersection in the same point, and doesn't cover degenerate cases like collinear edges.

Does the algorithm handle cases like this? Are there any known limitations to the input for it to be processed properly?

P.S. Feel free to close the issue if it's not actionable.

Polygon with holes (inners are replaced as outers).

https://gist.github.com/c7c1343e8102c506b1f256755446c531

Hi,

This tool is really helpful to me, thanks a lot!

I have a question regarding an edge case mentioned in the README.md:

An exception includes polygons with spikes or cuts such as [[0,0],[2,0],[1,1],[2,2],[0,2],[1,1],[0,0]], who
are currently allowed and treated correctly, but make the output non-simple (by OGC definition).

This example is rejected in 1.1.7. Try to run this:

var feature, simplepolygon;

simplepolygon = require("simplepolygon");

feature = {
  type: "Feature",
  geometry: {
    type: "Polygon",
    coordinates: [[0, 0], [2, 0], [1, 1], [2, 2], [0, 2], [1, 1], [0, 0]]
  }
};

simplepolygon(feature);

Is this a bug? Or is the README outdated?

@mclaeysb

In line

Variable allIsectsAsIsectRbushTreeItem isn't declared as var, let or const.

In some environments this amounts for the variable becoming global. Linters complain about it being undeclared, and QUnit doesn't pass tests if

QUnit.config.noglobals = true; config option is used.

Do you think you could declare this variable without side effects?

Just noticed some positive changes in v1.2.0.

Still not 100% there yet, but better than before, only splits 1 geometry.

Using this complex.geojson

Before to v1.2.0

Now v1.2.0