[OSM-dev] Projection Issues

[Christopher Schmidt]

On Wed, May 31, 2006 at 01:21:08PM -0400, Christopher Schmidt wrote:
> On Wed, May 31, 2006 at 08:16:44AM -0700, Mikel Maron wrote:
> > Do you have an OpenLayers instance configured to request tiles from OSM in Mercator? With that, I can look at any problems
> > in streets.rbx. For the extent of the world, you can set the northern and southern borders to anything reasonable, say 85/-85.
> > 
> > Does that sound like a good next step?
> 
> Right now, the WMS powering OSM does not support the Mercator projection
> (at least, not if 
> http://svn.openstreetmap.org/www.openstreetmap.org/ruby/api/wms/wms.map
> is accurate). All layers are are WGS-84 (straight lat/lon projection), 
> so there is no way to request mercator projected images.
> 
> It does seem like OSM is using a tile engine which stretches tiles such
> that they follow the mercator projection -- images near the poles are
> stretched to infinity, certainly -- but I'm afraid that doesn't mean
> much for OpenLayers.
> 
> As I understand it, a mercator projection can be implemented in a system
> such as this: The backend WMS server is the one bending the images to
> fit the tiles -- the tiles should not be bending to fit the earth. In
> the OSM setup, the tile requests themselves are modified as you get away
> from the equator -- which is not a system I've seen any other WMS client
> mimic.

And after talking through this more with Schuyler, I finally understand
why. When using a Mercator projection, all your tiles are the same
height -- if your units are in meters. As you get further towards the
poles, the smaller *degree* measures are still the same measures in
meters.

The problem here is that OSM's setup right now depends on two
contradictory ways of dealing with data: 
 * Mercator projected
 * Unprojected/EPSG:4326

There are several possible ways to fix this.
 * Stop with the Mercator Madness :) And start using Unprojected
   coordinates. This would probably simplify a lot of math all over,
   since there would no longer be any need to compute crazy deltas for
   tile sizes -- if it's 1 degree wide and 1 degree tall, it's a square,
   no matter where it is in the world.
 * Change the WMS server to support queries in the mercator projection,
   which means that OpenLayers and other clients could simply switch to
   using meters, instead of degrees, and get accurate data. However,
   this may require changing more than I would expect. What i would
   expect is that math which is specific to degrees/pixel might need to
   be modified, but other than that, things should get easier: With the
   units being passed in meters, you can, as above, forego a lot of the
   hairy math that comes in trying to determine the affect of the sphere
   on the tile shape/size.
 * Create an OpenLayers.Layer.OSM, which acts like a mercator
   projection, but does all the hairy math to convert from meters to
   degrees internally: So OpenLayers would think of a tile as
   "-10000,-10000,10000,10000", but would convert it in the request
   string to -2,-2,2,2.

Note that if option 3 were to be implemented, it basically continues to
leave OpenStreetMap out of the mainstream WMS world: Other WMS clients
would probalby not have the flexibility to request data in the way that
OpenLayers can. (I'm not *sure* of this, but it seems unlikely.)

The first is one that people who are using other WMS clients will
probably be more comfortable with.

The second will be right, but will be at least slightly less usable.

A combination of one and two would let people get pretty maps (via
mercator projection) and unprojected data when needed. The combination
of these would be great to have, but even one of them would be great...
and I think it's clear that Option 3 is not the optimal one, but if we
need to fall back to it, then I guess we'll have to.

-- 
Christopher Schmidt
Web Developer