Talk:OSM Composer

mkgmap call failed!

Alles installiert, Pfade richtig gesetzt, Bereich eingegeben und Generieren gedrückt. Es kommen einige Fehlermeldungen (z.B. "Registry remove call failed!" sowie "java.io.IOException: Server returned HTTP response code: 403 for URL: http://api.openstreetmap.org/api/0.5/map?bbox=8.537001,49.418697,8.587001,49.4523", das Programm läuft dennoch weiter. Ganz am Ende wird aber keine Img-Datei generiert, stattdessen kommt die Fehlermeldung "mkgmap call failed!" - ich weiß nicht weiter, was ich tun soll, hab schon alles mögliche gecheckt und probiert... Drbobo 17:27, 10 December 2008 (UTC)

welche Version? 053 ist zurzeit deutlich stabiler als die 054development (die hat eher mehr Fehler gebracht als beseitigt).--Extremecarver 19:26, 10 December 2008 (UTC)

map_composer_053, mkgmap-r590... Drbobo 19:50, 10 December 2008 (UTC)

Benutze bitte mal eine neuere mkgmap version. Mit 680-690 sollte es auf jeden Fall funktionieren.--Extremecarver 21:58, 10 December 2008 (UTC)

Ja, das Fehlerhandling könnte noch besser werden. Das "Registry remove call" kannst Du ignorieren. Das eigentliche Problem ist daß Composer keine OSM-Daten über die API runterladen kann. Ohne OSM auch kein mkgmap. Wenn ich Deine URL in den Browser kopiere, bekomme ich XML-Daten. Geht es jetzt? --Nop 08:35, 11 December 2008 (UTC)

Ich habe den Fehler gefunden, lag an einer fehlerhaften (zu großen) Einstellung bei "Speicher für Java Aufrufe". Herausgefunden hab ichs, indem ich die "Batch-Datei" commands.log im Maps-Verzeichnis gefunden habe und mkqmap separat aufgerufen habe. Die Fehlermeldung war eindeutig. Veilleicht könnte man ja die Fehlermeldungen, die die aufgerufenen Programme zurückgeben, ins Log integrieren?

Danke jedenfalls, der OSM Composer ist grandios, mit den einzelnen Progs rumzumachen macht nur halb so viel Spaß, wenn überhaupt... Drbobo 15:16, 11 December 2008 (UTC)

Start Path

It wouldn't start when clicking on start.bat - I assume it only accepts to be started from c: drive not d: ???? after changing the folder to d:\garmin\map_compser_040\ and then entering the text from start.bat manually it started. Same was possible with editing the batch file to: d: java -Xmx512M -jar map_composer.jar I don't know whether this caused any of the probs further on.

It should not be path dependent at all, actually I am running it from D: myself. I have tried copying it around on my drive a little and it did start from any directory on any drive. What error message do you get when you try to start the batch from a console? --Nop 06:42, 17 October 2008 (UTC)

I get "Unable to access jarfile map_composer.jar" - even though it is in the same folder as start.bat --Extremecarver 10:26, 17 October 2008 (UTC)

No idea what might be causing that. On Unix I'd suspect the local dir missing from the path, but I have never seen this under windows. --Nop 12:35, 20 October 2008 (UTC)

Objekte / Map Rendering Rules

I can't understand the difference beetween "Garmin Objekte importieren" and "Kartenumsetzung importieren" I have a ready2use .csv file but it wouldn't import (same happened too to your file):

java.io.FileNotFoundException: d:\Java\map_composer\data\riding_map.csv (The system cannot find the path specified)

This is the csv file I'ld like to use (have a look at it for yourselve, maybe you like it - it includes a ton of defintions, has to be used togeter with the 4011.typ file (on the same folder in SVN.open....) - otherwise you'll rather get rubbish). http://svn.openstreetmap.org/applications/utils/export/garmincyclemap/cycling-map-features.csv For the moment that's how I made my maps: http://wiki.openstreetmap.org/index.php/OSM_Map_On_Garmin/Cycle_map/TYP_files However I think doing it your way might get me nicer results....

The reason was some test code remaining in the import routine, I fixed it and your file imports properly now. The "Garmin Objekte" table holds just the basic objects available on the GPS device (basically the contents of your TYP file) and the "Kartenumsetzung" is your ready-to-use mkgmap rules file.

I studied your page - just found out that TYP files exist and I guess OSM Composer will have some support for them once I have understood how they work. --Nop 07:03, 17 October 2008 (UTC)

The concept of typfiles (or .typ files...) (not type files - typ because of .typ suffix)is really easy. Every garmin unit has a de facto "built in" .typ file that defines how a certain type like 0x01 will render. By writing a new definition for 0x01 into a typfile the layout of this can be be changed. I think this really started with topo France garmin maps, because they were horrible to look at without .typ files. Also topo Deutschland v1 did greatly profit from a .typfile - the reason being is that some things won't show up at all without .typfile.

If you use Mapsource and Windows the easiest way to add a typfile to your maps is by using mapsettoolkit (just remember max 8 characters, and for every map the typfile must have a unique name - otherwise it will work in mapsource, but not on GPS). Many newer maps from Garmin like Topo Deutschland V2 come with 8byte typfiles that allow far more definitions than the older typfiles - which are unluckily for the moment the only ones supported by mkgmap. The important thing is that i.e. 0x01 in the typfile corresponds to 0x01 in the .csv definition file for mkgmap.

Thanks. Now I just need to make it work. I tried to combine the 4011.typ file with my own gmsupp.img with sendmap20 V4, but the resulting gmsupp.img was not recognized as a valid map on my etrex Vista. I guess something does not match up and I need to find out what it is. --Nop 11:57, 17 October 2008 (UTC)

You can't just use the .typ file because I don't use standard definitions (not enough space for features important to me...). To best understand the process I'ld advise you to build first a map just based on the cyclemap with tpyfile rendering as described here: http://wiki.openstreetmap.org/index.php/OSM_Map_On_Garmin/Cycle_map/TYP_files. You could to try to download the Germany topo 2 sample files offered for free by garmin.de , I'm not very firm with sendmap as I don't use it. Have you acces to a MS Windows pc with mapsource? If then it's easiest to use mapsettoolkit to integrate the typfile and then send the maps with mapsource. For editing typ files maptk is a great utility with graphic editor (great for making the designs, establishing new definitions is much faster with a text editor.--Extremecarver 23:05, 17 October 2008 (UTC)

Thanks, I got TYP files to work and I am currently adding support for generating them to OSM Composer. --Nop 12:37, 20 October 2008 (UTC)

For Linux you will have to use sendmap to include a typfile to a map (and watch out that the mapID corresponds between typfile and maps - mapsettoolkit corrects this).--Extremecarver 10:26, 17 October 2008 (UTC)

Further Questions

I still don't understand it. Isn't it possible to just selct one file to achieve both things, like it's done in newer mkgmap versions, this is what is written in mkgmap.

 There are three files: garmin_feature_list.csv, osm_garmin_map.csv and
 feature_map.csv.
 Currently only feature_map.csv is used within mkgmap, and the other two are
 used to generate it.  This may change though."

I only want to use my version of feature_map.csv (since?? r_659 called map_features.csv) instead of using the two other files to generate it.

• Basically I want to import custommapping.csv - everything else just sucks IMHO. This would then also enable people to quickly just experiment. CSV Files with the scheme like custommapping.csv can be found at several places on OSM wiki already, mostly with according TYP file for drawing nice maps.

If you just want to you use your existing file, go to "Einstellung" and add it under "Externe Regeln", then OSM Composer will just use it as is.

If you want to import it and use OSM Composer to do modifications to TYP and/or mkgmap rule set, then import the default garmin_feature_list.csv into "Garmin Objekte" once so Composer knows the basic definitions. Then you can import your custommapping.csv into "Kartenregeln" and you can start playing around with it there. --Nop 12:41, 20 October 2008 (UTC)

How to select a Region

3. Can't I just take a region outline like Austria? I would like to insert the osm file from geofabrik for Austria for a baseline? How can I easily find the coordinates? Are they listed in WGS84 ?? What do the following settings do? Kachelgroeße Updateinterval and URL

Thanks a lot and awaiting your response, --Extremecarver 21:45, 16 October 2008 (UTC)

OSMC cannot use a local osm file, it downloads everything directly via xapi. The goal is to have a set of small (rectangular) regions easily and frequently updated with the latest server data. It is not written to process whole countries - but it might work. The easiest way to get the coordinates is copying a permalink url from the slippy map into the bottom field and pressing the parse button. I have added the some documentation for the fields on the main page. --Nop 23:05, 16 October 2008 (UTC)

Allright. I managed it. For urban areas right now the biggest I succeeded was about 30x15km. This resulted in a Data.osm of 9.5MB, Contours of around 24MB. And a resulting gmapsupp.img of 1.68MB. Kachel/Kachelgroeße = Tilesize of 0.1° seems best to me - nearly everything else simply crashes or doesn't download everything. I would still like to exchange data.osm with an osm.img from geofabrik and use a contour file with it (not so important, I could integrate the contours with gmaptool later. Will try if a larger map is possible by choosing different tile sizes...

That figures. I use 0.05 for urban areas and 0.2 for backcountry hiking area. --Nop 12:44, 20 October 2008 (UTC)

Ersetzungen

What does this really do? How is the effect achieved? How could I for example draw all Polylines two times that have the tag mtb=yes? I would then add a nice half transparent rendering with a typfile into which I would lay the text MTB with transparent background and thereby I would have all mtb ways nicely tagged. This could then too be done for tracktype=grade1/grade2 etc... once mkgmap supports 3byte Polylines we would have endless options to play around and create great maps.--Extremecarver 22:58, 19 October 2008 (UTC)

Yes, that's exactly the idea. A "Ersetzung" for mtb=yes will give you a copy of each way tagged as e.g. outline=mtb. You can then map this tag to any available way and this one will be on top of your regular tracks.

For routes I plan to have some underlay support that also draws the copy of the way under the original way so you don't need transparency. --Nop 13:31, 20 October 2008 (UTC)

Bug: Only one replacement considered

"If there are several matching rules for one way, all of them are executed. " - this doesn't seem to be true. I have not found a single Polyline in any map where two copy commands succeded. Only one copy of a way gets created, even if 2 or 3 rules are matching and calling for the copying of a way! This is easily visible on all motorways. On bridges and tunnels the oneway=yes copy gets dumbed - there seems to be a preference for bridges and tunnels. Also on ways where mtb=yes I have a preference for this over the tragtype. Both should be shown, as I used the typfile to draw the results on different sides of each way. --Extremecarver 21:30, 30 October 2008 (UTC)

Contourlines

It may be very nice to have a contour line every 5m. However every 10m would be plenty enough for me... Even every 25m would probably still suffice most people (most 1:50k Topographical maps use exactly this). Also at the moment only every 50m contour line gets properly tagged with height=name. I would like to have a nice altituted tag on every contour line, is this possible? Also using 0x21 0x22 and 0x23 for (10m/50m/100m) lines to differentiate the width of the countour line and zoom level would be great. Currently they all reside in the same zoomlevel (all 22 I think?). That's not nice either. BTW I don't wanna make you feel bad with all theese questions and criticism, I rather want to push forward your editor so that it becomes really usefull....--Extremecarver 23:10, 19 October 2008 (UTC)

I'll answer the technical part in the next chapter. I appreciate your feedback, I just believe that it will be a little time until we can really join our efforts. You already have a TYP file and mkgmap ruleset that you want to use. The main drive of my work is directed at building a good editor to get a good overview over the possibilities and create a suitable set of TYP/custom.csv for hiking. So some points (like the hard-coded contour configuration) are very valid, but currently outside my main focus. Once my hiking map has reached a similar level of development as your cycle map, our goals are much closer together. So please keep up the criticism, thanks to the Wiki nothing is lost. --Nop 15:03, 20 October 2008 (UTC)

Contour lines can be configured in detail for every region in V0.51. --Nop 12:40, 28 October 2008 (UTC)

• I don't know whether it's possible to have the ele tag for all elevation lines. This would be more practical.--Extremecarver 13:58, 20 October 2008 (UTC)

Actually, using just the ele-Tag is the default of srm2osm and it is still included in the contour OSM. If you remove the other mkgmap mappings and just leave the one for ele, you can work with only that one. But Garmin has 3 different Line types for contours and the defaults even look good, so why not use them? --Nop 15:12, 20 October 2008 (UTC)

Yeah I'ld like to use all 3 types. But I don't want to look at 5m lines. Therefore I commented out the elevation_minor. If I could choose 10m_minor/50m_medium/200m_major I would work with the default options. Probagely deleting the elevation number tags in order not to clutter the map too much, is needed because you have an elevation line every 5m, with elevation lines at 10m it would'nt be needed. However not hardcoding these options would be best. We use OSM to have more option, not less... I'm mainly using this map for mtbiking - so I usually use 200m or 300m scale on my Vista HCx. For that 5m lines are too much ( I could off course play around with the levels and use a levels command of --levels=0:24,1:23,2:22,3:20,4:18,5:16,6:14,7:10 instead of the default rendering and set the lines at 24/23/22 (for 5/10/50 - for 10/50/200 23/22/20 would then accordingly fit my needs). Oh integrating a GUI possibility for --levels wouldn't be too bad.... I tend to use more levels because my Vista HCx slows down badly on high zoom levels if used with standard levels. Changing this I can pan around quickly even when zoomed far out. --Extremecarver 15:31, 20 October 2008 (UTC)

A config utility for levels will come - once I understand them :-) --Nop 12:40, 28 October 2008 (UTC)

it's quite easy to understand. However there are some problems with the contourlines as they come from a second osm file. If you define some more levels, and "stretch" the zoom level of your map you will get more steps. I usually have/had the problem that being zoomed in close -> too few detail was visible. Being zoomed out far -> too much detail still on map, taking ages to scroll around on Vista HCx. In Mapsource the same applies, i.e. it's a pain to drag around Deutschland Topo V2 without first going to details lowest (--> fault of too few zoom steps). ---- 23:00, 30 October 2008 (UTC)

Proxy Server support?

Hi is there support for a proxy Server? If yes how I can define it? --Zapfen 11:17, 20 October 2008 (UTC)

There is proxy support in V0.5. Just setup your proxy in "Einstellungen" --Nop 22:42, 23 October 2008 (UTC)

Need proxy settings for both OSMC and SRTM2OSM, is this a global Java setting or program internal? in the last case, can somebody implement proxy options? --Skippern 17:11, 20 October 2008 (UTC)

Proxy support is an internal detail of the software. OSMC now has proxy support. If you cannot get direct proxy support, there is the option to capture a socket with an external tool and deviate it to a proxy, but that's tricky. --Nop 22:43, 23 October 2008 (UTC)

SRTM2OSM has no proxy support. --Drbobo 21:16, 14 December 2008 (UTC)

i18n

Can somebody enable i18n so that separate language files can be used, so we can translate the program to any language we like (for me, English, for many of my colleagues, Portuguese) --Skippern 17:11, 20 October 2008 (UTC)

I would also be interested in multi-language support. I can speak German but am native English speaker. It would be easier to contribute if the program was open source though :( Eric2 09:21, 9 March 2009 (UTC)

version 0.50

Huge input files

1. I don't know if this is really the problem, but if I give a large input file (austria.osm from geofabrik with 291MB), it doesn't seem to matter what I put in as settings, but it will crash with "out of memory" even though I attributed 1200MB to Java via start.bat. The window allways tells "Daten lesen fuer REGION". The log doesn't output anything but

Saving table Setting
Saving Regions
Saving table IDManager

I can't see it writing any data. So I don't know what really happens. It doesn't see to matter how small the region I want to use from austria.osm actually is. With a smaller tile (49 MB, cutout with osmosis from austria.osm). I'm now waiting since about 20 minutes with the computer calculating but I don't get any output. I'll try to cut a very small file with osmosis next.

As I mentioned a few times, OSM Composer is meant for downloading smaller regions and not tested for processing huge files. The option to read an OSM file was added for testing, my current input files are < 10MB in size. Once you specify a file, it is not cut in any way, but all data is read. It is very likely that this is too much at the moment. This was even documented, have you noted the manual page OSM Composer/Manual? --Nop 06:46, 24 October 2008 (UTC)

You should think about integrating Osmosis for cutting the region beforehand: This is an example syntax to easily cut out the region needed:

java -Xmx1024M -jar osmosis.jar --read-xml austria.osm --tee 1 --bounding-box bottom=47.8 left=16.80 top=47.99 right=16.99 --write-xml newregion.osm

The data entered into the region window would perfectly fit into this command (tee 1 specifies that 1 bounding box should be cut out). I think cutting out data is somehow broken. If I use bounding box of osmosis and afterwards input exactly the same tilesize as a region, then it works. Otherwise it doesn't work for me. May it be possible that srtm2osm is used WITHOUT -large option? Something like this seem to me to be the reason why even fairly large regions simply don't get read. I tried to use a precut box of 48.00-48.40 x 16-16.50 but even such a relatively small region wouldn't pass (waited 10 minutes).

I agree, integration of Osmosis is probably required to process the size of file you have in mind. srtm2osm is called without --large, but that is easy to add. You can do it maually by changing the call documented in generate.bat. Once the file exists, it will just be reused. --Nop 06:46, 24 October 2008 (UTC)

I have done some experiments with larger files. The results are in the OSM Composer/Manual. --Nop 07:23, 25 October 2008 (UTC)

The problem for me was not srtm2osm I think, because it allways crashed on the first step of "reading data". You could try downloading austria.osm.bz2 from geofabrik, cutting the 48-48.40 * 16-16.50 with osmosis (this is not even a forth of 1°*1°) and try to run it. When srtm2osm crashes, then it gives an error message. I however never got any error messages - just using processor at 100% for over 10minutes without any progress (also staying within the memory allocated to java). I'll retry with 0.51.

Handling of large files has greatly improved in V0.51. Try again now and let me know about your results. --Nop 20:51, 27 October 2008 (UTC)

Working without mkgamp rules

3. There is one major problem I think. If one neither inputs one owns' rules for mkgmap, nor clicks on "use standard rules" then the program will do nothing and not proceed.

Possible. But what should it do, it needs some set of rules to work. Acutally, to make use of Conversions or Route support, you will have to import and extend your current set of mkgmap rules. --Nop 06:46, 24 October 2008 (UTC)

After I played around a bit it worked. I think what would be needed is that the "basic" configuration works out of the box (after setting program paths). Meaning that after setting up the program paths one can click on "Generate" right away and it will work. This is currently with a fresh unzipped 0.50 (or 0.41) not the case.--Extremecarver 08:27, 24 October 2008 (UTC)

What did you have to change to make it work? --Nop 08:29, 24 October 2008 (UTC)

I don't actually know. The first thing I tried was just setting the apps paths and then clicking on generate. It would loop indefinitely however. Then next I set use standard mkgmap rules and it would work without any other change. Later on after many changes it would work also without that option set. I'll have to play around a bit more to really understand how the system works. --Extremecarver 08:47, 24 October 2008 (UTC)

There was one thing I forgot earlier - now its in the instructions: You have to restart after setting the icon path. That could have been the problem. --Nop 18:03, 24 October 2008 (UTC)

That's well possible.

Kartenumsetzung Importieren und Typfiles

Ist es moeglich ein Typfile zu importieren (kompiliert als .typ oder auch unkompiliert als .txt)? Ich habe im Manual eine Sektion dazugefuegt. Koennte man typfiles wirklich integrieren (damit meine ich nicht auswechseln), dann koennte man ueber die Buttons "Geraet/Typ" und "mkGmap Regeln" auch gleich das richtige Rendering angezeigt bekommen/editieren. Noch besser waere falls bei der Import Funktion auch die Moeglichkeit der Ergaenzung bestehen wuerde (fuer evtl kommende typfile importierung sowie map-features.csv Importierung). Somit koennte man blitzschnell zwei verschiedene Files zusamenfuegen. Es muesste eine Abfrage kommen, welcher Wert uebernommen wird, wenn ein Objekt wie |0x50||20 in bestehender wie importierender Version vorkommt (außer identisch). Meine Programmierskills wuerden fuer sowas nicht ausreichen, daher mache ich sowas noch per Hand in Textfiles, soll nur ein Vorschlag sein wie man es machen koennte. Dann koennte man zum Beispiel Bausteine wie steets_features.csv oder mtb_features.csv oder wander_features.csv erstellen, und dann fuer die gewuenschte Karte einfach aus den Bausteinen zusammenfuegen.--Extremecarver 00:04, 26 October 2008 (UTC) Edit: Sorry for writing this in German, didn't think, it's too late....

It would be possible to parse and import the .txt TYP definition file, but this would be a lot of work - and rather difficult as it would have to work for all possible ways to write a .txt file. Basically, the same as writing the TYP compiler again - it would have to understand and convert all possible contents of the TYP file and produce a different output format. Merging it with an existing set of data makes it even more difficult and I don't think it is worth the effort - I would suggest replacing the TYP information completely and then continue editing the TYP definition in OSM Composer.

At the moment, I do not plan such a complex import function, the core functions of OSMC still can use a lot of improvement. But if someone else is willing to try it, I will give my full support. A converter to transform the .txt file into a .tbl file and a set of .png files could be a separate program. If written in Java, it could be included into OSMC later.

As for the idea of creating a combination of feature libraries, I am sceptical whether it would work. In a TYP file you have to abuse the existing Garmin definitions a lot, except for points where there are enough IDs available. I expect that TYP files made for different purposes will usually be quite incompatible, extending and abusing different IDs in different ways. --Nop 07:24, 26 October 2008 (UTC)

No problem, I will just use my typfile afterwards. I'm simply not getting used to the concept.

Kartenumsetzung Importiergen java.lang.ArrayIndexOutOfBoundsException: 5

I got this error when I try to import my own map-features file (I tried to import my stuff into osm composer but this is way too complicated compared to just writing a single line into map-features.csv and then writing a definition for the typfile creation). If you get this error go into Umsetzungsregeln and look up what is the last item that was imported. Then have a look into the file you wanted to import. It is HIGHLY probable that there is an error in the line, therefore the import stops (would be better if the program continued or gave some meaningful error message). I often had the error that by writing in the file I somehow lost something of the line, i.e. Correct:

polygon|natural|wood|0x50||20

Will produce Exception: 5:

polygon|natural|wood|0x50|20

It took me some time to figure out it was an error in the file and not me importing something at the wrong place. Therefore I documented it here. --Extremecarver 23:23, 25 October 2008 (UTC)

If the file is damaged like that, it should not work in mkgmap either - the last entry is the zoom level and that is important for rendering. But thank you for the hint, I have hardened the import for this kind of problem, should be gone in V0.51. --Nop 06:54, 26 October 2008 (UTC)

mkgmap just ignores the complete line and continues with the next line, therefore it doesn't matter as much (if you have 2-3 errors you might not even notice), on the other hand having an indication about the error is even better. (as long as you know what to search for, I though a long time that the file just wouldn't fit the purpose of importing).--Extremecarver 10:20, 26 October 2008 (UTC)

V.051

Local osm data import doesn't work Bug Report: Cannot find region_input.osm I put the osm file (whole austria.osm 269MB) renamed as teststadt_input.osm into maps/etrex but then after about 30 seconds osm composer crashed including closing the cmd.exe Will try cutting it with osmosis before.

What was the setting of "Datenquelle" in "Region"? Sounds like it was set to use osmosis. Did you have a path to osmosis confiured in the settings?

Crash is probably an out of memory error. Largest files I could process was about 200 MB. --Nop 00:30, 28 October 2008 (UTC)

Well possible. Tried to use osmosis, path to osmosis is setup correctly. I set error log to trace all and this is what I got before the crash: Upps corrected: the errorlog.txt didn't even get written anymore. Something must be wrong with osmosis integration. It says: cutting input file in the cmd.exe (set to display all), then opening input file. And then it crashes as the input file I just gave it was not the cutted one but one much too large and crashing with out of memory (can only provide 1300MB, as I have 2048MB). I suspect maybe the cut-out data from osmosis is written somewhere else, or not at all?

Please find the errorlog.txt on SVN: http://svn.openstreetmap.org/applications/utils/export/OSM_Composer/ - this is the error log of the testrun without the manual replacement.

I checked my test region, it generates ok. Looks like something went wrong with the call to osmosis. Please set the log level back to "Methods", the additional logging is internal database stuff and will not help us in finding the problem. Please have a look at commands.log, the first entry should be the call to osmosis. Does it look good? Does it run when executed seperately on a command line? Does it produce an output file? Maybe the 'ß' in the filename is a problem. Or maybe it's the -XmX1600 --Nop 07:09, 28 October 2008 (UTC)

It's the XmX1600 in the call to osmosis (I don't think osmosis needs much memory anyhow, it's made to cut the world file, so 512 should be enough for any input file to it). Here's the relevant part of command.log (same applies to mkgmap - I think mkgmap never needs more than 1024MB, because if it would need more, the .img file becomes bigger than the limit acceptable to garmin (somewhere around 16MB).:

rem Local file is current: test_contour.osm
rem Cutting input file
java -Xmx1600M -jar D:\Garmin\osmosis-0.29\osmosis.jar --read-xml D:\Garmin\mkgmap_680\austria.osm --tee 1 --bounding-box bottom=47.80 left=15.80 top=48.20 right=16.35 --write-xml D:\Maps\Etrex\test_input.osm 
rem Build the garmin maps
java -Xmx1000M -jar D:\Garmin\mkgmap_680\mkgmap.jar --latin1  --map-features=D:\Maps\Etrex\customMapping.csv --mapname=88220001 test_contour.osm test_data.osm 
rem Generating Garmin osmc file 
C:\Garmin\sendmap20\sendmap20.exe -l D:\Maps\etrex\etrextst.typ 

this command does not run through because of

Error occured during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

So I was too generous with the memory? :-) Ok, let's make this value configurable, too. --Nop 10:35, 28 October 2008 (UTC)

Yeah. I can go up to 1400M, not depending on page file. This seems to be a Windows XP limitation. Supposedly 1600M is the absolute max any XP machine can handle, and 1300M the about normal max for Windows XP that most people should reach if enough memory/virtual memory is available. I'm just trying to get my system to accept 1600M, but for the moment I don't succeed. 64bit systems should be much better for that.

Well, 1600 was the limit on my machine, also XP. We'll just make it configurable with a default of 1000 I guess.--Nop 12:31, 28 October 2008 (UTC)

Ok, I changed my mind and just turned it down to 512M. If there is no need for more, why bother? Should work again now in V0.52. --Nop 20:52, 28 October 2008 (UTC)

For Osmosis I'm sure it's enough. For mkgmap I don't know. 1300MB which I used as a standard setting was more than enough for big tiles. 512MB is supposedly not enough to create maps that are as big as the Garmin limit. The problem with the 1600MB is that Windows XP can only address 2GB of application memory (+2GB system). So if more than 448MB are dedicated to applications (easily happens if you have antivirus, sandbox, .... on autostart) than it's hard to go there. 1024 should be no problem for anyone (maybe except firefox 2 open since several hours with 20 tabs....). On the other hand reading in the file by osm composer crashed in v0.50 on much smaller files than what can be done with mkgmap with 512MB (mkgmap on 1300MB can take about a 540-600MB big osm file). I suppose 1024 would be a good value as 512MB may just be a bit just.

The next problem is that the .reg file won't work, because mkgmap is called without option -o (java -Xmx1000M -jar D:\Garmin\mkgmap_680\mkgmap.jar --latin1 --map-features=D:\Maps\Etrex\customMapping.csv --mapname=88220001 test_contour.osm test_data.osm ):

[HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\MapSource\Families\OSM Composer]
"ID"=hex:82,00
"Typ"="D:\\Maps\\etrex\\etrextst.typ"
[HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\MapSource\Families\OSM Composer\1]
"Tdb"="D:\\Maps\\Etrex\\88220000.tdb"
"Bmap"="D:\\Maps\\Etrex\\88220000.img"
"Loc"="D:\\Maps\\Etrex\\"
"Typ"="D:\\Maps\\etrex\\etrextst.typ"

because now the files are named: 88220001.img; 88220002.img; however the overview and tdb are 63240000.img 63240000.tdb. So after adding this to the registry, mapsource won't start. So for now I'll quickly add to the main page, that 1600MB of available memory (real and virtual) have to be available. I just enlarged the paging file, and then it runs through (except for the reg error).

Are you sure that the -o parameter works? I did not get mkgmap to use the correct names, but Composer should rename those files if MapSource integration is activated in the settings. --Nop 10:35, 28 October 2008 (UTC)

Oh you're right. Doesn't work. -o works only for srtm20sm. You could however add --description=88220001 (same as --mapname). Maybe map renaming doesn't work because of the 1600M error.

Have you tried whether --description works? Have you Enabled MapSource integration in the settings? Is the .reg file newly generated or is it a left-over from earlier runs? --Nop 12:31, 28 October 2008 (UTC)

The reg file is newly created. However the process doesn't show up in the command.log. I can't really test anything because the command.log doesn't include all steps. If I want to build new maps right now I can only do the following: 1. Generate. 2. Go into command.log and copy everything into cmd.exe with xmx1200. If I now click again on Generate then the files are deleted, an empty gmapsupp.img is created, and 6324000.img is complained missing (has been deleted directly before). Therefore I can't really help here. I can only after step2 use mapsettoolkit to integrate the maps (by creating a new overview map). Same applies if I use xapi.

Retried by just renaming and then registering. Then it works. So only that XMX1600M is a real pain for my configuration. I think default 1000 sounds pretty good. Configurable of course even better (=larger tiles possibe).

I installed on another machine and played around a bit. This is what I have observed: If mkgamp is called with only one single .osm file, it will not create and overview map file and I get an error that the (non-existent) file cannot be renamed. MapSource will crash. If there is more than one .osm, mkgmap creates 63240000.img and 63240000.tdb, renames them and all is well. I have not found any parameter to force mkgmap to always create those files. I always had at least one *_contour.osm and one *_data.osm, so I never noticed the problem. Once you have two files again, the problem should go away. --Nop 20:52, 28 October 2008 (UTC)

It wasn't possible for me to have 2 input files using "generate" as they were deleted on clicking on generate and then only one file passed to mkgmap. I know that mkgmap only creates those needed files if at least two input files are used.--Extremecarver 21:38, 28 October 2008 (UTC)

V0.52

Thanks, working again. Mapsource integratio nearly works. The typfile is not assigned the right FID. This means it will work in Mapsource, but not on GPS unit. I don't know any other way than to change the FID except doing this by hand or by using mapsettoolkit or gmaptool. On the other hand, people who have their own typ file will probabely know how to change the FID/PID.

If you are using an external TYP file, you have to use the family ID and product code that has been encoded in this typ file. Composer does not change that typ file in any way. If you change the IDs in Settings, Composer should patch them into the output of mkgmap and everything should work. If you have full control over the typ file, just make sure that the IDs set in composer and those in your typ definition match. --Nop 21:27, 29 October 2008 (UTC)

Great that also osm.bz2 files can be read (it's quicker though to extract it beforehand). This is IMHO the first version that works good enough to be actually usable. It did not crash on me when I tried to generate a 1°*1° map!

Well, thank you for helping me to find the problems and develop OSMC from a tool that works, but only on my machine into a more well-behaved application. Now we can actually start using and developing it further. --Nop 21:27, 29 October 2008 (UTC)

However java of mkgmap was hitting the 512MB ceiling (but then it did not crash - so maybe it's okay for some programs to hit that ceiling without crashing?). I think it would really be best if one could change the memory attribution. (also o.k. if this is done without GUI). When creating region_input.osm memory usage by srtm2osm.exe and java shot up to 1.4GB (overall 2.2GB of my 2.9GB virtual memory were used). This is about a 6-7x as large region as I was able to compile with v0.41.

A lower memory ceiling just means that Java has to execute the garbage collection more often instead of requesting more memory. So as long as it does not exceed the memory with conurrent objects like a DOM model of a huge file, everything should be fine. --Nop 21:27, 29 October 2008 (UTC)

I will try to integrate my typfile and map-features now. Lets see how it goes (Steve Radcliffe of mkgmap is working on 3byte typfile support - so soon really great sport specific maps should be producable). I will upload the results afterwards to SVN (if I get good results), you may import them to standard osm_composer settings if you like them.--Extremecarver 22:46, 28 October 2008 (UTC)

As I am still in the beginning of creating my hiking/trail riding map, I have not yet hit the problem of running out of object IDs. Also, I like to use composers overlays rather than creating many new entries. But if we really get 256 times more objects, we could pick up your idea and try to make a common base TYP file suitable for all outdoor activities and then define number ranges for specific extensions. This whould make it much easier to share some features and developments. --Nop 21:29, 29 October 2008 (UTC)

Have a look at my implementation here http://wiki.openstreetmap.org/index.php/OSM_Map_On_Garmin/mtb_map#Screenshots_Mapsource , feel free to copy any screenshots etc.. over to your front page here. Or implementing anything else.

Networks don't work yet, I'm not sure how to implement relations. Do you know how to do this?

What do you mean by this? I am creating relations for hiking routes in JOSM and I am putting those routes onto my hiking map. Both is easy. --Nop 18:38, 2 November 2008 (UTC)

The problem is that the tag is given only like this: ncn=EV9 or rcn=49. This is because theese are relations, so they are not defined as ncn=yes (or very sparingly). Same probabely goes for Motorways, like XXX=A1.

If those are relations, they are not tagged properly as routes. If those are normal tags on ways, you should be able to use a "Ersetzen" rule on them as they compare against regular expressions and you should be able to formulate one that matches all valid names. Can you give me an example? --Nop 00:04, 3 November 2008 (UTC)

Here is one example (I cut short on the length though):

 <relation id="2937" timestamp="2008-10-25T17:40:30Z" user="mapper_07">
   <member type="node" ref="17322873" role=""/>
   <member type="way" ref="3220515" role=""/>
   <member type="way" ref="3220516" role=""/>
   <member type="way" ref="3220517" role=""/>
   <member type="way" ref="3988112" role=""/>
   ..................
   <tag k="name:de" v="Bernsteinroute"/>
   <tag k="ref" v="EV9"/>
   <tag k="type" v="route"/>
   <tag k="created_by" v="Potlatch 0.10e"/>
   <tag k="route" v="bicycle"/>
   <tag k="network" v="ncn"/>
   <tag k="name" v="Amber Route"/>
  </relation>

The rule to catc ncn=yes doesn't work, also network=ncn doesn't give me any map overlay. (more to that later, seems still buggy though I can't figure the reason why). I have a replacement rule set for ncn=yes. However it doesn't kick in (no map_overlay is done) (I'll come back later to this topic, just got again the POI vs Polyline problem that really annoys me.

Searching for the relation id I can find these additional entries in input_data.osm.

 <relation id="18463" timestamp="2008-08-19T06:31:41Z" user="skunk">
   <member type="relation" ref="2937" role=""/>
   <tag k="type" v="network"/>
   <tag k="network" v="icn"/>
   <tag k="name" v="EuroVelo"/>
 </relation>

 <relation id="26820" timestamp="2008-08-19T06:31:53Z" user="skunk">
   <member type="relation" ref="2937" role=""/>
   <member type="relation" ref="21915" role=""/>
   <member type="relation" ref="22216" role=""/>
   <member type="relation" ref="26679" role=""/>
   <tag k="type" v="network"/>
   <tag k="url" v="http://www.wien.gv.at/verkehr/radfahren/radnetz/themenradwege/index.html"/>
   <tag k="network" v="rcn"/>
   <tag k="name" v="Radwege in Wien"/>
   <tag k="name:en" v="Cycleways in Vienna"/>
 </relation>

2. Example:

  <relation id="17206" timestamp="2008-10-21T22:19:45Z" user="kfg">
   <member type="node" ref="15733829" role=""/>
   <member type="way" ref="3220516" role=""/>
   <member type="way" ref="8033767" role=""/>
   <member type="way" ref="8652840" role=""/>
   <member type="way" ref="8803905" role=""/>
   ...
   <member type="way" ref="27872913" role=""/>
   <member type="way" ref="27873093" role=""/>
   <member type="way" ref="27873094" role=""/>
   <member type="way" ref="27895545" role=""/>
   <member type="way" ref="27895547" role=""/>
   <tag k="network" v="rcn"/>
   <tag k="type" v="route"/>
   <tag k="ref" v="6"/>
   <tag k="name" v="Donauradweg (NÖ)"/>
   <tag k="rcn" v="yes"/>
   <tag k="created_by" v="Potlatch 0.10b"/>
   <tag k="route" v="bicycle"/>
 </relation>

Is there a solution for this problem now? I don't get my routes too. --Zapfen 10:17, 24 December 2008 (UTC)

Example:

 <relation id="30070" timestamp="2008-12-23T10:03:42Z" user="longsch">
   <member type="way" ref="11962901" role=""/>
   <member type="way" ref="11963253" role=""/>
   <member type="way" ref="28676304" role=""/>
   ...
   <member type="way" ref="28750384" role=""/>
   <member type="way" ref="28750462" role=""/>
   <tag k="name" v="ncn 3 - Jura Mtb"/>
   <tag k="network" v="ncn"/>
   <tag k="ref" v="Mt 3"/>
   <tag k="route" v="mtb"/>
   <tag k="type" v="route"/>
 </relation>

I still don't understand what the nature of the problem is

a) your routes don't show up in the list "Routes" in OSM Composer

b) They are configured in the list but don't show up on the map

c) You are trying to create routes directly on ways with replacement and they don't show up.

Both examples should work.

Thanks for the response. The Problem is b) I can configure them in the routes list but I don’t see them on my map.

The files: route_input.osm and *_routes.osm remains empty. --Zapfen 15:28, 29 December 2008 (UTC)

Composer cannot find any routes. If there are routes in the input .osm, then it is likely that the filter is not set properly. You can change the filter in the Settings, default is route=foot. --Nop 23:06, 29 December 2008 (UTC)

The filter for the routes i set up like this:

I did some test with the TestStadt:

First time I start the generation Process I don't get any Data in the route_input.osm file. Then I go to Routes and configure them. After I have some entries. If I generates again the routes_input.osm is again empty. What's wrong? --Zapfen 10:35, 5 January 2009 (UTC)

I encountered a bug, too, that would delete the *_route.osm files when all files are current. Will be fixed with the next update. Workaround: Press the "Force Update" Button in the edit dialog of that region before generating to make sure that data is processed. First time will bring back your _route.osm, second run will put your routes in the map. --Nop 11:10, 5 January 2009 (UTC)

Thanks, I tried the workaround but there must be another problem. First run: I have the routes in "Routen". Second run: in route_input.osm I have the data. But in TestStadt_detail_routes.osm and in the Map I don't have any Routes. What's wrong there? Does the routes process write in the log? I don't see anything about this. --Zapfen 12:20, 5 January 2009 (UTC)

Merging contour.osm with data.osm

Merging of height region_contour.osm and region_data.osm. I'm not sure at all how to really solve this problem but I have on most maps created with mkgmap the problem, that in mapsource (though not on the gps unit) contourlines will rest behind all polygons. This doesn't happen if I before merge the two osm files into one (finally they are only xml files). Do you have the same problem? I know it's rather a problem of mkgmap though (i'm using r_683). The main problems that would be caused by merging the two osm files beforehand is, that in that case mkgmap wouldn't create the needed files for mapsource integration. (Could be solved by feeding two different regions to it though).--Extremecarver 22:46, 28 October 2008 (UTC)

I have seen the same thing. It seems that MapSource reads and draws the .img in a different order than the device handles them in the gmapsupp.img. I have no idea how to influence that. It would be possible to merge the .osm files first in an additional step and provide an additional dummy .osm file to force mkgmap to write an overview file. But I'd rather try to figure out with the mkgmap team why this happens. --Nop 21:29, 29 October 2008 (UTC)

Oh I've missed your answer. I think mkgmap IS NOT to blame because mkmapg simply makes two completely indifferent maps, and creates one overview map for both of them. So merging them beforehand would be nicer. An additional advantage would be that selecting maps in mapsource would be much easier, all garmin topo maps also only consist of one mapfile that includes both map and contour data. A disadvantage would be that the contourlines need to be recalculated on every update. Only if you find out how we could really solve this, I would consider keeping the contourlines seperate. The oter possibility would be to put contourdata into a completly seperate map which is created transparent. Then whenever one needs contourlines, one can simply switch the map on/off on the garmin unit. This gives one advantage: Much faster drawing on the gps unit itself. 2 big disadvantage which outweighs the speed advantage are however IMHO: for planning trips with Mapsource one has no contourlines, and if it's two maps, one can't decide wheter contourlines should be drawn under or over oter polylines.

Have you already conacted Steve about the contourline/polygon problem?--Extremecarver 12:21, 30 October 2008 (UTC)

Maybe it is possible to force MapSource to use a certain drawing order, I don't know. And no, I haven't contacted him. --Nop 16:48, 31 October 2008 (UTC)

Statistics.txt Top 100 not implemented

Now that for the first time I was able to create a larger region I would like to upload the mainly missing tags. We should incorporate them (I'll have a go at it right now). I'm not sure how we can display oneway streets (this is a pretty major thing so that should be one thing to think about).

Good question. Creating an overlay with little arrows would be easily done. But does mkmap/Garmin software see the direction of ways at all? Does the rendering match the direction? --Nop 21:30, 29 October 2008 (UTC)

3443	 way:oneway/yes
1172	 way:foot/yes
838	 way:building/yes
624	 node:class/free
612	 node:amenity/WLAN
607	 way:fixme/yes
500	 node:highway/traffic_signals
367	 way:surface/unpaved
296	 way:maxspeed/30
288	 node:addr:city/Wien
282	 way:surface/paved
257	 way:oneway/true
183	 way:bicycle/yes
178	 way:maxspeed/50
159	 way:area/yes
158	 way:maxspeed/40
157	 node:religion/christian
152	 way:cycleway/lane
139	 way:lcn/yes
133	 way:boat/no
131	 way:lanes/2
124	 way:junction/roundabout
118	 way:lanes/1
114	 way:oneway/-1
111	 way:cycleway/track
101	 way:addr:city/Wien
101	 node:railway/level_crossing
100	 way:access/private

Taking this into account:

• The following should be quite easy to implement (I know how): foot=yes; building=yes; amenity=wlan (class free applies mainly to this); traffic_signals; cycleway; bycicle=yes; lcn=yes (needs to be implemented with UND connection so that it is know wheter this is a bike route, or a tram route, a street route, etc....; access=private

I think not all tags need to be implemented. Composer has an internal ignore list of tags that will not show in the statistics, like note or OpenGeoDB tags. I dont know how you would want to process foot=yes or bicycle=yes. I rather aim to show obstacles and limitations and assume that all other ways can be used. What is an addr: tag? --Nop 21:32, 29 October 2008 (UTC)

Of course, however I think the mainly used tags should be in standard setup already. That way it's less work to beginners to make their first better then ever before looking garmin map. Until now I still think it will be easier for beginners to just follow a tutorial like the one for the cyclemap on garmin than to use osm_composer. Therefore at least the map should be a lot better in standard configuration already....

I tend to disagree. I spent a lot of time changing around lines and IDs in the .csv file and wondering why nothing happended before I understood what I was doing. The fact that you had broken lines in your .csv that were ignored by mkgamp but you were not aware of this until you tried importing them to Composer is and indication for a similar problem. It is my goal for Composer to give a much better overview, especially when you want to create a new TYP style. And if it doesn't, it means it isn't good enough yet or it needs more documentation or a proper tutorial. --Nop 07:42, 30 October 2008 (UTC)

I too don't know what the addr: tag is, if it is importing for routing than it should be included in standard configuration (there have been already successful tries of creating routable maps with mkgmap - though still a lot of additional work. that's why I didn't list it anyhow. I also don't know WTF is node:religion/christian. Have you got any ideas how to show oneway streets?

I think I read somewhere that route-tags on ways have been deprecated by relations, so I would not invest in supporting them.

well I need to read about that a bit more. It's nice however to see routes/relations. i.e. cycling down the Donauradwanderweg without highlighting you would loose the way, even though it's already completely written in OSM database (for Austria and Germany at least). --Extremecarver 00:48, 30 October 2008 (UTC)

• The following is hard to implement (I don't know how) but should be worked on: way:oneway/yes; node:addr:city/Wien;
• It's not important to me but probabely to others: way:maxspeed/XX; way:lanes
• This is already incorporated well enough I think: node:railway/level_crossing

Importing Garmin Items.tbl

It would be easier if on importing "Anzeigen" would be set to "clicked"/activated instead of deactivated. Anyhow probabley a global setting is enough here. Because if you device is capable of using typ files, with a definition for this type, it will be displayed. If one has has a black/white display then nothing defined by typfiles may be displayed.

Composer is supposed to give you an overview of what you are doing. So if your import contains entries unknown to Composer and the entries are created automatically, you are supposed to at least look at them once and activate them so you know what is going on. You can activate all of them in one go by setting a filter and marking and changing all. But if some of the changes were not intentional, you have a chance to notice that. --Nop 21:34, 29 October 2008 (UTC)

After importing I have in garmin.tbl a long list which is like the following:

467,0,"Import for highway=motorway","0x01","0x10",2,"",1,"",0,1,-1,-1,0,0,"",

What is this for? Wouldn't the normal definitions be enough? (I have 316 lines of definitions above, and about 160 import for).

No. The idea of Composer is that you set up all objects available on the device in the list "Gerät". You may add customizing for a TYP file, but you need to list all objects so they are selectable in the mkgmap rules by name. You just set up IDs once in this list, don't have to know any IDs and you cannot make mistakes when changing IDs already in use. When you make mkgmap rules, the entries in this list are simply selected in a drop down box. The benefit is obvious when you use Composer for TYP file and mkgmap rules, where you can even see the colors and icons that will be used, but you need to set up the basic list in any case. --Nop 21:34, 29 October 2008 (UTC)

I see your point, however it would take me ages (probabely more than 24 hours I believe) to include my .typfile into mkgmap. Please see my mtb map - I'll upload the tbl files plus screenshots very soon, I'm just working on creating a nice package, have a look at it and tell me how you think I could best start the import to completely switc over to osm composer. --Extremecarver 12:27, 30 October 2008 (UTC)

Bug in Ersetzungen Anlegen

• There is a bug that makes it really hard to implemement any overlay way. When copying an entry and then you want to select the next entry with a different style to use, only POI are offered in the list, no polylines. This means you have to create a polyline once more, even though it exists already! "Anlegen" should work like "Speichern". Right now it's really troublesome and takes much time (or am I too stupid?). The idea is, I first implemented different showing of tracktype=grade. Then I thought - wait - let's do this better. Make the tracktype appear besides the way not instead of it so I created path/track as seperated entries and then wanted to make 5 copies just using the already established design/concept for tracktype=grade. It's easy if I do this in outline.tbl, but pretty much impossible via the GUI.

--Extremecarver 00:38, 30 October 2008 (UTC)

I am not sure I understand the problem. I tested it but it seems to work. When you select the action "Kopie/Overlay erzeugen", the drop down box offers only polylines/ways as only those can be used to tag the copy of a way. When you select "Icon einblenden", then only POI/point styles are shown as only those can be used to tag a node of the way. --Nop 22:26, 30 October 2008 (UTC)

No not in my version. I clicked on "kopieren" of a Polyline Ersetzung, but then in the drop down box, actually only map_overlay was available and clicking on anlegen did not work. So I had to go out of "Ersetzungen" into garmin objects, create a new "map_overlay=xxx" and only once then could create it.

I think now I got it. You copied an Ersetzung, the drop-down box already shows the selected tag of the original entry and you want to create a new one from here. If that is correct, just select the first, blank entry in the drop-down box and then press the "..." button. If the box is empty, a new entry is created, if somethign is selected, this entry is edited. --Nop 23:10, 30 October 2008 (UTC)

Yip, that's what I meant. However selecting the blank entry, and then entering all the data sometimes simply does not work (or better most of the time).

Please be more specific. "simply does not work" does not contain any information about the nature of the problem. What does happen? What is the last valid step you observe? What is the final result and what was the thing that you did expect? --Nop 07:34, 31 October 2008 (UTC)

Did you too read about that problem: http://wiki.openstreetmap.org/index.php?title=Talk:OSM_Composer&curid=23928&diff=171272&oldid=171267#Bug:_Only_one_replacement_considered ?

I have ONE single place where 2 overlays get created, but all the other times only one map_overlay is created, and the rest is dumped. I tried to have at least allways two attributes show - by moving some features via typfile to one side of the polyline, some others to the other side. However only one is considered. That bug is giving me much bigger headaches (in an ideal world 2 tpyes could be displayed well on each side, but allways exchanging transparency ever XX points - now only 1 additional type is considered at all). The problem unrelated to the typfile.

After playing around a bit more, the bug in Ersetzungen seems to be of a bigger scale. Maybe something simply gets skipped while reading in the file. If you try out mtb_oneway=yes in the region 48.00-48.10 16.20-16.30 you will notice that even if no other condition creates a second way, somethings simply are skipped. I rechecked many times with Potlach, but at some roads the tag mtb_oneway=yes simply doesn't get read. Also the condition to create an icon on mtb_oneway=yes is not done. About halve of the ways tagged like this are skipped. On these ways however also other conditions are simply overgone, mtb=yes seems to work however everywhere - so there must be some problem in working done the conditions. --Extremecarver 02:36, 31 October 2008 (UTC)

Ok, lets debug this. First of all: Do the copies you configured exist in the _data.osm file? If you search for the marker tags you set for the copies, those ways should be easy to find. If you asked for multiple copies, they should be following each other in the file. How does this look? --Nop 07:34, 31 October 2008 (UTC)

No only one copy of each way can be found in data_osm. And this doesn't even seem to be the allways the same map_overlay for the same way. It's actually quite easy, every Polyline I have tagged with mtb_oneway=yes is also tagged with mtb=yes. For both entries a copy is supposed to be created. However only one map_overlay is created for a given way. I copied manually by hand in data.osm the way one more time setting wayid one digit higher (was empty), and voila all 3 ways were shown. I have no clue why this happens. I'll upload my config to SVN as debug.zip. http://svn.openstreetmap.org/applications/utils/export/OSM_Composer/ Try it out yourself.--

I found the bug. The way id on several map_overlays of the same way is the same, however mapsource will ONLY show two (or more) different ways on top of each other, if they have a different way id. Creating a map_overlay you put 99 in front of the actual way id, this way however only one of them (which one seems random, first one is picked I believe) is shown. Each copy creation should put a different number in front of the way, not 99 for all!!!!!!!!--Extremecarver 12:09, 31 October 2008 (UTC)

I think you are right - the copies are created and then lost again due to duplicate ids. Ok, I'll add a more intelligend mechanism for making pseudo-ids. --Nop 16:46, 31 October 2008 (UTC)

Still doesn't work correctly. Now 2 copies of each way maximum get created. I have some ways where 3 map overlays should be created, but are not. This time they are simply not copied (so it's not about the map_id). All ways that I have tagged mtb_oneway=yes are also tagged mtb=yes and mostly have tracktype=gradeX. However the mtb=yes map overlay doesn't get created in data.osm. I have no clue why.

<way id="27040429" timestamp="2008-10-30T18:14:18Z" user="extremecarver">
   <nd ref="296440537"/>
   <nd ref="296478977"/>
   <nd ref="296489525"/>
   <nd ref="302521739"/>
   <nd ref="296476358"/>
   <nd ref="296489527"/>
   <nd ref="296476361"/>
   <nd ref="296476362"/>
   <nd ref="296476363"/>
   <nd ref="296399355"/>
   <nd ref="302383865"/>
   <nd ref="296399356"/>
   <nd ref="296399357"/>
   <nd ref="296399359"/>
   <nd ref="296399360"/>
   <nd ref="296399361"/>
   <nd ref="296399362"/>
   <nd ref="296399364"/>
   <nd ref="296399365"/>
   <nd ref="296399366"/>
   <nd ref="307878137"/>
   <nd ref="296399368"/>
   <nd ref="296399369"/>
   <nd ref="296399370"/>
   <nd ref="296399371"/>
   <nd ref="296399373"/>
   <nd ref="296399374"/>
   <nd ref="296399376"/>
   <nd ref="296399377"/>
   <nd ref="296399378"/>
   <nd ref="302382198"/>
   <nd ref="296399382"/>
   <nd ref="296399383"/>
   <nd ref="296399386"/>
   <nd ref="296399387"/>
   <nd ref="296399388"/>
   <nd ref="296399389"/>
   <nd ref="296399391"/>
   <nd ref="296399392"/>
   <nd ref="296399393"/>
   <nd ref="296399394"/>
   <nd ref="296399400"/>
   <nd ref="296399401"/>
   <nd ref="296399402"/>
   <nd ref="296399404"/>
   <nd ref="296399405"/>
   <tag k="name" v="Steinbachgraben"/>
   <tag k="mtb_trail_type" v="singeltrail"/>
   <tag k="mtb_oneway" v="yes"/>
   <tag k="surface" v="unpaved"/>
   <tag k="mtb_trail_difficulty" v="S1"/>
   <tag k="created_by" v="Potlatch 0.10f"/>
   <tag k="mtb" v="yes"/>
   <tag k="highway" v="path"/>
   <tag k="foot" v="designated"/>
   <tag k="tracktype" v="grade5"/>
   <tag k="width" v="1"/>
 </way>

Only 2 copies are created in this example. One is mtb_oneway, the second is tracktype=grade5. mtb_yes gets skipped allways IF mtb_oneway=yes (while this is definitely the intended behaviour in the long run (I would like to have mtb=yes only do an map overlay if mtb_oneway doesn't exist (how can I do this with regular expressions?), it should according to the rules create 3 map_overlays. if mtb_oneway is not present, then mtb=yes gets created, I have no clue why this happens though.

Also I have a rule ncn=yes|true and no map_overlay ncn gets created at all--Extremecarver 01:08, 3 November 2008 (UTC)

Move objects up and down in the "Auswertungsreihenfolge"

I think it would be important if one could move objects up and down in Umsetzungsregeln and Ersetzungen. Right now this is only possible by hand in the tbl files. This needs to go hand in hand with a short description of the effects in the manual (I myself am not too confident what really happens on moving things up/down) As maps become more complex. --Extremecarver 12:24, 30 October 2008 (UTC)

You can move rules with the cursor keys. See OSM Composer/Manual#Editing rules.

Replacements can now be moved and also have a break option. --Nop 18:35, 2 November 2008 (UTC)

mkgmap --levels

I think the current problems are largely related to the --levels options. There should be the possibility to configure them too. Especially on the mtb_map wit street=oneway and other options the map is getting far too crowded. Some more zoom levels to make the switch from one zoomlevel to the next would help.---- 23:02, 30 October 2008 (UTC)

Available in V0.53 --Nop 00:11, 31 October 2008 (UTC)

This may still need to be ammended. I think I found the bug. You need to compile the contourline map with different levels than the data map. I.e. your map has objects down to 10, set minimum level to 10 and spread the levels above. Your contourlines are shown at 24,23,22 set levels to 0=24,1=23,2=22 for the compilation of the contour lines. If your contoulines are set to 23,22,20 then set levels to 24=0, .... (your choice),X=20. So the level command needs to be per map input file. The other option would be to join the files (might be easier afterall). One more solution could be (I'm not sure whether it works), to insert a dummy object (like a POI) at the lowest level chosen in the levels command into both data.osm and contour.osm --Extremecarver 22:25, 2 November 2008 (UTC)

The command without dummy file should look like the following:

java -jar mkgmap.jar --latin1 --map-features=customMapping.csv --mapname=88220001 --levels=0:24,1:22,2:21,3:20,4:18,5:15,6:13,7:10 1_data.osm --mapname=88220002 --levels=0:24,1:22,2:21,3:20 1_contour.osm

OR of course this works as well (mapnames will then augment by one for each additional input file).

java -jar mkgmap.jar --latin1 --map-features=customMapping.csv --mapname=88220001 --levels=0:24,1:22,2:21,3:20,4:18,5:15,6:13,7:10 1_data.osm --levels=0:24,1:22,2:21,3:20 1_contour.osm

But even this still causes some annoyances, because now the majour contourlines, will be shown at ANY zoomlevel - meaning it doesn't matter how far you zoom out, the major contourline will still be shown. (doesn't matter for a small region, but once we have e.g. compiled whole of Austria into one Mapset, panning around even on lowest detail setting and lowest zoom will be painfully slow. So I think proper merging of the two files will be the key to getting the contourlines in front of the Polygons in Mapsource. Or again same as for above explication, insert a dummy POI into zoomlevel 10-19 for the contourlines and accordingly set --levels 0:24,1:22,2:21,3:20,......7:10 (with 2:21 optional - this will give the majour contourline more time shown). Now only that little point added to contour.osm will be shown when zooming out farer than the according level to 19 instead of all majour contourlines. Notice however that by giving different zoom levels the levels will not correspond with map scale anymore (I would assume that zoom level 1 would be the same scale for both input files). --Extremecarver 22:58, 2 November 2008 (UTC)

I am sorry, but I don't understand at all. --Nop 23:57, 2 November 2008 (UTC)

The problem is that no map is allowed to be created with an empty level with mkgmap (sthis is the same for cgpsmapper, old section here was wrong). Therefore the contour.osm which has only objects in 20,22,23 is created with the wrong --levels command. Just try out the --levels set to both data files seperately yourself, and you'll see that now the contourlines will be on top of the forest polygon. Why am I so sure that no empty level is allowed to be created? set level 7 to 5 (assuming you have no single object that is so low), on opening the map you'll now see that if you get closer, suddenly the map dissapears in Mapsource. Effectively really the easiest and best solution is to merge data.osm and contour.osm because everything else is just trying to navigate around the garmin structure. Otherwise you need to understand the above :) and implement it properly. I added a bit of information to the top, hope it's clearer now. --Extremecarver 01:20, 3 November 2008 (UTC)

Yes. I didn't know about any restrictions for empty levels. I also didn't know --level can be given multiple times. Adding dummy objects to the maps would work. Merging everything as a future processing step is more difficult as we would currently hit the memory limit more quickly. I have an idea on how to lift that limit, but this means a major rewrite of the data handling. --Nop 13:11, 3 November 2008 (UTC)

Yes due to the memory limit adding dummies seems to be the easiest solution if we want to conserve the possibility to create big maps.--Extremecarver 14:13, 3 November 2008 (UTC)

Screenshots of Garmin PNAs

Instead of photographing your device you can download xImage from garmin and "pull" screenshots from any Garmin unit wit USB connector. That looks much better.

Thank you for the tip - I'll try that. --Nop 22:18, 30 October 2008 (UTC)

Map ID and identification

It would be great if for each region the following settings (now global), could be set to that compiling several different mapsets in Mapsource without deleting other ones, can be done: FID, PID, Mapset Name, -- Mapname (both hardcoded to osm composer right now). Optionally .typ file and input file selection could be helpful.--Extremecarver 22:51, 2 November 2008 (UTC)

The IDs are compiled into the TYP-File, thus there can be only one for the whole set. If you want different sets, you'd need a second copy of Composer - and separate map names and registry keys. Currently you'd have to do some manual renaming. Yes I know that this is possible. Why would I like the different settings?

It would be quicker to test changes on a small area instead of doing the big picture.--Extremecarver 01:22, 3 November 2008 (UTC)

Of course. I have a test region and I keep switching between real and test region. If you don't like that, you could try switching config files with different data directories. Basically you'd just have to exchange region.tbl and config.props. --Nop 13:01, 3 November 2008 (UTC)

Bug on new replacement type and/or new route

Process: I have found a new route with the name:Citydurchfahrt, Distanz:0, ID:26821, rcn, 1. Now I click on the button "..." in the line of "Hinterlegt mit" - as this is my first route_marker, nothing can be chosen if I click on the arrow for the drowpdownmenu. 2. Class is shown: Polyline, I set zoomlevel to 20, Prio is not set, Tag is set to route_marker= I put in a name, say test1, BUT now in the dropdownmenu "Garmin" I can only select POI, even though the object is a Polyline!!!! I I select any on the objects and then click on "Anlegen" I receive 3. I then try to do it manually - I again click on "...", and now I create a new Polylinetype (if I enter the data of an existing, a copy is created in mkgmaprules) and click on Anlegen (nothing happens), I close the window with "Abbruch". 4. I still can't select the new entry. So I close the two open windows with "Abbruch" after clicking on Anlegen in each. 5. I click again on Citydurchfahrt in the main route window. I move on to "hinterlegt with", and finally can select Test1. I click on ... besides it. 6. Finally now Polylines instead of POI are shown besides Garmin. Now I can click on "0x1e Fahrradwegmarkierung" like I would have liked to from the beginning. You may understand that following this procedure on each new replacement or new route is kinda troublesome.....--Extremecarver 01:39, 3 November 2008 (UTC)

For the next entry I have to do the same, or go to mkgmap Regeln, and copy test1 to test2 so that I can directly select it. Otherwise I have to do the same clicking around again hoping everything works out.

The dialog showing POIs instead of polylines is a bug, of course. I'll try to reproduce it, given your detailed description this should be no problem. --Nop 13:04, 3 November 2008 (UTC)

Fixed in V0.54 --Nop 07:14, 6 November 2008 (UTC)

Ignored tags in Replacements - v.053

Price Question - which tag simply gets ignored on the following way when working down the replacements rules wanting to create a copy of a way?:

   <tag k="name" v="Steinbachgraben"/>
   <tag k="mtb_trail_type" v="singeltrail"/>
   <tag k="mtb_oneway" v="yes"/>
   <tag k="surface" v="unpaved"/>
   <tag k="mtb_trail_difficulty" v="S1"/>
   <tag k="created_by" v="Potlatch 0.10f"/>
   <tag k="mtb" v="yes"/>
   <tag k="highway" v="path"/>
   <tag k="foot" v="designated"/>
   <tag k="tracktype" v="grade5"/>
   <tag k="width" v="1"/

Answer: <tag k="mtb" v="yes"/> because it's directly in front of: <tag k="highway" v="path"/>. As it seems to me any tag that's directly in fron of the the highway tag will get ignored. If it's after it's allright. It also seem allrigt if something is inbetween. I'm really stuck on why this fucks up so badly. For sure is that the above will work if it looks like the following:

   <tag k="name" v="Steinbachgraben"/>
   <tag k="mtb_trail_type" v="singeltrail"/>
   <tag k="mtb_oneway" v="yes"/>
   <tag k="surface" v="unpaved"/>
   <tag k="mtb_trail_difficulty" v="S1"/>
   <tag k="created_by" v="Potlatch 0.10f"/>
   <tag k="highway" v="path"/>
   <tag k="foot" v="designated"/>
   <tag k="mtb" v="yes"/>
   <tag k="tracktype" v="grade5"/>
   <tag k="width" v="1"/

In this case the foot=designated rule to create an icon (not a way overlay) works perfectly however. Theese are the rules I'm searching for for this way:

• 1. mtb=yes
• 2. mtb_oneway=yes
• 3. tracktype=grade5

All of them are supposed to create a copy of the way. However Anything directly behing highway=path will fail in doing so. Something in the search algorithm seems to be heavily broken/misconfigured.--Extremecarver 18:51, 5 November 2008 (UTC)

I have no idea why this would happen. Actually, the tags are not evaluated in their given order but put into a lookup table when reading the OSM. I assume I can download your current setup to have a look at this? --Nop 07:18, 6 November 2008 (UTC)

Yes I'll upload it (you can download the english translation too and put it into v0.54) - As usual find it here: http://svn.openstreetmap.org/applications/utils/export/OSM_Composer/debug2.zip , look for the way called Steinbachgraben in data.osm after running it. the problem however comes up on all ways if something is directly before highway=path. --Extremecarver 08:50, 6 November 2008 (UTC)

The bad news is that I did not get around to seriously debug this problem. The good news is that I think I found a way to make OSMC run with very little memory consumption and that I started a major rewrite of core functions. It is likely that this behaviour is changed, too. I suggest we have a look at it in the new version. --Nop 08:15, 16 November 2008 (UTC)

O.k. I do hope so, because it's kinda annoying that if you see i.e. mtb=yes but then mtb_oneway=yes missing, one would assume that one can cycle up, though its only possible for Downhill. Also contourlines had no height attribute in v.054 beta that you released.

Case sensitive comparison

A second big thig is that the rules are case sensivitve. If I make a rule to search for mtb=yes it will ONLY find mtb=yes but not Mtb=yes or MTB=yes. Is there a possibility to find all cases, or make it configurable?--Extremecarver 18:51, 5 November 2008 (UTC)

Yes, it is possible to make regular expressions case insensitive. I think it makes sense, cannot think of a use case where you would need exact matching. Will be changed in 0.54 --Nop 07:18, 6 November 2008 (UTC)

Any news on v 0.54 ?

Long time no see???--Extremecarver 23:46, 7 November 2008 (UTC)

Sorry, too much RealLife(tm) stress to do the testing for a stable release. --Nop 12:16, 10 November 2008 (UTC)

Put up a quick snapshot of the current state. Thank you for the language files, still need to integrate all Texts into the translation process. --Nop 07:23, 12 November 2008 (UTC)

Are you still finding time for OSM_Composer?? --Extremecarver 16:06, 27 November 2008 (UTC)

Currently not. I have moved and I am working on things like restoring water to the kitchen. But I will be back. The attempt to rewrite it for larger data volumes with stax2dom has failed, as that library is not developed far enough for that purpose. Next on schedule is a direct implementation using stax. --Nop 13:48, 4 December 2008 (UTC)

Transformation to stax was successful, OSM Composer should be able to handle huge files now. There will be a new version once I have tested this. --Nop 20:56, 8 December 2008 (UTC)

That's great news. Will thoroughly test it as usual. Mkgmap gets better and better too. ----

Mkgmap r 692 style branch

Hey Nop, SVN checkout the newest mkgmap style branch. It should be able to do the same things that are possbible with replacements right now (maybe without missing some stoff on copy...). I'm not sure whether it's easier to stick to your copying, or just placing appropriate commands directly to mkgmap. This only applies to the sepearte style branch for now, not working with standard rev. 692 from SVN. See the announcement here: Talk:Mkgmap#Multiple_tag_parsing_revisited_.28.2B_multiple_rule_matching.29--Extremecarver 23:03, 9 November 2008 (UTC) Ups just realised, this will take up many objects. Once we have rgn 2,3,4 this would be equivalent, right now I think it only works for very replacements without running out of objects in typ file. Unluckily rgn,2,3,4 output seems to be a bit harder to implement though.

I am following the development over there. Composer will support multiple rules in some way once they are in a binary release that everyone can use. But I think those rules still don't allow for multiple matching rules on the same way, regular expressions and the combinations that I am using. I have only 5 objects in use for marking all hiking routes which are partially transparent and used in 3 layers. I don't think that mkgmap will be able to do this. --Nop 12:30, 10 November 2008 (UTC)

They do allow matching multile rules on the same way. However as the ways are not copied, you have to have a new style for each new road type,... Here's the extract from the txt file (out of r 697). Regex is not supported, but there's quite a bunch of rules. I see the advantages primarily in compile speed. (this doesn't matter right now very much, considering current size limitations). Some other advantages are that a GPS is probably quicker to draw one way with a complex design, than two seperate ways to achieve the same layout. Also map size will be signigicantly smaller, depending on course how many replacements are done. Once rgn2,3,4 support is there, I think it would be better to change over to the new set, until then, probabley sticking to the "old" replacements is the better idea. (BTW have you found the bug with the replacements in v 0.53??)

Tag tests in mkgmap r 697 (from style-rules.txt)

The main test is that a particular tag exists and has a given value. So in the example above we had:

highway=motorway

This means that we look up the highway tag and if it exists and has the value 'motorway' then this test has matched.

You can also compare numeric quantities:

population > 10000
max_speed >= 30
population < 10000000

This means a population greater than ten thousand, a max speed greater than or equal to 30 and a population less than one million respectively. You will be able to compare quantities that have units too, for example

max_speed > 30mph

If a different unit is given in the tag (say km/h) then conversion will be performed. This is not implemented at the time of writing, so please let me know real useful cases that you come across that you would like to work.

Combining tag tests

Although it is possible to convert most OSM nodes and ways just using the one tags, it is occasionally necessary to use more than one. For special purpose maps it is more likely that you will need to look at more than one tag too.

For example, say you want to take roads that are tagged both as highway=unclassified and abutters=residential differently than roads that just have a plain highway=unclassified, you might have the following rules:

highway=unclassified & abutters=residential [ 0x06 ]
highway=unclassified [ 0x05 ]

This means that roads that have both tags would have garmin element type of 6, whereas unclassified roads without would have the type 5.

It is important to note that the order is important here. The rules are matched in the order that they occur and stop at the first one that matches. If you had them in the other order, then the highway=unclassified rule would match both cases. In general you want the most specific rules first and simpler, more general rules later on to catch the cases that are not caught be the more complex rules.

You can also combine alternatives into the one rule. For example

highway=footway | highway=path [ 0x7 ]

This means if the road has either the highway=footway tag or the highway=path tags (or both), then the condition matches and it would be represented with type 0x07. It is exactly the same in behaviour and speed as writing the two rules, one for footway and one for path and is converted to those two rules internally.

You are not limited to two tests and you can combine and group them almost in whatever way you like (with one exception, see below). So for a slightly forced example the following would be possible:

place=town & (population > 1000000 | capital=true) | place=city

This would match if there was a place tag with the value city, or if place had the value town and either the population was over a million or it was tagged a capital.

Additional tests

To wrap up this section here are the other available tests.

highway!=motorway

This will be true when the highway tag exists, but it does NOT have the value motorway

highway=*

This will be true when the highway tag exists on the element. It doesn't matter what the value is. This is especially useful for tags where it is just their presence that matters

highway!=*

This is true when there is no highway tag.

Generated files - purpose?

After running OSM Composer I found the following file types in the Maps dir: img, osm, tdb, txt, typ, log. Would like to understand the purpose of the files, so this is my guessing:

• img - map in Garmin format
• osm - map in OSM format
• tdb - ??
• log - batch-file, not named as .bat (why?)
• txt - Info
• typ - ??

Which ones do I have to copy to the garmin? only img? Also I would like to understand the numbers building the filenames - how are they calculated? Drbobo 16:05, 11 December 2008 (UTC)

Did you see the section "Output" on the bottom of the main page? --Nop 20:11, 11 December 2008 (UTC)

• tdb -- needed for Mapsource and Qlandkarte GT. Tells things about the maps, like a index. Not needed for GPS
• typ -- needed for custom displaying of objects. google for typ-file. Needed for GPS and Mapsource/Qlandkarte to have much better looking maps.
• .img/.osm is correct. watch out that there is one .img that is the overview map, which is kinda different. Again only needed for Mapsource / Qlandkarte GT.

Numbers are set by --mkmgmap options. If you have several mkgmap created maps, you have to give them different numbers. EVERY single .img needs to have a different name!

Best use Mapsource or if you're not on Windows XP, Qlandkarte GT for transferring maps to Garmin GPS (you can run Mapsource with Wine though Qlandkarte GT seems to become a viable alternative)--Extremecarver 22:30, 11 December 2008 (UTC)

Extremecarver: You wrote: typ -- needed for custom displaying of objects. google for typ-file. Needed for GPS... - I am not sure whether I understood that right - you need the typ file during the generation of the .img file, but you do not need to download it to the garmin device - right?

You need Typ files for displaying custom polylines/obejcts/gons as well as for changing the layout of the map. You don't need it during generation, but you need to build it upon your style-file (or depreceated map-features) so that your definitions are matching. You have to integrate the typfile to the maps (best integrate it in Mapsource via regsitry (use mapsettoolkit), but you can also do this later with gmaptool or cgpsmapper I think.

Version 0.60 and new mkgmap features

Hi Nop, sorry for not providing feedback to you sooner. I tried out version 0.60 and it seemed to work allright. However my map-features file produces faulty maps with newer mkgmap versions (I have some programming errors in it) so I didn't get to test very much. Did you notice that much of the functionality of osm_composer is now included to mkgmap?

• Relation/Routes (I have proposed that that relations will be implemented as an overlay, that would be much more usefull)
• Multiple Tag Parsing and Replacements (a bit complicated right now, but can do everything like osm_composer - simply needs more configuration)

being the major ones. There is still some more adaptions to do before it gets really usefull and up to the possibilities of OSM_Composer. Some of the work you are letting run with osm_composer could be overtaken by mkgmap, or maybe you have a look at mgkmap sourcecode in SVN to find out how to make the last adaptions. Also map-features is kinda depreceated now. The successor is called --style-file and much more inline with osm_composer (seperate files for overlays, lines, polygons, poi, relations, options). I will try tomorrow to parse the osm data file created by osm_composer with --style-file to mkgmap as my --style-file produces maps without faults with OSM_Composer.--Extremecarver 21:56, 15 December 2008 (UTC)

I had a look at the various mkgmap pages, but I could not find any current information about those features. Where are you getting your version? --Nop 12:54, 16 December 2008 (UTC)

You can get them here: http://www.mkgmap.org.uk/snapshots/ (standard trunk with one nightly version per day approx), or here http://www.mkgmap.org.uk/index.html (nod trunk) including autorouting when used with --route and mp files. I however compile from SVN myself (once setup I just need to run a batch file to download the newest diffs, and compiling it). Unfortunately most documentation (especially on the wiki) is not updated yet. Current SVN version is 824. Some documentation (overlays/replacements) has only been talked about in the mailinglist for now. --style-file scheme and Regex rules are explained however in /resources/help/--Extremecarver 13:09, 16 December 2008 (UTC)

It seems the new version of mkgmap is becoming usable and somewhat documented now. OSM Composer will support the new features, but it will still be some time before that. Composer does a lot of work fixing Bugs in mkgmap, especially with the MapSource installation. All this needs to be rechecked whether anything has been fixed or changed in the new version. Also, Composer now does almost support creating Mapnik styles as well as mkgamp styles, so I will have to finish the Mapnik support before I change all the rule handling and all changes will have to be done in a way that both generators are supported. This will take a little time, V0.7 of Composer will still be for mkgmap 590. --Nop 11:47, 10 January 2009 (UTC)

Get rid of contour lines

OSM Composer is a very powerful tool to generate up2date maps. I would like to generate just a common map without contour lines, do to some route mapping - is it possible to get rid of the coutour lines using OSM COmposer? If yes: how? Drbobo 02:24, 28 December 2008 (UTC)

Hm, never thought of that. It should be possible if you provide a dummy *_contour.osm file (must be valid OSM as it is handed to mkgmap and > 100 Bytes), then Composer will not try to generate one. Maybe I should simply add a switch. --Nop 23:03, 29 December 2008 (UTC)

Having a switch to turn off the contour lines would be great and IMHO very useful. Drbobo 17:25, 30 December 2008 (UTC)

OSM Composer und Multipolygone

In einem größeren Waldstück befinden sich Wasserflächen und Lichtungen. Das Waldstück bildet in einem Multipolygon den "outer", die Wasserflächen und Lichtungen die "inner". Nach dem Übertragen der Image-Datei werden die "inner" als Flächen nicht angezeigt. Obwohl jedoch ein zur Wasserfläche gehörender Name angezeigt wird. Verschiebt man auf dem Garmin etrex VISTA HCx den Kartenausschnitt, werden die Wasserflächen ganz kurz sichtbar. Es gibt weitere Konstellationen dieser Art, bei denen alle "inner" korrekt zu sehen sind, aber auch wiederum andere, bei denen dies nur teilweise der Fall ist. Wo liegt der Fehler? Falls Daten benötigt werden, bitte Rückmeldung. Danke! Svalbard 04.01.2009 20:46

meines Wissens werden Multipolygone von Garmin Geräten bzw. mkgmap nicht unterstützt. --Nop 22:45, 4 January 2009 (UTC)

neuest mkgmap Versionen unterstuetzen Multipolygone, jedoch irgendwie noch nicht korrekt. Im Wienerwald kann man ganz gut sehen dass es manchmal funktioniert, und manchmal nicht. Je groeßer das Multipolygon, desto haeufiger gibts Fehler! Falls ihr rausfindet warum es manchmal nicht funktioniert, schreibts hier oder gleich in der Mailing List von mkgmap!--Extremecarver 23:10, 4 January 2009 (UTC)

Ok, korrigiere. Mkgmap unterstützt Multipolygone noch nicht. --Nop 09:17, 5 January 2009 (UTC)

Using with mkgmap routable

Is it possible to use the routable mkgmap? Maning 07:38, 14 January 2009 (UTC)

Currently not. Map Composer's composition technique relies on mkgmap keeping the drawing order of the osm items. The last version that does this is r590, all later version draw the data at random, messing up the map. I have asked for a fix, but until there is one, the routing version cannot be used. --Nop 13:41, 14 January 2009 (UTC)

There will be many many more things to do, because you need osm2pl to convert osm to Polish Map before. That script would need to be heavily adapted first. Realistically any maps with many advanced features will only be routable once mkgmap supports routable maps directly from osm. Currently things like --style-file or depreceated map-features.csv are not taken into account when creating routable maps.--Extremecarver 14:10, 14 January 2009 (UTC)

Not able to run OSM Composer

When running start.bat, always show below error: Exception loading tables java.io.IOException: Not a NDSC table file: C:\Documents and Settings\ad\Desktop\map_composer_060\GarminItem.tbl I am not able to find the reason for this :( Any advice? Thanks boyamyxia 5 May 2009

Looks like the table has been corrupted or you are using a very old table with a new version of the program. Can you tell us about the versions? If you did not modify the map objects and rules, it might be the most simple solution to replace the tables from the installation zip. --Nop 09:05, 5 May 2009 (UTC)

I use the V0.60 download from here and unzip to one folder, the result is the same. Very strange... The error code details as below: boyamyxia 19 May 2009

      09-5-19 9:32 Exception loading table file C:\Documents and Settings\adm\Desktop\map_composer_060\GarminItem.tbl
      Line number 281
      creating table Garmin/TYP
      java.lang.RuntimeException: missing delimiters in data line
      at nop.ndsc.table.Header.tokenize(Header.java:124)
      at nop.ndsc.table.Header.load(Header.java:143)
      at nop.ndsc.Table.load(Table.java:215)
      at nop.ndsc.Table.init(Table.java:137)
      at nop.ndsc.Table.<init>(Table.java:111)
      at nop.ndsc.Table.<init>(Table.java:101)
      at nop.osmc.MapComposer.initData(MapComposer.java:93)
      at nop.ndsc.MainFrame$1.run(MainFrame.java:112)
      at java.lang.Thread.run(Unknown Source)
      09-5-19 9:32 java.io.IOException: Not a NDSC table file: C:\Documents and Settings\adm\Desktop\map_composer_060\GarminItem.tbl
      09-5-19 9:32 Exception loading tables
      java.io.IOException: Not a NDSC table file: C:\Documents and Settings\adm\Desktop\map_composer_060\GarminItem.tbl
      at nop.ndsc.Table.load(Table.java:229)
      at nop.ndsc.Table.init(Table.java:137)
      at nop.ndsc.Table.<init>(Table.java:111)
      at nop.ndsc.Table.<init>(Table.java:101)
      at nop.osmc.MapComposer.initData(MapComposer.java:93)
      at nop.ndsc.MainFrame$1.run(MainFrame.java:112)
      at java.lang.Thread.run(Unknown Source)

It's weird, as nobody else has reported problems of that kind. Can you please send me the file GarminItem.tbl to ekkehart at gmx dot de? --Nop 05:45, 19 May 2009 (UTC)

OSM Composer unter Linux

Mit etwas Bastelarbeit ist OSM Composer auch unter Linux ans Laufen zu bringen. Unter OpenSuse 11.1 ist zusätzlich das mono Paket zu installieren.

Man läd sich zuerst die beiden zip Archive map_composer_074.zip und osmc_starthilfe.zip herunter und installiert sich diese z.B. in seinem Home-Verzeichnis unter mapcomposer.

In dieses Verzeichnis kopiert man sich folgendes Script mit Namen start.sh

#!/bin/sh

java -Xmx1200M -verbose -client -cp ndsc15.jar:nop.jar:stax-1.2.0.jar:colorpicker.jar:bzip2.jar -jar map_composer.jar nop.osmc.MapComposer

Dieses Script mittels "chmod 755 start.sh" ausführbar machen.

Dann wechselt man in das Tools-Unterverzeichnis und kopiert sich die Linux-Versionen von sendmap und cgpsmapper in dieses Verzeichnis. Als nächstes ins Unterverzeichnis srtm2osm wechseln und ein Script mit Namen Srtm2Osm anlegen und dieses ebenfalls mittels "chmod 755 Srtm20sm" ausführbar machen. Der Pfad zu Srtm20sm.exe bitte im Script anpassen!.

#!/bin/sh

mono /home/uli/mapcomposer/Tools/srtm2osm/Srtm2Osm.exe $*

Jetzt kann man den OSM Composer mittels start.sh starten und muss noch die Programme unter Einstellungen->Garmin an die obigen Scripte anpassen. --Uli1969 17:13, 11 June 2009 (UTC)