From OpenStreetMap Wiki
Jump to: navigation, search

General Discussion

When generating map tiles for use as overlays, a lot of the pngs generated are fully transparent with no data. Is it possible to add an option where only tiles that contains data will be output as png, and tiles that are fully transparent that has no data will not be output at all. --[User:aircow33]

In general this can be done, but there are two issues with this:
  1. The only way for me to know the tile is really empty is to check that after generating, all of the pixels are set to the background color. This would mean a certain slowdown of tile generation
  2. Empty sea tiles: these will still have to be generated, since if they are missing, you won't be able to know if the missing tiles cover land or water
I'll try to add the support for this in the future --Breki 08:29, 29 August 2009 (UTC)

Hi Breki, I know in GDI+ there is are compound pens that makes drawing parallel lines very easy. Do you think you will add support of parallel lines support for Polylines in Kosmos?

Hi... I haven't even known about compound pens, thanks for pointing this out. I will definitively try to include them in the new Kosmos v3 code, since they look very useful for mapping purposes. --Breki 16:45, 26 August 2009 (UTC)

I can't see any license mentioned. But then again I can't see the source either so I assume it is closed source but free to use?

It's not closed source, I was just too lazy to write a source code export script from my two SVN repositories :). I have it now, the source will be published together with the new 2.1 release (probably today). The Kosmos license file is in license-Kosmos.txt .--Breki 05:13, 18 July 2008 (UTC)

Hi Breki, can you please tell me what particular Development environment you use, w/any applicable DDK or other packs needed, version numbers, etc. to compile the source here? :) :)

I'll write this on the Kosmos Development page soon. --Breki 06:38, 27 July 2008 (UTC)

Breki, I really enjoy working with Kosmos ALOT, I find the development interfaces are very good and easy to use. But I am facing a rendering concern. When I display maps, the street ends are cut-straight off when they terminate. Please have a look at all streets are rounded off when they terminate. :)

Yes, this is a known issue with Kosmos rendering. This is due to the way how the GDI+ draws lines and I haven't found a good (=easy) way of dealing with it so far. But it is on my todo list (and also listed here: Kosmos_Rendering_Help#Limitations) so when I get the time to deal with this, I'll try to fix it. BTW: Mapnik and Osmarender deal differently with this issue - Mapnik rounds the end, Osmarender makes a rectangular cut. --Breki 12:29, 6 August 2008 (UTC)
I am glad you are already aware of it! :). I think the rounded ends are most easy on the eyes, just my opinion there..... :) I hope to have this issue fixed in a future edition. Have a great day! Best wishes, Paula. --PaulaA 14:29, 6 August 2008 (UTC)

Hello Breki, I have to totally agree with the other posters on the text issue, .. I am always finding myself rendering maps... even at close-up, where street letters appear to collide with each other and jam together...., and so those letters sometimes makes it almost impossible to read, or (unless you crane your head in funny directions ;]) to read the names easily. Generally it looks OK & good on straightaways, but when the letters flip totally upside down or at opposite 45 degree angles against each other, this is the readability issue. Just wanted to let you know. Best wishes & great product!! Please keep it up! --Pete67 11:47, 3 December 2008 (UTC)

Thanks for the support, Pete. As for the letters issue (and other rendering issues) - I understand your problems and I'm trying to fix at least some of them. But the general problem is that the step from the rendering quality like it is now to some sort of "professional" map rendering quality is a huge one - both in terms of the effort needed to program it and in terms of computer processing power needed to draw such maps. Unfortunately I'm not doing this for my living (I would like to :) ), so the time available to develop new features in Kosmos is limited - and there are a lot of "todo" things on my list. So I always try to assess the usefulness of a feature compared to the effort needed to develop it. And I also have to take into account the fact that Kosmos renders maps interactively, which means that adding a feature that could greatly slow down the drawing speed can be a problematic thing. But I will try to improve on these things as times go by - you'll have to be patient, I'm afraid ;). --Breki 15:14, 6 December 2008 (UTC)
Thanks Breki so much, I imagine you are very very busy like I am. Just my 2 pennies worth to further explain what I seen: perhaps some kinda switch could be developed at runtime, so a command line like Kosmos.Console -render quality(x), might activate the heavy lifting portions like what you speak of, ... that is if it takes many seconds/minutes extra to run. I hope you at least consider tackling some of the rough edges in the drawing renderings!: but overall it is already pretty darn professional looking in my book. I guess when you look at the pictures of the streetmaps posted here before side by side showing some of the glitches, u start to notice things like end-streets not being finished drawn, and those letters turning around etc. But one thing at a time I guess ;) THANK YOU SO MUCH & happy holidays, and times & thank you for your time on this great product. Bye, Pete :))) --Pete67 7:32, 18 December 2008 (UTC)

Relations Support

Good to see relation rendering support in 2.1. However, is there any way we can do a Text Template rule where the TagToUse can refer to a tag of the Relation itself rather than a tag of the underlying Way? --Morb au 17:34, 20 July 2008 (UTC)

Hmm... good question. Unfortunately that's not so easy to implement with the current system - there is no way in the rules to distinguish between name=* (example) for the relation and the same tag for its members. I'll add this to the todo list, thanks for mentioning. --Breki 18:37, 20 July 2008 (UTC)

Bug Reports

When starting Kosmos.Gui.exe from the unpacked I get the following error message:

System.ArgumentException: Illegal hotkey 'Ctrl+N'.
  bei BrekiViews.WinForms.WinFormsMenuItem.set_Hotkey(String value) in d:\MyStuff\BuildArea\Sandbox\BrekiViews\trunk\source\BrekiViews.WinForms\WinFormsMenuItem.cs:Zeile 107.
  bei BrekiViews.Framework.MenuBuilder.Hotkey(String hotkey) in d:\MyStuff\BuildArea\Sandbox\BrekiViews\trunk\source\BrekiViews.Framework\MenuBuilder.cs:Zeile 76.
  bei Kosmos.Gui.KosmosGuiModule.OnLoad() in d:\MyStuff\BuildArea\Sandbox\OsmUtils\trunk\Kosmos.Gui.Controls\KosmosGuiModule.cs:Zeile 171.
  bei BrekiViews.WinForms.ApplicationShell.LoadModule(String moduleName) in d:\MyStuff\BuildArea\Sandbox\BrekiViews\trunk\source\BrekiViews.WinForms\ApplicationShell.cs:Zeile 113.
  bei BrekiViews.WinForms.ApplicationShell.Initialize() in d:\MyStuff\BuildArea\Sandbox\BrekiViews\trunk\source\BrekiViews.WinForms\ApplicationShell.cs:Zeile 82.
  bei BrekiViews.WinForms.TdiShellForm.OnLoad(EventArgs e) in d:\MyStuff\BuildArea\Sandbox\BrekiViews\trunk\source\BrekiViews.WinForms\TdiShellForm.cs:Zeile 565.
  bei System.Windows.Forms.Form.OnCreateControl()
  bei System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
  bei System.Windows.Forms.Control.CreateControl()
  bei System.Windows.Forms.Control.WmShowWindow(Message& m)
  bei System.Windows.Forms.Control.WndProc(Message& m)
  bei System.Windows.Forms.ScrollableControl.WndProc(Message& m)
  bei System.Windows.Forms.ContainerControl.WndProc(Message& m)
  bei System.Windows.Forms.Form.WmShowWindow(Message& m)
  bei System.Windows.Forms.Form.WndProc(Message& m)
  bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
  bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
  bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

David Schmitt 20:14, 7 July 2008 (UTC)

Huh, that's odd. Are you using German Windows, by any chance? --Breki 20:37, 7 July 2008 (UTC)
Yeah, a German Windows Vista David Schmitt 13:23, 8 July 2008 (UTC)
Fix: --Breki 15:46, 8 July 2008 (UTC)
2.0.508 works for me, thanks a lot for this awesome piece of software! David Schmitt 18:39, 8 July 2008 (UTC)

Loading Rendering Rules

Hi Breki, thank you for this great program! But, I am having a small roadblock, maybe you can see what I am doing not correct or what I can do. I am using the Console to generate a map on a offline computer designed for this purpose. However, I keep getting ERROR: Could not load rendering rules. I can see in the messages it is trying to connect with a outside IP. But what is strange is, I do have the Default rules in the directory, so I guess I don't really needed to connect to the IP which I hope I don't have to do each time. I guess you call them Cache Rules. But, If i load the same project in the GUI version, I get a slightly difference experience, ... it says "The rendering rules could not be loaded. A cached version of the rules is used instead". So, how do I get the Console to load rules on the local machine? :) I am so confused :( Thank you for any assistance & I am in love with this program and eager to make this work!!

This rendering rules loading logic has given me a lot of pain lately :). I've added the caching logic to the GUI, but looks like I forgot to add it to the console. I'll fix this and release a new package in a day or two. Thank you for reporting this! --Breki 07:11, 20 July 2008 (UTC)
Great Breki! It would be really nice if you made some command line switch for expressing where the location of the rules file was, or to override just to use Cache rules.... for those of us running Kosmos in a Intranet style fashion. This way, the program does not perform unnecessary transactions with Firewalls each time the command line is run. Or maybe better yet (idea), just implement a special command line switch which can say please use location C:/xx//- (i.e. Default/Cache rules), thereby overriding the connection with wiki. to grab rules. This would be so perfect & nice to streamline it down this way for us power users. :) Thank you so much for listening!!
Well this has always been possible. Simply open the project file (.kpr) in a text editor and edit the RulesSource/WikiPage tag to point somewhere on your disk. Or even more simple: open the project in GUI and edit the properties of the project :) --Breki 08:52, 20 July 2008 (UTC)
Ah, Thank you, .... have a very nice day. :)

Dear IgorbreJc: Are there any hidden features or ways to make rendered maps of varying quality or smoothing levels? Thank you so much.

Other than switching to "high-speed mode" in GUI, there aren't, I'm afraid. The default mode uses the highest quality I could achieve using C# GDI+ library. --Breki 20:39, 3 March 2009 (UTC)

rules tracktype and access

I like Kosmos very much, especially since T@H is stalling at the moment ;-). What i miss for the moment are rendering-rules for "access" (permissive/private/no) for highways and areas. different line-types (or even dot-lines like mapnik) for tracks (tracktype=grade[1-5]) would be great. ---jha- 23:09, 28 July 2008 (UTC)

If you really want this rules I suggest you create a separate rules page and play around with creating them yourself (see Kosmos_FAQ#How_to_use_rules). I'm not sure these should be in the "general purpose" rules, but if they don't clutter the map too much, we can add them there. Let me know of your results --Breki 05:41, 29 July 2008 (UTC)

Download Site down

I cannot reach the download site, trying since yesterday. Has anyone an alternative download link? --Maik 21:10, 3 November 2008 (UTC)

transparent tiles

Is it possible to render tiles transparent in kosmos.console? Or add this feature?--Walley 13:46, 29 December 2008 (UTC)

Yes it is, I've added Q/A to the FAQ page: --Breki 16:00, 30 December 2008 (UTC)

rendering modes/quality

Hi Breki, just wondering if your next version will incorporate any extra quality updates mentioned on this Wiki, to Kosmos methods or ways that OSM maps are rendered :) I see some fancy ways I can use this but would LOVE to have more control over the quality output (for fast maps with very basic rendering)... or higher quality "luxury" with all the bells and whistles, ... such as extra quality or details? Like smoother streets, names, ... i.e. more control for us end-users? :) Enjoy your product! Keep it up.

Much of it depends on the graphics libraries I am able to use: GDI+ (and now also Cairo). These are quite low-level regarding any mapping applications, so any special "bells and whistles" I have to implement myself, which is not a small effort. Drawing street names, for example, was quite a feat, especially since I didn't want it to slow down the map rendering too much. I'm constantly trying to improve stuff (see But, as already I said a few times, to get Kosmos to some sort of a professional level of rendering, this would have to become my day job. Unfortunately, it isn't yet :) --Breki 20:06, 23 March 2009 (UTC)

Cross Platform

Could it be an idea to try to rewrite Kosmos so that version 3 becomes cross platform complient? I need a Mac or Linux version to be able to use it, and because of various licensing issues would prefer not to use mono. --Skippern 19:49, 18 April 2009 (UTC)

This would probably mean rewriting it in Java. To be frank, this is not something I myself would do, for several reasons:

  1. I'm not proficient in Java and Java 3rd party libraries. I would have to invest a lot of my free time to get up to speed with Java, since in my professional life I work in C#.
  2. All of my own libraries (on which Kosmos depends) are written in C#, so this would mean an additional effort of porting them into Java.
  3. I doubt the similar rendering speed could be achieved using a cross-platform technology. So it means sacrificing usability for portability, and this is a big motivation killer for me.

Since the Kosmos code is open and its license is (currently) BSD, if there are brave soul(s) who want to make a cross-platform software out of it, they are welcome. But I think it would be better to invest time in extending existing cross-platform SW like JOSM instead of doing it from scratch. --Breki 14:14, 19 April 2009 (UTC)


Which is the latest version that works with .net2? I have w2k, no WinXP, so... no .net3.5 available. -- Smial 22:13, 27 August 2009 (UTC)

Huh, to tell you the truth, I don't remember, but I guess the 2.4x versions should work for .NET 2.0 --Breki 08:32, 29 August 2009 (UTC)
Thx, I once used 2.1.21 for some example maps for wikipedia, and never again later. We'll see :-) -- Smial 19:38, 30 August 2009 (UTC)


Moved page to Maperitive as Breki has changed the name of the Kosmos project. I will go through the article to update it to the new name but for now I suggest we leave the word Kosmos in the names of the rendering rules pages for legacy reasons. Alex McKee 06:57, 18 February 2010 (UTC)

Alex, I think this renaming is premature for two reasons:
  1. I haven't yet released Maperitive - so Kosmos is still the "official" name
  2. The old versions will still be called Kosmos (obviously). Maperitive represents a "next generation" of this software. I think the documentation for the old version should stay in Wiki for at least a few months, until Maperitive totally replaces Kosmos' functionality. So there should be separate pages for Maperitive (since it will be noticeably different from Kosmos in terms of user interface.
Regards, --Breki 15:36, 18 February 2010 (UTC)
OK I've moved it back. Also created a stub page Maperitive -- Harry Wood 15:57, 18 February 2010 (UTC)
Maperitive's discussion page also redirected here. I've removed that too Seventy7 21:04, 22 March 2010 (UTC)