Thanks to Ralf Kleinesel, I successfully created a map with three layers, using three different styles: * default: the basic map * routes: public transportation (bus, rail, ferry) * control: traffic_calming=* points (for now; later, could display zebra crossings, traffic lights, speed limits, oneway streets and so on) I would like to commit the "routes" and "control" styles to mkgmap within a couple of days. If anyone has any objections, speak up now. The "routes" style misuses line styles 0x1d, 0x1e for bus and rail routes. These are good, because they are visible at almost any detail or zoom level. That is, the rail routes will not disappear when you zoom to wider than 500m, even though railways disappear. I created a custom TYP file with http://ati.land.cz/gps/typdecomp/editor.cgi for the line patterns and I plan to publish the TYP file at http://www.polkupyoraily.net/osm/ along with all other files. I believe that these layer style files would have to include a TYP file. I don't have a clear idea how to package the TYP files. Can mkgmap look for TYP files inside a style directory? Should it? Marko
On Fri, May 7, 2010 at 7:13 PM, Marko Mäkelä <marko.makela@iki.fi> wrote:
I believe that these layer style files would have to include a TYP file. I don't have a clear idea how to package the TYP files. Can mkgmap look for TYP files inside a style directory? Should it?
The problem with the TYP files is that the family and product IDs have to match that of the map being generated. I have the following workflow in place: 1. My "generic" TYP file is in a directory where the style directories also are. 2. My map building script copies the TYP file to the directory where the current map is to be generated. In the copy process, the TYP file is also renamed to a unique name matching the current map . (If I recall, the TYP file name must also be unique if combining with several different maps.) 3. A Perl script then adjusts the TYP file family and product IDs to match that of the map being generated. 4. The adjusted TYP file is then passed as a parameter to mkgmap as the map is generated. Therefore, I would suggest that you think about distributing your TYP file, potentially with the style files, but note that users will have to adjust the name and IDs when they generate their own maps. (And by the way, thanks for taking the initiative on this. Last year I created a test public transportation layer, but have not had time to document or distribute what I did.) Cheers.
Clinton Gladstone wrote:
3. A Perl script then adjusts the TYP file family and product IDs to match that of the map being generated.
Aahh. :-) I made a program that patches this number. Oops, I think, I patch just the family-id, not the product-id. Is this necessary?
4. The adjusted TYP file is then passed as a parameter to mkgmap as the map is generated.
So do I. But I need nevertheless two typ files and two style files (for the Oregon and the Etrex). When I use certain numbers they can be good for the Etrex but harmful for the Oregon. (The Oregon gets lost in a boot up and crash cycle)
Therefore, I would suggest that you think about distributing your TYP file, potentially with the style files, but note that users will have to adjust the name and IDs when they generate their own maps.
And a certain note would also not be wrong: "Use it at your own risk". "If you have a sd-Card inside your unit use it rather on the sd card than on the flash space of your unit." This file is tested on a Garmin "whatever", so I am pretty sure, that it workes for Garmin devices of this type. Dani (just to be sure ...)
Hi all, mkgmap already contains a class uk.me.parabola.imgfmt.app.typ.TYPFile (written by Thomas Lußnig) which has a method setFamilyId(). I have not tested it yet, but I suppose this method just changes the family id of the TYP file. Is there any reason why mkgmap should not use this method to adjust the family id of an included TYP file? Best wishes Christian Daniela Duerbeck schrieb:
Clinton Gladstone wrote:
3. A Perl script then adjusts the TYP file family and product IDs to match that of the map being generated.
Aahh. :-) I made a program that patches this number. Oops, I think, I patch just the family-id, not the product-id. Is this necessary?
4. The adjusted TYP file is then passed as a parameter to mkgmap as the map is generated.
So do I. But I need nevertheless two typ files and two style files (for the Oregon and the Etrex). When I use certain numbers they can be good for the Etrex but harmful for the Oregon. (The Oregon gets lost in a boot up and crash cycle)
Therefore, I would suggest that you think about distributing your TYP file, potentially with the style files, but note that users will have to adjust the name and IDs when they generate their own maps.
And a certain note would also not be wrong: "Use it at your own risk". "If you have a sd-Card inside your unit use it rather on the sd card than on the flash space of your unit." This file is tested on a Garmin "whatever", so I am pretty sure, that it workes for Garmin devices of this type.
Dani (just to be sure ...)
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Sat, May 08, 2010 at 09:56:41PM +0200, Christian Gawron wrote:
Hi all,
mkgmap already contains a class uk.me.parabola.imgfmt.app.typ.TYPFile (written by Thomas Lußnig) which has a method setFamilyId(). I have not tested it yet, but I suppose this method just changes the family id of the TYP file.
Is there any reason why mkgmap should not use this method to adjust the family id of an included TYP file?
Good idea, I was thinking about the same. The Product ID would have to be adjusted as well, I think. Marko
On Fri, May 07, 2010 at 07:28:28PM +0200, Clinton Gladstone wrote:
The problem with the TYP files is that the family and product IDs have to match that of the map being generated.
Oh, right, I missed that. If only someone wrote an open source TYP file generator that processes text files. I still do have the plan to write something in Perl or GNU Assembler.
Therefore, I would suggest that you think about distributing your TYP file, potentially with the style files, but note that users will have to adjust the name and IDs when they generate their own maps.
Preferrably I would distribute just the source files (a Perl script or GNU assembler input, and the script to drive the translation). For now, I plan to distribute the TYP file, outside mkgmap. Even the "routes" style is somewhat useable without a TYP file. It is merely confusing to look at the map when the public transportation routes are displayed as boundaries on top of a map that already has administrative boundaries between suburbs.
(And by the way, thanks for taking the initiative on this. Last year I created a test public transportation layer, but have not had time to document or distribute what I did.)
No problem, I find public transportation second best to human-powered transportation (walking&bicycling), and want to serve this important audience too. I am open to any suggestions you might have, such as differentiating different modes of rail transportation. Currently trams, railway, subway are shown in the same line style, and subway routes are shown even where they are underground. The POIs for the stops are in the default style, because I think that someone who knows the city doesn't need the "routes" layer most of the time, but will still find it useful to search for stops. I think that the "routes" layer should only show lines. One problem with route relations is a limitation of the current "apply" command in the relations style file. It would be nice to apply the relations in a sorted order (by ref or name) and to filter out duplicates. If you have a bus route split in two relations (one per direction), you will see the bus line ref twice on ways that are used in both route directions. Likewise for stops that are used for both route directions (the start and end stops, at least). I posted a patch as the base of discussion some time ago, but nobody replied. This is not just about bus or train routes, but about any route relations. Best regards, Marko
participants (4)
-
Christian Gawron -
Clinton Gladstone -
Daniela Duerbeck -
Marko Mäkelä