Hi Cliff,
cliff wrote:So, is there a visible flag in the XML project file somewhere that specifies if the AM PNG is colour-mapped or not?
If the PNG is a 24-bit image, it's colour-mapped. If it's 16-bit, it's not. That's how I do the switching.
cliff wrote:I remember the question I had run into when looking at the climate files that wasn't clear - when the ID is re-used in 2 climate files that are both used on the map, it wasn't terribly clear how your data was resolving the conflict. What's the logic to this conflict resolution?
The values in the attributes map specify not just the land type ID, but also the climate ID. To get the climate and land type IDs from a pixel values, I use the following formulae:
ClimateID = AMpxl%256; (integer modulus)
and
LandTypeID = AMpxl/256; (integer divide)
(where AMpxl is the 16-bit pixel value from the image.)
The climate ID tells you which climate to look in, and the land type ID identifies the land type in that climate. Consequently, providing there 256 or less climates, and 255 or less land types in any climate (0 is reserved), these 2-byte codes uniquely identify each possible land type. I can't remember whether I have a check in the climate manager/editor to enforce these limits (I think so), but I figured no-one would use 257 climates in one map, or 256 land types in one climate. If they do, I may add a 'wide' attributes map option in the future, with 32 bytes per pixel (again using a PNG image, this time in RGBA mode).
Colour-mapped mode, on the other hand, is quite likely to suffer from conflicts, as there's nothing stopping a user from setting the same display colour for multiple land types (in the same or different climates.) Thus, the 16-bit values are guaranteed to be unique within a certain range, whereas the colour-mapped values may or may not be unique, depending on the users' settings. Furthermore, with colour-mapped files there is a chance that the user may edit the image and inadvertantly insert a colour that does not correspond to the display colour of a land type, in which case one cannot lookup the appropriate land type. You could, perhaps, do a nearest-match algorithm (and in fact I might do that, now that I think of it), but that's not guaranteed to get the value the user intended. These are the reasons colour-mapping is not on by default.
Anyway, does this stuff make any sense now?
Cheers,
Aaron.