Validate GeoJSON Coordinates Before Android Local AI Use

Direct answer

Treat GeoJSON as a spatial data contract, not as ordinary JSON with a coordinates array. RFC 7946 fixes the coordinate reference to WGS 84 longitude and latitude in decimal degrees. The first two elements of each position array are longitude and latitude, and an optional third value is height in meters above or below the WGS 84 reference ellipsoid. When both numbers are within valid ranges, swapping latitude and longitude can still pass numeric and shape checks; only a known source-axis contract or reference fixture can expose that mistake, so do not auto-swap to make a point look plausible. Validate domain meaning after JSON parsing, and preserve the input bytes and source revision so a user or reviewer can compare a proposal with its origin. Do not accept an alternate coordinate reference system by guessing from magnitude or by interpreting an extension member named `crs`. RFC 7946 removed the older alternative-CRS mechanism because interoperability suffered and does not expect a general GeoJSON processor to fetch transformation parameters. A product may define a documented conversion pipeline before generating RFC 7946 output, but it must record source CRS, transformation library/version, axis convention, units, and failure behavior. If those are unknown, preserve the source as unconverted data or reject the export instead of labeling it GeoJSON WGS 84. Validate the declared geometry type together with its coordinate nesting. Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, and GeometryCollection have different array shapes. A Polygon linear ring has at least four positions and its first and last positions must be identical. RFC 7946 says producers MUST follow the right-hand rule: exterior rings are counterclockwise and holes clockwise. For backwards compatibility, parsers SHOULD NOT reject a polygon solely because its winding differs. Keep producer conformance and tolerant parser behavior separate; if normalizing an imported ring, retain the source and record that transform. RFC 7946 discourages positions with more than three numbers because additional elements have unspecified and ambiguous semantics. If a fourth value resembles a timestamp or measure, do not invent a GeoJSON interpretation for it. Define a supported application profile for geometry types, null geometry, properties, IDs, dimensions, and extension members. A strict profile may reject types the product does not use, but describe that as application policy rather than claiming the RFC forbids every extension. Bounding boxes need a separate validator. RFC 7946 defines bbox length as twice the number of dimensions in the contained geometries, with the first point followed by the second point using the same axis order as positions. For a two-dimensional longitude/latitude profile, the order is west, south, east, north. A bbox crossing the antimeridian can legitimately have east longitude less than west longitude; ordinary min/max normalization would turn a narrow Pacific region into a nearly global box. For interoperability, RFC 7946 recommends cutting crossing geometries so neither part crosses the antimeridian, such as representing a crossing line as a MultiLineString. This recommendation is distinct from bbox validity and from map rendering behavior. A structurally valid feature is not evidence that its coordinates identify a real place. It does not geocode an address, establish positional accuracy, prove user intent, or authorize navigation. If a local model proposes a route or region, keep it untrusted: compare geometry to the task contract, expose relevant coordinates and uncertainty for review, and require separate confirmation before use. Coordinate decimal digits are not an uncertainty measure. Do not say that format validation proves a location is true. Keep parsing, profile validation, coordinate transformation, map presentation, and persistence as separate stages. JSON parsing establishes only syntax. GeoJSON validation establishes only that the selected profile and geometry invariants passed. A map view should not silently repair axes, reorder points, or discard bbox. If a caller needs another coordinate system, run a pinned and separately verified transform before encoding GeoJSON and retain provenance. This method does not claim that Cove integrates a geocoder, map SDK, or location-producing model. Use controlled fixtures rather than plausible addresses: an asymmetric longitude/latitude point, a third height with documented units, a fourth legacy value, each accepted geometry, closed and open polygon rings, both winding orders, a bbox with the wrong dimension, and an antimeridian bbox whose east is less than west. Record raw input, parser version, profile decision, normalization, and review state. Limit conclusions to those fixtures and the tested build.

A route proposal swaps longitude and latitude

A local assistant returns a GeoJSON LineString. The JSON parser accepts its coordinate arrays and the map draws a path, but the first two values were emitted latitude-first. Another fixture crosses the antimeridian and has a bbox with east numerically smaller than west.

Decision

Validate RFC 7946 axis order, geometry nesting, polygon rings, and bbox behavior against a named profile before preview or persistence; preserve raw input and request review for unsupported values.

Expected outcome

The team distinguishes valid JSON, valid GeoJSON structure, profile acceptance, and geographic truth without treating any one as proof of the others.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Pinned GeoJSON/RFC profile
• Coordinate-order and geometry fixtures
• Separate parse, range, and real-world-location evidence

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

1. Declare the accepted GeoJSON profile. List permitted object and geometry types, property keys, IDs, null-geometry policy, and coordinate dimensions. Separate RFC requirements from stricter application rules and preserve the source bytes.
2. Validate CRS, axis order, and dimensions. RFC 7946 uses WGS 84, longitude first and latitude second in decimal degrees. If the third value is used, define it as height relative to the WGS 84 reference ellipsoid in meters. Reject unsupported dimensions or route them through a separate versioned transform.
3. Check geometry-specific structure. Test each supported geometry shape. Require Polygon rings with at least four positions and identical first/last values. Enforce right-hand winding when producing geometry, but do not reject imports solely for winding when following the RFC compatibility guidance.
4. Validate bbox and antimeridian behavior. Check bbox length against twice the geometry dimension and preserve axis order. Test an east longitude smaller than west for a crossing bbox; never sort coordinates as ordinary numeric minima and maxima. Record any geometry cutting into multipart output.
5. Separate validation from application use. Keep parser success, profile validation, coordinate conversion, map preview, and saved state distinct. Review model-proposed locations before navigation; do not describe a valid feature as a verified place or accuracy result.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The RFC 7946 profile checks longitude-first WGS 84 positions and optional height units; extra dimensions are not guessed.
• Geometry nesting, polygon closure, producer winding, tolerant parser behavior, and bbox dimensions have separate fixtures.
• Antimeridian geometry and bbox cases are tested without min/max normalization; conversions are versioned and retain source provenance.
• No claim equates valid GeoJSON with geocoding, ground truth, accuracy, user authorization, or Cove map/model integration.

Decision table

Failure patterns to prevent

• Swapping latitude and longitude by local convention
• Treating valid syntax or bbox as proof of a real place
• Inferring CRS from untrusted properties

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• IETF — RFC 7946 GeoJSON format and coordinate rules
• IETF — RFC 8259 JSON data interchange format
• Android API — JsonReader streaming JSON parser

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions