[OSM-dev] [Fwd: Re: DLR journey times]

[Tom Carden]

Theo sent me some suggestions and pointers to data for my time-based 
London underground maps.  He also has a few OSM-related suggestions 
which other people might be interested in.

Forwarded here so I don't lose it (apologies to Theo - I hope you don't 
mind) and in the hope that someone else checks out his Mercator 
suggestion... I actually think it's wrong on the front page, where the 
transforms are done in javascript and ruby, but I copied the java 
implementation from Steve's ruby so that would figure.  Thoughts?

Tom.

-------- Original Message --------
Subject: 	Re: DLR journey times
Date: 	Mon, 19 Jun 2006 22:10:51 +0100
From: 	Theo Honohan <theo.honohan at gmail.com>
To: 	tom at tom-carden.co.uk
References: 
<9666266e0606150832l786770c4teb6d09a3eb9d4410 at mail.gmail.com> 
<65183.194.42.239.178.1150387110.squirrel at www.easilymail.co.uk>





On 15/06/06, *Tom Carden* <tom at tom-carden.co.uk 
<mailto:tom at tom-carden.co.uk>> wrote:

    Brilliant - unsolicited email goodness :)  Thanks! I'll drop you a mail
    when I've updated the data.  Thanks for the reference to the new
    stations
    too.

    I don't understand the quote though.  Latitude and longitude /are/
    angles. 


Well, I meant more that if you were drawing a national grid map you 
could just use the eastings and northings as cartesian coordinates.

But in any case I could argue that a) you're dealing in points, not 
independent lat and lon, or b) latitude and longitude don't actually 
denote angles -- they denote (circular) meridians or parallels, which 
you could represent in a cylindrical projection without any 
transformation ( e.g. in the "plate carree" projection that the map on 
OpenLayers front page appears to use, although obviously that's not a 
great idea because of the distortion.).

In fact, arguably the "data space" is plate carree anyway if you are 
storing latitude and longitude values with fixed precision.  Mercator 
would be an impossible choice for data space given that it goes off to 
infinity in two directions!

Polar coordinates are a total pain, though, which is why in an ideal 
world I think it would be good to avoid them.  The most plausible 
replacement for trig is 3-d cartesian coordinates, which don't have the 
weird, awkward mathematics problem of lat and lon, have pretty much 
homogeneous density all over the surface and which also fit in better 
with the fact that the earth's modelled by an ellipsoid rather than a 
perfect sphere.  The simplest projection to use for small areas would be 
either perspective or stereographic, maybe, because it's conformal and 
geometrically simple.

I guess the killer reason for using latitude and longitude is that 
they're what GPS devices spit out.  So position data goes straight into 
the map in native format.  (Ironically, though, I've discovered while 
researching this that GPS uses 3-d cartesian coordinates internally -- a 
coordinate system called ECEF which has the same origin as the WGS84 
ellipsoid.)

You probably know of Jo Wood's Landserf, which is written in java and 
includes OSGB <-> lat/lon conversion.  It's a pretty nice piece of 
software actually.  It might be possible to borrow that code to make a 
filter for adding points with OSGB coordinates to OSM.  I'm not sure 
about his idea of "footprints", though. 
http://www.soi.city.ac.uk/~jwo/landserf/landserf220/doc/programming/api/jwo/landserf/process/proj/OSGB.html 
<http://www.soi.city.ac.uk/%7Ejwo/landserf/landserf220/doc/programming/api/jwo/landserf/process/proj/OSGB.html>


    Granted, the map projection code I use is hack-ish, untested and
    probably
    wrong, but I'm not going to spend my time re-writing code to use the OS
    grid... as it stands it could transfer straight over to any other city
    with data in the same format.  If I used OSGB, there would be extra
    work
    to do.


Yes, really you should ignore me.  I hadn't slept well and didn't have 
the sense to edit my totally frivolous suggestion. :-)

By the way, I gather you think there is a bug in the current OSM 
mercator code.  Looking at it, could it be a missing divisor of 2 in the 
following line?  This is the java in the Trac repository.

79 
<http://trac.openstreetmap.org/browser/java/src/org/openstreetmap/processing/util/OSMMercator.java?rev=533#L79> 
	  public double ysheet(double lat) {
80 
<http://trac.openstreetmap.org/browser/java/src/org/openstreetmap/processing/util/OSMMercator.java?rev=533#L80> 
	    return Math.log(Math.tan(QUARTER_PI + (lat * PIby360)));
81 
<http://trac.openstreetmap.org/browser/java/src/org/openstreetmap/processing/util/OSMMercator.java?rev=533#L81> 
	  }


which according to the formulas at mathworld, etc. should read

79 
<http://trac.openstreetmap.org/browser/java/src/org/openstreetmap/processing/util/OSMMercator.java?rev=533#L79> 
	  public double ysheet(double lat) {
80 
<http://trac.openstreetmap.org/browser/java/src/org/openstreetmap/processing/util/OSMMercator.java?rev=533#L80> 
	    return Math.log(Math.tan(QUARTER_PI + (lat * PIby360) / 2));
81 
<http://trac.openstreetmap.org/browser/java/src/org/openstreetmap/processing/util/OSMMercator.java?rev=533#L81> 
	  }



Theo