jsts

JSTS is an ECMAScript library of spatial predicates and geometry functions conforming to the Simple Features Specification for SQL published by the Open Geospatial Consortium. It is a direct port of the well-established Java library JTS (JTS Topology Suite), produced through automatic AST-to-AST translation of the original Java source, so its public API mirrors org.locationtech.jts closely enough that Java-side documentation and examples largely transfer.

The I/O-related classes were the exception: since automatic translation could not cleanly handle them, WKT, GeoJSON, and OpenLayers 3+ readers/writers were manually ported and adapted for JavaScript. The result is a dependency-light geometry engine (a single small dependency, fastpriorityqueue) that runs equally in Node.js 18+ and in the browser, making it a common building block under web mapping stacks like OpenLayers and other GIS tooling that need robust polygon/line/point predicates without shelling out to a native geometry engine.

What You Get

• Full JTS-equivalent API surface — geometry classes (Point, LineString, Polygon, MultiPolygon, GeometryCollection) and operations translated 1:1 from the Java JTS Topology Suite, so JTS documentation and patterns largely apply directly.
• Spatial predicates and overlay operations — intersects, contains, within, crosses, touches, plus boolean overlay (union, intersection, difference, symmetric difference) implemented via the same relate/overlay algorithms as JTS.
• WKT and GeoJSON I/O — WKTReader/WKTWriter and GeoJSONReader/GeoJSONWriter classes for parsing and serializing geometries in the two most common GIS interchange formats.
• OpenLayers-native geometry bridge — a dedicated reader/writer pair converts directly between JSTS geometries and OpenLayers 3+ geometry objects, letting map applications run JSTS operations on features already rendered on an OL map.
• Precision and simplification tooling — GeometryPrecisionReducer, Douglas-Peucker and topology-preserving simplifiers, and buffer operations for cleaning up or generalizing geometry before further processing.
• ES modules and legacy ES5 builds — consumable as ES6+ source modules (bundler-friendly, tree-shakeable) or as a pre-built ES5 UMD bundle for direct <script> inclusion in older browsers.

Common Use Cases

• Client-side spatial analysis in web maps — running intersects/contains/buffer checks directly in the browser against features already loaded into an OpenLayers or Leaflet map, avoiding a round trip to a spatial database.
• GeoJSON validation and cleanup pipelines — parsing GeoJSON with GeoJSONReader, running IsValidOp/GeometryPrecisionReducer to repair or simplify malformed geometries before they’re persisted or re-served.
• Format conversion between WKT and GeoJSON — using WKTReader/GeoJSONWriter (or the reverse) as a lightweight conversion layer in Node.js ETL scripts that move geometry data between a database column and an API response.
• Porting JTS-based Java geometry logic to JavaScript/Node.js — teams migrating a Java backend’s spatial-analysis logic to a Node.js service can reuse the same algorithm names and call patterns almost verbatim, since JSTS mirrors the JTS API.

Under The Hood

Architecture JSTS is organized as a direct namespace mirror of the Java JTS source tree — src/org/locationtech/jts/{geom,algorithm,operation,io,index,noding,triangulate,...} — plus a src/java/{lang,util,io,text} shim layer that reimplements the small slice of the Java standard library (Comparable, Cloneable, Serializable, IllegalArgumentException, collections) that JTS classes depend on. Each JTS class becomes one JS module exporting a class of the same name (e.g. Geometry.js, RelateOp.js), with constructor overloading resolved at runtime via arguments.length inspection rather than TypeScript-style overload signatures. This keeps the JS call graph structurally identical to the upstream Java library, which is the deliberate design goal: anything that breaks the shape of a JTS class (renaming methods, flattening the geom/operation/algorithm layering) would break the promise that JTS knowledge transfers directly.

Tech Stack The package is plain ES modules ("type": "module" in package.json) targeting Node.js 18+, with almost no runtime dependency beyond fastpriorityqueue. Rollup builds the browser bundle (rollup.config.js producing dist/jsts.min.js), TypeScript (tsc) generates .d.ts type declarations from JSDoc rather than hand-written types, and JSDoc/jsdoc.json drives API documentation generation. CI (.github/workflows/node.js.yml) runs on Node 22 via Yarn on every push/PR to master.

Code Quality Tests live under test/auto (an automated JTS-style test-suite runner reading XML fixtures via testxml/, executed through test/auto/node/runner.js and generate.js) and test/manual (hand-written Mocha specs organized by JTS package: operation, algorithm, geom, io, linearref, index, triangulate, precision, issues). npm test runs both under nyc for coverage, and npm run lint runs ESLint (flat config, eslint.config.js) against src. Error handling favors throwing typed exceptions ported from Java (IllegalArgumentException, TopologyException) rather than swallowing failures, consistent with the upstream JTS contract the README explicitly documents as a caveat for consumers.

What Makes It Unique Unlike geometry libraries written natively for JavaScript, JSTS’s value is fidelity: because it’s generated from JTS via AST-to-AST translation (with only the I/O classes manually adapted), it inherits JTS’s extensively validated, decades-refined implementations of topology-sensitive algorithms — relate operations, robust overlay, buffer construction — that are notoriously hard to get numerically correct from scratch. That gives JSTS a correctness ceiling most pure-JS geometry libraries don’t attempt to match, at the cost of an API that reads like translated Java rather than idiomatic modern JavaScript.