Cutting down the default style
I work with typviewer which is capable of importing en exporting text files: http://opheliat.free.fr/michel40/TYPViewer3.5/ It is free to use but there is no info about under what license it can be used. You can ask the developer about the source code. You can have a look at http://code.google.com/p/mkgmap-style-s … efault.txt to see if this is workable or not. Also there is Nick Willinks Typwiz editor, http://www.pinns.co.uk/osm/ He is on this list so he might comment on this.
Correct link to my typ/txt files: http://code.google.com/p/mkgmap-style-sheets/source/browse/trunk/typ/world-t...
I agree TYP files are the way forward to 'liven up' IMG files. Creating a default TYP catering for everyone's needs is a no brainer. It would mean standardising type numbers which in my opinion won't be popular and indeed impair current flexibility: Cyclists and walkers rarely agree on what needs to rendered;to the former benches may be clutter,to the latter cycle hire shops a luxury. I can see some merit in establishing a basic default TYP - OK for highways & polygons but more troublesome for POIs. Both Michel's TypViewer & my TYPWiz are written in binary ; I have however made public my findings on the TYP Format - srch Ggle -- View this message in context: http://gis.638310.n2.nabble.com/Cutting-down-the-default-style-tp6978402p697... Sent from the Mkgmap Development mailing list archive at Nabble.com.
n Willink <nw@pinns.co.uk> writes:
Creating a default TYP catering for everyone's needs is a no brainer. It would mean standardising type numbers which in my opinion won't be popular and indeed impair current flexibility: Cyclists and walkers rarely agree on what needs to rendered;to the former benches may be clutter,to the latter cycle hire shops a luxury.
I don't follow this, and I wonder if I'm confused. As I see it a TYP defines a way to render a (possibly large) set of feature codes a style maps osm tags to feature codes feature codes don't have much to do with routing; there is other data also mapped by the style file that controls that So if a TYP has a lot of renderings, then there can be different styles using them. An example of this is Charlie's 'mapsource' and 'gps' styles, which use the same TYP, but have webmap-style casings and traditional-top-style lines respectively. Are you saying that if there are 4 fill patterns for forest with different codes, then that's somehow a problem (vs people just choosing which they want)? Is the issue running out of codes, or the TYP getting huge, or ?
Perhaps we're both saying the same thing. You could in theory have a TYP file which uses recommended types as created by a default style. You will have a problem with routable highways in particular as the available type numbers are fairly limited - subtypes are only reserved for extended types It could be done with most non routable polylines reserved for types 100+. There is a max of 1ff1f There is however one issue, in that there is little documentation as to the 'effect' of using extended types >150 The same could be done for polygons; a good example is the use of leisure=pitch and sport tag How many 'default' sports are there? My TYP file shows at least 10 but they may not be to someone elses liking. So it can be done. It is however my experience that most people after a while tend to modify a TYP to reflect their own preferences. -- View this message in context: http://gis.638310.n2.nabble.com/Cutting-down-the-default-style-tp6978402p698... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I would say there needs to be two different styles, one for without .typ-files, one for with .typ-files. because it is pretty random what happens if an object is not defined in the .typ-file. (it doesn't have to be invisible, it can be that there will be a fat big line too. Also the routable line types, could very well be left undefined in the .typ-file, this is advantageous on newer gps as well as mapsource/basecamp as they will adjust the line width depending on zoom level and pixel densitiy of the gps unit. Hence you could acutally end up with 3 styles: a) no .typ-ifle b) .typ-file only for POI and polygons as well as maybe some special lines that are unrelated to routable roads (so no bridges,tunnels, etc..) c) one style-file that makes full use of .typ-file for all POI, Lines and Polygons However I would also tend to agree that first there should be an opensource .typ-file compiler/reader. Currently most still depend on cgpsmapper to actually compile the .typfile and all have some deficiencies.
On Wed, Nov 09, 2011 at 05:00:52PM +0100, Minko wrote:
I work with typviewer which is capable of importing en exporting text files: http://opheliat.free.fr/michel40/TYPViewer3.5/
It is free to use but there is no info about under what license it can be used. You can ask the developer about the source code.
Can you ask the author? There is no email address visible on the page.
You can have a look at http://code.google.com/p/mkgmap-style-s … efault.txt to see if this is workable or not.
Sorry, what is the … hiding? Your message was text/plain only.
Also there is Nick Willinks Typwiz editor, http://www.pinns.co.uk/osm/ He is on this list so he might comment on this.
All we need is a bare-bones text-to-TYP converter. No GUI needed. Icons could be embedded in the text file in some one-character-per-pixel (ASCII graphics like) NetPBM format or imported from *.png files, if we want to be fancy (and do not mind having binary *.png files in our repository). Any of these existing conversion tools could be a starting point. The programming language does not matter; all we need is a reasonably machine-readable documentation of the TYP file format. Marko
All we need is a bare-bones text-to-TYP converter. No GUI needed. Icons could be embedded in the text file in some one-character-per-pixel (ASCII graphics like) NetPBM format or imported from *.png files, if we want to be fancy (and do not mind having binary *.png files in our repository).
I agree we need a text to TYP converter. We already have code in mkgmap that was written by Thomas Lußnig three years ago that can read and write typ files, perhaps the time has come to put it to use! I shall write a program that takes the polish-style text input as in http://mkgmap-style-sheets.googlecode.com/svn/trunk/typ/world-test/default.t... and writes a TYP file using the existing typ code, then see what is needed beyond that. ..Steve
Steve, that would be very useful. Only one thing: Latest TOPO TYP files include POIs with sizes 48x48 and in TRUE Color which allows for much clearer and more colourful icons.I wonder if his code would allow for this. The text format for these POIs has as far as I know not been standardised but I use the same as suggested by Michel Trey -- View this message in context: http://gis.638310.n2.nabble.com/Cutting-down-the-default-style-tp6978402p698... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 10/11/11 17:48, n Willink wrote:
Steve, that would be very useful.
Thanks, I am going to develop it on the trunk since the TYP file code is not at all used at the moment and I'll branch when it gets to the point of integrating or requires changes to non-TYP stuff.
Latest TOPO TYP files include POIs with sizes 48x48 and in TRUE Color which allows for much clearer and more colourful icons.I wonder if his code would allow for this.
The text format for these POIs has as far as I know not been standardised but I use the same as suggested by Michel Trey
It will be a while before I get to that, but I couldn't find the suggestion you refer to, could you give me a pointer to it? Thanks ..Steve
Have a look at I000093D.TYP which is part of a city navigator 2011 topo - because of copy protect I cannot attach typ file ; it contains various true color pois with sizes up to 48x48 which TYPWiz can parse. the following is a POI size 24x21 with colours set to zero ,ie true colors showing a little kitten created using the same program [_point] Type=0x3014 ExtendedLabels=N DayXpm="24 21 0 1" "#AA5A14" "#AA5A14" "#963C0A" "#823200" "#C88250" "#783200" "#A05A28" "#965A1E" "#BE8250" "#C8823C" "#C8823C" "#DC9650" "#D28C46" "#DC9650" "#D2823C" "#C8783C" "#BE7832" "#D29650" "#8C460A" "#8C501E" "#8C5A28" "#8C501E" "#AA7846" "#B46E3C" "#A05A28" "#BE783C" "#A05A28" "#78320A" "#A05A28" "#A0501E" "#823C00" "#B46E3C" "#BE8246" "#C8823C" "#D28C3C" "#D28C46" "#BE7832" "#B46E1E" "#B47828" "#C8823C" "#BE8232" "#C88C50" "#965A1E" "#8C5014" "#823C14" "#823C14" "#6E2800" "#8C461E" "#A05A1E" "#C88C50" "#823200" "#A05028" "#965028" "#AA6428" "#AA6E32" "#BE823C" "#C8823C" "#D28C46" "#C88232" "#C87832" "#B46E28" "#AA6E28" "#BE7832" "#B46E28" "#C8823C" "#C88246" "#B47828" "#82501E" "#783C0A" "#5A1E00" "#642800" "#781E00" "#8C4614" "#D2AA82" "#963C0A" "#96461E" "#783C0A" "#B48246" "#B4783C" "#BE7828" "#D28C3C" "#C87832" "#C87832" "#BE7828" "#AA6E28" "#C88232" "#AA6E28" "#A06E1E" "#AA6E1E" "#C87828" "#AA6E28" "#825032" "#6E3214" "#82461E" "#78320A" "#78280A" "#965A1E" "#AAA096" "#AA6E32" "#BE825A" "#C88C64" "#D29650" "#BE7828" "#D27828" "#C87828" "#BE6E1E" "#D28C3C" "#C8823C" "#BE8232" "#AA641E" "#C8823C" "#BE823C" "#BE8232" "#C87828" "#BE7828" "#B47832" "#BE9664" "#D2A078" "#965028" "#78320A" "#B4A078" "#A0A0A0" "#D2A05A" "#C88250" "#C8823C" "#C87828" "#BE6E1E" "#C8781E" "#C87828" "#BE6E28" "#C88232" "#C8823C" "#AA6E1E" "#B47828" "#BE8232" "#AA6E28" "#BE823C" "#BE7828" "#BE7828" "#B4781E" "#B47832" "#A06E28" "#965A28" "#AA6E32" "#B4A08C" "#A0A0AA" "#F0AA82" "#E6A06E" "#C87832" "#C87828" "#C8781E" "#C87828" "#D28232" "#B46E1E" "#B46E28" "#B46E1E" "#B47832" "#B46E28" "#B47832" "#AA6E28" "#C8823C" "#B47828" "#AA640A" "#AA6E14" "#B47828" "#B47828" "#AA823C" "#AA8246" "#BEAA96" "#A0A0AA" "#FAC896" "#FAAA6E" "#E69646" "#D28C3C" "#D28232" "#D28232" "#C88232" "#BE7828" "#B46E28" "#C88232" "#8C500A" "#AA6E28" "#AA6E1E" "#B4823C" "#A06E1E" "#B47832" "#B46E28" "#B46E1E" "#B47832" "#BE7832" "#B48246" "#C8966E" "#BEAAA0" "#A0A0A0" "#FAC8A0" "#FAB482" "#F0A05A" "#E69646" "#E69650" "#D28C3C" "#D28C46" "#B46E28" "#D2823C" "#AA641E" "#8C5A1E" "#AA6E28" "#8C5000" "#BE823C" "#965A1E" "#C88C50" "#AA641E" "#C88C46" "#C8823C" "#BE823C" "#C88C50" "#C89664" "#C8B4AA" "#A0A0A0" "#F0C8AA" "#FABE96" "#FAAA64" "#E69650" "#F0AA64" "#E6A05A" "#E69650" "#BE7832" "#C88232" "#A05A14" "#8C5A14" "#966414" "#B47832" "#C89646" "#A06428" "#DC9650" "#D29650" "#C88C46" "#C88C46" "#C8965A" "#C8965A" "#C89664" "#B4AAA0" "#A0A0A0" "#C8B4AA" "#FABE96" "#E6965A" "#B46E28" "#A06E3C" "#3C3214" "#281E14" "#82643C" "#D2965A" "#BE7832" "#8C5A14" "#AA7828" "#A06E32" "#A0783C" "#785A32" "#503214" "#6E501E" "#966E28" "#AA783C" "#B48246" "#BE8C5A" "#C89664" "#A0A0A0" "#A0A0A0" "#A0A0A0" "#F0AA78" "#DC965A" "#DC8C50" "#8C643C" "#5A5A50" "#141414" "#5A5032" "#DC966E" "#BE7832" "#AA6E1E" "#BE8C46" "#AA8250" "#64461E" "#1E1E14" "#000000" "#786E50" "#A06E46" "#A07832" "#B48250" "#B4823C" "#C8966E" "#A0A0A0" "#A0A0A0" "#A0A0A0" "#F0BE96" "#DCA064" "#DC9650" "#DC9664" "#3C1E00" "#968264" "#280000" "#BE8246" "#D28C50" "#BE8246" "#AA783C" "#BE965A" "#280A00" "#504632" "#786E50" "#462800" "#B48246" "#B48C50" "#BE9650" "#BE8C5A" "#D2A06E" "#AAA0A0" "#A0A0A0" "#A0A0A0" "#C8B4A0" "#F0AA6E" "#E6A05A" "#B46E1E" "#B47832" "#C89664" "#BE8250" "#AA6432" "#D2965A" "#B4783C" "#AA783C" "#AA6E46" "#8C6432" "#A07850" "#A08250" "#AA783C" "#C88C46" "#BE8246" "#BE8C50" "#C89664" "#C89664" "#C8AA96" "#A0A0A0" "#A0A0A0" "#AAA0A0" "#F0AA82" "#DC9650" "#D28C46" "#BE7832" "#BE6E32" "#E6A05A" "#BE7846" "#BE7846" "#D2966E" "#AA6E3C" "#AA7850" "#A06E32" "#AA6E3C" "#965A1E" "#BE823C" "#B47832" "#BE8C46" "#C8965A" "#C8965A" "#C8965A" "#D2A06E" "#A0A0A0" "#A0A0A0" "#AAA0A0" "#F0B482" "#DC965A" "#DC8C46" "#C8823C" "#E6965A" "#DC965A" "#C89664" "#B4783C" "#BE825A" "#B4825A" "#AA7850" "#B48250" "#BE8250" "#B48246" "#B47832" "#BE823C" "#C8965A" "#BE8C50" "#BE8C50" "#C8965A" "#D29664" "#A0A0A0" "#A0A0A0" "#BEB4A0" "#FAB482" "#F0AA6E" "#DC965A" "#FABE8C" "#DC965A" "#E6A064" "#C8825A" "#C87846" "#BE783C" "#AA6428" "#A06E46" "#C8966E" "#A06E3C" "#C88C5A" "#C88C50" "#C89664" "#BE8246" "#B4783C" "#BE8C50" "#D29664" "#C89664" "#A0A0A0" "#A0A0A0" "#F0C8A0" "#F0B48C" "#E6A064" "#E6AA6E" "#FAD2A0" "#DC965A" "#DC966E" "#E6AA78" "#823200" "#C85A1E" "#6E1E00" "#B48250" "#DCAA82" "#BE8C64" "#DCA064" "#C88C64" "#B4783C" "#AA7832" "#AA6E28" "#BE8C50" "#C8965A" "#D29664" "#A0A0A0" "#A0A0A0" "#FAC88C" "#FABE8C" "#F0B478" "#D2965A" "#B4783C" "#F0B482" "#DCA064" "#D29664" "#C8965A" "#AA5A28" "#B48246" "#BE8C50" "#BE8C50" "#C88C50" "#D2A064" "#8C5A14" "#AA7832" "#B47832" "#D29650" "#C8965A" "#C8965A" "#D2A064" "#A0A0A0" "#B4B4A0" "#F0BE8C" "#E6AA78" "#E6A06E" "#E6A064" "#BE823C" "#C8823C" "#BE8232" "#D29664" "#DC965A" "#D2965A" "#D2965A" "#D29664" "#BE8C50" "#BE8C50" "#AA6E28" "#BE8C3C" "#F0BE78" "#B4783C" "#D2A05A" "#D2A064" "#C89650" "#C89664" "#A0A0AA" "#F0D2B4" "#FABE82" "#FAC88C" "#E6A064" "#F0AA6E" "#DC9650" "#D2823C" "#BE7828" "#B46E1E" "#BE823C" "#C88C50" "#BE8C50" "#BE823C" "#AA6E1E" "#B47828" "#AA6E1E" "#B47832" "#BE8246" "#BE8C46" "#D29664" "#C88C5A" "#C88C50" "#C8965A" [end] -- View this message in context: http://gis.638310.n2.nabble.com/Cutting-down-the-default-style-tp6978402p698... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi
the following is a POI size 24x21 with colours set to zero ,ie true colors showing a little kitten created using the same program
The mkgmap typ compiler now can compile your kitten image (not checked in yet) See the attached TYP file. It can be opened and viewed with TYPViewer. TypWiz doesn't like something about the draworder section, which is empty. There are two icons in the icon set, your kitten and a low res image (not a kitten!). Since the icon sets are something different to the normal POIs there needs to be another section in the .txt file. For the lack of anything better I used so far: [_icons] Type=0x09 IconXpm="30 30 0 1" "#909090" ; etc IconXpm="20 20 10 1" "! c #909090" ; etc... lower resolution icon [end] But if you already have some other notation in use I can use that. On TYPViewer there are two buttons Additional Icons and Additional POIs, do you know what the second one means? I haven't added the new label section yet. ..Steve
You've been working hard at this! I've updated typwiz to show your typ file - I hadn't reckoned on 2 icons as it was set for 4. I think its a good idea to use icons rather than points [_icons] Type=0x09 IconXpm="30 30 0 1" "#909090" Presumably these are for the additional 'smaller' icons , not the main poi as show in Garmin's city navigator typs ... Or perhaps for all of them? I'm putting the final touches to my own saving routines and will test the code on mapsource/basecamp first - I'm a bit wary of testing it on my oregon as in the past I've managed to 'upset' the firmware and set undocumented flags. as far as Michels additional pois - I think its a stab in the dark with a navigator typ it produces the following hex dumps and additional labels 00 00 00 A6 01 00 00 FB @ HOME 19 00 07 00 A4 00 02 00 087 JALTA 00 A2 0C 00 00 38 36 00 1-2-3 11 00 00 1D 03 00 00 55 1 POTATO 2 04 00 17 00 12 01 04 00 1 STOP Strangely the hex is wrongly paired up. If you look at the block the hex acts /up to a point/ as 3 byte pointers, bit like pointers to LBL1 or NET1 in an IMG. A lot of the data is still unclear. I can see why he thinks they are additional pois as none of the labels seem to refer to the icons Interestingly, the *same *typ files is used in several different gemapsupps -- View this message in context: http://gis.638310.n2.nabble.com/Cutting-down-the-default-style-tp6978402p699... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick
I've updated typwiz to show your typ file - I hadn't reckoned on 2 icons as it was set for 4.
OK thanks it works now!
I think its a good idea to use icons rather than points
[_icons] Type=0x09 IconXpm="30 30 0 1" "#909090"
Presumably these are for the additional 'smaller' icons , not the main poi as show in Garmin's city navigator typs ... Or perhaps for all of them?
It is the whole bundle of icons (4 is the typical number, as you say) at different resolutions that occur in the TYP 9 section - offset 0x66 in the header. So the for the file I posted the source with the image data removed for brevity was: [_id] FID=23 ProductCode=1 CodePage=1252 [end] [_icons] Type=0x3014 IconXpm="24 21 0 1" ; [ image data removed ... ] IconXpm="16 16 3 1" ; [ image data removed ... ] [end] So there are two icons with different resolutions associated with the typ 0x3014, one of which happens to use the true colour format. As for the true colour images themselves, you can use them in a _point section too. I don't know if it will work on a device though!
as far as Michels additional pois - I think its a stab in the dark
Oh OK, I understand.
I can see why he thinks they are additional pois as none of the labels seem to refer to the icons
There are certainly more labels than icons, but I think they do match up where an icon exists. I didn't look very hard though. ..Steve
@Marko, I can't find any contact information either, maybe try michel40 at opheliat.free.fr? Marko wrote:
Sorry, what is the … hiding? Your message was text/plain only.
Copied my link from the osm forum, sorry. The correct link to my typ/txt files is http://code.google.com/p/mkgmap-style-sheets/source/browse/trunk/typ/world-t...
participants (6)
-
Felix Hartmann -
Greg Troxel -
Marko Mäkelä -
Minko -
n Willink -
Steve Ratcliffe