Hi IZ, On 6 February 2013 20:05, Ilya Zverev <[email protected]> wrote:
> Hi! As some of you have read (http://lists.openstreetmap.** > org/pipermail/dev/2013-**February/026495.html<http://lists.openstreetmap.org/pipermail/dev/2013-February/026495.html>), > in three days node ids are expected to surpass 2147483647, and this > method https://github.com/**openstreetmap/osmosis/blob/** > master/core/src/main/java/org/**openstreetmap/osmosis/core/** > util/LongAsInt.java#L30<https://github.com/openstreetmap/osmosis/blob/master/core/src/main/java/org/openstreetmap/osmosis/core/util/LongAsInt.java#L30>will > throw an exception "Cannot represent " + value + " as an integer." It > is used in every IdTracker implementation, so id trackers will become > unusable. > > This will affect tag and area filters. Regional extracts that are made > with osmosis will break. There is a comment at the start of each IdTracker > class: "The current implementation only supports 31 bit numbers, but will > be enhanced if and when required." I guess, now is the time. Can anybody > fix that? There must be a reason why this hasn't done sooner. > Thanks for the heads up. I could be wrong but I don't think this is an issue. It is used by ListIdTracker and BitSetIdTracker so those implementations will soon fail if you try to use them. However, the default implementation is now DynamicIdTracker which doesn't suffer from this issue (I hope ;-). DynamicIdTracker breaks the id range into chunks of 1024 and internally uses either ListIdTracker or BitSetIdTracker for each of those chunks depending on which is more efficient. As a result, the largest number either of those id trackers ever sees is 1023, the DynamicIdTracker adds a base offset to those numbers to get the final number and it stores the base number as a 64-bit long. The idTrackerType arguments could probably be removed from the --bounding-box and --bounding-polygon tasks now because the default implementation should be better than specifying one in the vast majority of cases. I've checked the rest of the codebase for use of the LongToInt class. It is used internally by the Entity class to store a changeset id as a 32-bit number instead of a 64-bit number. That should be safe for a while yet. Brett
_______________________________________________ osmosis-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/osmosis-dev
