My involvement in mkgmap and the default style
The mkgmap default style has not been changed much ever since the current style language was implemented. I was appointed the maintainer a couple of years ago, after I had submitted some patches. I am sorry for my low level of activity around mkgmap in the past year. I started refactoring the default style, but I had to suspend that, because I got too busy at my day job. Two weeks ago, I made the deadline and started vacation from work, but not from family. :-) I think I could pick up where I left with regard to splitting the default style, some time in August or later. Long term, I am going to escape the Garmin world. The USB interface on my Edge 705 died last October or November, so that I can no longer transfer any saved GPS traces to the computer. So, I bought myself a SonyEricsson Xperia Active for replacing both my GPS receiver and a decade-old dumbphone. There was some initial firmware trouble, but now with the SportyPal bike mount and OsmAnd 0.8 I am satisfied. The GPS accuracy may be slightly worse than that of the Edge, but the Bing aerial image coverage largely compensates for that. Battery life is not a problem, thanks to my DIY dynamo-powered USB charger. Also, I like the offline vector maps and offline routing that OsmAnd 0.8 supports. The bicycle routing might currently be even worse than Garmin's if possible, but the map display will not freeze while recalculating, and I get spoken turn instructions, even for following a GPX trace. I wonder if it would make sense to share some front-end code and area (boundary) processing code between mkgmap and OsmAndMapCreator. Both have been written in Java, after all. I have deliberately tried to avoid touching program code too much, because I get enough of that in my day job (writing C and C++). Even if I will likely not be using Garmin maps much, I plan to keep updating the map of Finland at http://www.polkupyoraily.net/osm/ (and fixing any issues reported by mkgmap) until someone else volunteers. Best regards, Marko
Hi Marko,
The mkgmap default style has not been changed much ever since the current style language was implemented.
I was appointed the maintainer a couple of years ago, after I had submitted some patches.
I am sorry for my low level of activity around mkgmap in the past year.
You are welcome. There haven't been complaints on the list so the default style seems to be ok ;-)
I started refactoring the default style, but I had to suspend that, because I got too busy at my day job. Two weeks ago, I made the deadline and started vacation from work, but not from family. :-)
I think I could pick up where I left with regard to splitting the default style, some time in August or later.
Yes, that would be great if you can finish that. I am not a big style implementor but I have the feeling that some changes to the implementation would be great. Including of styles seems to be not very intuitive (I must admit I haven't tried that yet so don't blame me if that's not the case... ;-).
Long term, I am going to escape the Garmin world. The USB interface on my Edge 705 died last October or November, so that I can no longer transfer any saved GPS traces to the computer. So, I bought myself a SonyEricsson Xperia Active for replacing both my GPS receiver and a decade-old dumbphone. There was some initial firmware trouble, but now with the SportyPal bike mount and OsmAnd 0.8 I am satisfied. The GPS accuracy may be slightly worse than that of the Edge, but the Bing aerial image coverage largely compensates for that. Battery life is not a problem, thanks to my DIY dynamo-powered USB charger. Also, I like the offline vector maps and offline routing that OsmAnd 0.8 supports. The bicycle routing might currently be even worse than Garmin's if possible, but the map display will not freeze while recalculating, and I get spoken turn instructions, even for following a GPX trace.
I wonder if it would make sense to share some front-end code and area (boundary) processing code between mkgmap and OsmAndMapCreator. Both have been written in Java, after all. I have deliberately tried to avoid touching program code too much, because I get enough of that in my day job (writing C and C++).
The boundary processing is quite special in mkgmap and I don't know the OsmAndMapCreator. But maybe OsmAndMapCreator may share the precompiled boundary format and the way how they are used.
Even if I will likely not be using Garmin maps much, I plan to keep updating the map of Finland at http://www.polkupyoraily.net/osm/ (and fixing any issues reported by mkgmap) until someone else volunteers.
Best regards,
Marko
Have fun! WanMil
There haven't been complaints on the list so the default style seems to be ok ;-)
No, the default marine style needs some work. Have a look at openseamap.org and search for Mainz. Here are lots of new IENC features like the fairway and many types of buoys and signs. Most of them are missing in the marine default style. Only the lateral buoys and the yellow ones are rendered on the Garmin map.
Od: <rheinskipper1000@gmx.de>
There haven't been complaints on the list so the default style seems to be ok ;-)
No, the default marine style needs some work. Have a look at openseamap.org and search for Mainz. Here are lots of new IENC features like the fairway and many types of buoys and signs. Most of them are missing in the marine default style. Only the lateral buoys and the yellow ones are rendered on the Garmin map.
Hi Marko/others, I am just search easiest and most efficient way how to build map for my outdoor activities. Using default style would be great way. I just build map of Finland without usinng any TYP file and style-files and comparing it to my map build with custom TYP file and styles files. I am using qlandkartegt for comparing, but default map looks very different in qlandkarte then in my Garmin. Probably because I need TYP file in same dir fo qlandkartegt shows map corectly. How can I get default TYP file? 1) There is just general forest(50) Suggestion: forest coniferous forest deciduous forest mixed forest general ... when tag for type of forest is missing. 2) Trail (16) grey line is not very visible on any background 3) Some important symbols are missing. e.g. amenity=quelle natural=quelle natural=spring amenity=spring alpine_hut wilderness_hut basic_hut lean_to viewpoint cave piste chairlift t-bar lift lighthouse Just very brief check probably more things are missing. Let me know if this testing is helpful or I should test different way. regards mira
On Mon, Jul 23, 2012 at 09:18:08PM +0200, Jaromír Mikeš wrote:
I just build map of Finland without usinng any TYP file and style-files and comparing it to my map build with custom TYP file and styles files.
I am using qlandkartegt for comparing, but default map looks very different in qlandkarte then in my Garmin. Probably because I need TYP file in same dir fo qlandkartegt shows map corectly. How can I get default TYP file?
Long time ago, I got the impression from Extremecarver that each Garmin unit can have a different built-in "TYP file", which is used when no TYP file is included in the map-set. My experience is limited to the Edge 705 and the GPSMap 60CSx. I do not care that much about the map presentation, because I rarely go off-road. POI search is more important to me.
Let me know if this testing is helpful or I should test different way.
Well, I think it could be useful to introduce a TYP file that goes with the default style. What do you think? Marko
Od: Marko Mäkelä <marko.makela@iki.fi>
On Mon, Jul 23, 2012 at 09:18:08PM +0200, Jaromír Mikeš wrote:
I am using qlandkartegt for comparing, but default map looks very different in qlandkarte then in my Garmin. Probably because I need TYP file in same dir fo qlandkartegt shows map corectly. How can I get default TYP file?
Long time ago, I got the impression from Extremecarver that each Garmin unit can have a different built-in "TYP file", which is used when no TYP file is included in the map-set. My experience is limited to the Edge 705 and the GPSMap 60CSx.
Huh ... that surprise me. I thought defaut.TYP is build-in mkgmap.jar In this case is case it is very unpredictable which way things will be displayed on user's unit. For e.g. I have garmin 78 which is meant for marine ... I can imagine that build-in TYP is tuned for displaying sea items, but I use it mostly for outdoor.
I do not care that much about the map presentation, because I rarely go off-road. POI search is more important to me.
My preferences are different I like to visit remote places and there many landscape information are important like: type of vegetation, peaks of mountains, direction of streams, all types of shelters, springs and so on.
Well, I think it could be useful to introduce a TYP file that goes with the default style. What do you think?
Definitely! It looks like only way to guarantee same presentation for all user on any unit. And also same look in qlandkartegt. Please have a look this short thread. http://sourceforge.net/mailarchive/forum.php?thread_name=203731.12204.11564-... mkgmap has compiler now so it can be distributed even in txt format. It can be maybe easier for maintaining. http://wiki.openstreetmap.org/wiki/Mkgmap/help/typ_compile I even think that later there could be more TYP file for different usages. best regards mira
On Tue, Jul 24, 2012 at 11:08:03PM +0200, Jaromír Mikeš wrote:
mkgmap has compiler now so it can be distributed even in txt format. It can be maybe easier for maintaining. http://wiki.openstreetmap.org/wiki/Mkgmap/help/typ_compile
Yes, the reason to write yet another translator was to have a free (as in speech) implementation, and to have the TYP file sources in a friendly format for a version control system. (Version control systems usually work by generating line-by-line diffs between revisions. The diagnostics (say, "svn diff" or "svn blame" cannot work well with binary blobs.)
I even think that later there could be more TYP file for different usages.
Sure. Now, just go ahead and write some TYP files. :-) Or ask the maintainers of existing TYP files to license the files. Note that unlike the style files which are merely translation rules, the TYP files are copied to the output. This probably means (I am not a lawyer) that the copyright license of the TYP file should be compatible with the rest of the input files (usually, an OpenStreetMap extract). If a TYP file source were licensed as GPL, it would probably be too restrictive. (You would have to accompany each copy of the map with the GPL license text and a copy of the TYP file source, or a written offer for the source.) The TYP file source license should be somewhat more liberal, I guess. Maybe CC0 or even PD? Marko
Am 25.07.2012 21:29, schrieb Marko Mäkelä:
I even think that later there could be more TYP file for different
usages. Sure. Now, just go ahead and write some TYP files.:-) Or ask the maintainers of existing TYP files to license the files. If you want to, you could use my TYP-File of RadReiseKarte. It's cc-by, but I don't know if it is a good thing to use other TYP-files because they mainly only works with the corresponding style-files.
Henning
Od: aighes <osm@aighes.de>
Hi Henning,
If you want to, you could use my TYP-File of RadReiseKarte.
I like the screenshot http://www.aighes.de/OSM/index.php?lang=en I extracted TYP file from your map.exe can I use it as starting point for my own TYP file which I would maintain?
It's cc-by,
mailing list maybe not allowing attachments?
but I don't know if it is a good thing to use other TYP-files because they mainly only works with the corresponding style-files.
That's the point! Marko, is somewhere some kind of chart which shows symbols used by mkgmap default style? I mean something like this: for e.g. water -> 0x3c00 sea -> 0x10f1d and so on best regards mira
On Thu, Jul 26, 2012 at 01:01:33AM +0200, Jaromír Mikeš wrote:
Marko, is somewhere some kind of chart which shows symbols used by mkgmap default style? I mean something like this: for e.g. water -> 0x3c00 sea -> 0x10f1d and so on
Uh, isn't that the default style? In the mkgmap source code, it is in resources/styles/default/{points,lines,polygons} I started splitting the default style into sub-styles, but did not complete the task yet. Currently there are a few sub-styles: contours_ft landuse waters You will have to check the points,lines,polygons files in these directories as well. Best regards, Marko
Od: Marko Mäkelä <marko.makela@iki.fi>
Hi Marko,
Marko, is somewhere some kind of chart which shows symbols used by mkgmap default style?
Uh, isn't that the default style? In the mkgmap source code, it is in resources/styles/default/{points,lines,polygons}
Of course ;)
I started splitting the default style into sub-styles, but did not complete the task yet. Currently there are a few sub-styles:
contours_ft landuse waters
As I said before I am mainly interested in hiking do you thinking to make dedicated style fo that too? Would be great. Meanwhile I am working on TYP file ( which is also hiking oriented) I found few troubles for me: POIS tourism=attraction and tourism=viewpoint ... both same symbol 2c04 Can get different? tourism=alpine_hut tourism=hostel ... both same symbol 2d02 Can get different? tourism=campsite tourism=caravan_site ...both 2b03 Can get different? tourism=basic_hut .... missing man_made=cairn LINES natural=cliff missing POLYGONS natural=beach | natural=sand ... missing natural=scree missing landuse=meadow | natural=fell ... missing wood=mixed wood=deciduos | wood=deciduous wood=coniferous Would be also great to have possibility recognize vegetation. Do you it is possible to add this to mkgmap styles? One question about copyright field in TYP file ... Few commented-out lines in top of typ.txt file is fine way how to do it? best regards mira
You might be interested in my style and typ files which capture a lot of the elements you're after: http://www.cferrero.net/maps/map_downloads.html On 27 Jul 2012, at 04:07, Jaromír Mikeš <mira.mikes@seznam.cz> wrote:
Od: Marko Mäkelä <marko.makela@iki.fi>
Hi Marko,
Marko, is somewhere some kind of chart which shows symbols used by mkgmap default style?
Uh, isn't that the default style? In the mkgmap source code, it is in resources/styles/default/{points,lines,polygons}
Of course ;)
I started splitting the default style into sub-styles, but did not complete the task yet. Currently there are a few sub-styles:
contours_ft landuse waters
As I said before I am mainly interested in hiking do you thinking to make dedicated style fo that too? Would be great.
Meanwhile I am working on TYP file ( which is also hiking oriented) I found few troubles for me:
POIS tourism=attraction and tourism=viewpoint ... both same symbol 2c04 Can get different?
tourism=alpine_hut tourism=hostel ... both same symbol 2d02 Can get different?
tourism=campsite tourism=caravan_site ...both 2b03 Can get different?
tourism=basic_hut .... missing
man_made=cairn
LINES natural=cliff missing
POLYGONS natural=beach | natural=sand ... missing natural=scree missing landuse=meadow | natural=fell ... missing
wood=mixed wood=deciduos | wood=deciduous wood=coniferous
Would be also great to have possibility recognize vegetation. Do you it is possible to add this to mkgmap styles?
One question about copyright field in TYP file ... Few commented-out lines in top of typ.txt file is fine way how to do it?
best regards
mira
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, you'll find it here: http://www.aighes.de/OSM/data/style.zip Linked on bottom of the download-site. In the zip, you'll find the txt-file (rrk_tyt.txt) in data directory. mkgmap generates the typ-file from the txt-file. If you extract the TYP-file from a map, it isn't a problem at all. You just have to take care about Family-ID and Product-ID. Henning
Hi, also my style and typ files could be interesting: http://wiki.openstreetmap.org/wiki/User:Computerteddy#Typ-_und_Stylefiles -- Viele Grüße Carsten
Marko Mäkelä <marko.makela@iki.fi> writes:
Long time ago, I got the impression from Extremecarver that each Garmin unit can have a different built-in "TYP file", which is used when no TYP file is included in the map-set. My experience is limited to the Edge 705 and the GPSMap 60CSx. I do not care that much about the map presentation, because I rarely go off-road. POI search is more important to me.
I have the impression there is a default TYP-type style for various families of units (etrex vista HCx is different from oregon 450, for instance) for mkgmap maps w/o a TYP file. So I agree with the above.
Let me know if this testing is helpful or I should test different way.
Well, I think it could be useful to introduce a TYP file that goes with the default style. What do you think?
Agreed. People talk about styles and TYP for specific purposes. I think a good plan is to have a main style that tries to be comprehensive (hikers don't care so much how the roads look and drivers don't care so much about trails, so each can be optimized) and then to see where we are. Issues that I see are: licensing: given ODbL and the complexity of license compatibility, CC0 makes sense for style and TYP. I don't think we as a community have any worry about someone taking styles private and spiffing them up and providing proprietary builds. I think the big point is that we have to be careful about only including things with consent from copyright holders. style/TYP interface: TYP can describe a rendering for elements that are already normal, and it can describe rendering for line and point types that are not normally in use. Ideally we could mix/match style and TYP, and I think that means having a plan for which codepoints have which meaning. That will allow decoupling of figuring out the mapping from osm to codepoints (not just which, but whether to include and at what scale), and display of codepoints. TYP can be beyond-style: it seems fine to have a TYP define lots of things that a style doesn't use. So a lot of people can use the same TYP. multiple codepoints for a reason: it's possible we could define a range of codepoints for the same semantics, and have multiple renderings in one file, so that the style could be changed to make the output change, without changing the TYP. But maybe we should see how much conflict there is. So I'm advocating: a definition of codepoints a default TYP file with a rough consensus render for those codepoints a default style that expects the default TYP file perhaps a 'basic' style that works w/o a TYP I've been using Charlie's TYP file (and style) and think it's a great improvement. I wonder if it makes sense for everyone who is maintaining a TYP to convert it to mkgmap input format and trim things for which they can't grant CC0, and publish that. I suspect that it would not be too contentious to try to merge the best of the existing TYPs. Other approaches are possible - I'm just rambling about how to manage complexity and get the best maps with the least total brain time. Greg
participants (8)
-
aighes -
Carsten Schwede -
Charlie Ferrero -
Greg Troxel -
Jaromír Mikeš -
Marko Mäkelä -
rheinskipper1000＠gmx.de -
WanMil