Incorrect north west latitude of RpfCoverageBox

Question

Incorrect north west latitude of RpfCoverageBox

mg629 opened this issue 6 years ago · 10 comments

I am converting CADRG to TMS and in the method makeTiles of MapTileMaker, I am getting back an incorrect north west latitude for the RpfCoverageBox but am not sure why.

public Rectangle2D makeTiles(RpfLayer rpfLayer) {
final Proj proj = new Mercator(new LatLonPoint.Double(), 50000, TILE_SIZE, TILE_SIZE);

   Vector<RpfCoverageBox> coverage = rpfLayer.getFrameProvider().getCoverage(90f, -180f, -90f, 180f, proj);
   
   for (RpfCoverageBox box : coverage) {
         // nw_lat value is coming out as 64.0046 when it should be 65.25
         nw_lat = box.nw_lat; (64.0046)
         
         // the following values are coming out correct I believe
         nw_lon = box.nw_lon; (-151.266)
         se_lat = box.se_lat; (59.861)
         se_lon = box.se_lon; (-143.77) 
   }

}

I have attached the CADRG specs from the A.TOC files at each level (50, 100, 250).

At this time I am not able to upload the full CADRG folders and files but might be able to do so in pieces if its needed.

Answer 1 · 2018-12-05T14:37:29.000Z

Hi, What do you get as output when you run the RpfTocHandler on the A.TOC file? It takes the parent RPF directory as an argument: java -cp <path to openmap.jar> com.bbn.openmap.layer.rpf.RpfTocHandler <path to RPF directory> Just to confirm, this is an A.TOC that came with the data, not something created from the OpenMap MakeToc class? - Don

…

On Dec 5, 2018, at 7:59 AM, mg629 ***@***.***> wrote: I am converting CADRG to TMS and in the method makeTiles of MapTileMaker, I am getting back an incorrect north west latitude for the RpfCoverageBox but am not sure why. public Rectangle2D makeTiles(RpfLayer rpfLayer) { final Proj proj = new Mercator(new LatLonPoint.Double(), 50000, TILE_SIZE, TILE_SIZE); Vector<RpfCoverageBox> coverage = rpfLayer.getFrameProvider().getCoverage(90f, -180f, -90f, 180f, proj); for (RpfCoverageBox box : coverage) { // nw_lat value is coming out as 64.0046 when it should be 65.25 nw_lat = box.nw_lat; (64.0046) // the following values are coming out correct I believe nw_lon = box.nw_lon; (-151.266) se_lat = box.se_lat; (59.861) se_lon = box.se_lon; (-143.77) } } I have attached the CADRG specs from the A.TOC files at each level (50, 100, 250). <https://user-images.githubusercontent.com/42076838/49475003-1b742200-f7e4-11e8-9cb4-2332648718e2.PNG> <https://user-images.githubusercontent.com/42076838/49475008-22029980-f7e4-11e8-8f14-edefa95582bf.PNG> <https://user-images.githubusercontent.com/42076838/49475015-25962080-f7e4-11e8-94b3-8ff673d137cb.PNG> At this time I am not able to upload the full CADRG folders and files but might be able to do so in pieces if its needed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#47>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB08k5N1OgeQPndWmdUJfob-bGbNMSsVks5u18M5gaJpZM4ZCreV>.

Answer 2 · 2018-12-05T20:47:03.000Z

Correct, the A.TOC file came with the data.

Attach is the output of RpfTocHandler for 50, 100, and 250 RPF directories.

Answer 3 · 2018-12-05T22:32:34.000Z

Looking at the difference between the two printouts, are you sure about the coordinates provided by the other program? I suspect that the other program is providing a set of corner coordinates for the combined area of what it refers to as subdatasets, while the RpfTocEntry coordinates are for that particular ’subdataset’. So I think both programs are giving you valid output, but the geographic areas represent different things. What made you look into this - where you having a different problem creating TMS tiles? - Don

…

On Dec 5, 2018, at 3:47 PM, mg629 ***@***.***> wrote: Correct, the A.TOC file came with the data. Attach is the output of RpfTocHandler for 50, 100, and 250 RPF directories. <https://user-images.githubusercontent.com/42076838/49542975-f72c4a00-f8a4-11e8-8120-c7397590daf1.PNG> <https://user-images.githubusercontent.com/42076838/49542979-f98ea400-f8a4-11e8-99a9-e9c192e9d0c3.PNG> <https://user-images.githubusercontent.com/42076838/49542984-fc899480-f8a4-11e8-8cb1-fceb899ad2e9.PNG> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#47 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB08k4-qmbH6uqMmTi0hgyw6odOko3smks5u2DDHgaJpZM4ZCreV>.

Answer 4 · 2018-12-05T22:52:45.000Z

The reason I started looking into the issue is my converted tms when loaded into a cesium viewer does not seem to display the full extent of the terrain. The tms on the cesium viewer map has upper left corner of 64.0046, -151.266.
According to the people who gave me the CADRG, the terrain should encompass Fairbanks which would be more like a upper left corner of 65.25, -151.266.
I noticed my min extents and max extents in my tms.json file after conversion was (min ext Lat=59.8619, Lon=-151.266 and max extent Lat=64.006, Lon=-143.7709).
It seems like the max extent should be Lat= 65.25?

Answer 5 · 2018-12-06T14:07:33.000Z

I understand what’s happening now - you’re being affected by the zones and the scale of the map you’re trying to render. If you’re not familiar with the zones in RPF, they are projection areas that are used to organize the image frames, and each one extends around the world for a limited range of latitude. They overlap each other, so when you view the map at the native scale of the chart and pan up or down, when you hit a zone boundary you can jump to the next zone, changing the projection parameters, without missing coverage from the zone you just left. The RpfLayer in OpenMap handles this - it picks the right zone based on the latitude of the map. The RpfLayer also tries to handle the situation where the map scale doesn’t completely match the scale of the chart, scaling the images to fit (and warping them if the projection type isn’t RPF). Viewing the charts like this does reveal some overlap problems. So the problem you’re seeing is that if the RpfLayer thinks it should be displaying zone 4, you’re going to see the extents of the zone 4 charts. When you move north and switch zones, you’ll see the extents of the zone 5 charts - each RpfTocEntry is it’s own continuous area of images within a specific zone. The OpenMap code is reading the correct latitude value for the zone entry, but the way that other program is combing the extents for all zone entries for a chart type is a little misleading. The OpenMap RpfLayer isn’t smart enough to try to fill the gaps in coverage with entries from another zone. That’s a change I’ve been meaning to make but haven’t gotten around to it yet. But this whole thing wouldn’t start to reveal itself unless the zone overlaps have gaps, and that doesn’t usually happen until you really start zooming away from the native scale of the chart. What you are seeing is making me think that the RpfLayer isn’t choosing the right zone for charts when it’s being used to create TMS images for a particular zoom level. Did you create TMS tiles for each chart type, or let the RpfLayer choose which chart type should be displayed at different TMS zoom levels? - Don

…

On Dec 5, 2018, at 5:52 PM, mg629 ***@***.***> wrote: The reason I started looking into the issue is my converted tms when loaded into a cesium viewer does not seem to display the full extent of the terrain. The tms on the cesium viewer map has upper left corner of 64.0046, -151.266. According to the people who gave me the CADRG, the terrain should encompass Fairbanks which would be more like a upper left corner of 65.25, -151.266. I noticed my min extents and max extents in my tms.json file after conversion was (min ext Lat=59.8619, Lon=-151.266 and max extent Lat=64.006, Lon=-143.7709). It seems like the max extent should be Lat= 65.25? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#47 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB08kzs0vJptY871n2pW0kDQpkzUgdo3ks5u2E49gaJpZM4ZCreV>.

Answer 6 · 2018-12-06T21:28:01.000Z

I let the RpfLayer choose which chart type should be displayed at different TMS zoom levels.

Answer 7 · 2018-12-10T16:22:27.000Z

Don, do you have any recommendations?
Should I try to create TMS tiles for each chart type? (not sure how to do that yet)
Would that help?

Answer 8 · 2018-12-11T16:24:34.000Z

I’m still trying to think of a solution for you. I think the real fix is a slight re-write of the RpfCoverageManager so it uses RpfCacheHandlers differently. It uses more than one RpfCacheHandler if it thinks the equator and/or dateline is on the map, so it uses different zones under special conditions. It should be adjusted so it uses as many as it needs to cover any zones on the map, so these overlap problems would just go away. But for a solution that doesn’t require a code change, you could try to help the situation using a java flag that lets java know it’s on a high resolution monitor, https://superuser.com/questions/988379/how-do-i-run-java-apps-upscaled-on-a-high-dpi-display <https://superuser.com/questions/988379/how-do-i-run-java-apps-upscaled-on-a-high-dpi-display>. I suspect that might help the RpfLayer choose the zone as it edges toward tiles close to the zone boundary. The RpfLayer can be told to only display a certain chart type, but that won’t help you here, since you’re being affected by it choosing the zone with lower zone close to the boundary. That choice is being made somewhere on behalf of the layer. I want to look into this myself later this week, and still working to the next release out. When I make a mod it’ll be in the 6.0 branch. - Don

…

On Dec 10, 2018, at 11:22 AM, mg629 ***@***.***> wrote: Don, do you have any recommendations? Should I try to create TMS tiles for each chart type? (not sure how to do that yet) Would that help? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#47 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB08kzRuRLoskbgb24G_z0E5RN7VAed0ks5u3opDgaJpZM4ZCreV>.

Answer 9 · 2018-12-11T22:37:37.000Z

Any help is appreciated. Thank you.
I will read through the link you supplied.

Answer 10 · 2019-01-04T18:57:17.000Z

Don,
Would you happen to have a release date already determined for the 6.0 branch?