Talk:Kosmos/v1.x

General Discussion

Bigger areas

Maybe if you would use an binary protocol Kosmos might be able to render bigger area. Navit use some kind of binary format and is able to render on the fly the whole of Europe from one file. The developer on pyroute seems to be working on an binary format as well . Also there is this page OSM_Mobile_Binary_Protocol

--Skywave 17:54, 20 January 2008 (UTC)

XML files are used in Kosmos for one practical reason - you can edit the data in JOSM and look at the results in Kosmos. And anyway, the issue XML or binary is not the real problem with large areas. In order for Kosmos to be able to draw a large area map in one screen, it has to process all of the data for that area. Currently all of the data is loaded into memory (as binary data, off course) and then processed in-memory, so memory sets the physical limit of the area that can be covered. I am thinking of using some other means for this (a compact client-side database like SQLite, for example), since then the data could be stored on disk and queried using SQL. But this will have to wait, since I have lot of other things to implement first. Thanks for suggestion, though. :) --Breki 20:35, 20 January 2008 (UTC)

License

Just a note to mention that Creative Commons licenses are not suitable for software releases for example, it does not protect you (the author) against people claiming damages from using Kosmos. --Edgemaster 18:26, 14 January 2008 (UTC)

Huh, I didn't know that. Looks like I'm going to have to find another type of license, thanks for the info. --Breki 20:57, 14 January 2008 (UTC)

Reliefs And Transparency In Tiles

It would be nice to have

• Shaded relief also rendered to tiles
• Transparency support for the rendered tiles (transparency defined in rules)

--Stefanb 12:49, 15 January 2008 (UTC)

Shaded relief in tiles are already on my todo list. As for transparency, you probably mean support for multiple layers in slippymap? There is a problem with this: when drawing relief in Kosmos GUI, it is actually "inserted" in between other map layers. So it is drawn (transparently) over polygons (land areas) but under the highways (which are not transparent). That kind of layering will be difficult to achieve in slippymap: you would probably have to generate at least three different sets of tiles. But I suppose it's not impossible, so I'll add it to the todo list. --Breki 19:35, 15 January 2008 (UTC)

PNG (unlike GIF) supports various transparency/opacity levels, so the forests (and such larger areas) could be made slightly transparent to show the relief/topography layer underneath it. --Stefanb 14:06, 16 January 2008 (UTC)

Yes, I tried this already when I was implementing shaded relief. Kosmos already has a transparency capability (well, it isn't documented yet): you can set the color of a template using ARGB format. Example #8099DB9C would render half-transparent green color. The problem with this alpha-transparency is that it makes the base color lighter. That's why I used a different approach in shaded reliefs: only black color with varying levels of alpha is used for shading pixels. --Breki 16:13, 16 January 2008 (UTC)

• maybe empty "transparent or colored shaded relief tiles only" should be enought --Dido 11:24, 16 January 2008 (UTC)

Kosmos OSM And Relations

Basically, the issue is what to do with OSM relations in Kosmos: obviously, for special relations like multipolygon a custom logic should be implemented in Kosmos to handle them. But what about relations in general? How to extend the existing Kosmos rendering rules system to include relations? Since Kosmos is all about simplicity (well at least I think it is ;) ), this extension should be simple to use --Breki 08:33, 20 January 2008 (UTC)

Wishlist

Skywave:

• Support for route relations (bicycle routes, cycle routes etc etc)

This will be implemented soon.

• Support for GPS (small arrow on GPS location or something and ofcourse logging)

Currently I'm not planning to integrate live GPS tracking into Kosmos, so this will have to wait for a while. I will however add displaying of GPX data.

UPDATE: Kosmos 2.0 will display GPX files and will be able to download GPS data directly from GPS modules. --Breki 13:16, 15 May 2008 (UTC)

• Making it more simple to create custom maps by creating colour selector in the OSM object inspection tool to make it really easy to support the selected object without messing in the stylesheet.

Editing of rules directly in Kosmos is on my todo list, but it's not a top priority, since it requires a lot of GUI work.

• Support for tunnels and bridges

Hopefully this will be implemented soon.

This things looked nice to me, so i though why not write them down. Great work though ! --Skywave 11:06, 3 February 2008 (UTC)

Thanks --Breki 17:42, 3 February 2008 (UTC)

Bener:

• I would like to see a possibility to export digital images with implemented georeferencial data, for example geoTiffs. I don´t know how, but I think a change of the bitmap-export-funktion must bring results. Calibrating maps manually is not exact enough and costs plenty of time. You would help many users of GPS-devices that uses non vector type maps. This is the only major thing i miss in your great Kosmos!

If I can get a hold of a 3rd party library that can do this, I could integrate it into Kosmos. Otherwise this will take time and I have a lot of other features I want to implement before georeferencing.

Would this help you? GeoTiff--Bener 22:19, 12 February 2008 (UTC)

Not really, but something here might :) : http://www.google.si/search?q=geotiff+c%23+library&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a --Breki 06:06, 13 February 2008 (UTC)

I like the idea of georeferencing Image Output. This would be a great way to say for example render a set area to use a map background in any GIS. How difficult would it be to implement export not only as GeoTiff, but also as georeferenced ECW and/or Jpeg2000? --Petz 10:38, 13 February 2008 (UTC)

To Bener,Petzl: I understand your wishes and needs. But when deciding what features to do first I have to balance the general usability of a feature with the effort needed to implement it. Meaning that a feature which is usable and interesting for lots of people and does not take too much time to implement has a higher priority than a feature that needs a lot of work and is only applicable in some cases. If I have to implement writing of GeoTiff or something else by myself, then this feature will have to wait, since there is a lot of other work in Kosmos which needs to be done. If you have any programming experience in .NET you can help even by investigating if there's an opensource .NET library for georeferencing. Here's one lead: http://trac.osgeo.org/gdal/wiki/GdalOgrInCsharp --Breki 12:44, 13 February 2008 (UTC)

And here's one good article I found: http://www.codeguru.com/cpp/g-m/bitmap/viewers/article.php/c9187/ --Breki 13:14, 13 February 2008 (UTC)

I'd like to add one more voice for the georeferenced export. Since your application makes it rather easy even for inexperienced people to render their own maps, the option of creating georeferenced tiles (say, TIFF with TFW or alike) would be very welcome. I currently have stitched Kosmos tiles together 5x5 and am trying to find a way to calculate the TFW contents for them. --Alexander Folkers

I agree, I'll try to add TIFF+TFW support before the first release of Kosmos 2.0 (both exporting and importing). Later I'll try to add support for GeoTIFFs too. --Breki 13:16, 15 May 2008 (UTC)

• I have to add: Will you sometimes implement Srtm2OSM into Kosmos?

Yes, it will be added, hopefully soon. Although contours will probably be rendered directly on maps and not as OSM ways, to enhance performance.

UPDATE: this is already finished, will be available in Kosmos 2.0. --Breki 13:16, 15 May 2008 (UTC)

• Will it be possible to create new projekt-files not manually but out of Kosmos?

That too... Kosmos 2.* will have MDI style user interface which will allow this and other stuff. --Breki 20:49, 12 February 2008 (UTC)

--Bener a few minutes later, 12 February 2008 (UTC)

• Will it be possible to Export bitmaps from the Console command line?

It will be possible in some future release of Kosmos, once I finish all the stuff I'm now working on --Breki 20:12, 21 May 2008 (UTC)

~Fantastico!

JudyC08: Hi, it looks like this was basically asked, but do you know if Kosmos will be able to do any Console Command-Line extraction commands for rendering of maps, right out of the box, from compressed osm_data.bz2 files, instead of just rendering the entire OSM file at once? ... i.e. specifically based on Bounding Box (N-Top/S-Bottom/W-Left/E-Right) cords. inputed? I think that would be -most- excellent & superb to work that way with any grace & ease! :) The present tools on windows are very crude and difficult to use, and require too much overhead, like Java5 based Osmosis for this particular purpose to extract sub-slices from larger OSM files :)

Judy, I think for really large files Osmosis is still the best option. Extraction of content is not so simple as it looks, you still have to understand the data inside and extract it appropriately (relations -> ways -> nodes). I haven't used osmosis much myself, but I know that it's very useful tool to many people and I frankly I have more than enough of other stuff I want to implement in Kosmos without replicating osmosis functionality. What I could do in the future is to use osmosis as an external tool for certain operations (including the one you described), so you won't need to remember all those command line switches ;). --Breki 16:49, 17 June 2008 (UTC)

• Is SVG vector format exporting possible? :D

Currently no, I need to find a good SVG .NET library and some free time to do it. --Breki 15:31, 18 June 2008 (UTC)

Hey that is cool!... will SVG exporting require .NET on my client machine? Because I work unfortunately in a very highly resource controlled, X64 machines cluster enviro. It would be quite nice not to have to install .NET anywhere. :) If that is possible. SVG even with .NET if required would be a sheer breakthru. I think VB supports SVG exporting routines without .net? I may be wrong

Well since the whole Kosmos is written in .NET technology (C# to be precise), I think you'll need .NET :) As for SVG support, there are some libraries out there but as I said, my free time is limited, unfortunately. I'll try to add SVG in next few months. --Breki 15:39, 19 June 2008 (UTC)

OUTSTANDING, I think SVG would enable highly scalable maps for everyone in a open standard non-proprietary format :) :). BTW, I must have .NET already installed then on my production machines because Kosmos does run perfectly.:)

Reported Bugs

--Singastreet: Hello, I've just used it. Very impressive... and it allows instant gratification :-). BTW, I notice that it does not render the sea / ocean. How can this be rectified? You can refer to the attached Singapore map. Thanks -- Singastreet 06:12, 10 January 2008 (UTC)

Yes, currently sea is not rendered as a polygon. The problem is that seas and oceans are too big to be treated as single closed polygons. Instead, only the coastline polylines are stored in OSM data and these are broken into many pieces. This makes rendering of sea harder than simple areas (like forests, for example). The problem is compounded by the fact that Kosmos works on cut-outs of OSM data, not the whole world, so there is an issue of what to do if coastline is missing in some parts. When I have the time, I'll try to implement a special template for sea rendering. --Breki 17:46, 10 January 2008 (UTC)

---

I am trying to render a 7MB OSM file and I get the following error:

ERROR: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index

************** Exception Text **************
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
   at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
   at System.ThrowHelper.ThrowArgumentOutOfRangeException()
   at Kosmos.CoastlineProcessorPlugIn.Run(OsmDatabase osmDB, IMapPainter mapPainter) in d:\MyStuff\BuildArea\Sandbox\OsmUtils\trunk\Kosmos\CoastlineProcessorPlugIn.cs:line 33
   at Kosmos.GdiMapPainting.GdiMapPainter.PrepareForPainting(OsmDatabase osmDB, RenderingCommandsList renderingCommandsList) in d:\MyStuff\BuildArea\Sandbox\OsmUtils\trunk\Kosmos\GdiMapPainting\GdiMapPainter.cs:line 53
   at Kosmos.Presenters.MapPresenter.AsyncReloadCompleted(Object sender, RunWorkerCompletedEventArgs e)
   at System.ComponentModel.BackgroundWorker.OnRunWorkerCompleted(RunWorkerCompletedEventArgs e)
   at System.ComponentModel.BackgroundWorker.AsyncOperationCompleted(Object arg)

That doesn't happen to me with smaller files.

--User:nosolomusic 10:42, 24 January 2008

This exception is (probably) a bug in Kosmos coastline processor. There isn't any explicit file size limit, 7 MB isn't really that big, I've rendered 30-40 MB with no problems. I will investigate this and fix it for the next version of Kosmos. Thanks for letting me know. --Breki 12:56, 24 January 2008 (UTC)

Thanks, Breki. By the way, I've created a new category for [Category:Kosmos_rules] where I added the Standard and Valencia Rendering Rules, and today I saw that someone added Finnish Kosmos Rules. I hope it's a good step and you like it ;) the tiles I generated can be seen at [1] --User:nosolomusic 16:33, 24 January 2008

Yes, I noticed your work today, I already mentioned it in my blog (http://igorbrejc.net/openstreetmap/kosmos/valencia-slippymap). It's a great step, keep me informed on your work. --Breki 16:16, 24 January 2008 (UTC)

tileserv - Wrong Latitude Values

I've picked a crossing and looked at it in Kosmos.Gui map and informationfreeway map, they show me the same (correct) coordinates, around lat=50.9743 and lon=11.1442, but tileserv map give's me lat=-30.56061 and lon=11.14422 in the permalink. -- Miskellaneous 14:51, 25 January 2008 (UTC)

I probably got the jscript OpenLayers code wrong. I will try to fix this before the next release, thanx. --Breki 20:25, 25 January 2008 (UTC)

tilegen - Non portable file name handling

While running Kosmos on Linux the file name of the tiles are created by concatenating the directory names always with \. This directory separator char is only valid on windows: you should use Path.DirectorySeparatorChar or Path.Combine. -Lupus 5 February 2008

Ordinarily I use Path.Combine method, but this concatenating had to implemented with a custom logic. But you are right, I should have used Path.DirectorySeparatorChar instead of '\'. I'll fix this for the next release, thanks. --Breki 08:10, 6 February 2008 (UTC)

printing wrong papersize

I tried to print the map and I have choosen a DIN A0(33.1 x 46,8 inch) as papersize, but printed will ba on a US Letter. This i really easy to reproduce: Cick on Print Map in the menu => the click on Page Setup => Select the disred papersize => leave the dialog with ok => enter the Page Setup again and you will see that the old papersize is selected. Henry Every 10:30 06.02.2008

Henry, thanks for the info, it will be fixed in the next release.--Breki 12:23, 6 February 2008 (UTC)

Henry, if you want it fixed earlier you could speed things up by sending Breki such a printer. I'm sure it would help him reproduce the problem more accurately :)) --Stefanb 14:38, 6 February 2008 (UTC)

:) --Breki 15:47, 6 February 2008 (UTC)

For sure how about a printer for 60 inch wide paper ? ;-) Or would you prefer a smaller(36") but faster one ? ;-P Is it right that the program is developed under C# ? I would like to have a look at the source, maybe I could help a little bit. By the way I found the problem using the foxitreader printer, which you can easily download.-- Henry Every

Its C#, yes. I will publish the sources together with the next release (hopefully by the end of the week). --Breki 20:22, 6 February 2008 (UTC)

Text on non-simple areas

There is a bug with rendering names of area, when area is not very simple (for example L-shaped house will have it's name not on house section, but in the yard of it) -- Users:LEAn 22:05, 3 april 2008 (UTC)

It's not really a bug, Kosmos just uses the area's extents and calculates the center of it. It (currently) does not have a more advanced algorithm (like this one). --Breki 18:49, 4 April 2008 (BST)

key with a colon ':' character

I wanted to create a rule picking up on a key with a colon ':' character in it. specifically "whitewater:section_grade" (see WikiProject Whitewater Maps). So my rule in the 3rd column looks like: {{tag|whitewhater:section_grade|3}}, but Kosmos says "Error parsing expression".

There was some debate about whether colons should be used in this way, but they have been used in various places e.g. Building attributes and WikiProject Piste Maps

-- Harry Wood 21:05, 6 April 2008 (BST)

Yes, currently colon is not permitted in Kosmos rules. I think it should be allowed, so I will correct this in the next version. --Breki 09:53, 7 April 2008 (BST)

Excellent! A related useability note: After getting a parse error I want to be able to fix the problem in my config files and then click the orange reload button, but currently I have to re-open the project. minor thing really. -- Harry Wood 10:21, 7 April 2008 (BST)

Help needed

I tried to use Kosmos, but I am not able to generate the necessary files for my area. Could you perhaps add more information in the HowTo section about creating the necessary files in JOSM? In the Sample project you have a .txt-file, a .xml file and a .osm.bz2 file. I can save my area in JOSM in the .xml file format alright, but there is no option to save in .osm.bz2 format. Also, while your .xml file is only 2kb and the .osm.bz2 file is 247 kb, mine are both about 9.000 kb. So I think there must be a difference. So now I do the following: I save those 2 files in one directory and add the RenderingRules.txt file. Then I try to open the .xml file with the Kosmos.Gui.exe -> Open project file. Then I get an error message: "Error. Could not load project file. Reason: At least one OSM file must be included in the Kosmos project file." I do not really understand what that means. Do I have to give special names (are there rules?) to the generated files, or can I name the files as I want? (I could open the sample map), so the program works on my machine. Thank you and sorry for the inconvenience, Longbow4u 10:20, 23 February 2008 (UTC)

You don't have to save it in .osm.bz2 (zipped OSM) format, just leave it as .osm (the way JOSM saves the data). You can save the file with any name you want, but you should update the sample Kosmos project file to point to your file, example (I only included a section of the project file, not the whole one):

...
    <OsmFiles>
        <!-- here you enter a list of OSM files which you want to render-->
        <File>MyMap.osm</File>
    </OsmFiles>
...

You can leave everything else as it is. I hope this helps - I'll update the Wiki page to make it more clear. --Breki 15:44, 23 February 2008 (UTC)

Thank you, now it works. Fantastic programme. I had tried several times before without success. Great, greetings, Longbow4u 20:23, 23 February 2008 (UTC)

Hi Breki, every version you create ist much better than the one before! Great! But I have problems to let Kosmos render the [Lake Konstanze][2] (South of Germany, border to Switzerland). The "Untersee" in the southwest is a seperate part of the lake and is rendered without problems. But the big part is not. I can not find major differences, an I tried to edit some tags with JOSM, but with no results. The .osm file I used was also created with JOSM. What is the problem? To many nodes for the lake? Is there a limitation of nodes for one single way? Could you check this problem out for me, please. --Bener 21:06, 4 March 2008 (UTC)

Funny, I used exactly this lake as a testing ground for Kosmos and Srtm2Osm a while back :). I'm not aware of any limitations, the only limitation that could exist would be in GDI+ rendering of large polygons with holes. I'll check it out and let you know. --Breki 07:05, 5 March 2008 (UTC)

The problem is here: http://www.openstreetmap.org/?lat=47.6648966993271&lon=9.3880588299919&zoom=17&layers=0BF If you zoom enough ( < 0m) in JOSM to the top of the cape, you'll see a node that is sticking out. Just delete that node and it will render the lake OK in Kosmos. Let me know if you've found that node. --Breki 07:40, 5 March 2008 (UTC)

Yeah! I found it without problems. I lived only roundabout 200m away from that place. I changed this node and updated the OSM database. Now this wouldn´t be a problem any more! Is it possible to let Kosmos be more tolerant for such little mistakes?! And I ask myself (and you): How did you find that little node? Not by checking the complete coast of this lake manually, I guess?! Thanks for your help!--Bener 21:13, 7 March 2008 (UTC)

Nice place you live in :). I found it more or less accidentally. I split the lake polygon into two and then noticed that it consisted of several ways. Then I checked how these ways were connected and noticed that rouge node (since it was at the end of a way). As for making Kosmos more tolerant to these errors, I'll add the code if more of similar problems appear. --Breki 06:20, 8 March 2008 (UTC)

I think you need to look at proper GIS software packages, they probably would be more suited to your work, and would allow you to do much more stuff than Kosmos is designed to do. Have a read of this introductory article, and from there you can make a choice of several free OS packages, or go for a commercial package such as Manifold for example. --Petz 07:51, 20 May 2008 (UTC)

I have to agree. Kosmos is pretty basic SW and does not have the rendering flexibility of Mapnik or Osmarender, other (real) GIS applications would probably be more suited your situation. --Breki 17:28, 21 May 2008 (UTC)

I am sorry, are you saying it is impossible for me to easily append a map under Kosmos with a spot filled in with a color? :/ --OpenGrass 19:59, 21 May 2008 (UTC)

It's not impossible, it's just that you cannot make the size of this "spot" variable. Kosmos rendering rules aren't that flexibile, that's what I was trying to say. --Breki 20:11, 21 May 2008 (UTC)

Ah I see what you mean! :) Ok, just back to the basics... I am not absolutely sure if this program of yours will fit my needs., still one of the most basic questions I have lingering in my head is: Can I use the RenderingRules file, to place instances of where I want icons or sizable shaded ellipses (in the future hopefully :) ;), for instance, explicity placed on the map, based on LAT and LON cords? :-) .... Or does achieving this goal need those spot instances to be contained in the OSM data? If it's not possible to place these "map spots" for the lack of a better term, in separate files like your smaller rules file, .... then maybe it would be a *very good* and very cool future innovation. Those OSM files tend to become real huge and not desirable to uncompress and tango with, and you can just let programmers deal with how to manage standard modifications to the RenderingRules or some other extras 'map-builder-file'. I probably should have put this under WISH LIST, but since I am here I just wanted to type some observations. BTW, I checked those other GIS applications suggested...though comprehensive, they are very very very bloated and too bulky and ugly for me. hehe have a great day! :D --OpenGrass 08:02, 22 May 2008 (UTC)

Well, rendering rules are not intended to be a new OSM files :). If you want to put information into a map, you should use OSM nodes, ways and tag them appropriately. If you have problems with large OSM files, I suggest you use filtering when downloading the data using OSMXAPI. --Breki 19:31, 25 May 2008 (UTC)

I need help! is it possible that the nasa FTP server is not reachable? I tried from 2 different locations and had no success. I tried it with Kosmos, srtm2osm and manually to access the server. --hanniball76 14:31, 14 June 2008 (UTC)

Yes, I noticed it, too. I tried with a FTP client and the server couldn't be reached. --Breki 13:15, 14 June 2008 (UTC)

Is there somewhere a mirror for the needed files? --hanniball76 14:31, 14 June 2008 (UTC)

Not that I'm aware of --Breki 20:09, 14 June 2008 (UTC)

Hello, I am having some difficulty setting up the Kosmos tile map service. After running the Kosmos.Console.exe tilegen Samples\SampleProject.xml, it generates all the dozens of folders with tiles. Then, when I run Kosmos.Console.exe tileserv Samples\SampleProject.xml, and proceed to http://localhost/kosmos/, I get a blank screen and javascript error: 'OpenLayers' is undefined. This is on a OFFLINE computer not connected to the Internet, so this could be the problem. I did see the <script src=http://openlayers.org reference to OpenLayers.js file, which I did download and placed in the root Kosmos directory and changed the HTML reference inside kosmosmap.htm to <script src="OpenLayers.js"></script>, ... but this did not resolve the issue and get the same error. What issues or configurations need to be resolved to to properly run http://localhost/kosmos/ on a offline computer to access the slippy map? :)

Huh, well to tell you the truth I never tried it in offline mode :). Can you try analyzing this with some kind of HTTP tracer (Firebug is a good choice)? The thing is that I'm in process of finishing the new version of Kosmos. I've just added "try tile server in offline mode" to the list of things I intend to finish before releasing it, so if you're in no hurry, I suggest you a week or two. --Breki 20:45, 16 June 2008 (UTC)

> No worries :) I am not in huge hurry, ... i'll just check back in a week or so to see what you find from your follow-up testing. I am sure you'll see the same issue I had.... It appeared to be some kind of reference issue maybe hard-wired in there somehow preventing offline execution of this. I was only getting some kind of general Javascript references error which I Bet you'll see,... like i said, even if i put the .JS file in the correct directory, and change your HTML URL path to reference the .JS file locally, I was not able to work around Javascript References Issues for some reason! :( I am building a internal intranet that is always offline, and tried different things to make it work to no avail so far. Best wishes-Steve

Well if there's any hard-wired reference, then it's probably be in the KosmosMap.htm file. You can try and edit it and see if you get anywhere. Just don't delete the ${KosmosTilesUrl} reference, because the tile server replaces this with your actual tile server URL. Let me know if you have any luck with this. --Breki 04:53, 17 June 2008 (UTC)

Sea depths

Are there any sea depths in the height data, which could be used for bathymetry rendering? Ojw 13:01, 9 April 2008 (BST)

If you're referring to the SRTM3 data used in Kosmos, then the answer is no, SRTM3 does not have bathymetric data. I've found this link with a list of publicly available bathymetry data, but I don't have any experience with this. --Breki 20:19, 9 April 2008 (BST)