Hello Steve, Steve Ratcliffe wrote
On 12/27/2011 01:49 PM, GerdP wrote:
I don't know why this happens now, and it really shouldn't (apart from
the timestamps which are easy to ignore), I will try to find out why.
thanks, tt would be great if this could be changed.
I discovered that it is only boundary lines that are affected.
I didn't quite track down the exact cause, but I guess that the relation members are held in a hash map somewhere and are read out in an indeterminate order.
Whatever the exact reason, adding a hashCode() method to the Way class prevents the random ordering, so I shall commit that change.
your fix helps when I use max-jobs=1, only a few bytes are different then, but I still get random output with max-jobs > 1. Is this expected? Regarding those different bytes for max-jobs=1: You said they are time-stamps. Would it be possible to write a constant value (from a parameter) to these bytes for debugging purposes? Gerd -- View this message in context: http://gis.638310.n2.nabble.com/PATCH-mkgmap-performance-part-2-tp7123938p71... Sent from the Mkgmap Development mailing list archive at Nabble.com.