[OpenLayers-Users] Questions: Projections, Google, Yahoo, etc

Tue Feb 20 03:15:39 EST 2007

Hi Stephen,

My WMS server is home-made: it's a fairly complete WMS 1.3.0
implementation but not quite ready for full release.  You can find
details (plus an alpha version) at
http://www.resc.rdg.ac.uk/trac/ncWMS/.  It's designed specifically for
fast creation of maps from NetCDF data, particularly ocean forecast
data.  It's deployed at
http://lovejoy.nerc-essc.ac.uk:8080/ncWMS/WMS.py? and there's an
OpenLayers interface at
http://lovejoy.nerc-essc.ac.uk:8080/ncWMS/godiva2.html.

Just by way of example, here's a URL for a Plate Carree (standard
lat-lon) image:

http://lovejoy.nerc-essc.ac.uk:8080/ncWMS/WMS.py?LAYERS=waves/wind_dir&ELEVATION=0&TIME=2006-12-30T00:00Z&TRANSPARENT=true&SCALE=0.000000,360.000000&OPACITY=100&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&STYLES=&EXCEPTIONS=XML&FORMAT=image/png&CRS=CRS:84&BBOX=-11.9,48.0,12.9,62.9&WIDTH=256&HEIGHT=256.

Here's the same thing in Mercator: note that the bounding box is the
same (i.e. expressed in decimal degrees) but the projection has
changed to EPSG:41001:

http://lovejoy.nerc-essc.ac.uk:8080/ncWMS/WMS.py?LAYERS=waves/wind_dir&ELEVATION=0&TIME=2006-12-30T00:00Z&TRANSPARENT=true&SCALE=0.000000,360.000000&OPACITY=100&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&STYLES=&EXCEPTIONS=XML&FORMAT=image/png&CRS=EPSG:41001&BBOX=-11.9,48.0,12.9,62.9&WIDTH=256&HEIGHT=256

The images are very similar but the Mercator image is squashed at the
bottom and expanded at the top.

>From the server's point of view, the key is to calculate, for a given
BBOX and image width/height, the lat-lon coordinates of each pixel in
the image.  My (Python) code to do this is at:
http://www.resc.rdg.ac.uk/trac/ncWMS/browser/trunk/web/WEB-INF/jython/grids.py.

>From a tiling client's point of view, the key is to calculate, for a
given image tile, the correct BBOX in decimal degrees.  For some
reason I can't find my code to do this right now (the current version
of my client doesn't actually use Mercator projection) but the general
idea is that you calculate the y coordinate, then use lat =
arctan(sinh(y)).  I think these are the steps:

1) Calculate the number of degrees per pixel (xdpp) in the *longitude
direction* (which is linear)
2) Calculate the y coordinate in degrees, pretending that the y
coordinate is also linear (i.e. j* xdpp)  This is the "fake y"
3) Convert the y coordinate to radians
4) Calculate arctan(sinh(y)) (remember, y in radians)
5) Convert back to degrees to get the real latitude in Mercator.

For example, for a 256*256 square tile where x goes from 0 to 90
longitude and the bottom of the tile is on the equator:
1) xdpp = 90 / 256 = 0.352
2) fake y in degrees at top of tile = 90 (=0.352 * 256)
3) fake y in radians = 1.57
4) lat in radians = arctan(sinh(y)) = 1.161
5) lat in degrees = 66.51

So the URL fragment for that tile is BBOX=0,0,90,66.51&CRS=EPSG:41001.

I'm afraid I don't have a PROJ4 definition as I'm not familiar with
these (perhaps I should be).  The Wikipedia article I referenced in my
previous email was the best explanation I could find of how the
Mercator projection is constructed.  I'm also not 100% sure the
"EPSG:41001" reference is right - I couldn't find confirmation.
Mercator projection is useful for low- and mid-latitude maps that are
intended to be viewed at relatively close quarters (it's a
navigational, direction-preserving projection) and hence is suitable
for Google Maps-type things.  It is much less useful when zoomed out
to global scale, or at high latitudes.

Hope this helps - please let me know if you have any questions.

If people think it's useful I could format this into a Wiki page for
future reference.

Best wishes,
Jon

On 2/19/07, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
> Hi Jon,
>
> Very interesting. I for one would love to see:
>
> 1) any code that you care to share on how to do the pixel to latlong and
> vica versa calcuations
> 2) you complete Proj4 definition for EPSG:41001
>
> Is your WMS server UMN Mapserver based?
>
> Best regards,
>    -Stephen Woodbridge
>
> Jon Blower wrote:
> > Hi Christopher,
> >
> >> In the case of a mercator projected WMS layer, the units are in meters.
> >> In that projection, meters are linear: if you move north one pixel, you
> >> will always be moving north the same number of meters.
> >
> > Unless I've misunderstood something I don't see how this can be true,
> > particularly near the poles.  Neither pole can be represented in
> > Mercator projection: they are at plus or minus infinity (y =
> > ln(tan(lat) + sec(lat))).  Hence a finite 2-D map must decide upon a
> > cut-off point north and south (say +/- 89.9 degrees).  The projection
> > can't be linear in metres otherwise the poles could be represented.
> > See http://en.wikipedia.org/wiki/Mercator_projection.
> >
> > It's very difficult to find information about Mercator projections and
> > WMS but I created a WMS that serves images in Mercator projection.
> > The BBOX is specified in *degrees* (lon and lat) and the CRS (or SRS
> > if you're using WMS 1.1.1) is "EPSG:41001" although I have yet to find
> > official confirmation of that code.  To work out the BBOX for a
> > specific tile (in OpenLayers, Google Maps etc) you need to do a bit of
> > calculation as the tile coordinate system is non-linear in degrees.
> > However it's not too hard and I can probably dig out the code if
> > people would like to see it.
> >
> > Using my WMS in this way gives perfect georeferencing of the tiles and
> > hence overlaying of the WMS tiles on top of Google Maps.  I don't see
> > why using metres to specify the bounding box would help, but I might
> > have missed something.  If my WMS wasn't down for server maintenance I
> > could post a couple of GetMap URLs to illustrate my point... ;-)
> >
> > In summary, my understanding of coordinate systems within OpenLayers
> > is that we need each tile to be the same number of "units" in size.
> > However, I can't think of a system for Mercator projection that would
> > allow this for the whole of the latitude dimension since the poles are
> > at infinity.  Therefore I think that if this assumption is indeed
> > present it needs to be relaxed to allow some javascript code to
> > calculate the BBOX based on a non-linear projection.
> >
> > Cheers, Jon
> >
> >
> > On 2/19/07, Christopher Schmidt <crschmidt at metacarta.com> wrote:
> >> On Mon, Feb 19, 2007 at 11:23:15AM -0500, Stephen Woodbridge wrote:
> >> > Hi all,
> >> >
> >> > I am trying to research the various commercial layer providers and I
> >> > think Google, Google Earth, and Yahoo Virtual all claim to use Mercator
> >> > projections.
> >>
> >> Yes.
> >>
> >> > Are they all using the same projection?
> >>
> >> Yep. It seems that all the commercial providers use the same projection.
> >>
> >> > Does anyone have a list of the projects that the various commercial
> >> > layer providers are using? In terms of Proj4 definitions?
> >>
> >> Nope. I thought for a long time that the proj4 string was just
> >> "+proj=merc"  -- there is a large body of literature on the web which
> >> essentially says this is the case (all the other values are defaults).
> >> However, when using that projection, I've had problems with offsets from
> >> Google Maps that I don't understand.
> >>
> >> > In OpenLayers, if I want to use one of these commercial layers and
> >> > overlay it with a WMS layer, how good it the registration of the
> >> images?
> >> > Which is best/worst or are they all the same?
> >>
> >> They are all the same. They all work in the same way: decide where to
> >> put the tiles, put pins down on the geographic locations of the corner
> >> of the tiles, and ask the base layer where those pins are, then draw the
> >> tiles.
> >>
> >> > I have read that with Google Layers there is some kind of stretching of
> >> > the tiles or something to get them to align.
> >>
> >> That's actually true for *all* layers -- even WMS ones -- but it should
> >> have no affect in any case other than Google. Essentially, this results
> >> in a linear stretch of the content vertically. For tile areas that cover
> >> less than a few degrees, this is fine, because the Mercator projection
> >> is close enough to linear that it isn't a problem. For areas where a
> >> single tile covers from 0->90 degrees north, this becomes obviously
> >> wrong: zoom out on http://openlayers.org/dev/examples/google.html for an
> >> example.
> >>
> >> Some of this can be accomodated for by using smaller tiles (vertically),
> >> but at some point, there will need to be reprojection support in your
> >> setup -- most likely in OpenLayers -- and that support doesn't exist in
> >> code that's available today.
> >>
> >> > Is there are write up of
> >> > what is getting stretched and why?
> >>
> >> Google's API interacts in decimal degrees, even though the underlying
> >> data is projected into meters. Because of this, as you move throughout
> >> the map, the number of pixels in one geographic unit (degree) change.
> >>
> >> In the case of a mercator projected WMS layer, the units are in meters.
> >> In that projection, meters are linear: if you move north one pixel, you
> >> will always be moving north the same number of meters.
> >>
> >> Because of this, combined with the fact that  OpenLayers doesn't support
> >> reprojection, it is neccesary to take a tile and ask the base layer
> >> where that tile is geographically.
> >>
> >> > and how this might impact overlaying
> >> > other data in an application build around OL.
> >>
> >> It shouldn't. The goal is to make the overlaying of data be transparent
> >> to the user. This reprojection defaults to on for layers which support
> >> it -- WMS -- and has few ill effects when you have a server that accepts
> >> arbitrary bounding boxes.
> >>
> >> Regards,
> >> --
> >> Christopher Schmidt
> >> MetaCarta
> >> _______________________________________________
> >> Users mailing list
> >> Users at openlayers.org
> >> http://openlayers.org/mailman/listinfo/users
> >>
> >
> >
>
>

-- 
--------------------------------------------------------------
Dr Jon Blower              Tel: +44 118 378 5213 (direct line)
Technical Director         Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre   Fax: +44 118 378 6413
ESSC                       Email: jdb at mail.nerc-essc.ac.uk
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------