You can clone with
HTTPS or Subversion.
Early revisions of the grid_renderer used an incrementing counter for each feature processed, and burned that integer into the grid buffer during rendering. During encoding these keys were re-mapped back to the feature's actual id.
After #753 was finished for all key datasources, I moved to burning the feature.id() directly into the rendering buffer because they were now promised to be unique and because it simplified the encoding boilerplate.
This was short-sided because we need to support at least 32 bit integers (and in the future perhaps 64 bit) for both feature.ids(). Currently now its possible for feature ids to overflow when pushed into the unsigned short rendering buffer which is limited to 65535 and only positive numbers.
move to int32 for grid rendering buffer - closes #1196
note to anyone watching - yes, we need to consider moving to 64 bit integers, but since feature.id() is 32 that was my target for now.
was this backported to the 2.0 branch ?
On mapnik 2.0, could I reduce the impact of the issue if I reduce the density of overlapping points?
@cgendreau - no, the only workaround is to ensure that your feature ids are less than 65,535.
@springmeyer You mean a maximum of 65,535 features or 65,535 as the maximum value of a feature?
It depends. Most directly I mean the maximum value of the feature id. In the case of the the Mapnik postgis plugin (which I think is what you are using) by default the feature.id() is incremented per feature - so that would mean the overflow could be avoided by rendering less than 65k features per tile. The postgis plugin has a key_field option which allows the user to control which value is used for the feature.id() and in that case overflow would only occur based on that fields value.