Hacker News Reader

Comment by mamaar | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com