Reference material is only worth trusting if its mistakes are visible. When something published here is found to be wrong, it gets fixed on the page and recorded below with the date. Entries are never removed, including old ones, because a corrections log that gets tidied is not evidence of anything.
Typographic fixes and rewording are not recorded. A correction is a change to a claim: a wrong number, a wrong description of what a tool does, or a statement about the specification that does not hold. Found one? Send it in.
Log
Was: A longitude outside -180 to 180, or a latitude outside -90 to 90, was reported as an error, and the conformance corpus stated the rule as "Longitude is bounded to the range -180 to 180" citing RFC 7946 section 3.1.1.
Now: Section 3.1.1 states no bound on either value. It says a position is an array of numbers whose first two elements are "longitude and latitude, or easting and northing". Section 4 fixes the coordinate reference system as WGS 84 and then permits an alternative "where all involved parties have a prior arrangement", which a file has no way to declare. The validator now warns instead of refusing, which left it the only implementation in the conformance run rejecting a file on a rule the specification does not carry. The warning still says the coordinates are not WGS 84 degrees, because that is the part worth knowing.
on Conformance Matrix (page since removed)
Was: The geojson-validation row said the library caught 4 of the 25 files that break RFC 7946, level with a bare JSON.parse and last in the table. Nineteen of its verdicts were wrong.
Now: It catches 21 of the 25, which puts it third. The fault was in our runner, not the library. gjv.valid takes a boolean second argument that swaps the return value from a verdict to the list of reasons, and the runner passed a callback there; an empty array is truthy, so every document that parsed as JSON was recorded as accepted. The runner now takes the verdict from the one-argument call and the message from the two-argument one. The other eleven columns are unaffected and were re-run to confirm it.
Was: Coordinate bounds were listed among the rules no JSON Schema can express, and three pages repeated it. A longitude outside -180 to 180, or a latitude outside -90 to 90, was said to be out of reach because a schema cannot bound the first two elements of a position while still letting a third through for height.
Now: Draft 2020-12 does exactly that with prefixItems, and the runner already compiles with strict mode off, so ajv accepts the construction. Rebuilding the schema with those bounds and running the whole corpus catches three more malformed files, and a fourth where a projected crs member turns metres into degrees, with no valid file wrongly refused. Two rules do stay beyond any schema: whether a ring's last position equals its first, and whether a hole sits inside its exterior. The published schema is unchanged for now; adding the bounds is a change to a distributed artifact and is being decided separately.
Was: Every area figure in the worked examples was invented. The two land parcels were given as 1,680 and 1,540 square metres and their union as 2,890, against a stated sum of 3,220. The city district was 48.6 hectares with 44.1 developable after subtracting the park.
Now: Measured on the WGS 84 ellipsoid from the coordinates the page itself publishes, the parcels are 28,136 and 28,135 square metres and their union is 52,988. The district is 22.5 hectares and 19.5 remain after the park. The old parcel figures were out by a factor of about seventeen. Every number on the page now comes from running the code shown beside it.
Was: The guide showed an input and an output for each operation and never showed how to get from one to the other, naming functions like turf.intersect() and ST_Intersection() in passing without a working example.
Now: Each operation now carries the code in four languages, Python with Shapely, PostGIS, GDAL and Turf.js, and the output printed under each one is what that code produced when it was run. Adding the code surfaced three things the prose had not: the four libraries return four different 1km buffers, Turf has no line-on-polygon clip and silently falls back to a bounding box, and Turf's dissolve returns one feature per merged piece where the other three return one per group.
Was: A table of real-world size comparisons gave four before-and-after figures: US States 2.4MB to 0.5MB, World Countries 12MB to 1.8MB, US Counties 14MB to 1.5MB, and Scattered Points 1.0MB to 0.9MB.
Now: None of those four datasets was named or linked, so no reader could check any of them. The table was replaced with one measurement anyone can repeat: Natural Earth 1:10m countries, 23.3MB of GeoJSON to 4.2MB of TopoJSON, and 6.5MB to 1.3MB after gzip. We have not shown the old figures were wrong, only that nothing stood behind them.
Was: Converting GeoJSON to GeoPackage was said to lose nothing, on the grounds that GeoPackage is a strict superset of GeoJSON's type system.
Now: It loses three things. A property named id or fid is consumed by the automatic primary key and is not written back out. A Feature's top-level id returns as an ordinary property. A fourth element in a position is cut to three. The page now lists what the measurement found.
Was: Converting a Shapefile to GeoJSON was said to lose nothing structural beyond field names that were already truncated.
Now: Polygons come back with their rings reversed. The shapefile specification winds an outer ring clockwise and RFC 7946 requires counterclockwise, so every polygon through a shapefile is returned in the wrong direction and nothing reports it.
Was: Two claims rested on nothing measurable: that a TopoJSON file of US county boundaries is typically 80% smaller than the equivalent GeoJSON, and that a Shapefile mangles non-ASCII field values into mojibake.
Now: The TopoJSON figure now comes from a dataset anyone can fetch: 82% smaller on disk and 80% after gzip on world country boundaries. The encoding claim was wrong in kind. Non-ASCII text is not mangled, it is replaced: Chinese and Cyrillic come back as one question mark per character while accented Latin survives.
on GeoJSON File Size Optimization
Was: Minification was said to save 30 to 45% on real datasets. Simplification was credited with a 61% reduction and precision reduction with cutting coordinate characters by roughly 70%.
Now: Measured on Natural Earth 1:10m countries, minifying saves 61% of the uncompressed bytes and 12% once the file is gzipped, so both ends of the stated range were wrong and the compressed figure was missing entirely. Simplification at 0.01 degrees saves 65%, which was close. Precision reduction from 15 to 6 places saves 42% of the file. Every figure on the page now comes from a measurement script run against one pinned dataset.
on GeoJSON File Size Optimization
Was: Two worked examples cited specific datasets that were never named or linked: a 13MB US Census county boundary file reduced to 0.9MB, and a Golden Gate park boundary from OpenStreetMap with 8,400 vertices reduced to 1,200 at a tolerance of 0.0001 degrees.
Now: Both were removed, because neither could be traced to a file anyone could fetch. We have not shown either is wrong. The second is hard to credit: on the dataset now used throughout the page, that same tolerance removes under 3% of positions, where the example claimed 86%. The page now follows one public-domain dataset from start to finish so every number on it can be reproduced.
on Conformance matrix, winding and structure (page since removed)
Was: Four fixtures were described using rules that RFC 7946 does not contain. Self-intersection and zero-area spikes were attributed to clause 3.1.6, which never mentions either. A nested GeometryCollection was called forbidden in as many words. Winding order was described as a should, when the specification says must.
Now: RFC 7946 says nothing about self-intersection at all; that rule belongs to the OGC Simple Features model. Nesting a GeometryCollection is discouraged, not forbidden: the text says implementations SHOULD avoid it. Winding is the reverse of what was published, a linear ring MUST follow the right-hand rule and parsers SHOULD NOT reject one that does not. All four fixtures were reclassified and the analysis rewritten.
on Conformance matrix, empty and encoding (page since removed)
Was: An empty coordinates array on a Point, LineString or Polygon was marked invalid, and a leading byte order mark was marked invalid.
Now: RFC 7946 section 3.1 says processors MAY read a geometry with an empty coordinates array as a null object, so accepting one is conformant. RFC 8259 section 8.1 says a parser MAY ignore a byte order mark without calling it an error. All four are now recorded as ambiguous, which is what the specifications actually leave open.
on Conformance matrix, legacy members (page since removed)
Was: A crs member was marked invalid, and three guide pages said RFC 7946 explicitly forbids it.
Now: RFC 7946 removed the crs member, which is not the same as forbidding one. A crs member today is a foreign member, and section 6.1 says foreign members MAY be used. The document stays structurally valid, which makes the silent misreading of projected coordinates worse.
Was: The Empire State Building in Web Mercator was given as [-8232838, 4975221].
Now: The correct projected position is [-8236050, 4975301]. The longitude value was out by about 3.2 km.
Was: Treating degrees as a flat grid was said to overstate area at 60 degrees north by about four times.
Now: The overstatement is one divided by the cosine of the latitude, so about two times at 60 degrees north and about 1.4 times at 45 degrees.
Was: A one kilometre buffer around a point was described as a 64-vertex polygon, and Turf's default was given as 64 segments per quarter circle.
Now: The result has 33 positions, and Turf's default is eight segments per quarter circle.
Was: Altitude in KML coordinates was said to be dropped during conversion.
Now: Altitude is kept as a third position value, which RFC 7946 permits and reads as elevation in metres.