- mkgmap-dev - The mkgmap lists

Commit: r987: Limit number of points in way to avoid routing problems.
by svn commit 25 Mar '09

25 Mar '09

Version 987 was commited by markb on 2009-03-25 08:50:17 +0000 (Wed, 25 Mar 2009) Limit number of points in way to avoid routing problems.

1 0

Search index with mapsource generated gmapsupp?
by Johann Gail 24 Mar '09

24 Mar '09

Just an idea, I cant test it, as I havn't a running mapsource at hands. What happens, if you generate single img tiles with mkgmap, import that tiles to mapsource and build a gmapsupp from within mapsource? I would expect, but could be wrong, that the resulting gmapsupp would contain the global search index for roads. Has anyone ever tried this?

1 0

[PATCH v1] Weird routing failure + possible fix
by Mark Burton 24 Mar '09

24 Mar '09

Hi, Someone has pointed out that the routing doesn't work in this little map. http://www.openstreetmap.org/?lat=30.918&lon=35.112&zoom=9 I have been testing using mapsource, not a gps. If you try and route across road 227, it misses a chunk out on the left hand side. Road 227 contains quite a few points so I tried splitting the road into more than one segment to see if it made a difference using the attached patch. I experimented with different values of MAX_POINTS_IN_WAY and discovered that when using values of approx 250 or more, the gap in the routing appears. As I don't really know what's causing the problem here and what the limit is, I suggest we limit roads to no more than, say, 200 points to avoid this problem. Any thoughts? Cheers, Mark

2 2

Oneway=no vs. motorway_link routing
by Ralf Kleineisel 24 Mar '09

24 Mar '09

Hi, I tried a route along this motorway exit: http://data.giub.uni-bonn.de/openrouteservice/index.php?start=10.0073556,49… on my etrex and in mapsource. Both avoided the exit. The part of the motorway_link which is common for both directions has "oneway_no". The routing on openroutservice shows this, too. My rule for the line type is: highway=motorway_link {add oneway=yes; add bicycle=no; add foot=no} [0x09 road_class=4 road_speed=3 level 4] The "add oneway=yes" should only make it oneway if it is NOT "oneway=no", right? If I look at the line in GPSMapEdit it says "Polyline has direction". Does this mean that line type 0x09 is always oneway for Garmin or is the tag setting in mkgmap buggy? I used r973. BTW: GPSMapEdit always shows "Polyline has direction" but not "One way" in the "routing" tab, even for residential one-ways. Is that correct? I am sure this type of motorway exit worked before I switched to type 0x09 (the reason was better routing instructions).

2 2

[PATCH v8] - alpha patch to support road find by name
by Mark Burton 23 Mar '09

23 Mar '09

v9 - based on r985. Now tries to reduce (connected) groups of roads with the same name and city to just one entry - please test. If you find that you are still seeing multiple entries for a road, check the OSM data to see that the road really is sensibly defined, i.e. it's quite possible to have a bunch of connected road segments some of which have the same name and the others having no name - in that case, the road will get listed more than once. Also, dual carriageways will show up as two entries. Feedback/comments welcome. ----------- Hi, The attached patch is for the current SVN trunk and it generates the sorted road data that is required by the gps to find roads/intersections by name. As for the number field, I haven't thought yet how that would get its data. Please test this patch and report success/failure. If it doesn't break anything for anyone, I would like to commit it fairly soon as I think that quite a few people will be happy to have street finding added to the trunk. Cheers, Mark

3 9

Re: [mkgmap-dev] [PATCH v8] - alpha patch to support road find by name
by Mark Burton 23 Mar '09

23 Mar '09

On Mon, 23 Mar 2009 15:10:16 +0100 Florian Lohoff <flo(a)rfc822.org> wrote: > On Mon, Mar 23, 2009 at 01:36:45PM +0000, Mark Burton wrote: > > > A little nitpick (Its always possible to optimize something :) ) > > > > Nitpicks are fine. > > > > > > + // given a list of roads sorted by name and city, build a new > > > > + // list that only contains one entry for each group of roads > > > > + // that have the same name and city and are directly connected > > > > > > As it happens i live in a street which is intersected by a roundabout. > > > As the roundabout does not have the street name on it this will produce > > > multiple segments. So probably it should be directly connected > > > or via a way with "junction=roundabout" ... > > > > > > But this is just a little optimization probably for the next generation ;) > > > > I am sure that some people would prefer that the two roads are not > > squashed together in that situation because it would "hide" one of the > > roads and so they may think that the one road that has been shown > > stops at the roundabout when, in reality, it carries on past the > > roundabout. So, given that it's a bunch of work to implement and I'm not > > convinced it would be universally popular, I will leave that for > > someone else to add. > > The point is when you have a long road you'd like the navi to select the > right segment based on the housenumber. So when you are out of luck you > select the wrong segment and wont find that specific housenumber. Sorry, I don't understand what you are saying there. Cheers, Mark

2 2

Template args + --net parameter results in default image name
by Matt White 23 Mar '09

23 Mar '09

I've just been updating my IMG creation process to use all the new mkgmap options (was running a pretty old version), and noticed a little bit of weirdness. I'm using a template file to create some standard format maps, and if the --net parameter is specified in the template file, the first IMG file created gets the default 62340001.IMG file name, regardless of the other parameters such as map name. Using version r984. Eg: Template File: family-id: 3081 product-id: 2601 overview-mapname: 30810100 net gmapsupp tdbfile # Following is a list of map tiles. mapname: 30810101 description: OSM-AU Victoria input-file: VIC.osm.gz country-name: Australia country-abbr: AUS region-name: Victoria region-abbr: VIC mapname: 30810102 description: OSM-AU New South Wales input-file: NSW.osm.gz country-name: Australia country-abbr: AUS region-name: New South Wales region-abbr: NSW ... (Five more file templates here) Command line: java -Xmx1024M -jar mkgmap.jar -c template.args This builds a file set like: 62340001.IMG 30810102.IMG ... (next five files correctly named) 30810100.IMG 30810100.tdb If the net parameter is removed from the template file OR the --route parameter is supplied, then all the files are correctly named. I can live without the net parameter, but just thought I'd the issue up the flagpole... Matt

3 3

That last subject should have been [PATCH v9] not [Patch v8] but you guessed that!
by Mark Burton 22 Mar '09

22 Mar '09

1 0

Commit: r986: Fix reading of options from a file.
by svn commit 22 Mar '09

22 Mar '09

Version 986 was commited by steve on 2009-03-22 16:21:45 +0000 (Sun, 22 Mar 2009) Fix reading of options from a file. Previously an option without a value would be ignored and further more could cause a following option to be ignored. - bug reported by Matt White Also fix tests that were altered by previous fixes.

1 0

map features and detail levels
by Paul Ortyl 22 Mar '09

22 Mar '09

Hi, I have noticed unusual behaviour of some POIs. I cannot understand why some types are shown even at low detail level where others are not. An example: point|tourism|picnic_site|0x4a|0x00|20 point|tourism|information|0x4c|0x00|20 point|amenity|toilets|0x4e|0x00|20 are visible in MapSource even as all other POIs with resolution at 20 or slightly less are no more there. Does MapSource treat these three types specially? That is resolution 20 for these types means something else as for other types? I have double-checked (grep -r) for "picnic_site" in my garmin related directories, and the only definition of this feature sets the resolution to 20. Any ideas? Paul -- Don't take life too seriously; you will never get out of it alive. -- Elbert Hubbard

3 2