December 2012 - mkgmap-dev - The mkgmap lists

splitter r251
by GerdP 07 Dec '12

07 Dec '12

Hi all, I've committed r252: - remove some warnings (from eclipse juno) reg. missing close() - don't create tiles larger than 85° lat or 90° lon - cut large empty areas if splitting doesn't find nice solution In most cases splitter will find a nice split within a few seconds. A few problems remain open: 1) output of the area.poly file 2) handling of complex polygon files containing areas with diagonal lines. For now, these are simply approximated with the bounding box (of each single area). No test is done until now to make sure that polygons have no holes 3) trimming is completely disabled for now. I did not yet find a nice algorithm that trims tiles in a way so that no gaps are created. This is needed when complex polygons are used to filter data. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r251-tp5739586.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

rendering nested relations
by Minko 07 Dec '12

07 Dec '12

I'm struggling to render nested networks of international cycling route relations and maybe found an issue with the sort order of relation ID's. My observation is that if the parent relation has a higher ID than the child relation, my mkgmap style won't render the tags of the parent relation on the underlying ways. For example, this cycleway which is part of a (super)relation EV12 (North Sea Cycle route) and a national route LF1. http://www.openstreetmap.org/browse/way/4549529 (cycleway) http://cycling.waymarkedtrails.org/nl/?zoom=17&lat=52.13921&lon=4.33606 part of Noordzeeroute (2761) network = ncn, ref = LF1, route = bicycle, type = route http://www.openstreetmap.org/browse/relation/2761 part of North Sea Cycle Route - part The Netherlands (1977662) network = icn, ref = EV12, route = bicycle, type = superroute http://www.openstreetmap.org/browse/relation/1977662 part of North Sea Cycle Route (1207220) network = icn, ref = EV12, route = bicycle, type = superroute http://www.openstreetmap.org/browse/relation/1207220 My goal is to get ref EV12(North Sea Cycle Route) on this cycleway, but all it gets are the ncn tags LF1 (Noordzeeroute). With a similar route relation in Germany, I don't have problems to render it, for instance this way: http://www.openstreetmap.org/browse/way/23018057 (highway=secondary) http://cycling.waymarkedtrails.org/nl/?zoom=15&lat=52.0506&lon=6.70903 part of D3 D-Netz-Route (Nordrhein-Westfalen) (2003425) network = ncn, ref D3, route = bicycle, type = route http://www.openstreetmap.org/browse/relation/2003425 part of Capitals Route (2003423) network = icn, ref EV2, route = bicycle, type = superroute http://www.openstreetmap.org/browse/relation/2003423 part of D-Netz-Route 3 (901472) network = ncn, ref D3, route = bicycle, type = route With this way, mkgmap renders tags EV12 (Capital route) as expected. With JOSM I found out that the sort order of the relation ID is the problem. If I swapped the contents and tags of relation 2761 and 1977662 (of course I didnt upload it to OSM, just saved the file) it gets rendered. If I make a new relation, it gets a negative ID and there is no problem either, all the relations that I put in this new relation gets the tags from the parent relation. In the German route example, the parent relation has a lower ID than the child, 2003423 vs 2003425. With this the relation styles have no problem to render it. Is there a way to solve this?

4 5

Commit: r2386: Make it possible to specify --no-option to disable options.
by svn commit 06 Dec '12

06 Dec '12

Version 2386 was committed by steve on 2012-12-06 20:43:41 +0000 (Thu, 06 Dec 2012) Make it possible to specify --no-option to disable options.

1 0

Commit: r2385: Correct check if a destination is unambiguous
by svn commit 05 Dec '12

05 Dec '12

Version 2385 was committed by wanmil on 2012-12-05 17:33:10 +0000 (Wed, 05 Dec 2012) Correct check if a destination is unambiguous With the process-destination option the destination tag is copied to adjacent ways but only if the destination is unambiguous. But the check did use wrong tag (destionation instead of destination). Add the rule that motorway_link and also motorway imply oneway=yes if oneway is not set.

1 0

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

Commit: r2384: The family id should be patched into typ file.
by svn commit 03 Dec '12

03 Dec '12

Version 2384 was committed by steve on 2012-12-03 12:58:56 +0000 (Mon, 03 Dec 2012) The family id should be patched into typ file. Creates a copy of the typ file and patches the family and product ids to be the current values.

1 0

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

The --no-option patch
by Steve Ratcliffe 02 Dec '12

02 Dec '12

Hi Attached is the patch that allows you to turn off any option by prefixing the name with "no-" For example: mkgmap --description="hello world" 00000001.pbf --no-description 00000002.pbf will result in the first file having the description "hello world" but the second one will have no description at all. ..Steve

1 0

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