Projects/Marble/VectorTilingProposal - Revision history

Tackat: /* Server Requirements */

2012-05-28T18:01:31Z

‎Server Requirements

Tackat: /* Server Requirements */

2012-05-28T16:52:44Z

‎Server Requirements

Tackat at 16:40, 28 May 2012

2012-05-28T16:40:29Z

Tackat: /* Hook nodes */

2012-05-28T16:32:29Z

‎Hook nodes

Tackat: /* Discussion of a possible Vector Tiling approach */

2012-05-28T16:20:44Z

‎Discussion of a possible Vector Tiling approach

Tackat: /* Discussion of a possible Vector Tiling approach */

2012-05-28T16:04:24Z

‎Discussion of a possible Vector Tiling approach

Tackat: /* Hook nodes */

2012-05-28T15:58:21Z

‎Hook nodes

Tackat: /* Discussion of a possible Vector Tiling approach */

2012-05-28T15:51:13Z

‎Discussion of a possible Vector Tiling approach

Tackat at 15:40, 28 May 2012

2012-05-28T15:40:44Z

Tackat: /* Discussion of a possible Vector Tiling approach */

2012-05-28T15:31:51Z

‎Discussion of a possible Vector Tiling approach

@@ Line 5: / Line 5: @@
 == Server Requirements ==
 * For reasons of performance tile data files should be available '''statically''' (so it shouldn't be necessary to have a script create the tiles on demand). This should at least be the case for lower zoom levels.
 * It should be ''easy to set up any server'' based solution on the KDE server. The same applies for tile creation.
 * ''Tile update'' needs to be possible regularly (e.g. once a week).

@@ Line 5: / Line 5: @@
 == Server Requirements ==
-* For reasons of performance tile data files should be available '''statically''' (so it shouldn't be necessary to have a script create the tiles on demand).
+* For reasons of performance tile data files should be available '''statically''' (so it shouldn't be necessary to have a script create the tiles on demand). This should at least be the case for lower zoom levels.
-* It should be ''easy to set up any server'' based solution on the KDE server.
+* It should be ''easy to set up any server'' based solution on the KDE server. The same applies for tile creation.
-* ''Tile update'' needs to be possibly regularly (e.g. once a week).
+* ''Tile update'' needs to be possible regularly (e.g. once a week).
 * The tiling access scheme should be similar to the current bitmap tiles: i.e. the '''access urls''' should be similar to  e.g. a.tile.openstreetmap.org/3/4/2.png

@@ Line 72: / Line 72: @@
 Also note the purple "helper node" at the top-right of the child tile. This node requires a special form of tagging so that it can be distinguished from the other "hook nodes". The purpose of the helper nodes is this: if a polygon is downloaded without any parents to hook in then the polygon area needs to get properly closed. The helper nodes define nodes that close the polygons properly even if there are no parent tiles that the polygon can hook into.
+The nice thing about this concept of "hook nodes" is that a map browser client doesn't necessarily need to provide support for them: Since they are just specially flagged nodes they can just be considered normal nodes by the client and the client would still render the whole tile properly. Advanced map browser clients could still make use of them.
-−
+The same also applies if the child tile defines some "hook nodes" (e.g. a cut off lake like the Caspian Sea on Tile 2 above) that are meant to be used by a parent tile and the available parents don't have fitting interfaces (because the lake isn't covered in those parent tiles). Then the two end-points of the half-cut lake would get connected right away until more data is available.
-The nice thing about this concept of "hook nodes" is that the map browser client doesn't need to support them: Since they are just specially flagged nodes they can just be considered normal nodes by the client and the client would still render the whole tile properly. The same also applies if the child tile defines some "hook nodes" (e.g. a cut off small lake) that are meant to be used by a parent tile and the available ones don't have fitting interfaces (because the lake isn't covered in those parent tiles). Then the two end-points of the half-cut lake would get connected right away until more data is available.

@@ Line 66: / Line 66: @@
 [[File:hooknode_h.png | 300px]]
-Also note the purple "helper node" at the top-right. This node requires a special form of tagging so that it can be distinguished from the other "hook nodes". The purpose of the helper nodes is this: if a polygon is downloaded without any parents to hook in then the polygon area needs to get properly closed. The helper nodes define nodes that close the polygons properly even if there are no parent tiles that the polygon can hook into.
+And here is a picture that shows the "hook nodes" of both, the level 0 and the level 2 tile:
 The nice thing about this concept of "hook nodes" is that the map browser client doesn't need to support them: Since they are just specially flagged nodes they can just be considered normal nodes by the client and the client would still render the whole tile properly. The same also applies if the child tile defines some "hook nodes" (e.g. a cut off small lake) that are meant to be used by a parent tile and the available ones don't have fitting interfaces (because the lake isn't covered in those parent tiles). Then the two end-points of the half-cut lake would get connected right away until more data is available.

← Older revision		Revision as of 16:20, 28 May 2012
Line 65:		Line 65:

	[[File:hooknode_h.png \| 300px]]		[[File:hooknode_h.png \| 300px]]
		+
		+	Also note the purple "helper node" at the top-right. This node requires a special form of tagging so that it can be distinguished from the other "hook nodes". The purpose of the helper nodes is this: if a polygon is downloaded without any parents to hook in then the polygon area needs to get properly closed. The helper nodes define nodes that close the polygons properly even if there are no parent tiles that the polygon can hook into.
		+
		+	The nice thing about this concept of "hook nodes" is that the map browser client doesn't need to support them: Since they are just specially flagged nodes they can just be considered normal nodes by the client and the client would still render the whole tile properly. The same also applies if the child tile defines some "hook nodes" (e.g. a cut off small lake) that are meant to be used by a parent tile and the available ones don't have fitting interfaces (because the lake isn't covered in those parent tiles). Then the two end-points of the half-cut lake would get connected right away until more data is available.

← Older revision		Revision as of 16:04, 28 May 2012
Line 61:		Line 61:

	[[File:hooknode_g.png \| 300px]]		[[File:hooknode_g.png \| 300px]]
		+
		+	Now of course the "child" tile would have to define hook nodes as well so that its polygons can hook into the polygon of the parent tile. In this picture the hook nodes that are meant to be connected to the parent tiles are colored yellow:
		+
		+	[[File:hooknode_h.png \| 300px]]

← Older revision		Revision as of 15:58, 28 May 2012
Line 56:		Line 56:

	[[File:hooknode_f.png \| 300px]]		[[File:hooknode_f.png \| 300px]]
		+
		+	Now if we just provided hook nodes for the next level then we'd have to download the full range of level 0 to level 8 parent tiles just to properly embed a single level 9 tile. So it would be useful if the hook nodes would span a wider range of zoom levels: E.g. a level 0 tile could provide hook nodes for zoom levels 1 and 2 - or even for 3. This approach would then reduce the amount of parent tiles to be downloaded for higher zoom levels dramatically.
		+	Here you can see the hook nodes on a level 0 tile for level 1 (red) and level 2 (green) as an example:
		+
		+	[[File:hooknode_g.png \| 300px]]

@@ Line 49: / Line 49: @@
 [[File:hooknode_e.png | 300px]]
-So ideally one would merge polygons from lower zoom levels with those polygon section from higher zoom levels into a single polygon. Of course one would need to specify points where the polygon sections of higher zoom levels could dynamically "hook in". For the lack of a better term we just call these specially tagged nodes "hook nodes" in this document. So a level 0 tile would just contain hook nodes (here red squares) along the QuadTile borders for the level 1 tile borders (black lines):
+==== Hook nodes ====
 [[File:hooknode_f.png | 300px]]

← Older revision		Revision as of 15:40, 28 May 2012
Line 48:		Line 48:

	[[File:hooknode_e.png \| 300px]]		[[File:hooknode_e.png \| 300px]]
		+
		+	So ideally one would merge polygons from lower zoom levels with those polygon section from higher zoom levels into a single polygon. Of course one would need to specify points where the polygon sections of higher zoom levels could dynamically "hook in". For the lack of a better term we just call these specially tagged nodes "hook nodes" in this document. So a level 0 tile would just contain hook nodes (here red squares) along the QuadTile borders for the level 1 tile borders (black lines):
		+
		+	[[File:hooknode_f.png \| 300px]]

@@ Line 42: / Line 42: @@
 Now this approach would work to some degree and might be the first mile-stone to implement. However it has some backdraws:
- * It requires to completely "overpaint" the tile of the tile level below. So it would still be required to render the area below the level 2 tile.
+* It requires to completely "overpaint" the tile of the tile level below. So it would still be required to render the area below the level 2 tile.
- * the same geometric feature that is covered in both tile levels is distributed across different polygons. This might make "filling" (e.g. with a plain color or a texture) harder. Same applies for selection of such a polygon.
+* the same geometric feature that is covered in both tile levels is distributed across different polygons. This might make "filling" (e.g. with a plain color or a texture) harder. Same applies for selection of such a polygon.
 Also note that if tiles weren't fully opaque with this approach we'd run into artefacts like visible on this picture (land shines through where there should be sea, e.g. Red Sea). To better recognize the issue the land of the level 2 tile has been marked with a darker gray tint:
 [[File:hooknode_e.png | 300px]]