Kosmos Rendering Help

From OpenStreetMap Wiki
Jump to: navigation, search
Help
Available languages
Deutsch English Русский

One of the most interesting features of Kosmos rendering engine is the ability of users to define how maps should be rendered by writing definitions in OpenStreetMap Wiki pages. One example of such a page is Kosmos General Purpose Rules page, which is intended to contain rules for rendering standard maps.

Kosmos will automatically download rendering rules page and parse it. The idea is to "democratize" rendering of OSM data by providing a Wiki mechanism so that many OSM users can contribute their rendering rules. Also, there could be many Wiki pages containing different sets of rendering rules for different types of maps - city maps, hiking maps, driving maps etc. There could even be separate rendering rules pages for displaying on the screen and for printing maps.

You can also save the raw contents of the rendering rules Wiki page into a file and use this file in Kosmos instead (see FAQ).

If you have any questions about using rendering rules, maybe a visit to Kosmos FAQ page will help.

Contents

Rules Table(s)

Rules have to be entered in one or more tables as seen on the KosmosStandardRules and Kosmos General Purpose Rules pages. Anything outside the tables is ignored by Kosmos and can be used for writing comments or separating the Wiki page into several sections (which is highly recommended, since you can then edit portions of rule list separately).

Each row represents a single rule:

Rule Name Targets Selector Templates Options Comment
RestaurantNode Node amenity=restaurant Icon (MinZoom=13, IconUrl=http://wiki.openstreetmap.org/images/5/58/Restaurant.png, Width=12:5;17:20)
Text (MinZoom=15, Color=black, TagToUse=name, FontName=Arial, FontStyle=regular, FontSize=15:5;17:9, TextLineOffset=-200%)
Restaurant.png

The table column's are as follows:

Child Rules

By giving the rule a name which starts with a dot, you are specifying that this is a child rule of the parent rule (parent rule is the first non-child rule that appears before in the table). Example:

HighwaySecondary Way highway=secondary Text (MinZoom=15, Color=black, TagToUse=name, FontName=Arial, FontStyle=regular, FontSize=15:6;17:9) ChildrenFirst
.Bridge bridge=yes Polyline (MinZoom=8, Color=#FDBF6F, BorderColor=gray, BorderWidth=30%, Width=8:1;10:2;13:6;17:14)
.* Polyline (MinZoom=8, Color=#FDBF6F, BorderColor=gray, Width=8:1;10:2;13:6;17:14)

What does this all mean? We are specifying that all ways tagged with highway=secondary will have their names rendered as text. Also, all such ways which represent bridges will be drawn using a polyline with a thicker border. All other ways (non-bridges) will be drawn using a normal border width.

Child rules compete for the right to be rendered. The first child rule that meets the selector criteria will be used to render an OSM element. All child rules (of the same parent) after that will be ignored for this OSM element.

A child rule named as .* represents a special case (called the default child rule) which is used to cover all OSM elements which did not match other child rules. You do not have to specify this default child rule, but if you do, make sure it is the last child rule in the list.

Any Targets or Options specified for child rules are ignored by Kosmos.

Sometimes you want templates specified by child rules to be rendered before those of the parent. In this case, specify ChildrenFirst option for the parent rule.

Element Selectors

Two types of element selectors are available:

It is possible to set more than one tag for each rule. This means that only those elements which have all of the specified tags would match the query. So for example:

{{tag|amenity|restaurant}} {{tag|cuisine|chinese}} {{tag|name|Hot Rat}}

would select all Chinese food restaurants whose names are 'Hot Rat' (not that I know any ;) ).

Complex Expressions Syntax

NOTE: complex expressions are an experimental feature at the moment. The syntax described below will probably change in the near future (it will be simplified). Also, I will try to make expressions evaluation less performance-intensive.

Kosmos currently uses Flee library to evaluate complex expressions. Check out the link to see all the available operators.

Three specials functions are provided by Kosmos to be used in the complex expressions:

  1. IsTaggedWith (e,"key"): returns true if the element (node, way, area) has any tag which uses the specified key ; otherwise false.
  2. ValueNum (e,"tag"): returns a numerical value of the tag tag
  3. ValueString (e,"tag"): returns a string value of the tag tag

Be sure to read Kosmos Rendering Help#Performance Considerations regarding the use of complex expressions.

Templates

Kosmos templates are graphical representations of OSM elements on the map. Currently these are templates which can be used:

Each rule can have one or more templates (the example above uses two). Each template has to be its own line, example:

Name der Regel Ziel Selektor Vorlagen Optionen Kommentar
RestaurantNode Node amenity=restaurant Icon (MinZoom=13, IconUrl=http://wiki.openstreetmap.org/images/5/58/Restaurant.png, Width=12:5;17:20)
Text (MinZoom=15, Color=black, TagToUse=name, FontName=Arial, FontStyle=regular, FontSize=15:5;17:9, TextLineOffset=-200%)
Restaurant.png

Each template has associated parameters. Some parameters are available for all template types and some are specialized for an individual template type.

Standard Parameters

Polyline Template Parameters

Polygon Template Parameters

Text Template Parameters

The text template works in two modes, depending on the type of the OSM element which it represents. For nodes, the text is rendered horizontally and centered on the node. For polylines, the text is rendered along the polyline.

Symbol Template Parameters

Icon Template Parameters

NOTE: Since version 2.3, icon template can be used for nodes and areas.

Using Colors

Colors can be entered as HTML color names, examples: "black", "white", "red", "#00FF00". Also, Kosmos supports the ARGB scheme, which means that you can also specify the alpha value of the color. This can be helpful if you want to use transparency effect. Example: color "#80FFFF00" means half-transparent yellow. The lower the alpha value is, more transparent will the template be.

Zoom Factor Values

Zoom factor values allow you to specify how the certain property will change its value according to the zoom level. Basically, you specify the property values for certain zoom levels, and the rest is calculated (interpolated) by Kosmos based on known points you specified. Example:

Width=1:1;9:1.5;17:6

means that the width used by the template will be 1 pixel on zoom level 1, 1.5 pixels on zoom level 9 and 6 pixels on zoom level 17. Everything in between is interpolated, so for example on zoom level 12 the width will be 3.1875

You can specify as many known points as you like. In addition, zoom level need not be an integer value.

Dash Styles

The following values are currently supported:

Example:

DashStyle=Dash

See [1] for examples.

Line Caps

Example:

LineEndCap=Round, LineStartCap=Round

See [2] for a list of all cap styles.

Hatch Styles

We may be able to take examples and supported values from [3]. -LastGrape/Gregory (LwD)

Rendering Options

These are some additional options which can change the behavior of the template. Currently only one option is available: EliminateSeams.

Two ways drawn without EliminateSeams option
Two ways drawn with EliminateSeams option
Two ways drawn with EliminateSeams option and Curved=true

EliminateSeams can be used on a polyline template. If this option is turned on, Kosmos will try to connect all the ways of the same type before actually drawing them on the screen. This means that seams are then eliminated.

However, this only works for ways rendered with the same rendering rule. Also, seam elimination prevents using Curved=true option for ways, since the combination can get ugly. On the example image, three ways are drawn instead of two.

Obviously, seam elimination algorithm has to be improved in the future.

Layering in Kosmos

Kosmos draws OSM elements in a certain order. This order defines what element comes above other element. Elements which are drawn first can be come partially or fully covered by other elements. More on this on Kosmos Layering.

Performance Considerations

In order for Kosmos rendering engine to draw as quickly as possible, following things should be avoided, especially when rendering a large OSM data set:

Limitations

The rendering engine has certain limitations, most of which stem from the fact that it uses .NET GDI+ for rendering. Also, since the engine is still in development, there will be continual improvements.

The limitations are:

Things still to be done:

Links

Personal tools
Namespaces
Variants
Actions
site
Toolbox