Today I received an invitation to attend the bi-monthly OSM US Maintainers Working Group.
But due to timezone difficulties, I don’t think I’ll be able to attend it live.
The meeting agenda has been shared, mainly focusing on the topic of standards and interoperability. There are some interesting starter questions there, so I’m intrigued to answer those questions in an OSM diary instead, hoping that I’ll be able to join the discussion asynchronously.
So, here we go :
“What standards (geospatial file or data formats, metadata schemas, wire protocols, structured text formats, encodings, etc.) does your project depend on or interact with?”
I frequently use GeoJSON format in several of my projects.
“Are there any standards that you wish would be evolved/extended but aren’t actively maintained? Or implementations that aren’t fully compliant that you wish would be?”
GeoJSON fits pretty much all of my required use cases. 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.
“Are there standard formats or protocols that you would like to use, but aren’t well supported in your language/ecosystem?”
The General Transit Feed Specification.
I’ve been interested in this data format for a long time, but I still don’t know how to properly tinker with it. Last time I worked on this, I had to make my own Python implementation to read and navigate GTFS files. I don’t know what the current situation is right now. Maybe it’s already supported, maybe not.
“What are your thoughts on Overture’s OGC proposal?”
I already posted my thoughts in a certain Slack thread somewhere. Here’s the verbatim quote:
“Does an OGC standard become legally binding worldwide or something?
I’ve been thinking for quite some time about the idea of having a single global geographic identifier for every place. Ideally, any online content that refers to a location — whether a blog post, tweet, video, or photo — would include that global GeoID so it could be reverse-searched more effectively, such as finding every piece of content that references a specific place. For now, I use OpenStreetMap node, way, or relation IDs as links whenever I mention a place as a rough workaround, but I still hope that vision could be developed further.”
“What role do you think maintainers in the OSM community should play in giving feedback on or submitting standards to formal bodies like OGC?”
I guess maintainers would only care about standards if those standards personally affect their lives (their projects depend on them).
One day, a certain still-popular web APIs were unilaterally deprecated by a certain majority market-share holder browser company. Several maintainers (me included) staged a protest on their mailing list, practically begging them not to cut our collective lifeline. A representative from that company personally told me a quick fix on how to navigate that situation, and I’ve been using that quick fix for years. I don’t know the rest of the story, but if my app is occasionally broken without a clear reason, I suspect that quick fix is no longer enough to resolve the deprecation issue. That was the last time I participated in a “standardization” discussion.
“Anything new with your project(s) you’d like to share?”
Not exactly my project per se, but several weeks ago I saw someone in an OSM diary who recommended SCEE as one of the best available OSM editors on mobile. So lately, I’ve tried doing field mapping with SCEE.
They were right, it’s so good.
But somehow preset tags are still missing (I can’t add ATM, recycling center, or power pole yet). I don’t know how to add new preset tags to the app. Is there a hidden menu somewhere, or should we make a pull request to the repository? I’m now quite interested in this topic.
Discussion
Comment from jake-low on 16 March 2026 at 19:59
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
outerandinnermembers 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.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.