[MapProxy] Distortion around antimeridian/date line with EPSG:3338

Bruce Crevensten becrevensten at alaska.edu
Tue Nov 5 14:55:38 PST 2013


Thanks again for your suggestions, André.  Our team is going to review our
options and see what approaches we may use for an interim solution, as well
as look forward towards more permanent possibilities.

We are indeed in an area of the world that is challenging with respect to
map projections that show large areas.  Ideally, we'd be able to freely
choose among any of the projections that are intended for polar regions --
including polar projections that are rotated to show our area of interest
in an orientation of our choosing (i.e. Alaska at the bottom of the map).

Given the general academic interest in climate change impacts in the
Arctic, it might be interesting to see if there are resources that could be
applied to addressing this issue across some of the more common tools used
for presenting Arctic data on web maps.  I will raise that issue with our
organization, since our challenges with Arctic/antimeridian map displays
are not a problem that are going to go away or solve itself.

Huge thanks,
 - Bruce


On Sun, Oct 27, 2013 at 12:20 PM, André Pirard <A.Pirard.Papou at gmail.com>wrote:

>  On 2013-10-27 00:46, Bruce Crevensten wrote :
>
> Andre, Oliver, thanks very much for the responses.  I'll explore
> alternatives for the project I'm working on.
>
>  Andre, can you give me more detail regarding your idea of building the
> picture in two parts?  Would that be a MapProxy configuration, i.e. create
> two layers with bounding boxes to prevent the problematic overlap, then add
> both layers on the OpenLayers client to yield the desired result?  Or are
> you thinking of a different approach?
>
>
> I was thinking of not producing an image that crosses the meridian. OSM
> tiles are undoubtedly free of that problem, but a larger image is not, an
> issue that Oliver put in terms of bounding boxes.
> Hence my idea to test if limiting your present display to right near the
> meridian is OK and then, indeed, go confidently forward to a solution like
> what you describe.
> Note that the OSM map itself is not problem free. If you notice that line
> splitting Чукотка <http://www.openstreetmap.org/#map=5/66.267/170.662>and zoom down to its Map data layer, you get a never
> ending data loading page<http://www.openstreetmap.org/#map=19/66.42085/-180.00000&layers=D>.
> JOSM takes a very long time loading across the line and times out, telling
> there's no data.  Probably an API problem timed out differently by the
> client.
> I can tell you tackled the trickiest part of the globe: I was there before
> ;-)
> The best advisors would be the unhappy islanders maybe, if you can find
> them ;-)
>
> Cheers,
>
>   André.
> PS: Curious me extracted the OSM html for rendering this across the line<http://www.openstreetmap.org/#map=19/68.97579/-179.99997>:
> as expected, single layer happily mixing x=0-1 and x=524286-524287, see
> below.
> BTW, wouldn't you be luckier reprojecting EPSG:3338 to OSM's instead?
> (Just like me talking English ;-))
>
>
>  On Thu, Oct 24, 2013 at 9:22 AM, André Pirard <A.Pirard.Papou at gmail.com>wrote:
>
>>  On 2013-10-24 14:01, Oliver Tonnhofer wrote :
>>
>> On 23.10.2013, at 21:37, Bruce Crevensten wrote:
>>
>>
>>  I'm trying to use MapProxy to present OpenStreetMap layers in a nonstandard projection, EPSG:3338 (Alaska Albers).  The end goal is to use this as a base layer in an app that adds other layers showing historical sea ice extent around Alaska, which is why this (or a similar polar projection) is needed.
>>
>> Instead of a clean map, I'm seeing extreme distortion around the antimeridian/date line.  Screenshot of distortion around antimeridian/date line is here:
>>
>>  Unfortunately there is no explicit support for handling the antimeridian in MapProxy (yet).
>> You will get unwanted results as soon as you cross the dateline (and that may happen internally when MapProxy transforms bounding boxes between 3857 and 3338).
>>
>>  Out of curiosity, I'd like to know the result of the test I suggested
>> and hence the possibility of the same kludge as for the unlucky islanders:
>> build the picture in two parts on each side of that line.
>>
>> Cheers,
>>
>>   André.
>>
>
> http://www.openstreetmap.org/#map=19/68.97579/-179.99997
>
>   <div style="" class="leaflet-map-pane">
>     <div class="leaflet-tile-pane">
>       <div class="leaflet-layer">
>         <div class="leaflet-tile-container leaflet-zoom-animated"><img src=
>         "http://b.tile.openstreetmap.org/19/524287/121593.png"<http://b.tile.openstreetmap.org/19/524287/121593.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://a.tile.openstreetmap.org/19/0/121593.png"<http://a.tile.openstreetmap.org/19/0/121593.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://a.tile.openstreetmap.org/19/524287/121592.png"<http://a.tile.openstreetmap.org/19/524287/121592.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://c.tile.openstreetmap.org/19/0/121592.png"<http://c.tile.openstreetmap.org/19/0/121592.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://c.tile.openstreetmap.org/19/524287/121594.png"<http://c.tile.openstreetmap.org/19/524287/121594.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://b.tile.openstreetmap.org/19/0/121594.png"<http://b.tile.openstreetmap.org/19/0/121594.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://a.tile.openstreetmap.org/19/524286/121593.png"<http://a.tile.openstreetmap.org/19/524286/121593.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://b.tile.openstreetmap.org/19/1/121593.png"<http://b.tile.openstreetmap.org/19/1/121593.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://c.tile.openstreetmap.org/19/524286/121592.png"<http://c.tile.openstreetmap.org/19/524286/121592.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://a.tile.openstreetmap.org/19/1/121592.png"<http://a.tile.openstreetmap.org/19/1/121592.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://b.tile.openstreetmap.org/19/524286/121594.png"<http://b.tile.openstreetmap.org/19/524286/121594.png>style=
>         "height: 256px; width: 256px;" class=
>         "leaflet-tile leaflet-tile-loaded" /><img src=
>         "http://c.tile.openstreetmap.org/19/1/121594.png"<http://c.tile.openstreetmap.org/19/1/121594.png>style=
>         "height: 256px; width: 256px;" class="leaflet-tile
> leaflet-tile-loaded" /></div>
>       </div>
>     </div>
>   </div>
>
>
> _______________________________________________
> MapProxy mailing list
> MapProxy at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapproxy
>



-- 
*Bruce Crevensten*


*Senior Software Engineer*
(SNAP) Scenarios Network for Alaska & Arctic Planning
www.snap.uaf.edu

*Engineering Coordinator*
(ACUASI) Alaska Center for Unmanned Aerial Systems Integration
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapproxy/attachments/20131105/903c935d/attachment.html>


More information about the MapProxy mailing list