January 2010 - mkgmap-dev - The mkgmap lists

Translating route=bus relations
by Marko Mäkelä 03 Jan '10

03 Jan '10

Hi all, The attached patch is a quick and dirty attempt at adding bus route information to the map, by appending to the street name. Some street names are not being appended to, but the patch is already generating impractically long street names near bus stations. In other words, the route information should instead be generated on layer(s) separate from the "base" map. It seems to me that the optimal translation rules for bus routes could be place-specific. For example in the Helsinki metropolitan area, ${ref} is really enough for identifying local bus routes. The attached patch displays ${network} too, but end users could infer that from ${ref}. Long-distance bus routes might need ${operator}, but they could already be identified by ${name} (a dash-separated list of place names). It would seem to make sense to have long-distance routes and local routes on separate layers. One common layer could be enough for all local routes, for ease of use too (need to disable/enable one "local bus" layer instead of selecting "local bus Helsinki", "local bus Turku" etc.) Then again, some control freaks could like to have one layer per ${network} or ${operator}. Then the labels on the lines could omit ${network} or ${operator}, only mention the ${ref}. Could someone give me a hand with map layers (families in Garmin speak, if I understand correctly)? Would I have to invoke mkgmap multiple times, once for each map layer (family) and finally to combine the families to a single gmapsupp.img? Or can I ask mkgmap to generate multiple map families from the set of map tiles? What would be the best way to package translation rules for bus routes? If the route=bus layer is to be compiled separately from the "base" layer, then it would need a different style altogether, right? And I guess it could be compiled with fewer and bigger map tiles as well? Currently, my "base" layer of Finland is 3 tiles. I believe that one tile of bus routes would easily cover the entire country, at least until all bus routes have been mapped. Best regards, Marko

2 5

Mapsource installer
by Mark Burton 03 Jan '10

03 Jan '10

I wish to make a mapsource installer for the Baltic map. Can anyone please provide a simple recipe for doing that? Thanks, Mark

4 11

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

patch v1: Multipolygons: Polygon decomposition
by Christian Gawron 02 Jan '10

02 Jan '10

The attached patch (against the mp branch) replaces the current approach of the multipolygon code (just connecting the inner and outer ways, thus forming polygons with overlapping segments) by a decomposition approach: The "polygon with holes" is decomposed into "simple" polygons without holes. To make the further development easier, I have put the decomposition code into a separate class PolygonDecomposer. The decomposition code does not yet handle all possible cases - it just cuts off a quadrilateral for each inner way (which is not much different from the old approach) and does not yet check wether this quadrilateral contains or intersects any of the other holes.It should, however, already work for "normal" cases where the holes are not too complex. Best wishes Christian

1 0

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

Commit: r1457: * Tagged inner polygons are supported now
by svn commit 02 Jan '10

02 Jan '10

Version 1457 was commited by steve on 2010-01-02 15:12:31 +0000 (Sat, 02 Jan 2010) * Tagged inner polygons are supported now * Nested polygons (outer in inner in outer etc) are supported now * Bugfix in the findCpa method (this could also be interesting for the trunk). findCpa did search only for the two closest points. It didn't check if this connection intersects the outer polygon. The bugfix checks this (see attached picture: old version selects the red line, bugfix selects the green line). - WanMil

2 1

Commit: r1456: Add --nsis option to help file.
by svn commit 02 Jan '10

02 Jan '10

Version 1456 was commited by steve on 2010-01-02 15:03:36 +0000 (Sat, 02 Jan 2010) Add --nsis option to help file.

1 0

mp-branch
by Christian Gawron 02 Jan '10

02 Jan '10

First I wish to thank you for implementing this - I think the mp-code really needs improvement. I think there is still a clipping-related bug in the new code - the attached sample file is rendered correctly in the main trunk, but the hole in the forrest is "flooded" in the mp branch. Best wishes Christian

1 0

[mp: PATCH] Multipolygons: inner and nested polygons supported now
by WanMil 02 Jan '10

02 Jan '10

Thanks for committing the new multipolygon to a branch and for all of your comments. They're helpful always! I have improved the multipolygon handling in the mp-branch. Changes: * Tagged inner polygons are supported now * Nested polygons (outer in inner in outer etc) are supported now * Bugfix in the findCpa method (this could also be interesting for the trunk). findCpa did search only for the two closest points. It didn't check if this connection intersects the outer polygon. The bugfix checks this (see attached picture: old version selects the red line, bugfix selects the green line). Next thing to do is to bugfix the PolygonSplitter. Comments are welcome! WanMil

2 6