0> In article <4AE75888.8060206@gmx.de>, 0> Christian Gawron <URL:mailto:christian.gawron@gmx.de> ("CG") wrote: CG> Toby Speight schrieb:
I don't have a server I can put it on, but I'm using Geofabrik's "Great Britain" extract[1], and this is the relevant line from the splitter:
/-------- | 63240015: 2615296,-407552 to 2846720,102400 | # : 56.118164,-8.745117 to 61.083984,2.197266 \--------
[1] <URL: http://download.geofabrik.de/osm/europe/great_britain.osm.bz2 >
CG> Ok, I will have a look at it. I'm not so familiar with the CG> newest version of the splitter - how can I tell it to create CG> the tile 63240015 with the coordinates above? Can you send me CG> the areas.list?
I could give you the full areas.list (I don't know whether you can make splitter create a single tile) - but - I'm experimenting with cutting out smaller extracts using osmosis, to see whether I can produce a smaller file that still triggers the problem. I did manage to reproduce it by extracting just the coastline from great_britain.osm: /-------- | osmosis --read-xml $< --way-key-value keyValueList='natural.coastline' --used-node --write-xml $@ \-------- This gives a file containing only the coastline, which can be processed without splitting. And, for me, this exhibits the inversion. It does take quite a while to run through mkgmap, unfortunately (an hour of CPU time for me), so I'm looking at cutting it down to process smaller groups of islands. I might not get it done today, though, and I'm about to go off-line for a few days (back around the middle of next week). BTW, I was wrong about this affecting multiple areas of the GB extract - the other boundaries I saw were from my contour tiles, not general OSM. CG> Are there really inland seas using natural=shoreline instead of CG> natural=water? I've no idea - not in my region, I would think, but perhaps the Dead Sea? Let's not worry about this for now!
Also, in passing, is it normal to have lots of little blue "threads" appear on the GPS display connecting the sea regions? I've not seen this with other multipolygons, so I'm wondering if this is also a symptom of problems.
CG> No, this is part of the multipolygon code. It connects the inner and CG> outer polygons with two lines, and the coordinates of the "returning" CG> line are move by one map unit. There is a comment in the code stating CG> that this results in "triangles" but that it is necessary or some CG> "inner" polygons are not rendered at all. I must admit that I don't CG> really understand how polygons with "holes" should be coded in the IMG CG> file.
Okay, that's reassuring to know. It's a separate issue that can be dealt with independently.