November 2012 - mkgmap-dev - The mkgmap lists

Minor process-destination issue
by Chris66 28 Dec '12

28 Dec '12

Hi, Many destinations are entered with several cities, for example destination=Bonn;Rodenkirchen My Nüvi is displaying only the first entry: "Rechts abfahren nach A 555 (Bonn" The right ")" is missing also in this case. Bug or feature ? Some times ago there was a patch concerning the ";" handling, don't know if this patch was ever committed. The user should be able to decide via style file to display only the first entry or all entries. Do we have a style-function for this? item( ${destination}, 1 ) -> Bonn item( ${destination}, 2 ) -> Rodenkirchen Chris

4 7

Still problems with lakes
by RheinSkipper 13 Dec '12

13 Dec '12

Hi! I still have the problem that either lake Vänern in Sweden or lake Saimaa in Finland are partly rendered as land. The problem still exists using the latest precompiled sea from Wanmil. Using one of my older areas.list Vänern is OK but Saimaa is not. Letting the splitter create its own areas.list Saimaa is OK but then southern Vänern is dried out.

12 48

splitter maximum tile size
by WanMil 05 Dec '12

05 Dec '12

Hi, regarding thread http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013611.html there is a maximum tile size that can be processed. Is this limit considered by splitter? WanMil

7 25

splitter r250 and open questions reg. bounding polygon
by GerdP 04 Dec '12

04 Dec '12

Hi all, r250 fixes a performance issue that shows up if you use --keep-complete in combination with a max-areas value which is lower than the actual number of tiles (including the "pseudo-tiles"). Open problems/questions regarding complex bounding polygons: r247 uses such a polygon without problems, but it doesn't try to fit the tiles into the polygon. r248 and above always try to fit the tiles into the polygon and they stop if that is too difficult. I think it would be better to use a compromise: - try to fit into the polygon, if that isn't possible, use it only to "blank out" areas outside of the polygon and allow tiles to (heavily) overlap the polygon. In such a case a warning message should be issued and the resulting shape of the tiles could be output to a file, e.g. areas.poly. (I think that is what Felix suggested?) An alternative would be to use use a new parameter: --fit-into-polygon=true would tell splitter that the user does not want the result if it doesn't fit into the polygon, so it is allowed to stop with an error message if that's not possible. Other ideas? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r250-and-open-questions-reg-boundin… Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 7

address index question
by Richard Welty 02 Dec '12

02 Dec '12

i'm shifting from a consumer of Dave Hansen's roll ups of the Lambertus maps to generating specific maps on my own with mkgmap. the first one i generated looks good, but i'm trying to sort out correct population of the address index. i downloaded an extract from osm via xapi, and ran mkgmap with these parameters: $ java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar capitaldistrict-2012-11-23.osm --index --gmapsupp i got a bunch of errors which look like complaints about malformed data in osm, which i'll go look at and clean up later (an example: SEVERE (RoadNetwork): capitaldistrict-2012-11-23.osm: Road (South Lake Avenue, http://www.openstreetmap.org/browse/way/5579946) contains zero length arc at http://www.openstreetmap.org/?mlat=42.65485&mlon=-73.78075&zoom=17) i installed the map on my nuvi 255w. the map looks good, although i haven't gone out and tried to route with it yet. my main interest right now is getting a properly populated address index, and it doesn't seem to have one. i went back and reviewed the .osm file and verified that there are POIs in it with what appear to be properly populated addr: fields. are there any specific requirements for OSM data to get the address index populated properly? admin_boundary data perhaps? (this would be an issue in the US where address data doesn't usually match up well with admin_boundaries.) thanks, richard

8 16

splitter r247
by GerdP 02 Dec '12

02 Dec '12

Hi all, I've just committed r247. Changes: - added parameter --polygon-file to specify a bounding polygon. The polygon is only used when the tiles are calculated, it is NOT used when the real split process runs. - performance improvements in the new split algorithm The polygon file format is that of osmosis, I've simply added the osmosis sources: http://wiki.openstreetmap.org/wiki/Osmosis/Polygon_Filter_File_Format I hope that is the right way to do it. The polygon is only used when no split-file is given. It is used when all nodes were read. In this first pass, splitter fills a grid with node counts. Instead of filtering each node (which would take much too much cpu time), splitter simply uses the polygon to set those grid counts to 0 (zero) which do not intersect with the polygon. When that is done, splitter calculates the tiles. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r247-tp5737673.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

7 31

parameter no-trim
by GerdP 30 Nov '12

30 Nov '12

Hi all, I want to change the behaviour of splitter: If no bounding polygon is given, we can have two situations: a) the input file contains no bounding box. In this case splitter calculates a bbox that is automatically trimmed. b) the input file contains a bounding box. In this case splitter should - by default- try to trim this bounding box (and not more). If --no-trim=true is given, splitter should not trim the bbox. Trimming singular tiles doesn't make much sense, esp. not with keep-complete=true. We risk holes in the map and gaps in ways crossing the tile, eg. ferry lines OK? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/parameter-no-trim-tp5738361.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 1

splitter r249
by GerdP 29 Nov '12

29 Nov '12

Hi all, I've commited r249 - overlap defaults to -1, it is set to 0 if keep-complete=true, else to 2000 - using a bounding polygon forces no-trim=false. Splitter makes sure that no holes are created within the polygon - if using a bounding polygon splitter will not create tiles that cover large parts outside of the polygon, still, tiles will be aligned and therefor may cover small outside areas - too complex polygons are rejected, esp. those that are not rectilinear The split algorithm is now quite complex, I am pretty sure that I did not find all errors yet, but it works fine for all workload that I have tested. The performance is poor if you split large areas with very few points, e.g. an ocean. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r249-tp5738211.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 3

mkgmap birthday
by Steve Ratcliffe 29 Nov '12

29 Nov '12

Hi On this day, 6 years ago, revision 1 was committed to svn. $ svn log -r1 ------------------------------------------------------------------------ r1 | steve | 2006-11-26 20:46:08 +0000 (Sun, 26 Nov 2006) | 1 line Created mkosmgmap project ------------------------------------------------------------------------ As you can see it originally had a slightly different, but equally hard to pronounce, name. It took less than a month to get the first working map, primitive as it was, and it has grown massively from there. I never have imagined at the time that it would still be getting bigger and better all this time later. I'd like to thank everyone on this list who uses mkgmap and especially to those that have helped to develop it in the past and those that are doing so now. To celebrate I thought that I would break everything ;) I've updated the www.mkgmap.org.uk website to make it easier to add content, documentation, short news items about new features etc. in the future. You can now also sign up and get svn access to your own branch on any of the projects. If you already have svn access that you've used in the last couple of years, then you already have an account with the same login details as your svn account. There may be problems with things missing from the web site, subversion commit permissions, commit emails to the mailing lists etc. I'll probably notice from the error logs, but if you notice something wrong persisting, then let me know. Best wishes to all. ..Steve

9 8

POIs only in nearest list
by Thorsten Kukuk 29 Nov '12

29 Nov '12

Hi, don't remember anymore if this was already a topic here, I found some similar reports, but didn't fully understand them. I created a map of europe, about 911 tiles, containing only highways, some very few landuses and cities as POIs. The only errors I found in the log files are the usual area too small to split ones. The problem is that no city in the middle of the map can be find if you search for them. But they are all visible on the map and in the nearest list. I saw this effect already for some POIs in the past with maps like my DACH extract, but wasn't able to reproduce it. I know that too many POIs can generate problems, but that already the citys of europe should be too much for such a big map? Is there already some experience where a limit is? And shouldn't we warn for it? Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

1 0