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

Stephen Woodbridge woodbri at swoodbridge.com
Mon Feb 19 18:35:47 EST 2007


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




More information about the Users mailing list