New Osm File Format: 30% Smaller Than Pbf, 5x Faster to Import
Posted2 months agoActive2 months ago
community.openstreetmap.orgTechstory
calmmixed
Debate
40/100
OpenstreetmapData FormatsGis
Key topics
Openstreetmap
Data Formats
Gis
A new OSM file format is proposed, claiming 30% smaller size and 5x faster import times than the current PBF format, sparking discussion about its specifications, compatibility, and potential trade-offs.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
1h
Peak period
4
2-4h
Avg / period
1.7
Comment distribution12 data points
Loading chart...
Based on 12 loaded comments
Key moments
- 01Story posted
Oct 24, 2025 at 6:23 PM EDT
2 months ago
Step 01 - 02First comment
Oct 24, 2025 at 7:35 PM EDT
1h after posting
Step 02 - 03Peak activity
4 comments in 2-4h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 26, 2025 at 2:25 AM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45699725Type: storyLast synced: 11/20/2025, 7:35:46 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Aside from OSM specifics, performance friendly formats for spatial data that support spatial indexing can make huge impact on usability and productivity of applications. e.g. trying to view a large dataset in QGIS that has been saved as KMZ (zipped XML) can make QGIS basically hang for minutes, while the same dataset saved as something like flatgeobuf [1] can be loaded instantly.
[1] https://flatgeobuf.org/
How's geojson of the same data?
because otherwise this is true of all new ̶s̶p̶e̶c̶s̶ edit: ideas (this isn't even a finished spec), and it implies absolutely nothing.
Can anyone recommend me a method of meshing LIDAR point clouds? The sparseness of the data on building walls & other near-vertical surfaces combined with a lack of point normals leads to degenerate solutions with all the common approaches (poisson/ball pivot/vcg in meshlab) not to mention extremely slow perf. Tree canopies and overhanging parapets make a simple heightmap approach less-than desirable (though ultimately acceptable if I can't find anything better). I'm trying to turn 90 billion lidar points into maybe 30-50 million triangles, hopefully without spending months developing a custom pipeline.
It combines airborne LiDAR and building footprints, it's OS (https://github.com/3DBAG) with the reconstruction pipeline here: https://github.com/3DBAG/roofer.
https://media.jochentopf.com/media/2022-08-15-study-evolutio...
https://github.com/osmlab/osm-data-model
https://blog.openstreetmap.org/2023/01/04/reminder-call-for-...
Resolving the coordinates to node references in current data model is such a nuisance as it's slow and requires lots of RAM.