Talk:MapCSS/0.2

From OpenStreetMap Wiki
Jump to: navigation, search

Contents

Suggested improvements for MapCSS 0.2

child: relation > node -- a node that is a member of that relation
descendant: relation node -- a node that is a member of that relation, or whose enclosing way is a member of that relation, or whose enclosing relation is...
  • I am not particularly in favor of a "thinnest" keyword. I think you should be able to just specify 0.01 as width and have the renderer figure out what to do with it (if it does not support subpixel, it should fallback to 1 pixel, etc). --spaetz

Dealing with z-index and cascades more sensibly

Use the CSS subpart syntax to create multiple styles for a single element. Each subpart defines its own cascade of properties.

E.g.

way[highway=footway] { width: 2; z-index: 3; }
way[fixme]::fixme_highlight { width: 10; z-index: 2; color: red; text: "fixme"; font-size: 12; }

draws footways with width 2 and highlights all ways if they have the FIXME key. The subpart name is a free identifier, but there are two special subparts:

The default subpart:

way[highway=footway]::default { width: 3; z-index: 2; }

can be interchangeably written as

way[highway=footway] { width: 3; z-index: 2; }.

Otherwise it is just an ordinary subpart.

The * subpart:

It is special in 3 ways:

  1. It is not rendered, so it is only there for "book keeping".
  2. It overrides all existing subparts:
    so
    way::A { a; }
    way::B { b; }
    way::* { c; }
    is equivalent to
    way::A { a; }
    way::B { b; }
    way::A { c; }
    way::B { c; }
  3. It initializes new subparts. In other words:
    way::* { a; }
    way::A { b; }
    is equivalent to
    way::A {}
    way::* { a; }
    way::A { b; }
    (which is in turn the same as
    way::A { a; }
    way::A { b; }
    or
    way::A { a; b; }.)

-- Bk 15:13, 13 July 2010 (UTC)

Declarations

to stop checking any rules from this point on, in circumstances where speed is really important. I agree it shouldn't be part of the core spec." and Komяpa says "IMHO this thing was invented just for easier debugging of Halcyon and shouldn't be present in mapcss at all." so we might want to delete it from the core spec.

more on dashes

add the following properties for advanced dashes drawing: 

dashes-offset: <NUM>;
dashes-background-color: <COLOR>;

The offset is a number >= 0 that specifies how much to skip from the start of the pattern. Background color sets the color of the line in between the dashes. If the color is non-transparent, this can also be done with the casing property. Otherwise it can be simulated in the following way: 

way {
  dashes: 30, 17, 2, 5;
  color: blue;
}

way::dashes-background {
  dashes: 5, 30, 17, 2;
  dashes-offset: 5;
  color: lightblue;
}

--Bk 11:25, 26 September 2010 (BST)

Generalized selectors (area)

In addition to the OSM specific basic selectors node, way and relation, it would be useful to have more "abstract" or GIS related selectors.

For a start we could have the area selector, which selects closed ways and Multipolygons.

Currently it would select a closed way with junction=roundabout, although it does not really represent an area. When osm has a real area data type in the future, this can be changed. --Bk 15:46, 2 October 2010 (BST)

area selector is now on the spec. If source data doesn't have relations, renderer could just not implement them. --Komяpa 10:00, 18 June 2011 (BST)

Testing for relation member roles

see subpage

fill-color vs. fill

Why not use standard W3C properties?

Dealing with areas

How is the best way to deal with areas. way[condition]:closed and area[condition] seems to be treated differently, at least in JOSM. --Skippern 18:14, 4 July 2011 (BST)

area should cover multipolygons and closed ways. For historical reasons, JOSM handles this a bit different: Unclosed ways are included, but reported by the validator when an area style applies. Actually the abstraction can be seen as an advantage, as renderers can decide on their own, how areas are defined in detail.--Bk 19:30, 8 July 2011 (BST)

icon-image formats and scaling

What formats are supported by icon-image, and is it possible to scale the images? The reason I am asking is that I wish to use SVG graphics. In some cases I would also allow the option to scale images, either use various resolutions of the same SVG file on different zoom levels or in some cases evaluate values to determine resolution. --Skippern 01:30, 7 July 2011 (BST)

scaling is possible. image formats depends on renderer, for now usually png is supported. --Komяpa 13:39, 8 July 2011 (BST)
I found scaling, icon-width and icon-height are documented, but I saw a stylesheet use icon-size (not documented?), which worked for me, looking into making a ticket to accept .SVG in the renderer in question. --Skippern 15:56, 8 July 2011 (BST)
Opened trac ticket in JOSM --Skippern 16:12, 8 July 2011 (BST)
JOSM doesn't support scaling of fill-image, is this something forgotten by MapCSS or is this a JOSM problem? --Skippern 17:54, 13 September 2011 (BST)
I think it is missing in MapCSS so far. --Bk 10:48, 15 September 2011 (BST)

Nested rules

Will there be a rule to handle nested rules? For example one could make a nested rule for natural=wetland with subrules for wetland=* i.e. by giving a background colour in the parent rule and fill symbol in each of the sub rules.... --Skippern 12:45, 26 August 2011 (BST)

In current practice, you would give background color in a [natural=wetland] rule and define details in subsequent rules, that repeat the [natural=wetland] filter, a better example:
way[highway=secondary] { color: yellow; width: 5; }
way[highway=secondary][tunnel=yes] { dashes: 4,4; }
--Bk 17:04, 26 August 2011 (BST)
The reason I ask this is that I am writing a set of highly complicated rules, and nesting would allow me to simplify alot. What I am looking for is something like:
way[highway=secondary] { color: yellow; width: 5; way[tunnel=yes] { dashes: 4,4: } }
--Skippern 20:18, 26 August 2011 (BST)
Yes, I think nested rules would have a lot of potential, but maybe the idea is a little ahead of it's time...--Bk 14:59, 13 September 2011 (BST)

icon-image on areas

Shouldn't it be possible to use icon-image, or a similar rule on areas? i.e. a hospital icon rendered in the center of a hospital building polygon. --Skippern 21:17, 7 September 2011 (BST)

Good idea, e.g. like Mapnik does it. --Bk 14:53, 13 September 2011 (BST)
Retrieved from "http://wiki.openstreetmap.org/wiki/Talk:MapCSS/0.2"
Personal tools
Namespaces
Variants
Actions
site
Toolbox