April 2010 - mkgmap-dev - The mkgmap lists

Address search icon behavior varies in some gps units
by maning sambale 08 Apr '10

08 Apr '10

Hi, A user roprt below: In Garmin Nuvi 855 when you click the Address icon to search an address, the popup message "No map data found." will immediately appear. In other Garmin units like 205w and 265w you can enter the city, street and house number. Some addresses are already working when you search for it. Provided the point in the map contains keys for address search such addr:<category here> you can search for it. It's working in 205w. In Garmin Nuvi 855 i don't know what's the problem. It won't let me search for an address. The maps were uploaded via Mapsource. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

2 2

[PATCH] Routable pedestrian areas
by Clinton Gladstone 07 Apr '10

07 Apr '10

The attached patch is an updated version of an earlier patch which I submitted. It adds a cheap but sub-optimal pedestrian routing option: --route-pedestrian-areas When this option is set, mkgmap will add a pedestrian way around the perimeter of pedestrian areas (Squares and Plazas). This will allow GPS devices to calculate routes through (i.e., on the perimeter of) such squares to other connecting ways. This is not the best solution, as you will always be routed along the edge of the area, but it works. I have been unable to think of a better, practical solution. The code is in the style of (read: shamelessly copied from) Mark's cycleway additions. I have been using the patch for some time, and I have found it quite useful for pedestrian routing in cities where such areas frequently occur. Your feedback and comments would be appreciated. Cheers.

1 0

Highway name or ref
by Lambertus 07 Apr '10

07 Apr '10

There's a question on the OSM forum about the naming of highways in the default stylesheet which comes down to this: if a ref is available then that seems always used even if a name is also available, can this be changed to show the name as well? http://forum.openstreetmap.org/viewtopic.php?pid=68439#p68439

5 8

Commit: r1631: Display road name instead of ref in routing directions.
by svn commit 07 Apr '10

07 Apr '10

Version 1631 was commited by marko on 2010-04-07 14:05:37 +0100 (Wed, 07 Apr 2010) Display road name instead of ref in routing directions. Apply the style part of the patch by Clinton Gladstone. The Java part was applied earlier.

1 0

Commit: r1630: Get the map levels so that we can read out from
by svn commit 07 Apr '10

07 Apr '10

Version 1630 was commited by steve on 2010-04-07 13:59:37 +0100 (Wed, 07 Apr 2010) BRANCH: overview Get the map levels so that we can read out from the input files.

1 0

Tile boundary artefacts
by WanMil 06 Apr '10

06 Apr '10

I have attached an interesting screenshot from my Oregon 400t. The map is the All in one map Europe (http://wiki.openstreetmap.org/wiki/All_in_one_Garmin_Map) You see that the light grey industrial area is splitted by a considerable yellow line. But the dark grey buildings do not have it although they are splitted by the tile bounds in the same manner. There is no multipolygon defined in the screenshots area. Maybe the boundary clipper sometimes cuts too much? I have never seen such artefacts on original garmin maps. WanMil

2 4

Commit: r1627: Merge the style-speed branch to trunk.
by svn commit 06 Apr '10

06 Apr '10

Version 1627 was commited by steve on 2010-04-04 14:52:14 +0100 (Sun, 04 Apr 2010) Merge the style-speed branch to trunk. This drops all tags that are not used right at the point of reading from the input file. This has varying benefits depending on the input data. In the best case, we avoid creating Node objects for a large number of points that should just stay as Coord objects. As the Node object contains numerous sub objects such as the Tags object this saving can be very large. Even on ways, where it is rarely possible to avoid creating a Tags object, you can reduce the number of resize operations needed. The biggest benefit is for Denmark and countries that have had automated bulk imports. In the UK the difference is merely in the 10s of megabytes rather than the hundreds or thousands.

2 1

Question to --add-pois-to-areas
by Daniela Duerbeck 06 Apr '10

06 Apr '10

Hi! How should --add-pois-to-areas work? Here is a Zoo:http://www.openstreetmap.org/?lat=28.40885&lon=-16.56398&zoom=17&layers… but it has got neighter icon nor can it be found in the POI search. How is this option expected to work? TIA, Dani P.S: This part is very small so maps are generated very fast: http://download.geofabrik.de/osm/africa/canary_islands.osm.bz2

4 11

--add-pois-to-areas seems to stop after one attribute of an area has no match
by Daniela Duerbeck 06 Apr '10

06 Apr '10

Hi! I found some examples where an area has more than one attribute. It seems to me that those get no POI generated if not all attributes match a polygon and a point. I would prefer if it gets a POI if one attribute matches. Dani

1 0

Sorted apply of relations, filtering out duplicate ref
by Marko Mäkelä 06 Apr '10

06 Apr '10

The current best practice seems to be to split bus route relations into two, with different "from" and "to" attributes. See for instance the "sketch-route" links for the bus routes HSL 731 and HSL 742 that I defined, at http://wiki.openstreetmap.org/wiki/Finland:HSL/bus#Linjat or the direct links http://78.46.81.38/api/sketch-route?534623&532590 http://78.46.81.38/api/sketch-route?375387&534624 The problem with this approach is that the current mkgmap "apply" would copy the bus route ref from each relation to the two-way street sections twice. Also, if the start and end stops are shared between the relations as they are for these examples, those bus stops would get the route ref twice. The apply_once that I implemented would be of no help. I think that the relation processing should be changed in a way that gives the processor a collection of all relations. I implemented a patch to that direction that does not change the behaviour yet. I would like to do something like this: SELECT UNIQUE ref FROM relations WHERE type=route AND route=bus ORDER BY ref APPLY { set route_ref=$ref; } I hope you get the idea. I do not actually propose any SQL-like syntax; the above is for illustration purposes only. Best regards, Marko

1 0