Hacker News Reader

Comment by mamaar | Hacker News Reader

There is also https://gitlab.com/tilelessmap/tilelessmap with some of the same focus areas.

> TilelessMap is an open, offline-first mapping engine designed for critical field use, such as forestry, emergency services, and humanitarian work. Built with C and optimized for mobile performance, TilelessMap enables full local map rendering without relying on cloud infrastructure — even in areas with poor or no internet connectivity.

They have an Android app with maps of Yellowstone, Sweden and Norway.

https://play.google.com/store/apps/details?id=org.tileless.m...

View on HN

I am curious: is it called "tileless" because it uses tiles, but offline? Or does it somehow not use tiles?

There are no tiles. All geometry is loaded and rendered directly from an SQLite database on every render.

Geometry is stored as TWKB (Tiny Well-Known Binary) to reduce storage and transport size. During decoding, they do clever work using aggregate functions and reusing buffers across rows to reduce allocations.

There is real potential in the tech, but unfortunately little momentum behind it.

> There are no tiles. All geometry is loaded and rendered directly from an SQLite database on every render.

Which can be done with tiles. Or maybe I don't understand what you mean by "tiles"? What do you describe as "tiles"?

I would define a tile as a slice of geometries, not whole features.

The difference with Tileless' approach, is that they load whole features from the database and don't split them into tiles. So if a feature extends outside the current view, they would load the whole geometry rather than the intersection of the tile's extent and the geometry.

Vector tiles are optimized for concurrent downloads and browser / CDN caching and doing a good job of that.

That's interesting. So that makes it more efficient for offline maps? How much more efficient? I'm curious now!

Hi I am th author of TilelessMap (ResilientMaps). The idea is to not destroy data. In a tile the geometries are cut into smaller pieces. That is important to be able to do efficient caching. Vector tiles are also often simplified to fit each zoom level. This means that the data is quite worthless for anything byt rendering. So far tilelessmap is also just rendering. But it opens up the possibilities for any gis processing/analyses that you can do on desktop gis. Since it is difficult to cache without tiles it has to be a very efficient render path. So, all polygons are pre-triangulated from the server. If you are familiar with gpu rendering you know that the gpu only can render points, lines and triangels as primitives. Triangulation is a quite expensive step. In a tile-redenerer that is solved by very aggressive simplification. At each zoom level quite few geoemtries and vector points are actually shown. In tilelessmap a polygon is encoded in twkb as a list of vertices, and after that, indexes into the vertex list how the gpu builds triangels. The vertex list is decoded into VBO (vertex buffer object) and the triangle index list is decoded into EBO (element buffer object) This is very efficient, and even in a phone many geometries and vertices can be rendered. No cache needed, which reduces complexety and makes it possible to keep large geometries without cutting them in tiles. Also, the storage in the db is relational. This means that you can keep a full datamodel all the way out to the deveice. This opens a lot of possibilities. I hope that I will get time to furhter develop this. I think this is filling a gap in gis of today. More like a modern version of ArcPad (but so far without the functionality). It is all GPL v3 licensed. Hope this helps understanding the incitaments for the project.

This is a really interesting project and thanks for sharing these tech details! Are you guys working on an iOS app yet? Would love to give it a try.

Not yet. I hope, if the Android version gets some attention to do that. But App-store gives some issues with licensing with GPL. Dual licensing will be needed, but I would like to limit the more permissive license, but not contrain anyone from develop to iOS. I don't really know how to do it. I do not want a closed source fork for iOS by me or anyone else. I just want all ideas and work on this to be open to anyone. Apple don't really like that thinking. But most of this is written in C and many platform-differenties is handled by SDL3. So, I think it should be very possible to port it.

IIRC it usually means it stores the vectors and draws it clientside.

Also known as vector tiles.

Not necessarily. That's one way to do it, but e.g. OsmAnd just has big region-shaped files and not a load of tiny square tiles like a web viewer has that loads the data piecemeal

Reply on news.ycombinator.com