User Tools

Site Tools


mapcraftweb

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
mapcraftweb [2010/10/09 20:51]
sam
mapcraftweb [2015/02/04 22:39] (current)
Line 4: Line 4:
  
 This then is a holding page for ideas on how to move //​Mapcraft//​ into a more dynamic, web based, environment. Navigation similar to //​GoogleMaps//​ would be good, with support for much larger maps stored in a database. This then is a holding page for ideas on how to move //​Mapcraft//​ into a more dynamic, web based, environment. Navigation similar to //​GoogleMaps//​ would be good, with support for much larger maps stored in a database.
 +
 +See also: [[/​mapcraftweb/​rest]],​ [[mapcraftweb/​ajax]]
  
 ===== Implementation ===== ===== Implementation =====
Line 29: Line 31:
 A sub-sector can be represented with a single hex in the same way. There is the possibility of falling back to sub-sub sectors (4x5 hexes). A sub-sector can be represented with a single hex in the same way. There is the possibility of falling back to sub-sub sectors (4x5 hexes).
  
-This saves space in the database. +This saves space in the database ​in areas with little detail.
- +
-==== Hex v Pixels ==== +
- +
-The easy approach is maybe just to have a big image (or lots of small tiles stitched together) and display that. We then can draw whatever we want on the map and have it look pretty. This gives no artificial tiles which constrain the look. +
- +
-The problem here is that the system doesn'​t //know// what a bit of land is. A green pixel may be anything making it difficult to add intelligence to the map. You could have multiple layers, at which point it starts getting complex to manage. +
- +
-If hex tiles are small enough, and there is a good variety of terrain types, maps should look just fine. +
-==== Dynamic Resolution ====+
  
-It's a fantasy world, so maps don't need to be accurate, however to ensure that they don't look too blocky, we need to store them at a reasonable resolution.+===== Current Status =====
  
-We will assume the smallest resolution will be 1 tile = 5km. Low res areas will not specify every tile, instead if no tile for given location is found, then we look for a mod 5 tile, e.g. tile 0 will define tiles 0-4, if the others are missingIf mod 5 is missingthen look at mod 25, then mod 125 etc.+Currently SVN has code which can display ​basic map things and paths aren't yet supportedThere is a REST interface for thiswhich works nicely for getting tiled map images.
  
-==== Tile Shape ====+  * REST interface to display maps. 
 +  * Display Things (towns, cities etc) 
 +  * Display map by named area. 
  
-I've assumed tiles will be hexagons, but is this necessary? Squares are much easier to work with, and if the resolution ​is high enough won't look out of place.+There is also a utility for importing maps from the old XML files, which is being used for testing. How best to do actual editing has yet to be decided.
  
-At the resolution we show at however, I think we need to stick with hexagons. i.e., maps will often be displayed with hexagons of 8-16 pixels in sizewhich looks very bad for square tiles.+Support for the REST interface has been added into the Alfresco Yagsbook implementationso that a Yagsbook encyclopedia can now reference these maps and embed them. Maps can currently ​be selected according to areaand the area is automatically scaled to a sensible size.
mapcraftweb.1286657492.txt.gz · Last modified: 2015/02/04 22:39 (external edit)