> --=-=-=
>
> Felix Hartmann writes:
>
>> D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar
>> -Xmx1200M splitter.jar --mapid=6320 --maxnodes=100
>> --resoultion=15 switzerland.osm
>>
>> /D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar
>> -Xmx1200M splitt
Felix Hartmann writes:
> D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar
> -Xmx1200M splitter.jar --mapid=6320 --maxnodes=100
> --resoultion=15 switzerland.osm
>
> /D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar
> -Xmx1200M splitter.jar --mapid=6320
Chris Miller wrote:
Hi Valentijn,
Chris Miller schreef:
but my impression is that the conclusion was that the splitter should
be rounding areas off to boundaries in multiples of 4096 rather than
2048?
As far as I've seen - thanks to Steve Ratcliffe's findings - divisible
by 2
Hi Valentijn,
> Chris Miller schreef:
>
>> but my impression is that the conclusion was that the splitter should
>> be rounding areas off to boundaries in multiples of 4096 rather than
>> 2048?
>>
> As far as I've seen - thanks to Steve Ratcliffe's findings - divisible
> by 2048 is enough, if yo
> If you do that, does that mean that those of us who manually calculate
> our areas.list files as input to splitter will then need to ensure the
> bounding coordinates are divisible by 4096 rather than 2048?
No, the generation of areas.list is a completely separate step from the actual
splitting
> Chris Miller schreef:
>
>> but my impression is that the conclusion was that the splitter should
>> be rounding areas off to boundaries in multiples of 4096 rather than
>> 2048?
>>
> As far as I've seen - thanks to Steve Ratcliffe's findings - divisible
> by 2048 is enough, if you make sure tha
Chris Miller schreef:
> but my impression is that the conclusion was that the splitter should be
> rounding areas off to boundaries in multiples of 4096 rather than 2048?
As far as I've seen - thanks to Steve Ratcliffe's findings - divisible
by 2048 is enough, if you make sure that the difference
Quoting Chris Miller :
>> Hi
>>
>> On 10/08/09 22:37, Chris Miller wrote:
>>
>>> Hi Steve/anyone,
>>>
>>> Can someone please clarify exactly how DivisionParser.round(Area) is
>>> supposed to behave? My understanding is that it is taking the area
>>> passed in and rounding
>>>
>> On past experien
> Hi
>
> On 10/08/09 22:37, Chris Miller wrote:
>
>> Hi Steve/anyone,
>>
>> Can someone please clarify exactly how DivisionParser.round(Area) is
>> supposed to behave? My understanding is that it is taking the area
>> passed in and rounding
>>
> On past experience, it is pretty safe to assume t
Hi
On 10/08/09 22:37, Chris Miller wrote:
> Hi Steve/anyone,
>
> Can someone please clarify exactly how DivisionParser.round(Area) is
> supposed to behave? My understanding is that it is taking the area
> passed in and rounding
On past experience, it is pretty safe to assume that any rounding co
> Chris,
>
>> to behave? My understanding is that it is taking the area passed in
>> and rounding the edges *outwards* to the nearest multiple of 0x0800.
>>
> Not _completely_ unrelated, I'm not sure if you know about this:
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/002789.html
>
> A
> If that is the case, then it is better to aim for readability and
> maintainability. The bit-shifting expression should be easier to read
> than the monster bit-masking expression. And because you are shifting
> the same amount right and left, it won't matter whether you are using
> arithmetic
On Tue, Aug 11, 2009 at 06:52:35AM +, Chris Miller wrote:
> >> private int roundDown(int val) {
> >> return val >> SHIFT << SHIFT;
> >> }
> > I would write this as
> >
> > return val & ~(1 << SHIFT);
>
> That's not the same thing though. I assume you really mean:
>
> return val & ~((1 << SHI
>> private int roundDown(int val) {
>> return val >> SHIFT << SHIFT;
>> }
> I would write this as
>
> return val & ~(1 << SHIFT);
That's not the same thing though. I assume you really mean:
return val & ~((1 << SHIFT) - 1);
And in fact that's what was there originally for positive numbers. Nega
On Mon, Aug 10, 2009 at 09:37:44PM +, Chris Miller wrote:
> Assuming my understanding above is correct, here's how I think the rounding
> methods should be implemented to give the correct rounding in all situations:
>
> private int roundDown(int val) {
> return val >> SHIFT << SHIFT;
> }
I
Chris,
> to behave? My understanding is that it is taking the area passed in and
> rounding
> the edges *outwards* to the nearest multiple of 0x0800.
Not _completely_ unrelated, I'm not sure if you know about this:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/002789.html
As far as I kn
Hi Steve/anyone,
Can someone please clarify exactly how DivisionParser.round(Area) is supposed
to behave? My understanding is that it is taking the area passed in and
rounding
the edges *outwards* to the nearest multiple of 0x0800. ie, the area should
get a little bit bigger in each direction.
17 matches
Mail list logo
