[Mapcss] Basic semantics

[Richard Fairhurst]

Thomas Davie wrote:
> I'm just getting going with a renderer that'll use MapCSS,

\o/

> If someone could cover these basics I'd appreciate it.

But before that I'll just briefly quote from a mail I sent last July:

> I was going to write a brief message outlining the philosophy (FWIW)
> of MapCSS, but might as well summarise it here:
>
> - be CSS-like
> - but not dogmatically so: if shadowing the original CSS spec would
>   vastly overcomplicate things, don't. Keep it simple!
> - be informed by the vocabulary of previous attempts (Cascadenik,
>   Mapnik XML, etc.)
> - degrade gracefully - it's fine if clients don't support absolutely
>   everything

So that's the big picture answer. MapCSS should do whatever is CSS-like, 
unless it's clearly unworkable or too complex when applied to a map.

That means the answer to this:

 > The most important thing that I can't get fixed in my head at the
 > moment is whether a MapCSS file specifies a bunch of statements that
 > must be executed (causing the side effect of some map being rendered)
 > in order, or whether it specifies a bunch of consistent rules that
 > together can be queried to find the style of a particular {node | way
 > | relation}.

is the latter, because that's how CSS works.

> The second case doesn't seem to make much sense either though. No
> method of evaluating the style of an object is specified. Suppose one
> rule specifies to set tag a to x, while another specifies to set tag a
> to y. Which takes precidence? Suppose 3 other rules depend on
> (respectively) a not being set, a being x, and a being y, which of these
> rules apply? When should styles be merged, and when should they be
> applied one on top of each other?

Ignore the 'set' and 'exit' stuff. 'exit' is basically a hack (a speed 
optimisation for Halcyon) and 'set' an ill-conceived attempt to mix 
TagTransform in to cope with the haphazard nature of OSM tagging. I 
think there are probably things we can do to address the latter, but 
'set' probably isn't one :)

cheers
Richard