Hi rphyrin, thanks for sharing your thoughts on these questions. Sorry you weren’t able to make it to the meeting live.

GeoJSON is indeed a format that so many software projects rely on and use to interoperate. One topic that came up in the live meeting was how OSM’s data model (nodes, ways, relations) often needs to be converted to GeoJSON or similar formats (points, linestrings, polygons) in order to work with the data in other software, and the edge cases that come up when doing this. Some of them are tricky but purely mechanical processes, like assembling a multipolygon relation’s outer and inner members into proper polygons (libosmium does this very well). Others are subjective and require interpreting OSM’s folksonomy of tagging, like determining whether a closed way should be interpreted as a linestring or as a polygon. Different projects address this ambiguity in lots of different ways.

My only concern right now is how to make GeoJSON files more compact. I haven’t researched much about this since there’s currently no urgent performance issue that needs to be handled, but I love tweaking my apps for performance.

I’ve run into this too. There are some binary formats that are more compact than GeoJSON, but it’s hard to beat GeoJSON for broad compatibility. I’ve found in the past that you can reduce the size of a GeoJSON object a lot by making sure the coordinates are truncated to a reasonable number of decimal places (5 or 6 is plenty for OSM data). This can easily halve the size of large geometries, and the savings get even better once you apply gzip compression (less noise in the values means they compress better). But a lot of JSON encoder libraries don’t support this level of control over the output formatting, so I’ve occasionally resorted to doing this using a regex on the encoded result.