VL.NetTopologySuite.GeoJSON 0.0.1-alpha

VL.NetTopologySuite.GeoJSON

GeoJSON for VL.NetTopologySuite, as nodes for vvvv gamma.

Read a GeoJSON document into NetTopologySuite features, and write features back out. Three nodes, in VL.NetTopologySuite's own NetTopologySuite.IO category beside Read WKT and Write WKT.

Status: 0.0.1-alpha, the first release — a prerelease, early. It needs VL.NetTopologySuite 0.0.4-alpha (on nuget.org since 2026-10-18), which installs with it. Every node resolves in a headless vvvvc compile of all six help patches, 86 tests pass, the category is proved, and the changed help patches were run in vvvv 7.4. F1 is not yet checked. See docs/ROADMAP.md.

Until 2026-10-18 this was VL.GeoJSON, with four nodes of its own and no dependency on any sibling. Why it changed is in docs/ARCHITECTURE.md.

Learning it

Six help patches, in the order the help browser shows them:

GeoJSON text
     ↓
Read GeoJSON            ← parses when the text CHANGES, not every frame
     ↓
Features (Spread) ─────────────────→ VL.Mapsui  FeatureLayer → Map
     ↓  GetSlice / Count / ForEach ── vvvv's own spread nodes
     ↓  Split                      ── VL.NetTopologySuite
Geometry ──────────────────────────→ VL.NetTopologySuite  Buffer / Area / Intersection
Attributes (Dictionary) → TryGetValue      … or GetAttribute, for one by name

The types crossing every arrow are NetTopologySuite's own — Feature and Geometry. Not wrappers, and no adapter anywhere. GeoJSON calls a feature's table properties; NetTopologySuite calls the same table attributes, and the nodes that open it use NetTopologySuite's word.

Nodes

A feature is opened with VL.NetTopologySuite's Split (→ Geometry, Attributes) and GetAttribute (→ one by name, with Success, never throws). That package installs with this one.

Deliberately absent, each for a reason worth reading:

• A FeatureCollection type, and therefore any node to open one. Read GeoJSON hands back the features directly, the way XMLReader and JSONReader hand back an XElement rather than a document. Why.
• Count — the result is a Spread, so Count [Collections.Spread] already works on it, as do GetSlice and a ForEach region.
• A blocking file node — FileReader (String) [IO] → Read GeoJSON is one. The one file node here reads in the background, because a big file must not freeze vvvv. Why.

Two things to know before using it

Parsing is a process node, not an operation. 1,000 features cost 0.8 of a frame and 10,000 cost 9.7 frames, so re-parsing every frame is not slow — it is a patch that never draws again. The text is parsed when it changes; watch the Parses pin settle at 1.

Decoded geometry gets SRID 4326. RFC 7946 §4 mandates WGS84 longitude and latitude, and the upstream library stamps it unaided — so this is a fact about the format, not a guess about the data. It differs from Read WKT right beside it, which gives 0, because WKT carries no CRS semantics. NTS never throws on mixed SRIDs, so if a patch combines both, make them agree through the Factory pin. Setting an SRID is a label, never a reprojection — nothing here reprojects anything.

Requirements

vvvv gamma 7.2 or newer (.NET 8). Depends on VL.NetTopologySuite 0.0.4-alpha, NetTopologySuite 2.6.0, NetTopologySuite.Features 2.1.0 and NetTopologySuite.IO.GeoJSON4STJ 4.0.0 — the same NTS versions the sibling packages pin, so a vvvv loading all of them sees one assembly identity.

No Newtonsoft.Json. Why: same parse speed, half the retained memory, and the only ring-orientation control of the two.

Building

# vvvv must be CLOSED first - it holds the staged assemblies open
.\build.ps1                     # build + stage dist\ + install upstream packages into deps\
dotnet test test\VL.NetTopologySuite.GeoJSON.Tests\VL.NetTopologySuite.GeoJSON.Tests.csproj
.\tools\Test-VLPackage.ps1      # static package checks
.\tools\Test-VLPatch.ps1        # structural checks on every .vl - BOM, IDs, link endpoints
.\pack.ps1                      # pack into dist\feed\

# needs VL.NetTopologySuite built and packed too: D:\2026_Projects\vl-nettopologysuite\dist
.\tools\Compile-HelpPatches.ps1 # headless vvvvc over every patch, then READS the generated C#
                                # to check each node actually resolved - vvvvc's exit code does not

# load measurements, off by default because they take ~10 s and allocate hundreds of MB
$env:VLGEOJSON_LOAD = '1'; dotnet test -c Release --filter LoadTests

# open a help patch to read or adjust it: double-click Open-HelpPatch.cmd in the repository root
# (a picker in Help.xml order, with Close my vvvv / Normalize / Check), or by name:
.\tools\Open-HelpPatch.ps1 "Access"

# the only thing that proves where a node appears in the browser:
& "C:\Program Files\vvvv\vvvv_gamma_7.4-win-x64\vvvv.exe" `
    ".\help\VL.NetTopologySuite.GeoJSON\HowTo Read GeoJSON.vl" `
    --package-repositories ".\dist;.\deps;D:\2026_Projects\vl-nettopologysuite\dist"

Documentation

Two of those are copied from vl-mapsui rather than linked, on that repository's own principle: a rule transfers; a note about another repository's file does not.

Status

Nothing is published to nuget.org. What is verified, and what is not, is tabulated in docs/ROADMAP.md — the distinction between a node resolved, it is in the right category and it computes the right value is three separate claims here, and only the last two need a running vvvv.

Licence

MIT. See LICENSE.

This package wraps NetTopologySuite and NetTopologySuite.IO.GeoJSON4STJ, both BSD-3-Clause, and declares them as NuGet dependencies rather than redistributing them.

help\VL.NetTopologySuite.GeoJSON\Assets\ne_10m_populated_places_simple.geojson - 7,342 cities, used by HowTo Handle a large GeoJSON file - is Natural Earth's 1:10m populated places, public domain, taken unmodified from nvkelso/natural-earth-vector on 2026-10-18.