Geojson

The EU Deforestation Regulation applies from 30 December 2026. For operators placing timber, cocoa, coffee, palm oil, soy, cattle, and rubber on the EU market, compliance requires a Due Diligence Statement submitted through the TRACES NT system. That statement must include plot-level geolocation data — and the format specification is not flexible. TRACES accepts GeoJSON in WGS84 (EPSG:4326) with coordinates expressed as decimal degrees to at least six decimal places. Plots over 4 hectares require a complete boundary polygon. Plots under 4 hectares may be represented by a single point. ...

If you have found a tutorial that includes a line like ogr2ogr -f GFT ... or links to http://www.gdal.org/ogr/drv_gft.html, the tutorial is dead. The GFT driver connected to Google Fusion Tables, which Google shut down on December 3, 2019. The gdal.org/ogr/drv_gft.html URL itself no longer resolves — the entire GDAL documentation was restructured and the GFT driver pages were not preserved. Links to it from GIS community sites still circulate and lead nowhere. ...

Data scientists encounter GIS when spatial data shows up in a project: a dataset with latitude/longitude columns, a shapefile from a government portal, a GeoJSON file someone dropped in the repo. The first few operations usually work. Then something breaks silently — a spatial join returns an empty DataFrame, a buffer produces geometry the size of a continent, or exported shapefiles arrive at the lab with every field name truncated. ...

GIS format conversions do not crash loudly when they fail. They produce an output file, report success, and leave you with data that is wrong in ways you may not notice until the analysis is already done. Field names get silently cut at 10 characters. Geometries disappear without warning. Coordinate systems shift without errors. Attribute types coerce to something that looks right but produces wrong numbers. These are not edge cases. They are the default behavior of the tools most GIS teams use daily — including GDAL/OGR, QGIS’s built-in export, and ArcGIS Pro’s geoprocessing toolbox. None warn you by default. ...

You convert a GeoJSON file to a shapefile and load it into ArcGIS. Your attribute table has changed. The field called municipality_name is now municipali. The field called building_type_code and the field called building_type_category are both now called building_t, except one of them got renamed to building_t0 by GDAL and you missed it. Your spatial join script that references building_type_code now silently returns nulls on every row. This is not a GDAL bug. It is the shapefile format working exactly as designed since 1983. ...

GeoJSON keeps showing up in places it shouldn’t. Someone drops a 2 GB .geojson into a processing pipeline, the script that used to run in 20 seconds runs for eight minutes, and the team spends a Thursday wondering whether the problem is their query planner, their RAM, or their patience. The problem is the format. GeoJSON is a perfectly good interchange format — human-readable, one-spec wonder, works everywhere a text editor opens. It’s a terrible working format as soon as your dataset has more than a few hundred thousand features. This post is about when to stop loading GeoJSON directly and what to convert to instead, based on what teams handling real-scale data actually reach for. ...

You run a GeoJSON-to-Shapefile conversion. The tool says it succeeded. You load the Shapefile into ArcGIS or QGIS and everything looks fine at first glance. Three weeks later, someone discovers that half the attribute data is wrong or missing. This is not hypothetical. It happens constantly in GIS workflows, and the reason is that GeoJSON and Shapefile are fundamentally different formats with incompatible assumptions about how data should be stored. Most conversion tools handle the geometry correctly but silently destroy the attributes. ...