December 2009 - mkgmap-dev - The mkgmap lists

some comments on mkgmap default style
by maning sambale 06 Feb '10

06 Feb '10

Hi, some observation about the default style: 1. Coastlines are shown as thin blue lines, is it possible to render coastline as polygon, where sea areas are shaded as blue. A work around I did before is to manually edit all sea-areas and then add a natural=water tag (bad data edit) . 2. Administrative boundaries clutter the map. They appear like roads and can be confusing while driving. Suggestion is to make the admin boundaries thinner. Hope it helps improving the default stylesheet. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

5 8

Help from the style file gurus
by Charlie Ferrero 23 Jan '10

23 Jan '10

Hello list, Question #1 =========== I am using the overlays style file in combination with a TYP file to define custom styles for one-way streets (overlaid blue arrows in the direction of the one-way, type 0x10), and for bridges (two parallel lines outside the road, type 0x12). This all works fine. Where I'm stuck is when I have a one-way street that is also a bridge. I had assumed that the stop/continue system would help me here, but sadly it doesn't work as I expected. The following are my style rules for trunk roads: #lines file excerpt: highway=trunk & (bridge=yes | bridge=true) [0x111 resolution 16 continue] highway=trunk & oneway!=* [0x02 resolution 16 stop] highway=trunk & (oneway=yes | oneway=true) [0x123 resolution 16 stop] #overlays file excerpt: 0x111: 0x02, 0x12 0x123: 0x02, 0x10 Applying these rules results in one-way bridges having the bridge styling, but no one-way symbols (see attached screenshot; the fact that the railway is plotted on top of the bridge is quite another problem). Can a style guru point me towards where I'm going wrong? Question #2 =========== Does the stop/continue system work across style files? In other words, if I've got a polygon that is tagged: sport=tennis barrier=fence And in my style files I've got: #lines barrier=fence [0x2d resolution 23 default_name 'Fence'] #polygons sport=* [0x19 resolution 23] mkgmap by default will process the lines file first and plot the fence. It will not then process the polygons file, so all I see in the resulting map is a fence. Can I use continue/stop (once I've learned how to use it properly) to plot both the fence and the area? Thanks, -- Charlie

6 18

Understanding the sea
by Mark Burton 08 Jan '10

08 Jan '10

Hi, I'm trying to understand how the --generate-sea stuff works. I want to know how it decides whether an "island" is water or land. The code does not really contain sufficient comments for me to work out what it's doing. I would expect it to close coastline segments that reach the tile boundary in a direction that is consistent with the "water on the right" convention but I can't see that in the code. Can anyone help please? I hesitate to whine about contributions to mkgmap as I don't want to stop them arriving but if we can't easily work out how the code works then it doesn't bode well for maintenance and bug fixing when the original author has moved on. I have agreed to help produce a marine map of the Baltic so it would be really nice if the sea was filled in without any really major problems (flooded land, etc.) I realise that this is dependent on the performance of the MP stuff but it seems to me that generating the right polygons in the first place would be a good start. I guess that the Baltic area is probably rather a challenge for the current state of the art. Thanks, Mark

9 12

Commit: r1443: Combine any gmapsupp files given as input into the output gmapsupp file correctly preserving family id's etc.
by svn commit 03 Jan '10

03 Jan '10

Version 1443 was commited by steve on 2009-12-27 21:12:59 +0000 (Sun, 27 Dec 2009) Combine any gmapsupp files given as input into the output gmapsupp file correctly preserving family id's etc.

3 3

amenity=embassy not handled by mkgmap ?
by Hendrik Oesterlin 03 Jan '10

03 Jan '10

Hello, First, I would introduce myself: I am living in New Caledonia and I bought an Garmin nüvi 755 GPS because I have the possibility to import the data from openstreetmap.org. I have to travel to New Zealand next month, and during my last stay there I was sad of using my non-graphic GPS to report my position to an paper map.... especially during driving ;-) In the meantime, I got the virus and I added plenty of data to New Caledonia and I compiled an gmapsupp.img for NC. Now I noticed that an POI amenity=embassy added in OSM is not available in the produced gmapsupp.img (both with mkgmap v1303 et 1311) Is this an error in mkgmap? How can I make embassies correctly display in Garmin maps? Some of them are just tagged as amenity=public_building and display correctly on the Garmin map. But this seems to be an dirty work around, as the dedicated amenity=embassy exists. -- Kind regards Hendrik Oesterlin New Caledonia ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

5 8

Baltic map looking good
by Mark Burton 02 Jan '10

02 Jan '10

I'm really pleased how well the Baltic marine map has come along (sample pics attached). Almost makes the hours spent working on the extended type attributes worthwhile. Just need those marine people to enter into the OSM database the remainder of the 10,000 marine map objects that the area probably contains. Mark

3 6

[PATCH v1] - provide alternative sea drawing mechanism
by Mark Burton 02 Jan '10

02 Jan '10

Firstly, I would like to thank everyone who responded to my "Understanding the sea" post. From those posts and my own study, I finally worked out what it does. And yes, it works pretty well inasmuch that it generates some useful polygons. The "sea sector" heuristic doesn't work for me so I have been disabling it. The problem is, the end result is "butt ugly". Our MP implementation really can't do a good job on zillions of little islands. After frigging around for a couple of days trying to improve the visual quality, I tried the obvious alternative technique of not using a MP but, instead, just having a sea background and then put the land on top using plain polygons. Guess what? It works very nicely as the attached pics show. I now have a splendid map of the Baltic area (OK it's weird at the edges but that's not a problem for now). Here's the (future) commit comment for this patch: Provide an alternative to using a multipolygon when generating the sea. The --generate-sea option can now take a comma separated list of values: no-mp - don't generate the sea using a multipolygon - instead, generate a background sea polygon and then individual land polygons with tag natural=land. This requires a suitable land polygon type to be defined in the style file (suggested type is 0x010100) and the polygon must be defined in the TYP file as having a higher drawing level than the sea polygon type. no-sea-sectors - disable the generation of "sea sectors" when the coastline fails to reach the tile's boundary. With no values specified, the --generate-sea option should work as before. Oh yes, this patch doesn't include it, but I am also disabling the DP code for polygons as it makes them weird. Cheers and thanks again for the helpful postings. Mark

3 7

Multipolygons code rewritten (1st try)
by WanMil 01 Jan '10

01 Jan '10

Hi, I have rewritten the MultiPoloygonRelation class regarding the algorithm described in http://wiki.openstreetmap.org/wiki/Relation:multipolygon/Algorithm. This is a first (very early and not very well tested) implementation of this algorithm. I don't have time to go on with it within the next days. Multipolygons are a big discussion in the mailing list at the moment so maybe someone likes to review the code and gives some helpful comments on it. (Any comment is very welcome!!) These are the open points: * Tagged inner polygons are not considered yet! This a big open point which must be implemented next. (Some comments point to the place where to do this) * The code currently does not remove any inner or outer polygon segment. This must be changed in future. But at the moment I have no solution how to decide which segment should be removed and which segment must remain for map generation. (To be honest I did not think about it for long ;-) * The inner and outer tags in the polygon are not used at the moment. This must also be changed. * The code is completely unoptimized. It's just an early study if this can improve the multipolygon code. I am happy about any improvements! * The old insertPoints method does not consider the direction of the polygons. This can result in self intersecting polygons. I don't know if that matters but it can easily be improved. I am happy if someone can explain me if that matters than I can implement a fix (hopefully :-). * I don't know if my synthetic ids are generated well. I think there should be one synthetic generator for whole mkgmap? Have a happy new year (with the multipolygons case fixed :-))) WanMil

3 2

Commit: r1449: Provide an alternative to using a multipolygon when generating the sea.
by svn commit 31 Dec '09

31 Dec '09

Version 1449 was commited by markb on 2009-12-31 12:00:01 +0000 (Thu, 31 Dec 2009) Provide an alternative to using a multipolygon when generating the sea. The --generate-sea option can now take a comma separated list of values: multipolygon - generate the sea using a multipolygon (the default behaviour so this really doesn't need to be specified). polygons | no-mp - don't generate the sea using a multipolygon - instead, generate a background sea polygon plus individual land polygons with tag natural=land. This requires a suitable land polygon type to be defined in the style file (suggested type is 0x010100) and the polygon must be defined in the TYP file as having a higher drawing level than the sea polygon type. no-sea-sectors - disable the generation of "sea sectors" when the coastline fails to reach the tile's boundary. An unrecognised option value or the value "help" will cause some help blurb to be printed. For backwards compatibility, with no values specified, the --generate-sea option should behave as it did before.

3 7

Commit: r1451: Allow tag used for land polygons to be specified (default is natural=land).
by svn commit 31 Dec '09

31 Dec '09

Version 1451 was commited by markb on 2009-12-31 18:01:40 +0000 (Thu, 31 Dec 2009) Allow tag used for land polygons to be specified (default is natural=land). This is done with a new generate-sea sub-option, usage is land-tag=TAG=VAL. For example, --generate-sea=polygons,land-tag=foo=bah

1 0