Re: [OpenMap Users] RpfFrameCacheHandler.getSubframeData()

From: Brightwell, William <wbrightwell_at_mtcsc.com>
Date: Fri, 27 Aug 2010 01:17:45 +0000

Don,

Yes, it is consistent and it is always the southern side of the image. In
particular it is a GNC (1:5m) map series. I am using the LLXY projection.
I tried the CADRG projection and experienced the same issue as well.

Thanks,
Adam


On 8/26/10 6:49 PM, "Don Dietrick" <dfdietrick_at_gmail.com> wrote:

> Hi Adam,
>
> Is the part of the map that is cut off consistent (the southern side)?
> What is the latitude of the map, and what chart type? Sometimes the
> RpfLayer doesn't know how to handle straddling the CADRG zone borders
> and the overlap isn't enough to cover the map window at certain
> scales.
>
> - Don
>
>
> On Thu, Aug 26, 2010 at 2:59 PM, Brightwell, William
> <wbrightwell_at_mtcsc.com> wrote:
>> Thanks Don.  That answers my question.
>>
>> So perhaps you can help me determine the cause of the issue I am
>> experiencing.
>>
>> Essentially, at specific projection scales my RPF data is being "cut off".
>> What I mean by cut off is that when I zoom to a specific range of the scale,
>> part of the imagery is cut off.  However, if I continue zooming (even by
>> just a little bit) it will reappear. This behavior is very predicable,
>> meaning that it always happens at the same range of scales.
>>
>> Example:
>> 1:9m --> good.
>> 1:8m --> no good.
>> 1:7m --> good.
>>
>> My first inclination is that the wrong values for the upper left and lower
>> right were being passed to the piece that determines which frames are to be
>> loaded.  However, these values are correct.  So, now I am trying to figure
>> out how OpenMap determines which frames to load.  I'm assuming I will find
>> my issue there.   Do you have any pointers?
>>
>>
>>
>> Thanks,
>> Adam
>>
>>
>> On 8/26/10 1:27 PM, "Don Dietrick" <dfdietrick_at_gmail.com> wrote:
>>
>>> Hi Adam,
>>>
>>> Each Rpf frame image is made up of 6x6 subframe images (each one of
>>> the subframe images is 256x256 pixels).  The images are managed in the
>>> TOC/entries at the frame level, though.
>>>
>>> Hope this helps,
>>>
>>> Don
>>>
>>> On Thu, Aug 26, 2010 at 12:54 PM, Brightwell, William
>>> <wbrightwell_at_mtcsc.com> wrote:
>>>> Don,
>>>>
>>>> I am trying to understand the ³getSubframeData()² method found in
>>>> RpfFrameCacheHandler.  Could you please explain to me why the value of ³6²
>>>> is important in this piece of code from that method?
>>>>
>>>> --- START CODE ---
>>>>
>>>>        RpfTocEntry entry = tocs[tocNumber].entries[entryNumber];        /*
>>>> If beyond the image boundary, forget it */        if (y < 0 || x < 0 ||
>>>> entry == null || y >= entry.vertFrames * 6                || x >=
>>>> entry.horizFrames * 6) {            return null;        }        if
>>>> (!entry.isFramesLoaded()) {
>>>>            tocs[tocNumber].loadFrameInformation(entry);        }
>>>>        RpfFrameEntry frameEntry = entry.getFrame(y / 6, x / 6);        /*
>>>> Get the right frame from the frame cache */        RpfFrame frame =
>>>> (RpfFrame) get(frameEntry);
>>>>
>>>> --- END CODE ---
>>>>
>>>> Thanks,
>>>> Adam
>>>>
>>>> --
>>>> W. Adam Brightwell
>>>> Software Engineer, MTCSC
>>>> Certified Scrum Master
>>>>
>>>> Email: wbrightwell_at_mtcsc.com
>>>> DCO:   william.brightwell_at_chat.dco.dod.mil
>>>> Office: 843-856-1935/1985 x51632
>>>> SPAWAR: 843-218-3583
>>>> Cell: 843-810-8701
>>>>
>>>>
>>
>> --
>> W. Adam Brightwell
>> Software Engineer, MTCSC
>> Certified Scrum Master
>>
>> Email: wbrightwell_at_mtcsc.com
>> DCO:   william.brightwell_at_chat.dco.dod.mil
>> Office: 843-856-1935/1985 x51632
>> SPAWAR: 843-218-3583
>> Cell: 843-810-8701
>>
>>
>>

-- 
W. Adam Brightwell
Software Engineer, MTCSC
Certified Scrum Master
Email: wbrightwell_at_mtcsc.com
DCO:   william.brightwell_at_chat.dco.dod.mil
Office: 843-856-1935/1985 x51632
SPAWAR: 843-218-3583
Cell: 843-810-8701
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Thu Aug 26 2010 - 21:31:28 EDT

This archive was generated by hypermail 2.3.0 : Tue Mar 28 2017 - 23:25:09 EDT