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

Jon Blower jdb at mail.nerc-essc.ac.uk
Mon Feb 19 11:55:08 EST 2007


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
--------------------------------------------------------------



More information about the Users mailing list