Talk:Kosmos/Rendering Help

From OpenStreetMap Wiki
Jump to: navigation, search

Unicode in Rendering Rules

I'm looking for a way to use unicode-characters in Kosmos Rendering Rules. As soon as I use non-ASCI-characters I get an error. How can I get Kosmos to work with unicode? --Zaŝa 12:07, 4 August 2009 (UTC)

Can you give me an example of such a rule? --Breki 18:01, 4 August 2009 (UTC)
Take a look at this:ŝa/festo#Esperanto

If I remove the ĝ in renkontiĝo the rule works just fine only with this letter I get problems. Then I thought it may be is this quite uncommen letter which is only used in the esperanto language and tried the same with a more commen non-ASCII-letter (the german ä) and it didn't work either. BTW adding this tag to the OSM Database works just great.

Yes, looks like non-ascii chars are a problem with the current implementation of Kosmos (I use regex, so this could be a culprit). I'll address this problem in Kosmos v3. --Breki 12:30, 12 August 2009 (UTC)

One more question: Works the * as a wildcard so that it shows all tags listet no matter what value this tag has?

From what I rememeber, this should work. --Breki 12:30, 12 August 2009 (UTC)

--Zaŝa 19:47, 5 August 2009 (UTC)

Text labels in areas

Is there a way to show text inside an area? I would like, for instance, to show the name of a park.
I tried

ParkText || {{IconArea}} || {{tag|leisure|park}} || Text (MinZoom=14, Color=black, TagToUse=name, FontName=Arial, FontStyle=regular, FontSize=14:8;17:10)

but it renders the text along the polygon.

--Zorko 21:07, 3 January 2008 (UTC)

Version 1.1 now has this feature, I added a new rule as a reference on how to do it:
SchoolText || {{IconArea}} || {{tag|amenity|school}} || Text (MinZoom=15, Color=black, TagToUse=name, 
FontName=Times New Roman, FontStyle=bold, FontSize=15:6;17:10, TextMode=AreaCenter)
--Breki 16:52, 4 January 2008 (UTC)

Complex expression

Hi, can you explain the feature "Complex expression" a little bit more? I am not able to understand it at the moment :) What I would like to achieve (as an example, i got more of these, but I think this one is known nearly everywhere): amenity=fast_food ; name=McDonalds should get a nice yellow M on the Map, name=Burger King should get their logo and every other fast_food should get a general logo. Is such thing possible? What does the functions "IsTaggedWith" and "ValueNum" deliver and what do they expect? Does IsTaggedWith only search for fast_food or for amenity? Great software btw :D --ernie_hh 02:11, 13 January 2008 (UTC)

Well, complex expressions are a bit experimental at the moment :). I have just added a section on complex expressions syntax. As for your case, it is possible, but it will be very slow (because the 3rd library Kosmos uses for complex expressions evaluation is slow and your rule works on nodes). So I recommend that you wait for a new version of Kosmos, which will have a simpler way to achieve what you're looking for. --Breki 08:33, 13 January 2008 (UTC)
The new version is here... check out the Wiki page, I've added an example relevant to you ;). --Breki 10:27, 13 January 2008 (UTC)

Aligning node labels

Howth harbour

Is there a way to align or offset the label on a node? I have some labels appearing on top of their icons, and I'd like to move the labels off to one side? Ojw 13:25, 7 April 2008 (BST)

TextLineOffset allows you to specify a vertical offset relative to node. It should he good enough to fix the lighthouse and buoy labels in your map on the right. --Stefanb 15:06, 7 April 2008 (BST)
Thanks. Sample output on right. Ojw 13:02, 9 April 2008 (BST)

Icon URLs

Would it be possible to have the icon URL modified using some tag in the OSM data? Ojw 13:07, 9 April 2008 (BST)


Yes, something like this should be possible. Once I get the Kosmos in a running state... currently there's a lot of scaffolding around the code, so a new version will probably not be available very soon. I've added this to the todo list. --Breki 20:11, 9 April 2008 (BST)

IconURL limitations?

I've been having some problems using icons - the example here works fine as icon. But a file:// URL causes a crash. And an icon I tried from hosted on my website just wasn't displayed.

Are there any limitations on iconURL we should know about? e.g.

  • only certain types of URL? (http:// or file://)
  • can it handle transparent PNGs?
  • Any file size restrictions?
  • Any PNG compression restrictions?
  • Any colour depth restrictions?
  • Any limitations on characters in the URL? (spaces, escaped characters, etc.?)

Ojw 13:12, 10 April 2008 (BST)

I'm not aware of any restrictions, the question is where the error occurs: during icon loading or drawing. Can you post the actual error you get? --Breki 20:10, 10 April 2008 (BST)
"Format exception: Input string was not in a correct format" for
| Lighthouse || {{IconNode}} || {{tag|man_made|lighthouse}} || Icon (MinZoom=10 iconUrl= Width=12:5;17:20)
Just to make sure: is this the exact string? If it is, you forgot commas:
| Lighthouse || {{IconNode}} || {{tag|man_made|lighthouse}} || Icon (MinZoom=10, iconUrl=, Width=12:5;17:20)

--Breki 06:45, 13 April 2008 (BST)

I tested Kosmos with your icon and it works fine. So it must be commas :). I'll make improvements on error handling and reporting when parsing rendering rules in the future. --Breki 07:21, 13 April 2008 (BST)

I tested Kosmos with IconUrl=file://E:/fastfoodnode20.png - before that i copied the icon on my harddisk named E: - and it works fine.. --ChrSchultz 20:44, 13 October 2009 (UTC)

Halo effect

How to do a text with a halo effect (mapnik like white border around text)?--Walley 19:23, 25 April 2008 (UTC)

Halo effect is currently not supported, but I have it on my todo list for Kosmos. Once I get the GUI redesign over, I'll add some of these new rendering features. --Breki 15:44, 26 April 2008 (UTC)
Can you do it with a large white label under a smaller black label? Ojw 19:22, 26 April 2008 (UTC)
Hmmm I doubt the result would be good enough, since halo effect is usually done differently (each character separately). --Breki 18:47, 27 April 2008 (UTC)


Hello Breki,

following the link you posted on your website I will (hopefully correctly) ask my questions here again - one by one ;)

• Rendering rules specification to be slightly improved: The Wiki help about the rendering rules does not completely / clearly explain the syntax in my eyes. Okay, I had the 1.09 version before (which failed when I tried to use it in 1.12), and the current one at least shows now what is ment by “tables”. But I miss an example for comments - are they only possible between tables? Apart from that the header structure and function is not described (although latter is nearly self explaining).

As far as I remember, everything in between wiki tables is ignored by Kosmos, so you can put anything there.

• Color of map background: The header is part of the second question: I thought and hoped that the background-color statement describes the background of the map. But now I recognize that it´s part of the according table only. So I expect that it´s not possible to specify the map background at the moment, is it? That´s a pity because I would like to have a different background than #F8F8F8 ;) Maybe this could be incorporated into the rendering rules file as well.

Yes, this is a limitation: you cannot specify the background and sea colors. I will fix this in next releases.

• Labeling: In my map section there are several buildings which are labeled with “yes” ... This question I could answer myself meanwhile. I had used a disadvantageous example map, and I thought, the renderer had an oder issue. But one side questions remains:

• "yes" or "true"? By the way: Sometimes I find “yes”, sometimes “true” as boolean value. Which one is correct, or can I use both according the the OSM specification (resp. does Kosmos accept both)? I mean tags like “oneway” or “no exit” for roads.

This is not a Kosmos issue, Map Features specify that you have to use "yes" and not "true". So I guess you can either correct the tags in your area or add additional rendering rules to cover the "true" value. Putting additional logic into Kosmos which will treat yes and true as same is out of the scope of Kosmos, in my opinion. There are just too much similar "special cases" to cover: Kosmos would then become too entangled into a tagging scheme, which is changing all the time anyway (not to mention multilanguage support for such special cases). I want to keep a right balance between simplicity and usability in Kosmos.

• Optional street name shortening: Suggestion: I don´t know if you can detect whether a street name fits or if it´s too long. Probably not at the moment. But if so (in future), you could implement a kind of “shortening lookup table” for standard name parts. In German for instance “Hamburger Straße” could also be written as “Hamburger Str.”. Same applies to “Hamburger Platz” which would be “Hamburger Pl.”. The table could contain all relevant international expressions and help labeling streets which are very short or narrow to each other.

My answer is similar to the above, with one additional consideration: calculating the optimal "version" of the name is very CPU-intensive and would slow down the rendering. I'm very cautious when adding such features in Kosmos, which is primarily oriented towards interactive (=fast) rendering.

An additional "alt name" tag or something would also be imaginable which would be used as alternative in case of a narrow situation detected by the renderer.

Aren't there tags for abbreviated names in OSM? Kosmos already supports tag fallback (Kosmos_Rendering_Help#Text_Template_Parameters), so you can use this to achieve similar result.

• Label positioning: This is not an easy one because it´s difficult to keep such modifications from data version to data version (because point IDs could change): But sometimes you wish that you could tell the tool that the name of a pub or something shall appear above the symbol instead of below. Even more difficult: To be able to assign an offset (even depending on the zoom scale) to such symbols in order to prevent overlays or too big gaps to other elements. Only a thought … ;)

This will be added soon.

• Label positioning improved: I want to draw a PSV map of my town, so I need to position the names of train-, bus- and tramstations very exactly. positioning not only vertically, but also horizontally and not to forget rotating would be essential, since there are exactly 453 stations in town... RalpH himself 22:31, 24 November 2008 (UTC)

• colour from tag: again drawing the psv-map: the tram lines have different colours, so for an optimal rendering it should be possible to get the colour of the rendered line from a tag within the relation/route. RalpH himself 22:31, 24 November 2008 (UTC)

• boxes showing the bus-/tramnumbers: On these coloured lines, I'd like to see some tiny little boxes saying the bus-/tramlines going along that route (like it is already with the important streets, e.g. ref=*). Probably even in the same colour as the line is already (see above) ;) RalpH himself 08:13, 25 November 2008 (UTC)

• same line, drawn side by side: the last one: several tram-/buslines on the same route should be drawn side by side, instead of on top of each other. Any suggestions? (by the way, that's what it looks by now: [1] - and what it should be kind of: [2] RalpH himself 22:31, 24 November 2008 (UTC)

• Close dead-end streets: At least in the standard configuration dead-end streets are "open", thus there is no closing border like in most other maps (like from Mapnik and Osmarender). I like the rounded style but also the straight one Osmarender uses if the road ends in the middle of nowhere. Maybe there´s already a "closing" option, maybe even with the choice between both styles, but I haven´t found it yet.

Yes, this is a known issue. The problem is the GDI+ library Kosmos is using to draw the map. I'll try to address this in future releases.

• Traffic lights: There´s very often a collision between traffic lights and street names. Maybe the same applies to other items which are directly connected to "highways" like bus stops or train stations. Is there a chance to optimize the rendering in order to prevent such collisions? Maybe by splitting the name using spaces like "Hamburger ooo Straße" or even by separating like "Ham- ooo burger Straße" (ooo is the traffic light symbol)?

Huh, this is out of the scope of Kosmos - see my other comments. For a professional-looking map you always need a human intervention to clean up things. I think Osmarender is more suited for this, since you get a SVG output file which can be edited by drawing SW. Maybe in some (distant) future Kosmos too will be able to produce SVG output.

Please take the above suggestions as result of a kind of "fresh eye review" or "brain storming" but not as order of features ;)

Suggestions and critiques are always welcome :)

Best regards, Kristian

PS: Maybe it´s a good idea to use following 0s in the zip file names in order to "correct" the order of the files in the listing ;)

Yes, that would be good. I'll try to fix my build script when I have the time. --Breki 14:05, 27 May 2008 (UTC)

PPS: Your link contained a comma at the end of the title ... :( Can this be removed somehow? Only a cosmetic item ...

•Child : What do I have to change to render unclassified highways narrower when lanes=1 ? (it seems to work but I think both are drawn) ...

Child templates do NOT exclude any parent templates. So you need to move the "Polyline (MinZoom=11, Color=white, BorderColor=red, Width=11:1;13:3;17:14)" to a separate child called ".*" ("everything else"). See KosmosStandardRules#Highways for example (HighwaySecondard and its child rules). --Breki 15:37, 18 June 2008 (UTC)

Corrected and it works ... Thanx --PhilippeP 06:56, 19 June 2008 (UTC)
Rule Name Targets Selector Template Options Comment
HighwayUnclassified Way highway=unclassified Polyline (MinZoom=11, Color=white, BorderColor=red, Width=11:1;13:3;17:14) EliminateSeams
.HighwayUnclassifiedLanes1 lanes=1 Polyline (MinZoom=11, Color=white, BorderColor=red, Width=11:1;13:2;17:8) EliminateSeams
Rule Name Targets Selector Template Options Comment
HighwayUnclassified Way highway=unclassified EliminateSeams
.HighwayUnclassifiedLanes1 lanes=1 Polyline (MinZoom=11, Color=white, BorderColor=red, Width=11:1;13:2;17:8) EliminateSeams
.* Polyline (MinZoom=11, Color=white, BorderColor=red, Width=11:1;13:3;17:14) EliminateSeams


Wer kann diesen Artikel in Deutsch übersetzen? Danke, --Markus 09:10, 17 February 2009 (UTC)

bin dabei --ChrSchultz 22:22, 9 October 2009 (UTC) erledigt --ChrSchultz 10:28, 15 November 2009 (UTC)

Questions regarding TextMode=WayCenter

Am I right, that the above mentioned attribute is not really centering the text along a path or way, but counts the number of nodes inside and then selects the one most in the middle?

I am asking because I modified a style for rendering Airport maps ( to show labels on taxiways and runways and I recognized that on two node ways (a short taxiway link), the box is placed near to one end, not in the middle of both nodes.

Example of an edited AirNav Style

I understand it is not easy to calculate the middle of a curved path with a lot of nodes, but is it possible to modify the mechanism that it calculates the middle of the 2 middle nodes if you are having an even number of nodes instead of taking one of them? TobiBS 09:21, 23 May 2009 (UTC)


Is it possible to generate a text combined from several tags? I know it is possible to align them above each other, but I would like to combine for example a number from the tag with a unit from an other tag or with static text. Is this possible in any way? TobiBS 10:17, 25 May 2009 (UTC)

It is possible to get text for lables from ref-tag in relations...

the tags of the highway are:


is it possible to get the reference from the second relation? Thanks --ChrSchultz 20:17, 24 September 2009 (UTC)

Capitalize text

I would like to ask for another feature, should be easy to implement: Is it possible to make a name for a tag in capitals only? That is an often used technique in maps, for example to show the size of a town. TobiBS 09:44, 26 May 2009 (UTC)