3 ms·

One task where GeoJSON falls down is simplification of a group of polygons with common boundaries, e.g. the 48 conterminous US states. If you start with a highl

One task where GeoJSON falls down is simplification of a group of polygons with common boundaries, e.g. the 48 conterminous US states. If you start with a highly detailed set of polygons, you need to simplify them for practical display in an online map. GeoJSON doesn't encode the fact that the boundary points are common between adjacent polygons. When you simplify those polygons, each one is handled separately, and you end up with "slivers" where the boundaries are misaligned: https://www.bing.com/images/search?q=map+slivers+betwen+polygons&form=HDRSC3&first=1 https://www.bing.com/images/search?q=map+slivers+betwen+poly... TopoJSON solves this by encoding each such boundary only once. So when you simplify the polygons, they are all done together, and the same simplification applies to adjacent polygons. No more slivers! https://github.com/topojson/topojson https://github.com/topojson/topojson https://github.com/topojson/topojson-simplify https://github.com/topojson/topojson-simplify

Demiurge 5mo ago
Is this actually GeoJSON falling down, or decades of convention extended to JSON? Topology is great, but it is sidestepped by Shapefile/WKT/WKB/etc, in favor of independent primitives like POINT, LINE, POLYGON. If GeoJSON did not exist as a new JSON GIS data format encoding these primitives, TopoJSON would not have "replaced" it, due to the added mis-match with other non-topological formats. From what I can tell, the top criticism of GeoJSON is the under-enforced winding order specification, and crossing the antemeridian.
- jvanderbot 5mo ago
  Right. Encoding a union algorithm into the data structure just introduces the reverse problem: Selecting a subset now requires extra logic beyond jq.
  - Stratoscope 5mo ago
    Similarly, typical map APIs like the Google Maps API accept GeoJSON and not TopoJSON. I was not suggesting TopoJSON as a replacement for GeoJSON, but as a complement to it. With the tools on the TopoJSON GitHub, you can have GeoJSON input and output, but convert to TopoJSON for the simplification step to avoid the "slivers" problem.
echoangle 5mo ago
How is that a geojson problem? If your dataset is correct, adjacent borders will just use the same points and will match exactly.
- sdenton4 5mo ago
  The problem is simplification. Suppose two regions share a border with some nonlinear points a, b, c, d. Simplifying the polygon for the first region might yield a, b, d while the second yield a, c, d. This creates gaps or overlaps between the two regions.
  - echoangle 5mo ago
    So don’t simplify the shapes on their own. Geojson is a storage and exchange format, you can still convert it to other formats if you want to modify it.
    - rented_mule 5mo ago
      I think what the original comment is pointing out is that GeoJSON lacks a concept of a shared boundary. Shared boundaries expressed in GeoJSON get around that by duplicating data. Whenever data is duplicated, there's a risk that the copies will not be exactly the same. That makes the task of modification more challenging given that the real world is full of messy data, like duplicates not matching. 20-25 years ago I worked a lot with map data from otherwise high quality, and sometimes authoritative, sources like the USGS and NOAA that had this non-identical shared boundaries problem (in formats other than GeoJSON). If the format doesn't allow such mistakes to be expressed, then they have to fix their data to publish it in said format.
      - echoangle 5mo ago
        Sure, but not every format is useful for everything. Geojson is great if you want a simple way to express a shape to show on a map. It’s like criticizing CSV because people put strings in choice value fields instead of doing a foreign key to another table. That’s just not what the format is used for.
pramsey 5mo ago
GeoJSON is not TopoJSON. Saying that is "falling down" is like criticizing a zebra for not being a giraffe. GeoJSON is a mapping of the (non-topological) "simple features" model into JSON, full stop. It does that fine.
- Stratoscope 5mo ago
  Yes, the same "slivers" problem occurs when you try to simplify features in any format that uses individual polygons, such as shapefiles or whatnot. That's the only case I was referring to. I don't think I would trust a zebra or a giraffe for this task either.
NelsonMinar 5mo ago
I like TopoJSON and have used it in projects. But it's weird to set it up as opposition to GeoJSON. It's a complement. GeoJSON is a general data format meant to replace uses of ESRI Shapefiles and other complex formats. TopoJSON is more of a solution for a particular application need. Is there much work developing or using TopoJSON these days? I haven't seen much about it in a few years.
- Stratoscope 5mo ago
  To be clear, I'm not suggesting TopoJSON as an alternative to GeoJSON. I like GeoJSON and was loosely involved with the working group that created and updated its spec. I'm just saying that for the specific task I mentioned GeoJSON or any format such as shapefiles that store polygons individually naturally leads to the "sliver" problem. A nice processing pipeline is: 1. Convert GeoJSON to TopoJSON. 2. Run the simplification on the TopoJSON. 3. Convert the resulting TopoJSON back to GeoJSON. The TopoJSON GitHub has tools for each of these steps.
perrygeo 5mo ago
Partly true, but don't blame GeoJSON. Blame the data model. GeoJSON is firmly rooted in the "simple features" model of spatial data. Sometimes called the "vector data model", this is ubiquitous in GIS. Each geographic entity (aka "Feature") has a single geometry and many non-geometry attributes. Each feature is independent. The vector data model (for better or worse) is the basis of many systems because it fits the tabular/relational style so closely. What is a feature but a row in a table plus a special column describing its geometry? Topological relationships are ignored by design. TopoJSON, ESRI coverages, the internal OpenStreetMap data model, and a few others are notable exceptions. They explicitly handle spatial relationships, at the cost of making the model unintelligible to row-based processing.

Demiurge 5mo ago

Is this actually GeoJSON falling down, or decades of convention extended to JSON? Topology is great, but it is sidestepped by Shapefile/WKT/WKB/etc, in favor of independent primitives like POINT, LINE, POLYGON. If GeoJSON did not exist as a new JSON GIS data format encoding these primitives, TopoJSON would not have "replaced" it, due to the added mis-match with other non-topological formats. From what I can tell, the top criticism of GeoJSON is the under-enforced winding order specification, and crossing the antemeridian.

jvanderbot 5mo ago
Right. Encoding a union algorithm into the data structure just introduces the reverse problem: Selecting a subset now requires extra logic beyond jq.
- Stratoscope 5mo ago
  Similarly, typical map APIs like the Google Maps API accept GeoJSON and not TopoJSON. I was not suggesting TopoJSON as a replacement for GeoJSON, but as a complement to it. With the tools on the TopoJSON GitHub, you can have GeoJSON input and output, but convert to TopoJSON for the simplification step to avoid the "slivers" problem.

echoangle 5mo ago

How is that a geojson problem? If your dataset is correct, adjacent borders will just use the same points and will match exactly.

sdenton4 5mo ago
The problem is simplification. Suppose two regions share a border with some nonlinear points a, b, c, d. Simplifying the polygon for the first region might yield a, b, d while the second yield a, c, d. This creates gaps or overlaps between the two regions.
- echoangle 5mo ago
  So don’t simplify the shapes on their own. Geojson is a storage and exchange format, you can still convert it to other formats if you want to modify it.
  - rented_mule 5mo ago
    I think what the original comment is pointing out is that GeoJSON lacks a concept of a shared boundary. Shared boundaries expressed in GeoJSON get around that by duplicating data. Whenever data is duplicated, there's a risk that the copies will not be exactly the same. That makes the task of modification more challenging given that the real world is full of messy data, like duplicates not matching. 20-25 years ago I worked a lot with map data from otherwise high quality, and sometimes authoritative, sources like the USGS and NOAA that had this non-identical shared boundaries problem (in formats other than GeoJSON). If the format doesn't allow such mistakes to be expressed, then they have to fix their data to publish it in said format.
    - echoangle 5mo ago
      Sure, but not every format is useful for everything. Geojson is great if you want a simple way to express a shape to show on a map. It’s like criticizing CSV because people put strings in choice value fields instead of doing a foreign key to another table. That’s just not what the format is used for.

pramsey 5mo ago

GeoJSON is not TopoJSON. Saying that is "falling down" is like criticizing a zebra for not being a giraffe. GeoJSON is a mapping of the (non-topological) "simple features" model into JSON, full stop. It does that fine.

Stratoscope 5mo ago
Yes, the same "slivers" problem occurs when you try to simplify features in any format that uses individual polygons, such as shapefiles or whatnot. That's the only case I was referring to. I don't think I would trust a zebra or a giraffe for this task either.

NelsonMinar 5mo ago

I like TopoJSON and have used it in projects. But it's weird to set it up as opposition to GeoJSON. It's a complement. GeoJSON is a general data format meant to replace uses of ESRI Shapefiles and other complex formats. TopoJSON is more of a solution for a particular application need. Is there much work developing or using TopoJSON these days? I haven't seen much about it in a few years.

Stratoscope 5mo ago
To be clear, I'm not suggesting TopoJSON as an alternative to GeoJSON. I like GeoJSON and was loosely involved with the working group that created and updated its spec. I'm just saying that for the specific task I mentioned GeoJSON or any format such as shapefiles that store polygons individually naturally leads to the "sliver" problem. A nice processing pipeline is: 1. Convert GeoJSON to TopoJSON. 2. Run the simplification on the TopoJSON. 3. Convert the resulting TopoJSON back to GeoJSON. The TopoJSON GitHub has tools for each of these steps.

perrygeo 5mo ago

Partly true, but don't blame GeoJSON. Blame the data model. GeoJSON is firmly rooted in the "simple features" model of spatial data. Sometimes called the "vector data model", this is ubiquitous in GIS. Each geographic entity (aka "Feature") has a single geometry and many non-geometry attributes. Each feature is independent. The vector data model (for better or worse) is the basis of many systems because it fits the tabular/relational style so closely. What is a feature but a row in a table plus a special column describing its geometry? Topological relationships are ignored by design. TopoJSON, ESRI coverages, the internal OpenStreetMap data model, and a few others are notable exceptions. They explicitly handle spatial relationships, at the cost of making the model unintelligible to row-based processing.