Cartographical semantics

Home of Thorf's myriad Secret Projects.

Moderators: Seer of Yhog, Thorf

Cartographical semantics

Postby Sock Puppet » Tue Apr 16, 2013 1:08 pm

Relevant links:
* http://mystara.thorf.co.uk/other/legend.png
* http://www.icemark.com/tower/maps/htmlmap/map.htm
* viewtopic.php?f=21&t=5753 (birchbeer's .gbr files)

----

I'm working on a system so that maps can be generated usng raw code in a wiki, rather than relying on an expert with map editor skills. And it occurred to me that every hex is made up of a number of elements:

* background colour (dark brown for mountains, green for clear and light forest)
* dingbat (city icon, mountain icon, etc)
* border layer
* river/coast later
* plateau edge layer
* road/path/wall layer

Some of these will be hard to implement, but I think by using precision css image placing and alpha transparent png files, a lot of it can be done. I'm thinking every base image could be encoded by a three letter code which will then be parsed by the wiki. The first letter will encode the background colour, the second a dingbat (which may be context-variable on the background colour), the third a river/coast layer.

It's very much a though experiment at this stage.

Thorf, do you have any square-based palettes of your map artwork?
Last edited by Sock Puppet on Tue Apr 16, 2013 3:07 pm, edited 1 time in total.
I am Ashtagon's sock puppet account.
User avatar
Sock Puppet
Troll
 
Posts: 324
Joined: Thu Jun 12, 2008 2:02 pm

Re: Cartographical semantics

Postby agathokles » Tue Apr 16, 2013 2:11 pm

For a (relatively) quick example, you could use the GIMP brushes posted by birchbeer. In theory, an even better solution would be to use SVG (e.g., an SVG-edit extension or plugin with vector hexes and a hex grid).

From a technical point of view, the background and dingbat are relatively easy to implement and encode in text. However, rivers and coastlines would be rather difficult to do properly, unless one accepts a lot of straight lines instead of curves, or implements something much more complex.

BTW, a similar thing to what you're considering is implemented in the map editor for the Battle for Wesnoth game.

GP
agathokles
Blue Dragon
 
Posts: 6122
Joined: Sat May 24, 2008 6:42 pm
Location: Milan, Italy

Re: Cartographical semantics

Postby Culture20 » Wed Apr 17, 2013 9:10 pm

agathokles wrote:For a (relatively) quick example, you could use the GIMP brushes posted by birchbeer. In theory, an even better solution would be to use SVG (e.g., an SVG-edit extension or plugin with vector hexes and a hex grid).
SVG would probably be better, especially since modern browsers should support it.
From a technical point of view, the background and dingbat are relatively easy to implement and encode in text.
Each hex would have to be numbered with a toggle-able overlay for identification with its wiki-source since the wiki text can't exist in the same grid shape. Even if you started out the text like
Code: Select all
^=mountain
-=plains
~=ocean
A=volcano
T=forest
  A  ^  ^  ^  ^
^  ^  T  -  -  -
  ^  -  -  ~  ~

you'd start to have positional problems unless you made each layer excluding water (land, feature[coral, magic point, etc], city, roads, text) as its own text hex "grid" then make the html/svg maps into layers. Hmm. Never mind, I guess it could be done, but whitespace would matter...
However, rivers and coastlines would be rather difficult to do properly, unless one accepts a lot of straight lines instead of curves, or implements something much more complex.
This is the kicker (along with borders, plateaus, etc). You could express them in complex mathematical formulas, but it might be best to have coastlines be an SVG overlay from the start so that the wiki-using folk just input hex data. Assuming this is for Mystara, there is the benefit that we already know most of the coastlines (although past and future versions are unknown). Basically, whoever starts a project draws up some coastlines in an SVG editor and make that the starting point for others
User avatar
Culture20
Bugbear
 
Posts: 184
Joined: Sat Mar 17, 2012 9:39 pm

Re: Cartographical semantics

Postby Ashtagon » Wed Apr 17, 2013 10:57 pm

Let us suppose a TLA (three letter acronym)...

m - dark brown (mountains)
h - light brown (hills)
f - dark green 9forest, jungle)
c - medium green (light forest, clear, farmland)
m - pale green (marshes)
i - pale grey (ice cap, tundra)

That's the first letter. The second letter would encode a dingbat. This might need to vary depending on the context of the first letter.

For a river, we know it must start in one hex side and end in a hex side (possibly the same hex side). That's 36 possible graphics. We can further say that the path will make either a short route within the hex or a long route within the hex, making a total of 72 standard river graphic overlays to be made.

Coast graphics would require 144; the pathway would be described as for rivers, but an additional question of which side of the wandering line is the high ground would need to be made. Effectively, they form an overlay graphic in "coastline blue" that would be placed over a land hex.

Deeper levels of water would be represented by different colour water hexes. Again, in order to make for nice patterns of transition, a set of 144 tiles per isodepth boundary line to be drawn would be needed. These would work identically to the coast graphics in general usage.

One limitation of such an engine for drawing coasts and ocean depth isodepth lines is that you can't have more than one in a single hex.

I have a feeling that the code for a river/ocean overlay graphic would need to be quite long. <aybe a TLA of its own:
[start hex side 1-6], [end hex side 1-6], [route descriptor code]

route descriptor code:
1 - path goes on shortest possible route
2 - path goes on longest possible route
3 - long route variant (eg hex sides 1-4, curves down instead of up)

This probably needs more thought, but could work.

Hmm, I suspect this probably falls into teh realms of technically doable, but the end-user interface would probably be worse than just teaching someoen to use a decent map making app.
Emma Rome, otherwise known as Ashtagon
Image
Overall site admin for The Piazza. My moderator colour is pink!
User avatar
Ashtagon
Hierarch
 
Posts: 3362
Joined: Thu May 22, 2008 5:45 pm
Location: Hillvale, Isle of Dawn

Re: Cartographical semantics

Postby Thorf » Thu Apr 18, 2013 1:40 pm

Ashtagon wrote:Hmm, I suspect this probably falls into teh realms of technically doable, but the end-user interface would probably be worse than just teaching someoen to use a decent map making app.


That's pretty much my thought, too. Even before you get into the complexities of making curved paths appear on the grid, it would be very time-consuming to put together maps. You'd need to build an editor, really.

It's an interesting concept, but it would require a lot of development work to implement it.
User avatar
Thorf
Cartomancer
 
Posts: 2226
Joined: Fri May 23, 2008 2:41 am
Location: Akita, Japan

Re: Cartographical semantics

Postby Sock Puppet » Thu Apr 18, 2013 2:55 pm

A long time ago, I wrote an editor for Bard's Tale style maps (very similar to TSR offerings of the time in appearance), using javascript. I could edit maps and render them (surprisingly fast too, given the computers of the day). It would also generate code that could be copied and pasted into data files (javascript lacks that kind of functionality).

So, yeah, the technology for this almost exists anyway.
I am Ashtagon's sock puppet account.
User avatar
Sock Puppet
Troll
 
Posts: 324
Joined: Thu Jun 12, 2008 2:02 pm


Return to Thorf's Projects

Who is online

Users browsing this forum: No registered users and 1 guest