Talk:OSM Composer

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)

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)

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?

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)

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)

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 should not need this as they are all evaluated so the order is not that important. --Nop 22:16, 30 October 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)

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)