Hi Gerd Here is the patch based on the current trunk Ticker On Tue, 2019-04-23 at 11:51 +0100, Ticker Berkin wrote:
Hi
I think the mkgmap internal handling of types/subtypes of points is obscure.
In the points style file, the type code is always full, ie type << 8 | subtype, but when the points are read back from the RGN file for the MDR processing, the representation is the same provided the subtype is not zero, otherwise it is just type! Logic then decides that if the value is <= 0xff it is because the subtype is zero.
It is simpler and much clearer to preserve the original representation. This also allows unambiguous use of type 0 with subtypes, and, possibly, city with subtypes.
It also allows the same function to be used to test a type for being in the 'city' range, regardless of the context. mkgmap wasn't consistent the ranges for the isCity test.
City POI are written in a different manner to the RGN file. The old range for this was: type >= 0x0100 && type <= 0x1100 which I've kept, except changing to: ...& type < 0x1200. A similar range was used for MDR5.
However, city POI are held in group 1 of MDR 9/10. This is used in Find
City 'By Name'. The old range was: type <= 0xf, where, if the subtype was zero, type is right shifted by 8 (see above), non-zero subtypes messed up the testing. Now it uses the same range as above.
Actually neither of these ranges are correct for my Garmin devices. Find > City show nearby POI with types in the range 0x0100..0x0d1f, regardless of the img RGN or MDR. The eTrex Legend labels POIs in this range as {Large/Medium/Small} City/Town and points in the range 0x0e00..0x111f as "*".
Find > City 'by-name' returns POI if in group 1 of MDR 9/10. I find it a useful feature to have a POI that can be searched for but doesn't flood the list of nearby points.
Generally, non-zero subtypes for cities cause problems in the RGN structure and I've added a test for this to the style validation.
There is also a fix to --make-poi-index, but I can't detect any effect of this option.
This patch won't make any difference to the img output unless the there are points 0x1000, 0x1100.
If this patch is accepted, I'll do the equivalent to the img display system.
Regards Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev