Hi Ticker, yes, the patch is only for the reader. Reg. MAX_RGN_OFFSET_SIZE : You are right, it is about the pointers in RGN like indPointOffset in RgnFileReader. Anyway, with WANTED_MAX_AREA_SIZE = 0x3fff we want to produce even smaller subdivs . Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 28. Januar 2022 13:04 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Error in TreReader? Are our limits too small? Hi Gerd Subdivision.write needs adjusting to merge startRgnPointer and getType() MAX_RGN_OFFSET_SIZE limits to 16 bits rather than 24 so probably not be directly related. The 24 to 28 bit increase presumably covers all the subdivisions in the tile and so should allow larger maps. I didn't notice anything that checked the 24 bit limit apart from the put3u asserts Ticker On Fri, 2022-01-28 at 10:14 +0000, Gerd Petermann wrote:
Hi programmers!
Our code in TreFileReader differs from that in GPXSee treFile.cpp. Our code only reads 24 bits into field lastRgnOffset, but GPXSee reads up to 28 bits as offset. We assume 1 byte for the flags and 3 bytes for the offset. GPXSee assumes 4 bits for the flags and 28 bit for the offset.
Since our flags field has values > 0x10 I think the code in GPXSee looks better. Not sure what that means. Maybe we can write larger tiles? Is MapSplitter.MAX_RGN_OFFSET_SIZE related to this?
Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev