6 posts tagged with "glmap"

Here is a building in the centre of Warsaw the way our previous offline map format stored it, on a 12-bit grid:

The dashed line is the outline as it was mapped in OpenStreetMap. Every vertex of a GLMap tile sits on a grid laid over the tile, and the tiles that serve street-level zooms cover about 3 km of Warsaw each. With 12 bits per axis the grid step there is 73 cm, and the orange lines show how far each corner moved to reach it. At zoom 13 nobody sees that. At zoom 17, where these buildings fill the screen, the corners visibly go astray. With 14 bits the step is 18 cm.

gom5, our new map format, moved to 14 bits. Those two extra bits per axis cost bytes in the file, bytes in the download and time in decoding, and we did not see all of it at once.

We have published the polygon triangulator of our map engine as a small library, earstrip, under the ISC license, the same one earcut uses. It is one C++ header, and a WebAssembly build on npm that takes the same arguments as earcut. In C++ it is 14% faster than earcut.hpp, in the browser 1.4 to 2.1 times as fast as earcut.js, and the comparison is near the end. This post is about how we got there.

A GPU fills triangles and nothing else. A map, on the other hand, is mostly polygons: buildings, parks, parking lots, the strip of grass between two tram tracks. Here are a few blocks of Śródmieście in Warsaw the way our renderer reads them from a map file, as outlines:

Before any of this gets a fill, every outline has to be cut into triangles. Hover over a polygon, or tap it, to see what it turns into. These blocks hold 331 polygons with 5,151 vertices, and they become 4,514 triangles.

Zoom level 13 of our offline map of the Masovian Voivodeship, the region around Warsaw, has 3,740,425 polygons. On one core of an M4 Pro, the constrained Delaunay triangulator in our engine needs 2.93 seconds to cut all of them. This October I replaced it with ear clipping. To write this post I rebuilt the ear clipper one idea at a time, one commit per idea, and timed every commit on those same 3.7 million polygons, so each section below ends with a number.

GLMap for Flutter, Kotlin Multiplatform, and React Native is now available in beta. Install the packages from pub.dev, the Globus Maven repository, or npm to bring native maps, search, routing, and offline data to Android and iOS apps while writing your feature code in Dart, Kotlin, or TypeScript.

Try the demos, add GLMap to your app, and tell us what works—and what gets in the way. Your feedback will help shape the APIs, examples, and integration experience before a stable release.

A traveller in Warsaw types Zlotaa 59. They mean Złota 59, and as of this release the online search finds it.

GLSearch now corrects common typos in online map search: a missing letter, an extra one, or a wrong one in the name of an address, a business or a place. The user picks the destination instead of retyping it.

The map is open on Warsaw, and someone types Eiffel Tower Paris France. GLMap search starts from the map center: it opens the detailed maps around it and puts the nearest results first. The Eiffel Tower is 1,370 km away, in a map file that such a search never opens.

This is what the engine does with that query now, and with the other queries from this post. Each word is coloured by the role the engine gives it:

Words with an orange border are places the engine looks up before the search itself, and a dashed border marks a place name that belongs to the name of something else. The dot marked “map center” is where the map is open, and the circle is the area where the detailed maps are searched.

GLMap 2.0 is our largest SDK update in years. It adds 3D terrain, one search flow for online and offline data, new pedestrian routing profiles, Vulkan rendering on Android, and much smaller reference applications for Swift and Kotlin.

Most of the new features are a property or a request type, and they work with downloaded data and the same way on iOS and Android.