Hi John,
Thanks for sharing this! Glad to know you've found a simpler solution. One
time when you might find a bounding box error is drawing lines on the map (e.g.
to create transects and vertical sections) that span the dateline. The current
version of the Godiva2 viewer doesn't handle this at all well - see
http://www.reading.ac.uk/godiva2 for example.
So maybe if anyone's developing a Pacific-focused web map app, your workaround
could still be useful!
Cheers, Jon
----------------------------------------------------------------------
Message: 1
Date: Thu, 14 Jul 2011 14:55:35 -1000
From: John Maurer <jmaurer@xxxxxxxxxx>
To: THREDDS Users <thredds@xxxxxxxxxxxxxxxx>
Subject: Re: [thredds] spanning the dateline with TDS WMS in Google
Maps API
Message-ID:
<CAEoEVrnjW0ffqagOcoeBh0b6mO4iv9vDJVSEKBZ-GLFp2cg_jA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
Just a quick follow-up (to my own message). This whole business of creating a
custom EPSG code to dodge the dateline problem in Google Maps is unnecessary
and overly cumbersome. For one, you can't rely on external sources to provide
this custom EPSG code for you, so that quickly diminishes its charm. There is a
much easier workaround, too. Google Map tiles do not span the dateline, so you
should never have a tile that has a bounding box error (this should have dawned
on me earlier). The only reason I was getting invalid bounding boxes stemmed
from using Proj4js, which for some reason gives a negative value for 180
longitude (-20037508.34) and a positive value for -180 longitude (20037508.34),
which is the reverse of what one would expect--this led to the invalid bounding
box (min x of 20037508.34 is greater than max x of -20037508.34). If either
longitude is +/-180, then, multiply your Proj4js result by -1 and you're golden.
Cheers,
John Maurer
On Wed, May 11, 2011 at 3:49 PM, John Maurer <jmaurer@xxxxxxxxxx> wrote:
> Hi TDS folks,
> This tip is for anybody trying to display a global overlay or an
> overlay spanning the dateline using WMS (ncWMS) from their TDS in
> Google Maps API. A GetMap, GetFeatureInfo, or GetMetadata request will
> fail if the minimum x coordinate is greater than the maximum x
> coordinate, which happens when your bounding box spans the dateline: the
> error is something like "invalid bbox".
> For those tiles or requests that fall in this category, you can spoof
> a projection that is identical to Google Map's (spherical mercator,
> EPSG:3857) except that the longitude of origin gets shifted to 0
> degrees longitude rather than 180 degrees longitude. This side-steps
> the problem of the min x
> > max x scenario while remaining spatially accurate. It was suggested
> > to me
> by ncWMS author Jon Blower (thanks!).
>
> *Global NCOM sea surface height from TDS ncWMS in Google Maps API
> before/after dateline correction (dateline labeled with yellow line in
> "before" image):
>
> *[image: google_wms_dateline_beforeafter.png]
>
> Here are my notes for setting up this custom EPSG code in TDS, which I
> named EPSG:93857 (so I would remember it's related to EPSG:3857):
>
> 1. shutdown Tomcat
> 2. cd /usr/local/tomcat/webapps/thredds/WEB-INF/lib/
> (/usr/local/tomcat/ may live elsewhere on your system)
> 3. mkdir temp
> 4. cp epsg-wkt.jar temp
> 5. cd temp
> 6. unzip epsg-wkt.jar
> 7. rm epsg-wkt.jar
> 8. vi org/geotoolkit/referencing/factory/epsg/epsg.properties
> 9. Add the following EPSG code, probably below 3857 since it's related;
> this just changes "Longitude of natural origin" from 0.0 to 180.0:
> 93857=PROJCS["WGS 84 / Pseudo-Mercator Dateline",GEOGCS["WGS
> 84",DATUM["World Geodetic System 1984",SPHEROID["WGS
> 84",6378137.0,298.257223563,AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0.0,
>
> AUTHORITY["EPSG","8901"]],UNIT["degree",0.017453292519943295],AXIS["Geodetic
> latitude",NORTH],AXIS["Geodetic longitude",EAST],AUTHORITY["
> EPSG","4326"]],PROJECTION["Popular Visualisation Pseudo
> Mercator",AUTHORITY["EPSG","1024"]],PARAMETER["Latitude of natural
> origin",0.0],PARAMETER["Longitude of natural
> origin",180.0],PARAMETER["False
> easting",0.0],PARAMETER["False northing",0.0],UNIT["metre",1.
> 0],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["
> EPSG","93857"]]
> 10. zip -r epsg-wkt.zip META-INF/ org/
> 11. mv epsg-wkt.zip epsg-wkt.jar
> 12. mv epsg-wkt.jar ..
> 13. cd ..
> 14. rmdir temp
> 15. start Tomcat back up
> 16. NOTE: works for WMS requests (GetMap, GetFeatureInfo, GetMetadata)
> but will not appear in GetCapabilities (a future TDS/ncWMS enhancement
> should allow admin to add more EPSG codes)
>
> As another tip, you can convert from latitude and longitude to
> EPSG:3857 using PROJ.4's JavaScript library (PROJ4JS
> <http://www.proj4js.org>):
> surprisingly, the Google Maps API doesn't provide a function for
> computing this. You can then convert an x coordinate from EPSG:3857 to
> EPSG:93857 using a JavaScript function like this:
>
> function invertEPSG3857 ( x ) {
>
> var new_x = 0.0;
>
> // Maximum x coordinate in EPSG:3857 in meters:
>
> var max_x = 20037508.34;
>
> if ( x > 0 ) {
> new_x = x - max_x;
> }
> else {
> new_x = x + max_x;
> }
>
> return new_x;
>
> }
>
> Aloha,
> John Maurer
> Pacific Islands Ocean Observing System (PacIOOS) University of Hawaii
> at Manoa
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mailman.unidata.ucar.edu/mailing_lists/archives/thredds/attachments/20110714/ea1797a3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: google_wms_dateline_beforeafter.png
Type: image/png
Size: 283410 bytes
Desc: not available
URL:
<http://mailman.unidata.ucar.edu/mailing_lists/archives/thredds/attachments/20110714/ea1797a3/attachment.png>
End of thredds Digest, Vol 30, Issue 10
***************************************
