Update remaining MapLibre GL to MapLibre Native (#1216)

docs/mdbook/src/design/android-map-rendering-data-flow.md

@@ -66,9 +66,9 @@ actors.
 
 The key philosophy of rendering tiles is tiles are rendered layer by
 layer. A collection of tiles is called a tile set. To optimize tile
-rendering, MapLibre Native GL only renders *dirty* tiles. A dirty tile
+rendering, MapLibre Native only renders *dirty* tiles. A dirty tile
 is a tile rendered in the viewport that has changed due to user
-interaction. To initiate this process, MapLibre Native GL loads the
+interaction. To initiate this process, MapLibre Native loads the
 tileset to be rendered first. In a rendering request, if the tileset is
 already loaded, MapLibre Native will use a cached tile set.
 

docs/mdbook/src/design/coordinate-system.md

@@ -1,6 +1,6 @@
 # Coordinate System
 
-Before we jump into the coordinate system of MapLibre Native GL, let's
+Before we jump into the coordinate system of MapLibre Native, let's
 quickly review the concepts of translating a position on the face of
 Earth to a map tile. This is not a comprehensive refresher of coordinate
 reference systems or rendering basics. Rather this intends to guide the
@@ -21,7 +21,7 @@ Native.
 
 This document uses the word *Earth* when it refers to the planet in
 which we all live in and make map tiles for. This document uses the word
-*World* to denote the world MapLibre Native GL renders. The word *world*
+*World* to denote the world MapLibre Native renders. The word *world*
 in rendering terms mean the *world* to render. It could be a set of
 cones and boxes, a modeled city, anything composed of 3D objects.
 MapLibre Native renders map tiles in a range of zoom levels on a 3D
@@ -31,13 +31,13 @@ containing a set of map tiles to be rendered, not the *Earth*.
 
 #### Transformations
 
-MapLibre GL requires a series of coordinate transformations to render a
+MapLibre Native requires a series of coordinate transformations to render a
 geometry from map tile. This is where we refresh our rendering knowledge
 a bit. To render anything through a GPU:
 
 1.  Design and define model in the *Local Space*. We call anything that
     needs to be renderer a *model.* In the Local space, a model lives in
-    its own coordinate system. For MapLibre Native GL, in local space
+    its own coordinate system. For MapLibre Native, in local space
     each individual tile is modeled. This map tile is already populated
     by a map tile generation process. The longitude, latitude bound per
     tile is now translated to pixel bounds in this local space.
@@ -214,7 +214,7 @@ rendering workflow is to translate object coordinates to world
 coordinates. This is important to understand if we are to render
 multiple objects in the world. If we treat all tiles in a zoom level
 being rendered in a single 3D horizontal plane, then the World Space has
-only one object. And in MapLibre GL, this plane has an origin of (0,0),
+only one object. And in MapLibre Native, this plane has an origin of (0,0),
 positioned on the top left.
 
 ## Device Coordinates
@@ -255,7 +255,7 @@ Perspective projection matrix introduces the sense of depth perspective
 through the camera. As in objects further from the camera will look
 smaller and objects closer to the camera will look bigger. This
 perspective component is defined by parameter *w.* That is why the
-shaders that MapLibre Native GL at the time of writing uses 4
+shaders that MapLibre Native at the time of writing uses 4
 dimensional vectors over 3 dimensional vectors. The 4^th^ dimension is
 this parameter *w*. Therefore, theoretically a GL coordinate is of the
 form `(x, y, z, w)`.

docs/mdbook/src/design/expressions.md

@@ -76,14 +76,14 @@ implementation follows right after. Another part to notice here is the
 implementation evaluates both inputs because they are expressions too.
 Expressions can be nested.
 
-**Although it looks like JavaScript, for MapLibre Native GL**, **the
+**Although it looks like JavaScript, for MapLibre Native**, **the
 parser for any expression is written in MapLibre Native Core**. Each
 platform such as iOS, Android has their own Expression class which
 provides builders to build an expression and add it to a layer. When an
 expression is added to a layer, the rendering part of the code picks it
-up in the MapLibre Native GL Core.
+up in the MapLibre Native Core.
 
-Also, inside MapLibre GL Core, this definition mechanism allows
+Also, inside MapLibre Native Core, this definition mechanism allows
 extending expressions library with custom expressions if desired.
 
 ## Expression Types

docs/mdbook/src/design/ten-thousand-foot-view.md

@@ -4,14 +4,14 @@
 *Figure 1: MapLibre Native Components – Ten Thousand Foot view*
 
 From ten thousand foot, MapLibre Native is composed of *Map View* and a
-*Renderer*. MapLibre Native GL supports iOS, Android, Linux, QT, MacOS,
+*Renderer*. MapLibre Native supports iOS, Android, Linux, QT, MacOS,
 and nodeJS at the time of writing. Each of these *platforms* have their
 own *Map View* and *Map Renderer* component. A *Map Renderer* talks to a
 shared codebase that renders map by using device GPU. This shared piece
 of code at the time of writing supports OpenGL as its choice of
 rendering API.
 
-Apart from the platform code, *MapLibre Native GL* offers shared
+Apart from the platform code, *MapLibre Native* offers shared
 implementation for *Style, Layers, Text, Glyphs*, and *Tiles*.
 
 To summarize:
@@ -161,7 +161,7 @@ processing. The platforms also include worker threads for processing for
 platform-specific tasks such as running HTTP requests in the background.
 But the core code is agnostic about where those tasks get performed.
 Each platform is required to provide its own implementation of
-concurrency/threading primitives for MapLibre GL core to use. The
+concurrency/threading primitives for MapLibre Native core to use. The
 platform code is also free to use its own threading model. For example,
 Android uses a *GLSurfaceView* with a *GLThread* where the iOS SDK uses
 *Grand Central Dispatch* for running asynchronous tasks.
@@ -175,15 +175,15 @@ simplify, there is only one thread allocated for rendering loop,
 background or foreground[^7]. A *Tile Worker* is a thread that prepares
 a tile of a specific type. Geometry Tile Worker by the name of it,
 prepares a tile for rendering tiles that contains vector geometry.
-Following that same trend, MapLibre Native GL offers tile worker for
+Following that same trend, MapLibre Native offers tile worker for
 raster tiles and elevation tiles. Messages sent to a tile worker can be
 processed by any thread, with the assumption that only one thread at a
 time will work with a tile worker instance.
 
 Tile workers are not based on a common interface or base class. Tiles
-are. MapLibre Native GL offers a base Tile class. Raster, Geometry, and
+are. MapLibre Native offers a base Tile class. Raster, Geometry, and
 Elevation tile instances are inherited from Tile base class. Through
-this inheritance MapLibre Native GL maintains the association of Tile
+this inheritance MapLibre Native maintains the association of Tile
 types and tile workers. Any Tile Worker is an actor that accepts
 messages of a specific Tile type. For a Geometry Tile Worker, the type
 is a Geometry Tile.