Issue with geobucket package

Issue for path cli resolving when migrating CommonJS to ES6

This example tracks a path-resolution error that occurs when migrating a command-line tool from CommonJS to ES6 modules. It shows the same `require('..')` call working in CommonJS while its ES6 equivalent, `import {parse} from '../index.js'`, fails with `ERR_MODULE_NOT_FOUND` because the ES6 resolver does not search the `lib` directory. The visualization documents the failing command, the package.json configuration that sets `"main": "./lib"`, and the proposed fix of writing the import as `'../lib/index.js'` instead. The data comes directly from the user’s error trace and file contents.

57% match

Gist e9ca6a4ec4fe6c3bee98

This example shows how a JavaScript module with reserved-word property names—specifically `await`—triggers a parsing error during Rollup’s build pipeline, while the same names work in object literals. The code includes an `index.js` file defining an exported object with methods named `await` and `add`, and a `rollup.config.js` that applies the `rollup-plugin-babel` with the `es2015-rollup` preset via `.babelrc`. The visualization highlights the exact source-map error location from Rollup’s parser, contrasting valid syntax with the failing line. It uses Rollup’s plugin system and Babel’s preset configuration to demonstrate the issue.

HHypercubed

Gist 28a1d2e30c530c6a170ff5f68798b235

This example curates a set of GeoJSON-based specifications and extensions, organizing them by how they add keys, use multiple files, or serialize for streaming. It lists linked resources such as geojson-t, geocodejson-spec, geojson-ld, and the OGC Features API, alongside STAC and Mapbox simplestyle. It also covers the IMDF format for indoor data and the GeoJSON Text Sequences proposal, presenting a structured reference rather than a rendered map or interactive chart, with no code libraries or visualization APIs involved.

Gist 7d99b7d79138bda9a2dfb092728da54c

This example documents a debugging session for serving OpenStreetMap vector tiles with the VersaTiles toolkit. It shows how a version mismatch between the VersaTiles server (0.2.14) and its frontend client causes 404 errors for tile requests, as the server expects flipped Y-axis coordinates (2873/4058) instead of the standard OSM ordering (4058/2873). The fix involves downgrading to versatiles 0.2.13, which resolves the coordinate issue but introduces a client-side gzip decompression error (`Unimplemented type: 3`). The code uses `cargo install`, `versatiles convert`, `versatiles probe`, and `versatiles serve` commands, alongside `curl` for testing tile endpoints, referencing a Geofabrik extract of Pays de la Loire.

Gist 9ea54f64f11961c494767a8384892e83

This example demonstrates how to debug a geocoding failure by comparing two CSV files sent to the French government's geocoding API (api-adresse.data.gouv.fr). It shows that renaming the first column from `geocoder__line` to `geocoder__line_number` prevents rows from being silently dropped during the batch geocoding request. The shell script (`debug-geocoder-related-issue.sh`) uses `curl` to POST both files to the API, then displays the first eight geocoded results. The output files include latitude, longitude, and match scores, revealing how column naming affects API behavior.

Gist 4ab7840c00aa352f278636ea3f3f0d3e

This example demonstrates streaming merge of two French cadastral parcel GeoJSON files into a single unified feature collection, output as a continuous JSON stream to standard output. It shows how to combine multiple geospatial datasets without loading them entirely into memory. The code uses the `geojson-stream` library for parsing and stringifying GeoJSON features, Node.js `fs.createReadStream` for file input, and the `zlib` module to decompress gzipped source files. Data originates from the Etalab cadastre dataset, with separate scripts handling zipped and unzipped input files.

49% match

Gist 597373

This example shows a Node.js script that attempts to process crime incident data from a CSV file using the `ecsv` library, but it fails due to a system resource limit. The code calls `exec('wc -c "foo"', ...)` inside the `ecsv.each` callback for every row, spawning a new child process for each record. The visible stack trace from `child_process.spawn` reveals the error "Too many open files," indicating the script exhausts file descriptors because it launches processes asynchronously without waiting for completion. The gist demonstrates a common anti-pattern where unthrottled asynchronous process spawning overwhelms the operating system, using only Node.js core APIs (`child_process.exec`, `fs`) and the third-party `ecsv` parser.

CCaged

49% match