Hello WanMil, if I understand your post correctly the problem is with the osmosis software and it's not likely to be fixed soon. Unfortunately this would be the software I'd use myself to extract the needed part of the planet dump. What software would you recommend to do so? I've already tried to feed the mkgmap splitter an areas.list file with only the needed areas, but that gave me a partial invalid map (MapSource wouldn't display some tiles). Regards, Thilo

There are two problems: 1st: osmosis does not provide the boundary shape used to split the dump file. So mkgmap cannot differ if there is no data at a point because the point is outside the boundary shape of the dump or if there is no data because no OSM data exist there.

1) you can download the boundary shapes from geofabrik. sure it could be a nice feature in osmosis but very unlikely this will happen. osmosis works on streams and as soon as multiple polygons are used in piped streams this will create wrong polygons. But the real problem is that none of the tools in the whole process support polygon extracts in a way that is predictable and produces complete polygon shaped areas. by complete I mean that each way has to be clipped exactly at the polygon and then a node must be inserted at the polygon boundary. The polygon must be included too. If a way is a polygon or part of a polygon relation it has to be closed along the polygon boundary. 1) osmosis: does support cutting polygons but it has no detail knowledge about osm semantic and can never achieve this. the only option osmosis supports is to clip a way or to keep the whole way intact. inserting a way at the boundary requires to calculate the intersection of 2 ways in the projection of osm data. 2) splitter doesn't support polygon shaped extracts. 3) mkgmap has some kind of support. Mark has implemented it long time ago but i doupt anyone is really using it because it requires these boundary nodes in the osm file. now the big challenge is to close polygons. Didn't do much testing lately but just from following the thread it seems you have made lot of progress. But mkgmap is to late in the chain to really solve it without a lot of guessing and failing many times. as long as tiles are rectangles you may have gaps of any size from the boundary polygon to the tile boundary. closing them to the tile boundary isn't really a good idea. As long as the whole chain doesn't exist a nearly working solution is - extract only rectangles in osmsis with option completeWays and completeRelations - run splitter, but the input doesn't contain a bbx so it's required to insert the bbx in the osm file. haven't tried this part and don't know if splitter uses bbx in the incoming osm file. as alternative adjust the areas.list for splitter to the bbx used in osmosis. otherwise some tiles will have nearly empty areas caused by long ways extending the osmosis boundary. currently splitter doesn't include complete relations maybe mkmap can close polygons correct but I doubt it. in general a polygon can be closed. left or right along the tile boundary. only for coastline this can be solved by analyzing the direction of ways. for a relation based polygon there is a 50% chance.to get it correct. I have written a osmosis based splitter script once but lost it. splitter was improved so much that I didn't need it anymore. and performance was so bad compared to splitter. maybe I will try that again on a small testcase and use completeWays completeRelations and test the actual mkgmap

MB> I did submit a request for the splitter to support a bounding box MB> option that would bound the outer edge of the tiles (rounded MB> appropriately) but Chris didn't seem keen about that. Personally, I MB> think it would be useful. Well it wasn't so much that I wasn't keen, just that at the time I wasn't sure why you wanted it and was too lazy to implement it at the time :) There's actually another reason - there's a bug I accidentally introduced to the splitter a while back which is related. Since I added support for the bounding box tag, the splitter doesn't work correctly if there are multiple osm files given as input because only points inside the first file's bounding box are considered for splitting. Once I fix that it should be easy to add support for a --bound parameter (or you could simulate the same thing by supplying an additional osm file that only contains a <bounds/> tag). Currently I'm working on adding support for nested relations, including relations that are forward referenced. I thought it wasn't going to be too difficult but it's proving a bit trickier than I thought. Once that's done I'll look at fixing the above plus keeping whole multipolygon relations. Chris

MB> Using a small OSM file that contained the bounds tag would be fine MB> for my purposes. ...though I've just realised this would only work if your file's <bounds/> was a superset of any <bounds/> specified in your main osm file. If the main osm file didn't contain a <bounds/> tag at all, you'd also be OK. If you wanted to use the additional osm file to set bounds that were just a portion of the main osm's bounds, it wouldn't work and a new --bounds parameter would still be needed. Chris