Reviewing a utility network GeoJSON should begin by confirming that the file can be parsed and end with a reproducible list of findings. The checks in between are different: JSON structure, FeatureCollection type, valid geometry, plausible coordinates, duplicate identifiers, connectivity, required attributes and provenance metadata. No single check proves that the network faithfully represents field conditions.
The decision this guide supports
Before running rules, agree on what an error means for the specific workflow. A dangling end can be a defect in a closed network or an expected element in a service connection. A visual crossing may require a node, represent different elevations or require no connection. Each rule needs class context, tolerance and purpose; otherwise it produces a long list that nobody can resolve.
Before running rules, state the file contract: accepted geometry types, expected CRS, required properties, domains, units and spatial tolerance. A line without an identifier and a line that does not connect to a node are different problems, and the report must retain that distinction. Also define how GeometryCollection, Z coordinates, null properties and features outside the work area will be handled. A useful result identifies the feature, rule and location of each finding, supports export and leaves the original file unchanged. This contract lets two reviewers repeat the test and reach a comparable explanation.
Recommended workflow
- Agree. Check size, encoding, valid JSON and a FeatureCollection before reading properties.
- Structure. Review allowed geometry types, finite coordinates, closed rings and empty geometry.
- Check. Detect duplicate identifiers and duplicate geometry without assuming proximity means equality.
- Document. Apply class-specific connectivity rules and tolerances while preserving each individual finding.
- Operate. Export a summary with rule, severity, element, evidence and a review recommendation.
Minimum controls before publishing or delivery
A useful review combines automated checks with expert judgement. At minimum, record:
- unambiguous declared CRS and units.
- critical fields present with stable types.
- finding counts by rule and severity.
- a hash or version that makes the diagnostic repeatable.
Limits that must remain visible
GeoJSON follows its own coordinate rules and is practical for exchange or local diagnostics, but it does not preserve every capability of a geodatabase. GeoSAT’s tool processes the sample in the browser and reports signals; it does not certify topology, replace field inspection or guarantee acceptance by another system. With explicit consent, only a bounded summary should be shared, never the file by default.
To apply this method to a concrete project, review the GeoSAT sector service and compare its dependencies with the related service. These links serve different intents: this guide explains the process, while the service pages define scope, evidence and the appropriate commercial next step.
