Marble/VectorTilingProposal: Difference between revisions
< Marble
(Created page with "= Vector Tiles = === Design considerations, ideas, thoughts, nothing final ===") |
No edit summary |
||
Line 1: | Line 1: | ||
= Vector Tiles = | = Vector Tiles for Marble = | ||
=== | |||
Here are a few requirements that need to be met for technical, common-sense or organizational reasons: | |||
== 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). | |||
* It should be easy to set up any server based solution on the KDE server. | |||
* Tile update needs to be possibly regularly. | |||
* The tiling access scheme should be similar to the current bitmap tiles: i.e. the access urls should be similar to e.g. http://a.tile.openstreetmap.org/3/4/2.png | |||
== Tiling Requirements == | |||
* It needs to be possible to render single tiles alone. | |||
* It should be possible to show tiles from different tile levels at once. | |||
* It needs to be possible to identify features across tiles and across tile levels. E.g. it should be possible to identify several sections of the same river belonging together or resembling the same river. This could be done through an id that serves as a unique identifier for the same geometrical feature across tiles. This is also necessary to display the "same" feature only once in the model (despite having versions for multiple zoom levels in memory) | |||
* It should be possible to fill or select a certain polygon (e.g. a country) inspite of the fact that it might be distributed across different tiles that possibly belong to different tile levels. | |||
* The data that is stored inside a tile should stay relatively small (in the kB range). | |||
* The tiles rendered should adhere to cartographic standards. |
Revision as of 13:48, 28 May 2012
Vector Tiles for Marble
Here are a few requirements that need to be met for technical, common-sense or organizational reasons:
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).
- It should be easy to set up any server based solution on the KDE server.
- Tile update needs to be possibly regularly.
- The tiling access scheme should be similar to the current bitmap tiles: i.e. the access urls should be similar to e.g.
Tiling Requirements
- It needs to be possible to render single tiles alone.
- It should be possible to show tiles from different tile levels at once.
- It needs to be possible to identify features across tiles and across tile levels. E.g. it should be possible to identify several sections of the same river belonging together or resembling the same river. This could be done through an id that serves as a unique identifier for the same geometrical feature across tiles. This is also necessary to display the "same" feature only once in the model (despite having versions for multiple zoom levels in memory)
- It should be possible to fill or select a certain polygon (e.g. a country) inspite of the fact that it might be distributed across different tiles that possibly belong to different tile levels.
- The data that is stored inside a tile should stay relatively small (in the kB range).
- The tiles rendered should adhere to cartographic standards.