Browse Groups

• ... degrees/pixel of the map ... via CSS. It s not quite so simple, but I ll give you some formulas that should do the trick. Caveat - not tested, but I m
Message 1 of 19 , Dec 8 5:43 PM
View Source

> Another (probably simpler) idea would be to return the scale as degrees/pixel of the map
> in the REST response.  Doing so would make it easier for me to plot points via CSS.

It’s not quite so simple, but I’ll give you some formulas that should do the trick.  Caveat – not tested, but I’m pretty comfortable with my math.

Each zoom level has half the resolution of the previous level.  Level one has 1 m/pixel resolution at the equator, but resolution varies with the cosine of the latitude in Mercator project; resolution is 1 m/pixel / cosine (latitude).  For any given point, the resolution in the north-south direction in meters/pixel is the same as the resolution in the east-west direction; that’s the defining attribute of the Mercator projection.

Meters per degree longitude varies with latitude, but meter per degree latitude is constant over longitude.  For a given zoom level, variance of the meters per degree longitude cancels out the change in meters per pixel in the east/west direction as you move north and south in the Mercator direction.  Therefore, for all latitudes, the degrees longitude per pixel is constant.  If an image is 600 pixels wide, and covers 60 degrees of longitude, you have 0.1 degrees per pixel.

Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m) = 0.000009 degrees longitude/pixel.  Each zoom level up from there, you double the degrees long/pixel of a map.

i.e.  (0.000009 degrees longitude /pixel) * (2 ^ (zoom level -1))

The degrees latitude per pixel varies with latitude.  If you’re zoomed in close, the top of the map will have a scale similar to the bottom of the map.  However, if you’re showing all of North America, there’s significant variation; it why Greenland looks so big.  At the north pole, it’s zero degrees latitude per pixel – regardless of zoom level.  This is easily seen in the cosine effect:

Degrees latitude per pixel = (0.000009 degrees latitude/pixel) * (2 ^ (zoom level -1)) * cosine (latitude).

As latitude approaches 90 degrees, cosine(latitude) goes to zero degrees latitude per pixel goes to zero.  If you’re walking north on a Mercator projection map, you never get to the north pole, because your progress per step approaches zero.

So … while you can determine how many pixels you need to move by taking the shift in degrees longitude and multiplying by the pixels per degree, you have to use integration to accurately determine the number of pixels a move of N degrees latitude translates into.

I came up with a formula last night that used the longitude/ latitude bounding box of the current map; someone says the method for retrieving that information (getBounds) still isn’t working.  With some alternate math, you can use the coordinate of the center of your image, and the current zoom level, to determine where to plot a point relative to that center.

The simplest way to do this is determine the number of pixels north of the equator the center point of the image is, the number of pixels north of the equator your desired coordinate is, and calculate the difference.  Using the function I defined yesterday, center coordinate (centerlat, centerlon), and target coordinate (targetlat,targetlon) :

var degperpixel = 0.000009 * (2 ** (zoom – 1));

function MercatorProjectY(latitude)
{
latradians = latitude * 3.1415927 /180.0;
return (YProjradians * 180.0 / 3.1415927);
}

YCenterProj = MercatorProjectY(centerlat);

YTargetProj = MercatorProjectY(targetlat);

XDelta = (targetlon – centerlon) * degperpixel;

YDelta = (YTargetProj – YCenterProj) * degperpixel;

The point you want to plot is YDelta pixels above and XDelta pixels to the right of the center.  If you have a 600 x 400 pixel map, you could have YDelta values between -200 and 200, and XDelta values between -300 and 300.  Anything beyond that is off the map.

You can go in the opposite direction.  Say you know what you position is relative to the center of the map (yes, I know the coordinates you work with are relative to a corner of the

Image, but I forget which one; you can make the appropriate adjustment).  Starting with XDelta, YDelta:

function InverseMercatorProjectY(YProj)
{
YProjradians = YProj * 3.1415927 /180.0;
return (latradians * 180.0 / 3.1415927);
}

targetlon = (XDelta / degperpixel) + centerlon;  // simple enough

YTargetProj = (YDelta /degperpixel) + YCenterProj;  // YCenterProj calculated above

targetlat = InverseMercatorProjectY(YTargetProj);

If you want the bounding box of your 600 x 400 pixel map, apply this formula to XDelta, YDelta pairs of (-300,-200) and (300,200), respectively, for minimum and maximum bounds.

-Alan

• Alan, this is really terrific! Thank you for the detailed explanation and also for saving me a lot of heartache in figuring out the math 8-). My wish list,
Message 1 of 19 , Dec 12 8:33 AM
View Source
Alan, this is really terrific! Thank you for the detailed explanation and also for saving me a
lot of heartache in figuring out the math 8-).

My wish list, however still stands. It would be very helpful to developers if Yahoo! could
return this information in the REST response rather than requiring that every developer
implement their own degrees/pixel calculator.

Cheers,
Keith

--- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...> wrote:
>
> > Another (probably simpler) idea would be to return the scale as
> degrees/pixel of the map
> > in the REST response. Doing so would make it easier for me to plot points
> via CSS.
>
>
>
>
>
> It's not quite so simple, but I'll give you some formulas that should do the
> trick. Caveat - not tested, but I'm pretty comfortable with my math.
>
>
>
> Each zoom level has half the resolution of the previous level. Level one
> has 1 m/pixel resolution at the equator, but resolution varies with the
> cosine of the latitude in Mercator project; resolution is 1 m/pixel / cosine
> (latitude). For any given point, the resolution in the north-south
> direction in meters/pixel is the same as the resolution in the east-west
> direction; that's the defining attribute of the Mercator projection.
>
>
>
> Meters per degree longitude varies with latitude, but meter per degree
> latitude is constant over longitude. For a given zoom level, variance of
> the meters per degree longitude cancels out the change in meters per pixel
> in the east/west direction as you move north and south in the Mercator
> direction. Therefore, for all latitudes, the degrees longitude per pixel is
> constant. If an image is 600 pixels wide, and covers 60 degrees of
> longitude, you have 0.1 degrees per pixel.
>
>
>
> Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m) = 0.000009
> degrees longitude/pixel. Each zoom level up from there, you double the
> degrees long/pixel of a map.
>
> i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom level -1))
>
>
>
> The degrees latitude per pixel varies with latitude. If you're zoomed in
> close, the top of the map will have a scale similar to the bottom of the
> map. However, if you're showing all of North America, there's significant
> variation; it why Greenland looks so big. At the north pole, it's zero
> degrees latitude per pixel - regardless of zoom level. This is easily seen
> in the cosine effect:
>
>
>
> Degrees latitude per pixel = (0.000009 degrees latitude/pixel) * (2 ^
> (zoom level -1)) * cosine (latitude).
>
>
>
> As latitude approaches 90 degrees, cosine(latitude) goes to zero degrees
> latitude per pixel goes to zero. If you're walking north on a Mercator
> projection map, you never get to the north pole, because your progress per
> step approaches zero.
>
>
>
> So . while you can determine how many pixels you need to move by taking the
> shift in degrees longitude and multiplying by the pixels per degree, you
> have to use integration to accurately determine the number of pixels a move
> of N degrees latitude translates into.
>
>
>
> I came up with a formula last night that used the longitude/ latitude
> bounding box of the current map; someone says the method for retrieving that
> information (getBounds) still isn't working. With some alternate math, you
> can use the coordinate of the center of your image, and the current zoom
> level, to determine where to plot a point relative to that center.
>
>
>
> The simplest way to do this is determine the number of pixels north of the
> equator the center point of the image is, the number of pixels north of the
> equator your desired coordinate is, and calculate the difference. Using the
> function I defined yesterday, center coordinate (centerlat, centerlon), and
> target coordinate (targetlat,targetlon) :
>
>
>
>
>
> var degperpixel = 0.000009 * (2 ** (zoom - 1));
>
> function MercatorProjectY(latitude)
> {
> latradians = latitude * 3.1415927 /180.0;
> /(1 - sin(latradians))) / 2;
> return (YProjradians * 180.0 / 3.1415927);
> }
>
> YCenterProj = MercatorProjectY(centerlat);
>
> YTargetProj = MercatorProjectY(targetlat);
>
>
>
> XDelta = (targetlon - centerlon) * degperpixel;
>
> YDelta = (YTargetProj - YCenterProj) * degperpixel;
>
>
>
> The point you want to plot is YDelta pixels above and XDelta pixels to
> the right of the center. If you have a 600 x 400 pixel map, you could have
> YDelta values between -200 and 200, and XDelta values between -300 and 300.
> Anything beyond that is off the map.
>
>
>
> You can go in the opposite direction. Say you know what you position is
> relative to the center of the map (yes, I know the coordinates you work with
> are relative to a corner of the
>
> Image, but I forget which one; you can make the appropriate adjustment).
> Starting with XDelta, YDelta:
>
>
>
> function InverseMercatorProjectY(YProj)
> {
> YProjradians = YProj * 3.1415927 /180.0;
> return (latradians * 180.0 / 3.1415927);
> }
>
>
>
>
>
>
>
> targetlon = (XDelta / degperpixel) + centerlon; // simple enough
>
> YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> calculated above
>
> targetlat = InverseMercatorProjectY(YTargetProj);
>
>
>
> If you want the bounding box of your 600 x 400 pixel map, apply this formula
> to XDelta, YDelta pairs of (-300,-200) and (300,200), respectively, for
> minimum and maximum bounds.
>
>
>
> -Alan
>
>
>
>
>
>
>
>
>
>
>
> _____
>
• Can the moderator of this yahoo group please help this guy by removing him from the group? Apparently he doesn know how to read the bottom text of all of his
Message 1 of 19 , Dec 12 12:47 PM
View Source
Can the moderator of this yahoo group please help this guy by removing him from the group? Apparently he doesn' know how to read the bottom text of all of his messages showing how to remove from himself from the group list.....
-----Original Message-----
From: "Alberto Di Franco" <albedipa@...>
Date: Mon, 12 Dec 2005 15:20:56
To:<yws-maps@yahoogroups.com>
Subject: Re: [yws-maps] Re: More Mercator projection math

PLEASE NOT TO SEND MORE MESSAGES !!!!
----- Original Message -----
From: "kalperin" <kalperin@...>
To: <yws-maps@yahoogroups.com>
Sent: Monday, December 12, 2005 11:33 AM
Subject: [yws-maps] Re: More Mercator projection math

> Alan, this is really terrific! Thank you for the detailed explanation and also for saving me a
> lot of heartache in figuring out the math 8-).
>
> My wish list, however still stands. It would be very helpful to developers if Yahoo! could
> return this information in the REST response rather than requiring that every developer
> implement their own degrees/pixel calculator.
>
> Cheers,
> Keith
>
>
>
> --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...> wrote:
> >
> > > Another (probably simpler) idea would be to return the scale as
> > degrees/pixel of the map
> > > in the REST response. Doing so would make it easier for me to plot points
> > via CSS.
> >
> >
> >
> >
> >
> > It's not quite so simple, but I'll give you some formulas that should do the
> > trick. Caveat - not tested, but I'm pretty comfortable with my math.
> >
> >
> >
> > Each zoom level has half the resolution of the previous level. Level one
> > has 1 m/pixel resolution at the equator, but resolution varies with the
> > cosine of the latitude in Mercator project; resolution is 1 m/pixel / cosine
> > (latitude). For any given point, the resolution in the north-south
> > direction in meters/pixel is the same as the resolution in the east-west
> > direction; that's the defining attribute of the Mercator projection.
> >
> >
> >
> > Meters per degree longitude varies with latitude, but meter per degree
> > latitude is constant over longitude. For a given zoom level, variance of
> > the meters per degree longitude cancels out the change in meters per pixel
> > in the east/west direction as you move north and south in the Mercator
> > direction. Therefore, for all latitudes, the degrees longitude per pixel is
> > constant. If an image is 600 pixels wide, and covers 60 degrees of
> > longitude, you have 0.1 degrees per pixel.
> >
> >
> >
> > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m) = 0.000009
> > degrees longitude/pixel. Each zoom level up from there, you double the
> > degrees long/pixel of a map.
> >
> > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom level -1))
> >
> >
> >
> > The degrees latitude per pixel varies with latitude. If you're zoomed in
> > close, the top of the map will have a scale similar to the bottom of the
> > map. However, if you're showing all of North America, there's significant
> > variation; it why Greenland looks so big. At the north pole, it's zero
> > degrees latitude per pixel - regardless of zoom level. This is easily seen
> > in the cosine effect:
> >
> >
> >
> > Degrees latitude per pixel = (0.000009 degrees latitude/pixel) * (2 ^
> > (zoom level -1)) * cosine (latitude).
> >
> >
> >
> > As latitude approaches 90 degrees, cosine(latitude) goes to zero degrees
> > latitude per pixel goes to zero. If you're walking north on a Mercator
> > projection map, you never get to the north pole, because your progress per
> > step approaches zero.
> >
> >
> >
> > So . while you can determine how many pixels you need to move by taking the
> > shift in degrees longitude and multiplying by the pixels per degree, you
> > have to use integration to accurately determine the number of pixels a move
> > of N degrees latitude translates into.
> >
> >
> >
> > I came up with a formula last night that used the longitude/ latitude
> > bounding box of the current map; someone says the method for retrieving that
> > information (getBounds) still isn't working. With some alternate math, you
> > can use the coordinate of the center of your image, and the current zoom
> > level, to determine where to plot a point relative to that center.
> >
> >
> >
> > The simplest way to do this is determine the number of pixels north of the
> > equator the center point of the image is, the number of pixels north of the
> > equator your desired coordinate is, and calculate the difference. Using the
> > function I defined yesterday, center coordinate (centerlat, centerlon), and
> > target coordinate (targetlat,targetlon) :
> >
> >
> >
> >
> >
> > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> >
> > function MercatorProjectY(latitude)
> > {
> > latradians = latitude * 3.1415927 /180.0;
> > /(1 - sin(latradians))) / 2;
> > return (YProjradians * 180.0 / 3.1415927);
> > }
> >
> > YCenterProj = MercatorProjectY(centerlat);
> >
> > YTargetProj = MercatorProjectY(targetlat);
> >
> >
> >
> > XDelta = (targetlon - centerlon) * degperpixel;
> >
> > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> >
> >
> >
> > The point you want to plot is YDelta pixels above and XDelta pixels to
> > the right of the center. If you have a 600 x 400 pixel map, you could have
> > YDelta values between -200 and 200, and XDelta values between -300 and 300.
> > Anything beyond that is off the map.
> >
> >
> >
> > You can go in the opposite direction. Say you know what you position is
> > relative to the center of the map (yes, I know the coordinates you work with
> > are relative to a corner of the
> >
> > Image, but I forget which one; you can make the appropriate adjustment).
> > Starting with XDelta, YDelta:
> >
> >
> >
> > function InverseMercatorProjectY(YProj)
> > {
> > YProjradians = YProj * 3.1415927 /180.0;
> > return (latradians * 180.0 / 3.1415927);
> > }
> >
> >
> >
> >
> >
> >
> >
> > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> >
> > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > calculated above
> >
> > targetlat = InverseMercatorProjectY(YTargetProj);
> >
> >
> >
> > If you want the bounding box of your 600 x 400 pixel map, apply this formula
> > to XDelta, YDelta pairs of (-300,-200) and (300,200), respectively, for
> > minimum and maximum bounds.
> >
> >
> >
> > -Alan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _____
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Visit your group "yws-maps" on the web.
To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

www.automatetools.com
1-888-TOOLMATE
• Hey- Has anyone verified these equations? I just tried implementing them and it s not quite working for me. I m plotting gps tracks onto maps, and there
Message 1 of 19 , Jan 18, 2006
View Source
Hey-

Has anyone verified these equations? I just tried implementing them
and it's not quite working for me. I'm plotting gps tracks onto maps,
and there seems to be a shift associated with the data. There's a
good chance that I have a bug, but just want to check that the posted
code is verified first.

Also, put me on the list of those interested in getting rid of the
center star.

As others have stated, some sort of interface to convert lat/lon to
pixel coord (or even just the map bounds) would be _most_ excellent.

thanks,
jeff

--- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
>
> Alan, this is really terrific! Thank you for the detailed
explanation and also for saving me a
> lot of heartache in figuring out the math 8-).
>
> My wish list, however still stands. It would be very helpful to
developers if Yahoo! could
> return this information in the REST response rather than requiring
that every developer
> implement their own degrees/pixel calculator.
>
> Cheers,
> Keith
>
>
>
> --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...> wrote:
> >
> > > Another (probably simpler) idea would be to return the scale as
> > degrees/pixel of the map
> > > in the REST response. Doing so would make it easier for me to
plot points
> > via CSS.
> >
> >
> >
> >
> >
> > It's not quite so simple, but I'll give you some formulas that
should do the
> > trick. Caveat - not tested, but I'm pretty comfortable with my math.
> >
> >
> >
> > Each zoom level has half the resolution of the previous level.
Level one
> > has 1 m/pixel resolution at the equator, but resolution varies
with the
> > cosine of the latitude in Mercator project; resolution is 1
m/pixel / cosine
> > (latitude). For any given point, the resolution in the north-south
> > direction in meters/pixel is the same as the resolution in the
east-west
> > direction; that's the defining attribute of the Mercator projection.
> >
> >
> >
> > Meters per degree longitude varies with latitude, but meter per degree
> > latitude is constant over longitude. For a given zoom level,
variance of
> > the meters per degree longitude cancels out the change in meters
per pixel
> > in the east/west direction as you move north and south in the Mercator
> > direction. Therefore, for all latitudes, the degrees longitude
per pixel is
> > constant. If an image is 600 pixels wide, and covers 60 degrees of
> > longitude, you have 0.1 degrees per pixel.
> >
> >
> >
> > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m)
= 0.000009
> > degrees longitude/pixel. Each zoom level up from there, you
double the
> > degrees long/pixel of a map.
> >
> > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom level -1))
> >
> >
> >
> > The degrees latitude per pixel varies with latitude. If you're
zoomed in
> > close, the top of the map will have a scale similar to the bottom
of the
> > map. However, if you're showing all of North America, there's
significant
> > variation; it why Greenland looks so big. At the north pole, it's
zero
> > degrees latitude per pixel - regardless of zoom level. This is
easily seen
> > in the cosine effect:
> >
> >
> >
> > Degrees latitude per pixel = (0.000009 degrees latitude/pixel)
* (2 ^
> > (zoom level -1)) * cosine (latitude).
> >
> >
> >
> > As latitude approaches 90 degrees, cosine(latitude) goes to zero
degrees
> > latitude per pixel goes to zero. If you're walking north on a
Mercator
> > projection map, you never get to the north pole, because your
progress per
> > step approaches zero.
> >
> >
> >
> > So . while you can determine how many pixels you need to move by
taking the
> > shift in degrees longitude and multiplying by the pixels per
degree, you
> > have to use integration to accurately determine the number of
pixels a move
> > of N degrees latitude translates into.
> >
> >
> >
> > I came up with a formula last night that used the longitude/ latitude
> > bounding box of the current map; someone says the method for
retrieving that
> > information (getBounds) still isn't working. With some alternate
math, you
> > can use the coordinate of the center of your image, and the
current zoom
> > level, to determine where to plot a point relative to that center.
> >
> >
> >
> > The simplest way to do this is determine the number of pixels
north of the
> > equator the center point of the image is, the number of pixels
north of the
> > equator your desired coordinate is, and calculate the difference.
Using the
> > function I defined yesterday, center coordinate (centerlat,
centerlon), and
> > target coordinate (targetlat,targetlon) :
> >
> >
> >
> >
> >
> > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> >
> > function MercatorProjectY(latitude)
> > {
> > latradians = latitude * 3.1415927 /180.0;
> > /(1 - sin(latradians))) / 2;
> > return (YProjradians * 180.0 / 3.1415927);
> > }
> >
> > YCenterProj = MercatorProjectY(centerlat);
> >
> > YTargetProj = MercatorProjectY(targetlat);
> >
> >
> >
> > XDelta = (targetlon - centerlon) * degperpixel;
> >
> > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> >
> >
> >
> > The point you want to plot is YDelta pixels above and XDelta
pixels to
> > the right of the center. If you have a 600 x 400 pixel map, you
could have
> > YDelta values between -200 and 200, and XDelta values between -300
and 300.
> > Anything beyond that is off the map.
> >
> >
> >
> > You can go in the opposite direction. Say you know what you
position is
> > relative to the center of the map (yes, I know the coordinates you
work with
> > are relative to a corner of the
> >
> > Image, but I forget which one; you can make the appropriate
> > Starting with XDelta, YDelta:
> >
> >
> >
> > function InverseMercatorProjectY(YProj)
> > {
> > YProjradians = YProj * 3.1415927 /180.0;
> > return (latradians * 180.0 / 3.1415927);
> > }
> >
> >
> >
> >
> >
> >
> >
> > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> >
> > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > calculated above
> >
> > targetlat = InverseMercatorProjectY(YTargetProj);
> >
> >
> >
> > If you want the bounding box of your 600 x 400 pixel map, apply
this formula
> > to XDelta, YDelta pairs of (-300,-200) and (300,200),
respectively, for
> > minimum and maximum bounds.
> >
> >
> >
> > -Alan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _____
> >
>
• Oh, I already caught one problem (XDelta and YDelta should be computed with a / instead of a * ). The results are close , but not spot on. FYI, this is
Message 1 of 19 , Jan 19, 2006
View Source
Oh, I already caught one problem (XDelta and YDelta should be computed with a
"/" instead of a "*"). The results are "close", but not spot on.

FYI, this is for plotting running data with GPS, and when I plot with Google
Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the data set is
good. I am trying to use the Map Image API so that I can render my running
data on it.

thanks,
jeff

--- runningblogger <jeff@...> wrote:

---------------------------------
Hey-

Has anyone verified these equations? I just tried implementing them
and it's not quite working for me. I'm plotting gps tracks onto maps,
and there seems to be a shift associated with the data. There's a
good chance that I have a bug, but just want to check that the posted
code is verified first.

Also, put me on the list of those interested in getting rid of the
center star.

As others have stated, some sort of interface to convert lat/lon to
pixel coord (or even just the map bounds) would be _most_ excellent.

thanks,
jeff

--- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
>
> Alan, this is really terrific! Thank you for the detailed
explanation and also for saving me a
> lot of heartache in figuring out the math 8-).
>
> My wish list, however still stands. It would be very helpful to
developers if Yahoo! could
> return this information in the REST response rather than requiring
that every developer
> implement their own degrees/pixel calculator.
>
> Cheers,
> Keith
>
>
>
> --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...> wrote:
> >
> > > Another (probably simpler) idea would be to return the scale as
> > degrees/pixel of the map
> > > in the REST response. Doing so would make it easier for me to
plot points
> > via CSS.
> >
> >
> >
> >
> >
> > It's not quite so simple, but I'll give you some formulas that
should do the
> > trick. Caveat - not tested, but I'm pretty comfortable with my math.
> >
> >
> >
> > Each zoom level has half the resolution of the previous level.
Level one
> > has 1 m/pixel resolution at the equator, but resolution varies
with the
> > cosine of the latitude in Mercator project; resolution is 1
m/pixel / cosine
> > (latitude). For any given point, the resolution in the north-south
> > direction in meters/pixel is the same as the resolution in the
east-west
> > direction; that's the defining attribute of the Mercator projection.
> >
> >
> >
> > Meters per degree longitude varies with latitude, but meter per degree
> > latitude is constant over longitude. For a given zoom level,
variance of
> > the meters per degree longitude cancels out the change in meters
per pixel
> > in the east/west direction as you move north and south in the Mercator
> > direction. Therefore, for all latitudes, the degrees longitude
per pixel is
> > constant. If an image is 600 pixels wide, and covers 60 degrees of
> > longitude, you have 0.1 degrees per pixel.
> >
> >
> >
> > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m)
= 0.000009
> > degrees longitude/pixel. Each zoom level up from there, you
double the
> > degrees long/pixel of a map.
> >
> > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom level -1))
> >
> >
> >
> > The degrees latitude per pixel varies with latitude. If you're
zoomed in
> > close, the top of the map will have a scale similar to the bottom
of the
> > map. However, if you're showing all of North America, there's
significant
> > variation; it why Greenland looks so big. At the north pole, it's
zero
> > degrees latitude per pixel - regardless of zoom level. This is
easily seen
> > in the cosine effect:
> >
> >
> >
> > Degrees latitude per pixel = (0.000009 degrees latitude/pixel)
* (2 ^
> > (zoom level -1)) * cosine (latitude).
> >
> >
> >
> > As latitude approaches 90 degrees, cosine(latitude) goes to zero
degrees
> > latitude per pixel goes to zero. If you're walking north on a
Mercator
> > projection map, you never get to the north pole, because your
progress per
> > step approaches zero.
> >
> >
> >
> > So . while you can determine how many pixels you need to move by
taking the
> > shift in degrees longitude and multiplying by the pixels per
degree, you
> > have to use integration to accurately determine the number of
pixels a move
> > of N degrees latitude translates into.
> >
> >
> >
> > I came up with a formula last night that used the longitude/ latitude
> > bounding box of the current map; someone says the method for
retrieving that
> > information (getBounds) still isn't working. With some alternate
math, you
> > can use the coordinate of the center of your image, and the
current zoom
> > level, to determine where to plot a point relative to that center.
> >
> >
> >
> > The simplest way to do this is determine the number of pixels
north of the
> > equator the center point of the image is, the number of pixels
north of the
> > equator your desired coordinate is, and calculate the difference.
Using the
> > function I defined yesterday, center coordinate (centerlat,
centerlon), and
> > target coordinate (targetlat,targetlon) :
> >
> >
> >
> >
> >
> > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> >
> > function MercatorProjectY(latitude)
> > {
> > latradians = latitude * 3.1415927 /180.0;
> > /(1 - sin(latradians))) / 2;
> > return (YProjradians * 180.0 / 3.1415927);
> > }
> >
> > YCenterProj = MercatorProjectY(centerlat);
> >
> > YTargetProj = MercatorProjectY(targetlat);
> >
> >
> >
> > XDelta = (targetlon - centerlon) * degperpixel;
> >
> > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> >
> >
> >
> > The point you want to plot is YDelta pixels above and XDelta
pixels to
> > the right of the center. If you have a 600 x 400 pixel map, you
could have
> > YDelta values between -200 and 200, and XDelta values between -300
and 300.
> > Anything beyond that is off the map.
> >
> >
> >
> > You can go in the opposite direction. Say you know what you
position is
> > relative to the center of the map (yes, I know the coordinates you
work with
> > are relative to a corner of the
> >
> > Image, but I forget which one; you can make the appropriate
> > Starting with XDelta, YDelta:
> >
> >
> >
> > function InverseMercatorProjectY(YProj)
> > {
> > YProjradians = YProj * 3.1415927 /180.0;
> > return (latradians * 180.0 / 3.1415927);
> > }
> >
> >
> >
> >
> >
> >
> >
> > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> >
> > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > calculated above
> >
> > targetlat = InverseMercatorProjectY(YTargetProj);
> >
> >
> >
> > If you want the bounding box of your 600 x 400 pixel map, apply
this formula
> > to XDelta, YDelta pairs of (-300,-200) and (300,200),
respectively, for
> > minimum and maximum bounds.
> >
> >
> >
> > -Alan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _____
> >
>

Developer network
Building blocks
Computer security
Computer training Map

---------------------------------

Visit your group "yws-maps" on the web.

To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

---------------------------------
• Yes - I made a mistake in the equations, which I corrected in a later posting (dividing instead of multiplying). Also, you 0.000010728836 degrees per pixel
Message 1 of 19 , Jan 20, 2006
View Source
Yes - I made a mistake in the equations, which I corrected in a later
posting (dividing instead of multiplying). Also, you 0.000010728836
degrees per pixel instead of 0.000009 (for proper calibration - it's
65536 tiles times 512 pixels per tile wide at the equator at zoom
level 1.). The math is used in an actual web page at
http://mapnut.com/testzoom.html.

Sorry for the mistakes.

-Alan

--- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
>
> Oh, I already caught one problem (XDelta and YDelta should be
computed with a
> "/" instead of a "*"). The results are "close", but not spot on.
>
> FYI, this is for plotting running data with GPS, and when I plot
> Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the
data set is
> good. I am trying to use the Map Image API so that I can render my
running
> data on it.
>
> thanks,
> jeff
>
> --- runningblogger <jeff@k...> wrote:
>
>
> ---------------------------------
> Hey-
>
> Has anyone verified these equations? I just tried implementing them
> and it's not quite working for me. I'm plotting gps tracks onto maps,
> and there seems to be a shift associated with the data. There's a
> good chance that I have a bug, but just want to check that the posted
> code is verified first.
>
> Also, put me on the list of those interested in getting rid of the
> center star.
>
> As others have stated, some sort of interface to convert lat/lon to
> pixel coord (or even just the map bounds) would be _most_ excellent.
>
> thanks,
> jeff
>
> --- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
> >
> > Alan, this is really terrific! Thank you for the detailed
> explanation and also for saving me a
> > lot of heartache in figuring out the math 8-).
> >
> > My wish list, however still stands. It would be very helpful to
> developers if Yahoo! could
> > return this information in the REST response rather than requiring
> that every developer
> > implement their own degrees/pixel calculator.
> >
> > Cheers,
> > Keith
> >
> >
> >
> > --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...> wrote:
> > >
> > > > Another (probably simpler) idea would be to return the scale as
> > > degrees/pixel of the map
> > > > in the REST response. Doing so would make it easier for me to
> plot points
> > > via CSS.
> > >
> > >
> > >
> > >
> > >
> > > It's not quite so simple, but I'll give you some formulas that
> should do the
> > > trick. Caveat - not tested, but I'm pretty comfortable with my
math.
> > >
> > >
> > >
> > > Each zoom level has half the resolution of the previous level.
> Level one
> > > has 1 m/pixel resolution at the equator, but resolution varies
> with the
> > > cosine of the latitude in Mercator project; resolution is 1
> m/pixel / cosine
> > > (latitude). For any given point, the resolution in the north-south
> > > direction in meters/pixel is the same as the resolution in the
> east-west
> > > direction; that's the defining attribute of the Mercator projection.
> > >
> > >
> > >
> > > Meters per degree longitude varies with latitude, but meter per
degree
> > > latitude is constant over longitude. For a given zoom level,
> variance of
> > > the meters per degree longitude cancels out the change in meters
> per pixel
> > > in the east/west direction as you move north and south in the
Mercator
> > > direction. Therefore, for all latitudes, the degrees longitude
> per pixel is
> > > constant. If an image is 600 pixels wide, and covers 60 degrees of
> > > longitude, you have 0.1 degrees per pixel.
> > >
> > >
> > >
> > > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m)
> = 0.000009
> > > degrees longitude/pixel. Each zoom level up from there, you
> double the
> > > degrees long/pixel of a map.
> > >
> > > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom level -1))
> > >
> > >
> > >
> > > The degrees latitude per pixel varies with latitude. If you're
> zoomed in
> > > close, the top of the map will have a scale similar to the bottom
> of the
> > > map. However, if you're showing all of North America, there's
> significant
> > > variation; it why Greenland looks so big. At the north pole, it's
> zero
> > > degrees latitude per pixel - regardless of zoom level. This is
> easily seen
> > > in the cosine effect:
> > >
> > >
> > >
> > > Degrees latitude per pixel = (0.000009 degrees latitude/pixel)
> * (2 ^
> > > (zoom level -1)) * cosine (latitude).
> > >
> > >
> > >
> > > As latitude approaches 90 degrees, cosine(latitude) goes to zero
> degrees
> > > latitude per pixel goes to zero. If you're walking north on a
> Mercator
> > > projection map, you never get to the north pole, because your
> progress per
> > > step approaches zero.
> > >
> > >
> > >
> > > So . while you can determine how many pixels you need to move by
> taking the
> > > shift in degrees longitude and multiplying by the pixels per
> degree, you
> > > have to use integration to accurately determine the number of
> pixels a move
> > > of N degrees latitude translates into.
> > >
> > >
> > >
> > > I came up with a formula last night that used the longitude/
latitude
> > > bounding box of the current map; someone says the method for
> retrieving that
> > > information (getBounds) still isn't working. With some alternate
> math, you
> > > can use the coordinate of the center of your image, and the
> current zoom
> > > level, to determine where to plot a point relative to that center.
> > >
> > >
> > >
> > > The simplest way to do this is determine the number of pixels
> north of the
> > > equator the center point of the image is, the number of pixels
> north of the
> > > equator your desired coordinate is, and calculate the difference.
> Using the
> > > function I defined yesterday, center coordinate (centerlat,
> centerlon), and
> > > target coordinate (targetlat,targetlon) :
> > >
> > >
> > >
> > >
> > >
> > > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> > >
> > > function MercatorProjectY(latitude)
> > > {
> > > latradians = latitude * 3.1415927 /180.0;
> > > /(1 - sin(latradians))) / 2;
> > > return (YProjradians * 180.0 / 3.1415927);
> > > }
> > >
> > > YCenterProj = MercatorProjectY(centerlat);
> > >
> > > YTargetProj = MercatorProjectY(targetlat);
> > >
> > >
> > >
> > > XDelta = (targetlon - centerlon) * degperpixel;
> > >
> > > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> > >
> > >
> > >
> > > The point you want to plot is YDelta pixels above and XDelta
> pixels to
> > > the right of the center. If you have a 600 x 400 pixel map, you
> could have
> > > YDelta values between -200 and 200, and XDelta values between -300
> and 300.
> > > Anything beyond that is off the map.
> > >
> > >
> > >
> > > You can go in the opposite direction. Say you know what you
> position is
> > > relative to the center of the map (yes, I know the coordinates you
> work with
> > > are relative to a corner of the
> > >
> > > Image, but I forget which one; you can make the appropriate
> > > Starting with XDelta, YDelta:
> > >
> > >
> > >
> > > function InverseMercatorProjectY(YProj)
> > > {
> > > YProjradians = YProj * 3.1415927 /180.0;
> > > latradians = 2 * atan(exp(YProjradians)) - 3.1415927 / 2;
> > > return (latradians * 180.0 / 3.1415927);
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> > >
> > > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > > calculated above
> > >
> > > targetlat = InverseMercatorProjectY(YTargetProj);
> > >
> > >
> > >
> > > If you want the bounding box of your 600 x 400 pixel map, apply
> this formula
> > > to XDelta, YDelta pairs of (-300,-200) and (300,200),
> respectively, for
> > > minimum and maximum bounds.
> > >
> > >
> > >
> > > -Alan
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _____
> > >
> >
>
>
>
>
>
>
>
>
>
>
> Developer network

> Building blocks
> Computer security

> Computer training Map

>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>
• Perfect! I put in the new magic number and everything magically works great. Apparently I missed some later group discussions on this topic...have there been
Message 1 of 19 , Jan 20, 2006
View Source
Perfect! I put in the new magic number and everything magically works great.

Apparently I missed some later group discussions on this topic...have there
been any more progress on removing the star from the center of the map?

I will also be looking at adding tiling and stitching features to my app- I
know that the API mentions this but I haven't seen much technical info on it.
Any pointers?

thanks!

---------------------------------
Yes - I made a mistake in the equations, which I corrected in a later
posting (dividing instead of multiplying). Also, you 0.000010728836
degrees per pixel instead of 0.000009 (for proper calibration - it's
65536 tiles times 512 pixels per tile wide at the equator at zoom
level 1.). The math is used in an actual web page at
http://mapnut.com/testzoom.html.

Sorry for the mistakes.

-Alan

--- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
>
> Oh, I already caught one problem (XDelta and YDelta should be
computed with a
> "/" instead of a "*"). The results are "close", but not spot on.
>
> FYI, this is for plotting running data with GPS, and when I plot
> Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the
data set is
> good. I am trying to use the Map Image API so that I can render my
running
> data on it.
>
> thanks,
> jeff
>
> --- runningblogger <jeff@k...> wrote:
>
>
> ---------------------------------
> Hey-
>
> Has anyone verified these equations? I just tried implementing them
> and it's not quite working for me. I'm plotting gps tracks onto maps,
> and there seems to be a shift associated with the data. There's a
> good chance that I have a bug, but just want to check that the posted
> code is verified first.
>
> Also, put me on the list of those interested in getting rid of the
> center star.
>
> As others have stated, some sort of interface to convert lat/lon to
> pixel coord (or even just the map bounds) would be _most_ excellent.
>
> thanks,
> jeff
>
> --- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
> >
> > Alan, this is really terrific! Thank you for the detailed
> explanation and also for saving me a
> > lot of heartache in figuring out the math 8-).
> >
> > My wish list, however still stands. It would be very helpful to
> developers if Yahoo! could
> > return this information in the REST response rather than requiring
> that every developer
> > implement their own degrees/pixel calculator.
> >
> > Cheers,
> > Keith
> >
> >
> >
> > --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...> wrote:
> > >
> > > > Another (probably simpler) idea would be to return the scale as
> > > degrees/pixel of the map
> > > > in the REST response. Doing so would make it easier for me to
> plot points
> > > via CSS.
> > >
> > >
> > >
> > >
> > >
> > > It's not quite so simple, but I'll give you some formulas that
> should do the
> > > trick. Caveat - not tested, but I'm pretty comfortable with my
math.
> > >
> > >
> > >
> > > Each zoom level has half the resolution of the previous level.
> Level one
> > > has 1 m/pixel resolution at the equator, but resolution varies
> with the
> > > cosine of the latitude in Mercator project; resolution is 1
> m/pixel / cosine
> > > (latitude). For any given point, the resolution in the north-south
> > > direction in meters/pixel is the same as the resolution in the
> east-west
> > > direction; that's the defining attribute of the Mercator projection.
> > >
> > >
> > >
> > > Meters per degree longitude varies with latitude, but meter per
degree
> > > latitude is constant over longitude. For a given zoom level,
> variance of
> > > the meters per degree longitude cancels out the change in meters
> per pixel
> > > in the east/west direction as you move north and south in the
Mercator
> > > direction. Therefore, for all latitudes, the degrees longitude
> per pixel is
> > > constant. If an image is 600 pixels wide, and covers 60 degrees of
> > > longitude, you have 0.1 degrees per pixel.
> > >
> > >
> > >
> > > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m)
> = 0.000009
> > > degrees longitude/pixel. Each zoom level up from there, you
> double the
> > > degrees long/pixel of a map.
> > >
> > > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom level -1))
> > >
> > >
> > >
> > > The degrees latitude per pixel varies with latitude. If you're
> zoomed in
> > > close, the top of the map will have a scale similar to the bottom
> of the
> > > map. However, if you're showing all of North America, there's
> significant
> > > variation; it why Greenland looks so big. At the north pole, it's
> zero
> > > degrees latitude per pixel - regardless of zoom level. This is
> easily seen
> > > in the cosine effect:
> > >
> > >
> > >
> > > Degrees latitude per pixel = (0.000009 degrees latitude/pixel)
> * (2 ^
> > > (zoom level -1)) * cosine (latitude).
> > >
> > >
> > >
> > > As latitude approaches 90 degrees, cosine(latitude) goes to zero
> degrees
> > > latitude per pixel goes to zero. If you're walking north on a
> Mercator
> > > projection map, you never get to the north pole, because your
> progress per
> > > step approaches zero.
> > >
> > >
> > >
> > > So . while you can determine how many pixels you need to move by
> taking the
> > > shift in degrees longitude and multiplying by the pixels per
> degree, you
> > > have to use integration to accurately determine the number of
> pixels a move
> > > of N degrees latitude translates into.
> > >
> > >
> > >
> > > I came up with a formula last night that used the longitude/
latitude
> > > bounding box of the current map; someone says the method for
> retrieving that
> > > information (getBounds) still isn't working. With some alternate
> math, you
> > > can use the coordinate of the center of your image, and the
> current zoom
> > > level, to determine where to plot a point relative to that center.
> > >
> > >
> > >
> > > The simplest way to do this is determine the number of pixels
> north of the
> > > equator the center point of the image is, the number of pixels
> north of the
> > > equator your desired coordinate is, and calculate the difference.
> Using the
> > > function I defined yesterday, center coordinate (centerlat,
> centerlon), and
> > > target coordinate (targetlat,targetlon) :
> > >
> > >
> > >
> > >
> > >
> > > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> > >
> > > function MercatorProjectY(latitude)
> > > {
> > > latradians = latitude * 3.1415927 /180.0;
> > > /(1 - sin(latradians))) / 2;
> > > return (YProjradians * 180.0 / 3.1415927);
> > > }
> > >
> > > YCenterProj = MercatorProjectY(centerlat);
> > >
> > > YTargetProj = MercatorProjectY(targetlat);
> > >
> > >
> > >
> > > XDelta = (targetlon - centerlon) * degperpixel;
> > >
> > > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> > >
> > >
> > >
> > > The point you want to plot is YDelta pixels above and XDelta
> pixels to
> > > the right of the center. If you have a 600 x 400 pixel map, you
> could have
> > > YDelta values between -200 and 200, and XDelta values between -300
> and 300.
> > > Anything beyond that is off the map.
> > >
> > >
> > >
> > > You can go in the opposite direction. Say you know what you
> position is
> > > relative to the center of the map (yes, I know the coordinates you
> work with
> > > are relative to a corner of the
> > >
> > > Image, but I forget which one; you can make the appropriate
> > > Starting with XDelta, YDelta:
> > >
> > >
> > >
> > > function InverseMercatorProjectY(YProj)
> > > {
> > > YProjradians = YProj * 3.1415927 /180.0;
> > > latradians = 2 * atan(exp(YProjradians)) - 3.1415927 / 2;
> > > return (latradians * 180.0 / 3.1415927);
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> > >
> > > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > > calculated above
> > >
> > > targetlat = InverseMercatorProjectY(YTargetProj);
> > >
> > >
> > >
> > > If you want the bounding box of your 600 x 400 pixel map, apply
> this formula
> > > to XDelta, YDelta pairs of (-300,-200) and (300,200),
> respectively, for
> > > minimum and maximum bounds.
> > >
> > >
> > >
> > > -Alan
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _____
> > >
> >
>
>
>
>
>
>
>
>
>
>
> Developer network

> Building blocks
> Computer security

> Computer training Map

>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>

---------------------------------

Visit your group "yws-maps" on the web.

To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

---------------------------------
• Well, everything is working well with one exception: zoom level 2. Is there any chance that this is a special case that doesn t work with your original
Message 1 of 19 , Jan 20, 2006
View Source
Well, everything is working well with one exception: zoom level 2. Is there
any chance that this is a special case that doesn't work with your original
formulas?

--- Jeff Kalikstein <jeff@...> wrote:

---------------------------------
Perfect! I put in the new magic number and everything magically works great.

Apparently I missed some later group discussions on this topic...have there
been any more progress on removing the star from the center of the map?

I will also be looking at adding tiling and stitching features to my app- I
know that the API mentions this but I haven't seen much technical info on it.
Any pointers?

thanks!

---------------------------------
Yes - I made a mistake in the equations, which I corrected in a later
posting (dividing instead of multiplying). Also, you 0.000010728836
degrees per pixel instead of 0.000009 (for proper calibration - it's
65536 tiles times 512 pixels per tile wide at the equator at zoom
level 1.). The math is used in an actual web page at
http://mapnut.com/testzoom.html.

Sorry for the mistakes.

-Alan

--- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
>
> Oh, I already caught one problem (XDelta and YDelta should be
computed with a
> "/" instead of a "*"). The results are "close", but not spot on.
>
> FYI, this is for plotting running data with GPS, and when I plot
> Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the
data set is
> good. I am trying to use the Map Image API so that I can render my
running
> data on it.
>
> thanks,
> jeff
>
> --- runningblogger <jeff@k...> wrote:
>
>
> ---------------------------------
> Hey-
>
> Has anyone verified these equations? I just tried implementing them
> and it's not quite working for me. I'm plotting gps tracks onto maps,
> and there seems to be a shift associated with the data. There's a
> good chance that I have a bug, but just want to check that the posted
> code is verified first.
>
> Also, put me on the list of those interested in getting rid of the
> center star.
>
> As others have stated, some sort of interface to convert lat/lon to
> pixel coord (or even just the map bounds) would be _most_ excellent.
>
> thanks,
> jeff
>
> --- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
> >
> > Alan, this is really terrific! Thank you for the detailed
> explanation and also for saving me a
> > lot of heartache in figuring out the math 8-).
> >
> > My wish list, however still stands. It would be very helpful to
> developers if Yahoo! could
> > return this information in the REST response rather than requiring
> that every developer
> > implement their own degrees/pixel calculator.
> >
> > Cheers,
> > Keith
> >
> >
> >
> > --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...> wrote:
> > >
> > > > Another (probably simpler) idea would be to return the scale as
> > > degrees/pixel of the map
> > > > in the REST response. Doing so would make it easier for me to
> plot points
> > > via CSS.
> > >
> > >
> > >
> > >
> > >
> > > It's not quite so simple, but I'll give you some formulas that
> should do the
> > > trick. Caveat - not tested, but I'm pretty comfortable with my
math.
> > >
> > >
> > >
> > > Each zoom level has half the resolution of the previous level.
> Level one
> > > has 1 m/pixel resolution at the equator, but resolution varies
> with the
> > > cosine of the latitude in Mercator project; resolution is 1
> m/pixel / cosine
> > > (latitude). For any given point, the resolution in the north-south
> > > direction in meters/pixel is the same as the resolution in the
> east-west
> > > direction; that's the defining attribute of the Mercator projection.
> > >
> > >
> > >
> > > Meters per degree longitude varies with latitude, but meter per
degree
> > > latitude is constant over longitude. For a given zoom level,
> variance of
> > > the meters per degree longitude cancels out the change in meters
> per pixel
> > > in the east/west direction as you move north and south in the
Mercator
> > > direction. Therefore, for all latitudes, the degrees longitude
> per pixel is
> > > constant. If an image is 600 pixels wide, and covers 60 degrees of
> > > longitude, you have 0.1 degrees per pixel.
> > >
> > >
> > >
> > > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m)
> = 0.000009
> > > degrees longitude/pixel. Each zoom level up from there, you
> double the
> > > degrees long/pixel of a map.
> > >
> > > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom level -1))
> > >
> > >
> > >
> > > The degrees latitude per pixel varies with latitude. If you're
> zoomed in
> > > close, the top of the map will have a scale similar to the bottom
> of the
> > > map. However, if you're showing all of North America, there's
> significant
> > > variation; it why Greenland looks so big. At the north pole, it's
> zero
> > > degrees latitude per pixel - regardless of zoom level. This is
> easily seen
> > > in the cosine effect:
> > >
> > >
> > >
> > > Degrees latitude per pixel = (0.000009 degrees latitude/pixel)
> * (2 ^
> > > (zoom level -1)) * cosine (latitude).
> > >
> > >
> > >
> > > As latitude approaches 90 degrees, cosine(latitude) goes to zero
> degrees
> > > latitude per pixel goes to zero. If you're walking north on a
> Mercator
> > > projection map, you never get to the north pole, because your
> progress per
> > > step approaches zero.
> > >
> > >
> > >
> > > So . while you can determine how many pixels you need to move by
> taking the
> > > shift in degrees longitude and multiplying by the pixels per
> degree, you
> > > have to use integration to accurately determine the number of
> pixels a move
> > > of N degrees latitude translates into.
> > >
> > >
> > >
> > > I came up with a formula last night that used the longitude/
latitude
> > > bounding box of the current map; someone says the method for
> retrieving that
> > > information (getBounds) still isn't working. With some alternate
> math, you
> > > can use the coordinate of the center of your image, and the
> current zoom
> > > level, to determine where to plot a point relative to that center.
> > >
> > >
> > >
> > > The simplest way to do this is determine the number of pixels
> north of the
> > > equator the center point of the image is, the number of pixels
> north of the
> > > equator your desired coordinate is, and calculate the difference.
> Using the
> > > function I defined yesterday, center coordinate (centerlat,
> centerlon), and
> > > target coordinate (targetlat,targetlon) :
> > >
> > >
> > >
> > >
> > >
> > > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> > >
> > > function MercatorProjectY(latitude)
> > > {
> > > latradians = latitude * 3.1415927 /180.0;
> > > /(1 - sin(latradians))) / 2;
> > > return (YProjradians * 180.0 / 3.1415927);
> > > }
> > >
> > > YCenterProj = MercatorProjectY(centerlat);
> > >
> > > YTargetProj = MercatorProjectY(targetlat);
> > >
> > >
> > >
> > > XDelta = (targetlon - centerlon) * degperpixel;
> > >
> > > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> > >
> > >
> > >
> > > The point you want to plot is YDelta pixels above and XDelta
> pixels to
> > > the right of the center. If you have a 600 x 400 pixel map, you
> could have
> > > YDelta values between -200 and 200, and XDelta values between -300
> and 300.
> > > Anything beyond that is off the map.
> > >
> > >
> > >
> > > You can go in the opposite direction. Say you know what you
> position is
> > > relative to the center of the map (yes, I know the coordinates you
> work with
> > > are relative to a corner of the
> > >
> > > Image, but I forget which one; you can make the appropriate
> > > Starting with XDelta, YDelta:
> > >
> > >
> > >
> > > function InverseMercatorProjectY(YProj)
> > > {
> > > YProjradians = YProj * 3.1415927 /180.0;
> > > latradians = 2 * atan(exp(YProjradians)) - 3.1415927 / 2;
> > > return (latradians * 180.0 / 3.1415927);
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> > >
> > > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > > calculated above
> > >
> > > targetlat = InverseMercatorProjectY(YTargetProj);
> > >
> > >
> > >
> > > If you want the bounding box of your 600 x 400 pixel map, apply
> this formula
> > > to XDelta, YDelta pairs of (-300,-200) and (300,200),
> respectively, for
> > > minimum and maximum bounds.
> > >
> > >
> > >
> > > -Alan
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _____
> > >
> >
>
>
>
>
>
>
>
>
>
>
> Developer network

> Building blocks
> Computer security

> Computer training Map

>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>

---------------------------------

Visit your group "yws-maps" on the web.

To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

---------------------------------

Developer network
Building blocks
Computer security
Computer training Map

---------------------------------

Visit your group "yws-maps" on the web.

To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

---------------------------------
• Upon even furhter review, I have determined that zoom level 4 is also broken. At first, I thought this may be an even/odd issue, but zoom level 6 works. Note
Message 1 of 19 , Jan 22, 2006
View Source
Upon even furhter review, I have determined that zoom level 4 is also broken.
At first, I thought this may be an even/odd issue, but zoom level 6 works.

Note that I am using the "Map Image API". Is it possible that these zoom
levels are different than JS api?

thanks,
jeff

--- Jeff Kalikstein <jeff@...> wrote:

---------------------------------
Well, everything is working well with one exception: zoom level 2. Is there
any chance that this is a special case that doesn't work with your original
formulas?

--- Jeff Kalikstein <jeff@...> wrote:

---------------------------------
Perfect! I put in the new magic number and everything magically works great.

Apparently I missed some later group discussions on this topic...have there
been any more progress on removing the star from the center of the map?

I will also be looking at adding tiling and stitching features to my app- I
know that the API mentions this but I haven't seen much technical info on it.
Any pointers?

thanks!

---------------------------------
Yes - I made a mistake in the equations, which I corrected in a later
posting (dividing instead of multiplying). Also, you 0.000010728836
degrees per pixel instead of 0.000009 (for proper calibration - it's
65536 tiles times 512 pixels per tile wide at the equator at zoom
level 1.). The math is used in an actual web page at
http://mapnut.com/testzoom.html.

Sorry for the mistakes.

-Alan

--- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
>
> Oh, I already caught one problem (XDelta and YDelta should be
computed with a
> "/" instead of a "*"). The results are "close", but not spot on.
>
> FYI, this is for plotting running data with GPS, and when I plot
> Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the
data set is
> good. I am trying to use the Map Image API so that I can render my
running
> data on it.
>
> thanks,
> jeff
>
> --- runningblogger <jeff@k...> wrote:
>
>
> ---------------------------------
> Hey-
>
> Has anyone verified these equations? I just tried implementing them
> and it's not quite working for me. I'm plotting gps tracks onto maps,
> and there seems to be a shift associated with the data. There's a
> good chance that I have a bug, but just want to check that the posted
> code is verified first.
>
> Also, put me on the list of those interested in getting rid of the
> center star.
>
> As others have stated, some sort of interface to convert lat/lon to
> pixel coord (or even just the map bounds) would be _most_ excellent.
>
> thanks,
> jeff
>
> --- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
> >
> > Alan, this is really terrific! Thank you for the detailed
> explanation and also for saving me a
> > lot of heartache in figuring out the math 8-).
> >
> > My wish list, however still stands. It would be very helpful to
> developers if Yahoo! could
> > return this information in the REST response rather than requiring
> that every developer
> > implement their own degrees/pixel calculator.
> >
> > Cheers,
> > Keith
> >
> >
> >
> > --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...> wrote:
> > >
> > > > Another (probably simpler) idea would be to return the scale as
> > > degrees/pixel of the map
> > > > in the REST response. Doing so would make it easier for me to
> plot points
> > > via CSS.
> > >
> > >
> > >
> > >
> > >
> > > It's not quite so simple, but I'll give you some formulas that
> should do the
> > > trick. Caveat - not tested, but I'm pretty comfortable with my
math.
> > >
> > >
> > >
> > > Each zoom level has half the resolution of the previous level.
> Level one
> > > has 1 m/pixel resolution at the equator, but resolution varies
> with the
> > > cosine of the latitude in Mercator project; resolution is 1
> m/pixel / cosine
> > > (latitude). For any given point, the resolution in the north-south
> > > direction in meters/pixel is the same as the resolution in the
> east-west
> > > direction; that's the defining attribute of the Mercator projection.
> > >
> > >
> > >
> > > Meters per degree longitude varies with latitude, but meter per
degree
> > > latitude is constant over longitude. For a given zoom level,
> variance of
> > > the meters per degree longitude cancels out the change in meters
> per pixel
> > > in the east/west direction as you move north and south in the
Mercator
> > > direction. Therefore, for all latitudes, the degrees longitude
> per pixel is
> > > constant. If an image is 600 pixels wide, and covers 60 degrees of
> > > longitude, you have 0.1 degrees per pixel.
> > >
> > >
> > >
> > > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m)
> = 0.000009
> > > degrees longitude/pixel. Each zoom level up from there, you
> double the
> > > degrees long/pixel of a map.
> > >
> > > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom level -1))
> > >
> > >
> > >
> > > The degrees latitude per pixel varies with latitude. If you're
> zoomed in
> > > close, the top of the map will have a scale similar to the bottom
> of the
> > > map. However, if you're showing all of North America, there's
> significant
> > > variation; it why Greenland looks so big. At the north pole, it's
> zero
> > > degrees latitude per pixel - regardless of zoom level. This is
> easily seen
> > > in the cosine effect:
> > >
> > >
> > >
> > > Degrees latitude per pixel = (0.000009 degrees latitude/pixel)
> * (2 ^
> > > (zoom level -1)) * cosine (latitude).
> > >
> > >
> > >
> > > As latitude approaches 90 degrees, cosine(latitude) goes to zero
> degrees
> > > latitude per pixel goes to zero. If you're walking north on a
> Mercator
> > > projection map, you never get to the north pole, because your
> progress per
> > > step approaches zero.
> > >
> > >
> > >
> > > So . while you can determine how many pixels you need to move by
> taking the
> > > shift in degrees longitude and multiplying by the pixels per
> degree, you
> > > have to use integration to accurately determine the number of
> pixels a move
> > > of N degrees latitude translates into.
> > >
> > >
> > >
> > > I came up with a formula last night that used the longitude/
latitude
> > > bounding box of the current map; someone says the method for
> retrieving that
> > > information (getBounds) still isn't working. With some alternate
> math, you
> > > can use the coordinate of the center of your image, and the
> current zoom
> > > level, to determine where to plot a point relative to that center.
> > >
> > >
> > >
> > > The simplest way to do this is determine the number of pixels
> north of the
> > > equator the center point of the image is, the number of pixels
> north of the
> > > equator your desired coordinate is, and calculate the difference.
> Using the
> > > function I defined yesterday, center coordinate (centerlat,
> centerlon), and
> > > target coordinate (targetlat,targetlon) :
> > >
> > >
> > >
> > >
> > >
> > > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> > >
> > > function MercatorProjectY(latitude)
> > > {
> > > latradians = latitude * 3.1415927 /180.0;
> > > /(1 - sin(latradians))) / 2;
> > > return (YProjradians * 180.0 / 3.1415927);
> > > }
> > >
> > > YCenterProj = MercatorProjectY(centerlat);
> > >
> > > YTargetProj = MercatorProjectY(targetlat);
> > >
> > >
> > >
> > > XDelta = (targetlon - centerlon) * degperpixel;
> > >
> > > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> > >
> > >
> > >
> > > The point you want to plot is YDelta pixels above and XDelta
> pixels to
> > > the right of the center. If you have a 600 x 400 pixel map, you
> could have
> > > YDelta values between -200 and 200, and XDelta values between -300
> and 300.
> > > Anything beyond that is off the map.
> > >
> > >
> > >
> > > You can go in the opposite direction. Say you know what you
> position is
> > > relative to the center of the map (yes, I know the coordinates you
> work with
> > > are relative to a corner of the
> > >
> > > Image, but I forget which one; you can make the appropriate
> > > Starting with XDelta, YDelta:
> > >
> > >
> > >
> > > function InverseMercatorProjectY(YProj)
> > > {
> > > YProjradians = YProj * 3.1415927 /180.0;
> > > latradians = 2 * atan(exp(YProjradians)) - 3.1415927 / 2;
> > > return (latradians * 180.0 / 3.1415927);
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> > >
> > > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > > calculated above
> > >
> > > targetlat = InverseMercatorProjectY(YTargetProj);
> > >
> > >
> > >
> > > If you want the bounding box of your 600 x 400 pixel map, apply
> this formula
> > > to XDelta, YDelta pairs of (-300,-200) and (300,200),
> respectively, for
> > > minimum and maximum bounds.
> > >
> > >
> > >
> > > -Alan
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _____
> > >
> >
>
>
>
>
>
>
>
>
>
>
> Developer network

> Building blocks
> Computer security

> Computer training Map

>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>

---------------------------------

Visit your group "yws-maps" on the web.

To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

---------------------------------

Developer network
Building blocks
Computer security
Computer training Map

---------------------------------

Visit your group "yws-maps" on the web.

To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

---------------------------------

---------------------------------

Visit your group "yws-maps" on the web.

To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

---------------------------------
• This is excellent. Thanks Alan. You are da man. I would never be able to come up with this kind of math myself. - Earth C. ... works great. ... topic...have
Message 1 of 19 , Jan 22, 2006
View Source
This is excellent. Thanks Alan. You are da man. I would never be able
to come up with this kind of math myself.

- Earth C.

--- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
>
> Perfect! I put in the new magic number and everything magically
works great.
>
> Apparently I missed some later group discussions on this
topic...have there
> been any more progress on removing the star from the center of the map?
>
> I will also be looking at adding tiling and stitching features to my
app- I
> know that the API mentions this but I haven't seen much technical
info on it.
> Any pointers?
>
> thanks!
>
>
>
> ---------------------------------
> Yes - I made a mistake in the equations, which I corrected in a later
> posting (dividing instead of multiplying). Also, you 0.000010728836
> degrees per pixel instead of 0.000009 (for proper calibration - it's
> 65536 tiles times 512 pixels per tile wide at the equator at zoom
> level 1.). The math is used in an actual web page at
> http://mapnut.com/testzoom.html.
>
> Sorry for the mistakes.
>
> -Alan
>
> --- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
> >
> > Oh, I already caught one problem (XDelta and YDelta should be
> computed with a
> > "/" instead of a "*"). The results are "close", but not spot on.
> >
> > FYI, this is for plotting running data with GPS, and when I plot
> > Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the
> data set is
> > good. I am trying to use the Map Image API so that I can render my
> running
> > data on it.
> >
> > thanks,
> > jeff
> >
> > --- runningblogger <jeff@k...> wrote:
> >
> >
> > ---------------------------------
> > Hey-
> >
> > Has anyone verified these equations? I just tried implementing them
> > and it's not quite working for me. I'm plotting gps tracks onto maps,
> > and there seems to be a shift associated with the data. There's a
> > good chance that I have a bug, but just want to check that the posted
> > code is verified first.
> >
> > Also, put me on the list of those interested in getting rid of the
> > center star.
> >
> > As others have stated, some sort of interface to convert lat/lon to
> > pixel coord (or even just the map bounds) would be _most_ excellent.
> >
> > thanks,
> > jeff
> >
> > --- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
> > >
> > > Alan, this is really terrific! Thank you for the detailed
> > explanation and also for saving me a
> > > lot of heartache in figuring out the math 8-).
> > >
> > > My wish list, however still stands. It would be very helpful to
> > developers if Yahoo! could
> > > return this information in the REST response rather than requiring
> > that every developer
> > > implement their own degrees/pixel calculator.
> > >
> > > Cheers,
> > > Keith
> > >
> > >
> > >
> > > --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...>
wrote:
> > > >
> > > > > Another (probably simpler) idea would be to return the scale as
> > > > degrees/pixel of the map
> > > > > in the REST response. Doing so would make it easier for me to
> > plot points
> > > > via CSS.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > It's not quite so simple, but I'll give you some formulas that
> > should do the
> > > > trick. Caveat - not tested, but I'm pretty comfortable with my
> math.
> > > >
> > > >
> > > >
> > > > Each zoom level has half the resolution of the previous level.
> > Level one
> > > > has 1 m/pixel resolution at the equator, but resolution varies
> > with the
> > > > cosine of the latitude in Mercator project; resolution is 1
> > m/pixel / cosine
> > > > (latitude). For any given point, the resolution in the
north-south
> > > > direction in meters/pixel is the same as the resolution in the
> > east-west
> > > > direction; that's the defining attribute of the Mercator
projection.
> > > >
> > > >
> > > >
> > > > Meters per degree longitude varies with latitude, but meter per
> degree
> > > > latitude is constant over longitude. For a given zoom level,
> > variance of
> > > > the meters per degree longitude cancels out the change in meters
> > per pixel
> > > > in the east/west direction as you move north and south in the
> Mercator
> > > > direction. Therefore, for all latitudes, the degrees longitude
> > per pixel is
> > > > constant. If an image is 600 pixels wide, and covers 60
degrees of
> > > > longitude, you have 0.1 degrees per pixel.
> > > >
> > > >
> > > >
> > > > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m)
> > = 0.000009
> > > > degrees longitude/pixel. Each zoom level up from there, you
> > double the
> > > > degrees long/pixel of a map.
> > > >
> > > > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom
level -1))
> > > >
> > > >
> > > >
> > > > The degrees latitude per pixel varies with latitude. If you're
> > zoomed in
> > > > close, the top of the map will have a scale similar to the bottom
> > of the
> > > > map. However, if you're showing all of North America, there's
> > significant
> > > > variation; it why Greenland looks so big. At the north pole, it's
> > zero
> > > > degrees latitude per pixel - regardless of zoom level. This is
> > easily seen
> > > > in the cosine effect:
> > > >
> > > >
> > > >
> > > > Degrees latitude per pixel = (0.000009 degrees latitude/pixel)
> > * (2 ^
> > > > (zoom level -1)) * cosine (latitude).
> > > >
> > > >
> > > >
> > > > As latitude approaches 90 degrees, cosine(latitude) goes to zero
> > degrees
> > > > latitude per pixel goes to zero. If you're walking north on a
> > Mercator
> > > > projection map, you never get to the north pole, because your
> > progress per
> > > > step approaches zero.
> > > >
> > > >
> > > >
> > > > So . while you can determine how many pixels you need to move by
> > taking the
> > > > shift in degrees longitude and multiplying by the pixels per
> > degree, you
> > > > have to use integration to accurately determine the number of
> > pixels a move
> > > > of N degrees latitude translates into.
> > > >
> > > >
> > > >
> > > > I came up with a formula last night that used the longitude/
> latitude
> > > > bounding box of the current map; someone says the method for
> > retrieving that
> > > > information (getBounds) still isn't working. With some alternate
> > math, you
> > > > can use the coordinate of the center of your image, and the
> > current zoom
> > > > level, to determine where to plot a point relative to that center.
> > > >
> > > >
> > > >
> > > > The simplest way to do this is determine the number of pixels
> > north of the
> > > > equator the center point of the image is, the number of pixels
> > north of the
> > > > equator your desired coordinate is, and calculate the difference.
> > Using the
> > > > function I defined yesterday, center coordinate (centerlat,
> > centerlon), and
> > > > target coordinate (targetlat,targetlon) :
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> > > >
> > > > function MercatorProjectY(latitude)
> > > > {
> > > > latradians = latitude * 3.1415927 /180.0;
> > > > /(1 - sin(latradians))) / 2;
> > > > return (YProjradians * 180.0 / 3.1415927);
> > > > }
> > > >
> > > > YCenterProj = MercatorProjectY(centerlat);
> > > >
> > > > YTargetProj = MercatorProjectY(targetlat);
> > > >
> > > >
> > > >
> > > > XDelta = (targetlon - centerlon) * degperpixel;
> > > >
> > > > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> > > >
> > > >
> > > >
> > > > The point you want to plot is YDelta pixels above and XDelta
> > pixels to
> > > > the right of the center. If you have a 600 x 400 pixel map, you
> > could have
> > > > YDelta values between -200 and 200, and XDelta values between -300
> > and 300.
> > > > Anything beyond that is off the map.
> > > >
> > > >
> > > >
> > > > You can go in the opposite direction. Say you know what you
> > position is
> > > > relative to the center of the map (yes, I know the coordinates you
> > work with
> > > > are relative to a corner of the
> > > >
> > > > Image, but I forget which one; you can make the appropriate
> > > > Starting with XDelta, YDelta:
> > > >
> > > >
> > > >
> > > > function InverseMercatorProjectY(YProj)
> > > > {
> > > > YProjradians = YProj * 3.1415927 /180.0;
> > > > latradians = 2 * atan(exp(YProjradians)) - 3.1415927 / 2;
> > > > return (latradians * 180.0 / 3.1415927);
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> > > >
> > > > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > > > calculated above
> > > >
> > > > targetlat = InverseMercatorProjectY(YTargetProj);
> > > >
> > > >
> > > >
> > > > If you want the bounding box of your 600 x 400 pixel map, apply
> > this formula
> > > > to XDelta, YDelta pairs of (-300,-200) and (300,200),
> > respectively, for
> > > > minimum and maximum bounds.
> > > >
> > > >
> > > >
> > > > -Alan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _____
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Developer network
>
> > Building blocks

> > Computer security
>
> > Computer training Map
>
> >
> >
> > ---------------------------------
> >
> >
> > Visit your group "yws-maps" on the web.
> >
> > To unsubscribe from this group, send an email to:
> > yws-maps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
> > ---------------------------------
> >
>
>
>
>
>
>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>
• As far as I m aware, the math is correct. However ... I hadn t checked it for awhile, but the last I looked, the map image API produced two sorts of images:
Message 1 of 19 , Jan 23, 2006
View Source
As far as I'm aware, the math is correct. However ...

I hadn't checked it for awhile, but the last I looked, the map image
API produced two sorts of images:

1) PNGs
2) GIFs

The PNGs were the same images as used by the AJAX api. The GIFs,
however, were the images generated by the "old" Yahoo maps. This is
significant, because the "old" Yahoo maps did not use the Mercator
projection - it used the Cylindrical projection.

The cylindrical projection is actually simpler than the Mercator
projection; it's just taking the longitude and latitude and plotting
it on a square grid. Period. I would really need to spend more time
than I have tonight to confirm my suspicion, but I think it's just a
matter of dropping the MercatorProjectY and InverseMercatorProjectY
functions from the formulas ... and, I suspect (have not confirmed!)
the scale factor would go back to 0.000009 degrees per pixel.

However, if you can make use of them, I'd suggest using the PNG tiles
to get the Mercator projection. As I mentioned in my original
posting, the beauty of the Mercator projection is that resolution in
meters per pixel at any given point is the same in the north-south
direction as the east-west direction. This results in the map having
more accurate shapes in the far northern and southern latitudes; the
stret maps of Fairbanks, Alaska, look correct. It also results in
making Greenland look as big as South America; that's the drawback.
But no flat projection of a sphere is going to be perfect.

But - if you're happy with the cylindrical projection, the GIF tiles
should work, with a few adjustments in the formula. I hope this

-Alan

--- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
>
> Upon even furhter review, I have determined that zoom level 4 is
also broken.
> At first, I thought this may be an even/odd issue, but zoom level 6
works.
>
> Note that I am using the "Map Image API". Is it possible that these
zoom
> levels are different than JS api?
>
> thanks,
> jeff
>
> --- Jeff Kalikstein <jeff@k...> wrote:
>
>
> ---------------------------------
> Well, everything is working well with one exception: zoom level 2.
Is there
> any chance that this is a special case that doesn't work with your
original
> formulas?
>
> --- Jeff Kalikstein <jeff@k...> wrote:
>
>
> ---------------------------------
> Perfect! I put in the new magic number and everything magically
works great.
>
> Apparently I missed some later group discussions on this
topic...have there
> been any more progress on removing the star from the center of the map?
>
> I will also be looking at adding tiling and stitching features to my
app- I
> know that the API mentions this but I haven't seen much technical
info on it.
> Any pointers?
>
> thanks!
>
>
>
> ---------------------------------
> Yes - I made a mistake in the equations, which I corrected in a later
> posting (dividing instead of multiplying). Also, you 0.000010728836
> degrees per pixel instead of 0.000009 (for proper calibration - it's
> 65536 tiles times 512 pixels per tile wide at the equator at zoom
> level 1.). The math is used in an actual web page at
> http://mapnut.com/testzoom.html.
>
> Sorry for the mistakes.
>
> -Alan
>
> --- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
> >
> > Oh, I already caught one problem (XDelta and YDelta should be
> computed with a
> > "/" instead of a "*"). The results are "close", but not spot on.
> >
> > FYI, this is for plotting running data with GPS, and when I plot
> > Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the
> data set is
> > good. I am trying to use the Map Image API so that I can render my
> running
> > data on it.
> >
> > thanks,
> > jeff
> >
> > --- runningblogger <jeff@k...> wrote:
> >
> >
> > ---------------------------------
> > Hey-
> >
> > Has anyone verified these equations? I just tried implementing them
> > and it's not quite working for me. I'm plotting gps tracks onto maps,
> > and there seems to be a shift associated with the data. There's a
> > good chance that I have a bug, but just want to check that the posted
> > code is verified first.
> >
> > Also, put me on the list of those interested in getting rid of the
> > center star.
> >
> > As others have stated, some sort of interface to convert lat/lon to
> > pixel coord (or even just the map bounds) would be _most_ excellent.
> >
> > thanks,
> > jeff
> >
> > --- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
> > >
> > > Alan, this is really terrific! Thank you for the detailed
> > explanation and also for saving me a
> > > lot of heartache in figuring out the math 8-).
> > >
> > > My wish list, however still stands. It would be very helpful to
> > developers if Yahoo! could
> > > return this information in the REST response rather than requiring
> > that every developer
> > > implement their own degrees/pixel calculator.
> > >
> > > Cheers,
> > > Keith
> > >
> > >
> > >
> > > --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...>
wrote:
> > > >
> > > > > Another (probably simpler) idea would be to return the scale as
> > > > degrees/pixel of the map
> > > > > in the REST response. Doing so would make it easier for me to
> > plot points
> > > > via CSS.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > It's not quite so simple, but I'll give you some formulas that
> > should do the
> > > > trick. Caveat - not tested, but I'm pretty comfortable with my
> math.
> > > >
> > > >
> > > >
> > > > Each zoom level has half the resolution of the previous level.
> > Level one
> > > > has 1 m/pixel resolution at the equator, but resolution varies
> > with the
> > > > cosine of the latitude in Mercator project; resolution is 1
> > m/pixel / cosine
> > > > (latitude). For any given point, the resolution in the
north-south
> > > > direction in meters/pixel is the same as the resolution in the
> > east-west
> > > > direction; that's the defining attribute of the Mercator
projection.
> > > >
> > > >
> > > >
> > > > Meters per degree longitude varies with latitude, but meter per
> degree
> > > > latitude is constant over longitude. For a given zoom level,
> > variance of
> > > > the meters per degree longitude cancels out the change in meters
> > per pixel
> > > > in the east/west direction as you move north and south in the
> Mercator
> > > > direction. Therefore, for all latitudes, the degrees longitude
> > per pixel is
> > > > constant. If an image is 600 pixels wide, and covers 60
degrees of
> > > > longitude, you have 0.1 degrees per pixel.
> > > >
> > > >
> > > >
> > > > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m)
> > = 0.000009
> > > > degrees longitude/pixel. Each zoom level up from there, you
> > double the
> > > > degrees long/pixel of a map.
> > > >
> > > > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom
level -1))
> > > >
> > > >
> > > >
> > > > The degrees latitude per pixel varies with latitude. If you're
> > zoomed in
> > > > close, the top of the map will have a scale similar to the bottom
> > of the
> > > > map. However, if you're showing all of North America, there's
> > significant
> > > > variation; it why Greenland looks so big. At the north pole, it's
> > zero
> > > > degrees latitude per pixel - regardless of zoom level. This is
> > easily seen
> > > > in the cosine effect:
> > > >
> > > >
> > > >
> > > > Degrees latitude per pixel = (0.000009 degrees latitude/pixel)
> > * (2 ^
> > > > (zoom level -1)) * cosine (latitude).
> > > >
> > > >
> > > >
> > > > As latitude approaches 90 degrees, cosine(latitude) goes to zero
> > degrees
> > > > latitude per pixel goes to zero. If you're walking north on a
> > Mercator
> > > > projection map, you never get to the north pole, because your
> > progress per
> > > > step approaches zero.
> > > >
> > > >
> > > >
> > > > So . while you can determine how many pixels you need to move by
> > taking the
> > > > shift in degrees longitude and multiplying by the pixels per
> > degree, you
> > > > have to use integration to accurately determine the number of
> > pixels a move
> > > > of N degrees latitude translates into.
> > > >
> > > >
> > > >
> > > > I came up with a formula last night that used the longitude/
> latitude
> > > > bounding box of the current map; someone says the method for
> > retrieving that
> > > > information (getBounds) still isn't working. With some alternate
> > math, you
> > > > can use the coordinate of the center of your image, and the
> > current zoom
> > > > level, to determine where to plot a point relative to that center.
> > > >
> > > >
> > > >
> > > > The simplest way to do this is determine the number of pixels
> > north of the
> > > > equator the center point of the image is, the number of pixels
> > north of the
> > > > equator your desired coordinate is, and calculate the difference.
> > Using the
> > > > function I defined yesterday, center coordinate (centerlat,
> > centerlon), and
> > > > target coordinate (targetlat,targetlon) :
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> > > >
> > > > function MercatorProjectY(latitude)
> > > > {
> > > > latradians = latitude * 3.1415927 /180.0;
> > > > /(1 - sin(latradians))) / 2;
> > > > return (YProjradians * 180.0 / 3.1415927);
> > > > }
> > > >
> > > > YCenterProj = MercatorProjectY(centerlat);
> > > >
> > > > YTargetProj = MercatorProjectY(targetlat);
> > > >
> > > >
> > > >
> > > > XDelta = (targetlon - centerlon) * degperpixel;
> > > >
> > > > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> > > >
> > > >
> > > >
> > > > The point you want to plot is YDelta pixels above and XDelta
> > pixels to
> > > > the right of the center. If you have a 600 x 400 pixel map, you
> > could have
> > > > YDelta values between -200 and 200, and XDelta values between -300
> > and 300.
> > > > Anything beyond that is off the map.
> > > >
> > > >
> > > >
> > > > You can go in the opposite direction. Say you know what you
> > position is
> > > > relative to the center of the map (yes, I know the coordinates you
> > work with
> > > > are relative to a corner of the
> > > >
> > > > Image, but I forget which one; you can make the appropriate
> > > > Starting with XDelta, YDelta:
> > > >
> > > >
> > > >
> > > > function InverseMercatorProjectY(YProj)
> > > > {
> > > > YProjradians = YProj * 3.1415927 /180.0;
> > > > latradians = 2 * atan(exp(YProjradians)) - 3.1415927 / 2;
> > > > return (latradians * 180.0 / 3.1415927);
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> > > >
> > > > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > > > calculated above
> > > >
> > > > targetlat = InverseMercatorProjectY(YTargetProj);
> > > >
> > > >
> > > >
> > > > If you want the bounding box of your 600 x 400 pixel map, apply
> > this formula
> > > > to XDelta, YDelta pairs of (-300,-200) and (300,200),
> > respectively, for
> > > > minimum and maximum bounds.
> > > >
> > > >
> > > >
> > > > -Alan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _____
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Developer network
>
> > Building blocks

> > Computer security
>
> > Computer training Map
>
> >
> >
> > ---------------------------------
> >
> >
> > Visit your group "yws-maps" on the web.
> >
> > To unsubscribe from this group, send an email to:
> > yws-maps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
> > ---------------------------------
> >
>
>
>
>
>
>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>
>
>
>
>
>
>
> Developer network

> Building blocks
> Computer security

> Computer training Map

>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>
>
>
>
>
>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>
• Hey Alan- This does not look like a problem with gif vs png (I just explicity tried both, and they both dont work). It actually looks as if the entire scale
Message 1 of 19 , Jan 24, 2006
View Source
Hey Alan-

This does not look like a problem with gif vs png (I just explicity tried both, and they both dont' work). It actually looks as if the entire scale number is wrong for zoom level 2 and zoom level 4. Here is an example:

http://api.local.yahoo.com/MapsService/V1/mapImage?appid=RunningBlogger&latitude=30.2539275&longitude=-97.7664355&image_width=600&image_height=600&zoom=4

When I try to plot the resulting URL, my datapoints are in scale relative to each other, but not the map. It looks like the "degrees per pixel" is too large. I can experiement with this number until it looks "right" and report back.

----- Original Message ----
To: yws-maps@yahoogroups.com
Sent: Tuesday, January 24, 2006 1:06:56 AM
Subject: [yws-maps] Re: More Mercator projection math

As far as I'm aware, the math is correct. However ...

I hadn't checked it for awhile, but the last I looked, the map image
API produced two sorts of images:

1) PNGs
2) GIFs

The PNGs were the same images as used by the AJAX api. The GIFs,
however, were the images generated by the "old" Yahoo maps. This is
significant, because the "old" Yahoo maps did not use the Mercator
projection - it used the Cylindrical projection.

The cylindrical projection is actually simpler than the Mercator
projection; it's just taking the longitude and latitude and plotting
it on a square grid. Period. I would really need to spend more time
than I have tonight to confirm my suspicion, but I think it's just a
matter of dropping the MercatorProjectY and InverseMercatorProjectY
functions from the formulas ... and, I suspect (have not confirmed!)
the scale factor would go back to 0.000009 degrees per pixel.

However, if you can make use of them, I'd suggest using the PNG tiles
to get the Mercator projection. As I mentioned in my original
posting, the beauty of the Mercator projection is that resolution in
meters per pixel at any given point is the same in the north-south
direction as the east-west direction. This results in the map having
more accurate shapes in the far northern and southern latitudes; the
stret maps of Fairbanks, Alaska, look correct. It also results in
making Greenland look as big as South America; that's the drawback.
But no flat projection of a sphere is going to be perfect.

But - if you're happy with the cylindrical projection, the GIF tiles
should work, with a few adjustments in the formula. I hope this

-Alan

--- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
>
> Upon even furhter review, I have determined that zoom level 4 is
also broken.
> At first, I thought this may be an even/odd issue, but zoom level 6
works.
>
> Note that I am using the "Map Image API". Is it possible that these
zoom
> levels are different than JS api?
>
> thanks,
> jeff
>
> --- Jeff Kalikstein <jeff@k...> wrote:
>
>
> ---------------------------------
> Well, everything is working well with one exception: zoom level 2.
Is there
> any chance that this is a special case that doesn't work with your
original
> formulas?
>
> --- Jeff Kalikstein <jeff@k...> wrote:
>
>
> ---------------------------------
> Perfect! I put in the new magic number and everything magically
works great.
>
> Apparently I missed some later group discussions on this
topic...have there
> been any more progress on removing the star from the center of the map?
>
> I will also be looking at adding tiling and stitching features to my
app- I
> know that the API mentions this but I haven't seen much technical
info on it.
> Any pointers?
>
> thanks!
>
>
>
> ---------------------------------
> Yes - I made a mistake in the equations, which I corrected in a later
> posting (dividing instead of multiplying). Also, you 0.000010728836
> degrees per pixel instead of 0.000009 (for proper calibration - it's
> 65536 tiles times 512 pixels per tile wide at the equator at zoom
> level 1.). The math is used in an actual web page at
> http://mapnut.com/testzoom.html.
>
> Sorry for the mistakes.
>
> -Alan
>
> --- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
> >
> > Oh, I already caught one problem (XDelta and YDelta should be
> computed with a
> > "/" instead of a "*"). The results are "close", but not spot on.
> >
> > FYI, this is for plotting running data with GPS, and when I plot
> > Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the
> data set is
> > good. I am trying to use the Map Image API so that I can render my
> running
> > data on it.
> >
> > thanks,
> > jeff
> >
> > --- runningblogger <jeff@k...> wrote:
> >
> >
> > ---------------------------------
> > Hey-
> >
> > Has anyone verified these equations? I just tried implementing them
> > and it's not quite working for me. I'm plotting gps tracks onto maps,
> > and there seems to be a shift associated with the data. There's a
> > good chance that I have a bug, but just want to check that the posted
> > code is verified first.
> >
> > Also, put me on the list of those interested in getting rid of the
> > center star.
> >
> > As others have stated, some sort of interface to convert lat/lon to
> > pixel coord (or even just the map bounds) would be _most_ excellent.
> >
> > thanks,
> > jeff
> >
> > --- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
> > >
> > > Alan, this is really terrific! Thank you for the detailed
> > explanation and also for saving me a
> > > lot of heartache in figuring out the math 8-).
> > >
> > > My wish list, however still stands. It would be very helpful to
> > developers if Yahoo! could
> > > return this information in the REST response rather than requiring
> > that every developer
> > > implement their own degrees/pixel calculator.
> > >
> > > Cheers,
> > > Keith
> > >
> > >
> > >
> > > --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...>
wrote:
> > > >
> > > > > Another (probably simpler) idea would be to return the scale as
> > > > degrees/pixel of the map
> > > > > in the REST response. Doing so would make it easier for me to
> > plot points
> > > > via CSS.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > It's not quite so simple, but I'll give you some formulas that
> > should do the
> > > > trick. Caveat - not tested, but I'm pretty comfortable with my
> math.
> > > >
> > > >
> > > >
> > > > Each zoom level has half the resolution of the previous level.
> > Level one
> > > > has 1 m/pixel resolution at the equator, but resolution varies
> > with the
> > > > cosine of the latitude in Mercator project; resolution is 1
> > m/pixel / cosine
> > > > (latitude). For any given point, the resolution in the
north-south
> > > > direction in meters/pixel is the same as the resolution in the
> > east-west
> > > > direction; that's the defining attribute of the Mercator
projection.
> > > >
> > > >
> > > >
> > > > Meters per degree longitude varies with latitude, but meter per
> degree
> > > > latitude is constant over longitude. For a given zoom level,
> > variance of
> > > > the meters per degree longitude cancels out the change in meters
> > per pixel
> > > > in the east/west direction as you move north and south in the
> Mercator
> > > > direction. Therefore, for all latitudes, the degrees longitude
> > per pixel is
> > > > constant. If an image is 600 pixels wide, and covers 60
degrees of
> > > > longitude, you have 0.1 degrees per pixel.
> > > >
> > > >
> > > >
> > > > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m)
> > = 0.000009
> > > > degrees longitude/pixel. Each zoom level up from there, you
> > double the
> > > > degrees long/pixel of a map.
> > > >
> > > > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom
level -1))
> > > >
> > > >
> > > >
> > > > The degrees latitude per pixel varies with latitude. If you're
> > zoomed in
> > > > close, the top of the map will have a scale similar to the bottom
> > of the
> > > > map. However, if you're showing all of North America, there's
> > significant
> > > > variation; it why Greenland looks so big. At the north pole, it's
> > zero
> > > > degrees latitude per pixel - regardless of zoom level. This is
> > easily seen
> > > > in the cosine effect:
> > > >
> > > >
> > > >
> > > > Degrees latitude per pixel = (0.000009 degrees latitude/pixel)
> > * (2 ^
> > > > (zoom level -1)) * cosine (latitude).
> > > >
> > > >
> > > >
> > > > As latitude approaches 90 degrees, cosine(latitude) goes to zero
> > degrees
> > > > latitude per pixel goes to zero. If you're walking north on a
> > Mercator
> > > > projection map, you never get to the north pole, because your
> > progress per
> > > > step approaches zero.
> > > >
> > > >
> > > >
> > > > So . while you can determine how many pixels you need to move by
> > taking the
> > > > shift in degrees longitude and multiplying by the pixels per
> > degree, you
> > > > have to use integration to accurately determine the number of
> > pixels a move
> > > > of N degrees latitude translates into.
> > > >
> > > >
> > > >
> > > > I came up with a formula last night that used the longitude/
> latitude
> > > > bounding box of the current map; someone says the method for
> > retrieving that
> > > > information (getBounds) still isn't working. With some alternate
> > math, you
> > > > can use the coordinate of the center of your image, and the
> > current zoom
> > > > level, to determine where to plot a point relative to that center.
> > > >
> > > >
> > > >
> > > > The simplest way to do this is determine the number of pixels
> > north of the
> > > > equator the center point of the image is, the number of pixels
> > north of the
> > > > equator your desired coordinate is, and calculate the difference.
> > Using the
> > > > function I defined yesterday, center coordinate (centerlat,
> > centerlon), and
> > > > target coordinate (targetlat,targetlon) :
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> > > >
> > > > function MercatorProjectY(latitude)
> > > > {
> > > > latradians = latitude * 3.1415927 /180.0;
> > > > /(1 - sin(latradians))) / 2;
> > > > return (YProjradians * 180.0 / 3.1415927);
> > > > }
> > > >
> > > > YCenterProj = MercatorProjectY(centerlat);
> > > >
> > > > YTargetProj = MercatorProjectY(targetlat);
> > > >
> > > >
> > > >
> > > > XDelta = (targetlon - centerlon) * degperpixel;
> > > >
> > > > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> > > >
> > > >
> > > >
> > > > The point you want to plot is YDelta pixels above and XDelta
> > pixels to
> > > > the right of the center. If you have a 600 x 400 pixel map, you
> > could have
> > > > YDelta values between -200 and 200, and XDelta values between -300
> > and 300.
> > > > Anything beyond that is off the map.
> > > >
> > > >
> > > >
> > > > You can go in the opposite direction. Say you know what you
> > position is
> > > > relative to the center of the map (yes, I know the coordinates you
> > work with
> > > > are relative to a corner of the
> > > >
> > > > Image, but I forget which one; you can make the appropriate
> > > > Starting with XDelta, YDelta:
> > > >
> > > >
> > > >
> > > > function InverseMercatorProjectY(YProj)
> > > > {
> > > > YProjradians = YProj * 3.1415927 /180.0;
> > > > latradians = 2 * atan(exp(YProjradians)) - 3.1415927 / 2;
> > > > return (latradians * 180.0 / 3.1415927);
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> > > >
> > > > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > > > calculated above
> > > >
> > > > targetlat = InverseMercatorProjectY(YTargetProj);
> > > >
> > > >
> > > >
> > > > If you want the bounding box of your 600 x 400 pixel map, apply
> > this formula
> > > > to XDelta, YDelta pairs of (-300,-200) and (300,200),
> > respectively, for
> > > > minimum and maximum bounds.
> > > >
> > > >
> > > >
> > > > -Alan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _____
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Developer network
>
> > Building blocks

> > Computer security
>
> > Computer training Map
>
> >
> >
> > ---------------------------------
> >
> >
> > Visit your group "yws-maps" on the web.
> >
> > To unsubscribe from this group, send an email to:
> > yws-maps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
> > ---------------------------------
> >
>
>
>
>
>
>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>
>
>
>
>
>
>
> Developer network

> Building blocks
> Computer security

> Computer training Map

>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>
>
>
>
>
>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>

Visit your group "yws-maps" on the web.
To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

[Non-text portions of this message have been removed]
• I m sticking with my math this time. Take o look at http://mapnut.com/test.html It s rather mundane, but what I did was pick a center, and - based on image
Message 1 of 19 , Jan 25, 2006
View Source
I'm sticking with my math this time. Take o' look at

http://mapnut.com/test.html

It's rather mundane, but what I did was pick a center, and - based on
image width and height and zoom level - calculate the coordinates of
five points, going diagonally across the image, from lower left to
upper right, and placed markers at those points. You can't see the
fifth marker immediately, because it's just out of range of the view -
however, I made the map draggable, so you can confirm that it's there.
You'll notice that marker one is *precisely* on the lower left corner
and marker five is *precisely* positioned on the upper right. I
picked a high zoom level (14) because the higher the zoom level, the
greater the distortion to the projection. Take a look at the source
code to get of sense of what I'm doing; looking at the image won't
tell you much. I'm confident I'm handling the zoom levels correctly;
the resolution difference between adjacent zoom levels is always a
factor of two.

I'd like to see someone adapt this so you click on the map, and a
marker, with the correct coordinate, would be placed there. Any takers?

--- In yws-maps@yahoogroups.com, <jeff@k...> wrote:
>
> Hey Alan-
>
> This does not look like a problem with gif vs png (I just explicity
tried both, and they both dont' work). It actually looks as if the
entire scale number is wrong for zoom level 2 and zoom level 4. Here
is an example:
>
>
http://api.local.yahoo.com/MapsService/V1/mapImage?appid=RunningBlogger&latitude=30.2539275&longitude=-97.7664355&image_width=600&image_height=600&zoom=4
>
> When I try to plot the resulting URL, my datapoints are in scale
relative to each other, but not the map. It looks like the "degrees
per pixel" is too large. I can experiement with this number until it
looks "right" and report back.
>
> ----- Original Message ----
> To: yws-maps@yahoogroups.com
> Sent: Tuesday, January 24, 2006 1:06:56 AM
> Subject: [yws-maps] Re: More Mercator projection math
>
> As far as I'm aware, the math is correct. However ...
>
> I hadn't checked it for awhile, but the last I looked, the map image
> API produced two sorts of images:
>
> 1) PNGs
> 2) GIFs
>
> The PNGs were the same images as used by the AJAX api. The GIFs,
> however, were the images generated by the "old" Yahoo maps. This is
> significant, because the "old" Yahoo maps did not use the Mercator
> projection - it used the Cylindrical projection.
>
> The cylindrical projection is actually simpler than the Mercator
> projection; it's just taking the longitude and latitude and plotting
> it on a square grid. Period. I would really need to spend more time
> than I have tonight to confirm my suspicion, but I think it's just a
> matter of dropping the MercatorProjectY and InverseMercatorProjectY
> functions from the formulas ... and, I suspect (have not confirmed!)
> the scale factor would go back to 0.000009 degrees per pixel.
>
> However, if you can make use of them, I'd suggest using the PNG tiles
> to get the Mercator projection. As I mentioned in my original
> posting, the beauty of the Mercator projection is that resolution in
> meters per pixel at any given point is the same in the north-south
> direction as the east-west direction. This results in the map having
> more accurate shapes in the far northern and southern latitudes; the
> stret maps of Fairbanks, Alaska, look correct. It also results in
> making Greenland look as big as South America; that's the drawback.
> But no flat projection of a sphere is going to be perfect.
>
> But - if you're happy with the cylindrical projection, the GIF tiles
> should work, with a few adjustments in the formula. I hope this
>
> -Alan
>
>
>
> --- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
> >
> > Upon even furhter review, I have determined that zoom level 4 is
> also broken.
> > At first, I thought this may be an even/odd issue, but zoom level 6
> works.
> >
> > Note that I am using the "Map Image API". Is it possible that these
> zoom
> > levels are different than JS api?
> >
> > thanks,
> > jeff
> >
> > --- Jeff Kalikstein <jeff@k...> wrote:
> >
> >
> > ---------------------------------
> > Well, everything is working well with one exception: zoom level 2.
> Is there
> > any chance that this is a special case that doesn't work with your
> original
> > formulas?
> >
> > --- Jeff Kalikstein <jeff@k...> wrote:
> >
> >
> > ---------------------------------
> > Perfect! I put in the new magic number and everything magically
> works great.
> >
> > Apparently I missed some later group discussions on this
> topic...have there
> > been any more progress on removing the star from the center of
the map?
> >
> > I will also be looking at adding tiling and stitching features to my
> app- I
> > know that the API mentions this but I haven't seen much technical
> info on it.
> > Any pointers?
> >
> > thanks!
> >
> >
> >
> > ---------------------------------
> > Yes - I made a mistake in the equations, which I corrected in a later
> > posting (dividing instead of multiplying). Also, you 0.000010728836
> > degrees per pixel instead of 0.000009 (for proper calibration - it's
> > 65536 tiles times 512 pixels per tile wide at the equator at zoom
> > level 1.). The math is used in an actual web page at
> > http://mapnut.com/testzoom.html.
> >
> > Sorry for the mistakes.
> >
> > -Alan
> >
> > --- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
> > >
> > > Oh, I already caught one problem (XDelta and YDelta should be
> > computed with a
> > > "/" instead of a "*"). The results are "close", but not spot on.
> > >
> > > FYI, this is for plotting running data with GPS, and when I plot
> > > Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the
> > data set is
> > > good. I am trying to use the Map Image API so that I can render my
> > running
> > > data on it.
> > >
> > > thanks,
> > > jeff
> > >
> > > --- runningblogger <jeff@k...> wrote:
> > >
> > >
> > > ---------------------------------
> > > Hey-
> > >
> > > Has anyone verified these equations? I just tried implementing
them
> > > and it's not quite working for me. I'm plotting gps tracks
onto maps,
> > > and there seems to be a shift associated with the data. There's a
> > > good chance that I have a bug, but just want to check that the
posted
> > > code is verified first.
> > >
> > > Also, put me on the list of those interested in getting rid of the
> > > center star.
> > >
> > > As others have stated, some sort of interface to convert lat/lon to
> > > pixel coord (or even just the map bounds) would be _most_
excellent.
> > >
> > > thanks,
> > > jeff
> > >
> > > --- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
> > > >
> > > > Alan, this is really terrific! Thank you for the detailed
> > > explanation and also for saving me a
> > > > lot of heartache in figuring out the math 8-).
> > > >
> > > > My wish list, however still stands. It would be very helpful to
> > > developers if Yahoo! could
> > > > return this information in the REST response rather than
requiring
> > > that every developer
> > > > implement their own degrees/pixel calculator.
> > > >
> > > > Cheers,
> > > > Keith
> > > >
> > > >
> > > >
> > > > --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...>
> wrote:
> > > > >
> > > > > > Another (probably simpler) idea would be to return the
scale as
> > > > > degrees/pixel of the map
> > > > > > in the REST response. Doing so would make it easier for
me to
> > > plot points
> > > > > via CSS.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > It's not quite so simple, but I'll give you some formulas that
> > > should do the
> > > > > trick. Caveat - not tested, but I'm pretty comfortable with my
> > math.
> > > > >
> > > > >
> > > > >
> > > > > Each zoom level has half the resolution of the previous level.
> > > Level one
> > > > > has 1 m/pixel resolution at the equator, but resolution varies
> > > with the
> > > > > cosine of the latitude in Mercator project; resolution is 1
> > > m/pixel / cosine
> > > > > (latitude). For any given point, the resolution in the
> north-south
> > > > > direction in meters/pixel is the same as the resolution in the
> > > east-west
> > > > > direction; that's the defining attribute of the Mercator
> projection.
> > > > >
> > > > >
> > > > >
> > > > > Meters per degree longitude varies with latitude, but meter per
> > degree
> > > > > latitude is constant over longitude. For a given zoom level,
> > > variance of
> > > > > the meters per degree longitude cancels out the change in
meters
> > > per pixel
> > > > > in the east/west direction as you move north and south in the
> > Mercator
> > > > > direction. Therefore, for all latitudes, the degrees longitude
> > > per pixel is
> > > > > constant. If an image is 600 pixels wide, and covers 60
> degrees of
> > > > > longitude, you have 0.1 degrees per pixel.
> > > > >
> > > > >
> > > > >
> > > > > Zoom level 1 is (1 m/pixel) * (90 degrees
longitude/10,000,000 m)
> > > = 0.000009
> > > > > degrees longitude/pixel. Each zoom level up from there, you
> > > double the
> > > > > degrees long/pixel of a map.
> > > > >
> > > > > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom
> level -1))
> > > > >
> > > > >
> > > > >
> > > > > The degrees latitude per pixel varies with latitude. If you're
> > > zoomed in
> > > > > close, the top of the map will have a scale similar to the
bottom
> > > of the
> > > > > map. However, if you're showing all of North America, there's
> > > significant
> > > > > variation; it why Greenland looks so big. At the north
pole, it's
> > > zero
> > > > > degrees latitude per pixel - regardless of zoom level. This is
> > > easily seen
> > > > > in the cosine effect:
> > > > >
> > > > >
> > > > >
> > > > > Degrees latitude per pixel = (0.000009 degrees
latitude/pixel)
> > > * (2 ^
> > > > > (zoom level -1)) * cosine (latitude).
> > > > >
> > > > >
> > > > >
> > > > > As latitude approaches 90 degrees, cosine(latitude) goes to
zero
> > > degrees
> > > > > latitude per pixel goes to zero. If you're walking north on a
> > > Mercator
> > > > > projection map, you never get to the north pole, because your
> > > progress per
> > > > > step approaches zero.
> > > > >
> > > > >
> > > > >
> > > > > So . while you can determine how many pixels you need to
move by
> > > taking the
> > > > > shift in degrees longitude and multiplying by the pixels per
> > > degree, you
> > > > > have to use integration to accurately determine the number of
> > > pixels a move
> > > > > of N degrees latitude translates into.
> > > > >
> > > > >
> > > > >
> > > > > I came up with a formula last night that used the longitude/
> > latitude
> > > > > bounding box of the current map; someone says the method for
> > > retrieving that
> > > > > information (getBounds) still isn't working. With some
alternate
> > > math, you
> > > > > can use the coordinate of the center of your image, and the
> > > current zoom
> > > > > level, to determine where to plot a point relative to that
center.
> > > > >
> > > > >
> > > > >
> > > > > The simplest way to do this is determine the number of pixels
> > > north of the
> > > > > equator the center point of the image is, the number of pixels
> > > north of the
> > > > > equator your desired coordinate is, and calculate the
difference.
> > > Using the
> > > > > function I defined yesterday, center coordinate (centerlat,
> > > centerlon), and
> > > > > target coordinate (targetlat,targetlon) :
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> > > > >
> > > > > function MercatorProjectY(latitude)
> > > > > {
> > > > > latradians = latitude * 3.1415927 /180.0;
> > > > > /(1 - sin(latradians))) / 2;
> > > > > return (YProjradians * 180.0 / 3.1415927);
> > > > > }
> > > > >
> > > > > YCenterProj = MercatorProjectY(centerlat);
> > > > >
> > > > > YTargetProj = MercatorProjectY(targetlat);
> > > > >
> > > > >
> > > > >
> > > > > XDelta = (targetlon - centerlon) * degperpixel;
> > > > >
> > > > > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> > > > >
> > > > >
> > > > >
> > > > > The point you want to plot is YDelta pixels above and XDelta
> > > pixels to
> > > > > the right of the center. If you have a 600 x 400 pixel
map, you
> > > could have
> > > > > YDelta values between -200 and 200, and XDelta values
between -300
> > > and 300.
> > > > > Anything beyond that is off the map.
> > > > >
> > > > >
> > > > >
> > > > > You can go in the opposite direction. Say you know what you
> > > position is
> > > > > relative to the center of the map (yes, I know the
coordinates you
> > > work with
> > > > > are relative to a corner of the
> > > > >
> > > > > Image, but I forget which one; you can make the appropriate
> > > > > Starting with XDelta, YDelta:
> > > > >
> > > > >
> > > > >
> > > > > function InverseMercatorProjectY(YProj)
> > > > > {
> > > > > YProjradians = YProj * 3.1415927 /180.0;
> > > > > latradians = 2 * atan(exp(YProjradians)) - 3.1415927 / 2;
> > > > > return (latradians * 180.0 / 3.1415927);
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > targetlon = (XDelta / degperpixel) + centerlon; // simple
enough
> > > > >
> > > > > YTargetProj = (YDelta /degperpixel) + YCenterProj; //
YCenterProj
> > > > > calculated above
> > > > >
> > > > > targetlat = InverseMercatorProjectY(YTargetProj);
> > > > >
> > > > >
> > > > >
> > > > > If you want the bounding box of your 600 x 400 pixel map, apply
> > > this formula
> > > > > to XDelta, YDelta pairs of (-300,-200) and (300,200),
> > > respectively, for
> > > > > minimum and maximum bounds.
> > > > >
> > > > >
> > > > >
> > > > > -Alan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _____
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Developer network
> >
> > > Building blocks
>
> > > Computer security
> >
> > > Computer training Map
> >
> > >
> > >
> > > ---------------------------------
> > > YAHOO! GROUPS LINKS
> > >
> > >
> > > Visit your group "yws-maps" on the web.
> > >
> > > To unsubscribe from this group, send an email to:
> > > yws-maps-unsubscribe@yahoogroups.com
> > >
> > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
> > >
> > >
> > > ---------------------------------
> > >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------
> >
> >
> > Visit your group "yws-maps" on the web.
> >
> > To unsubscribe from this group, send an email to:
> > yws-maps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
> > ---------------------------------
> >
> >
> >
> >
> >
> >
> >
> > Developer network
>
> > Building blocks

> > Computer security
>
> > Computer training Map
>
> >
> >
> > ---------------------------------
> >
> >
> > Visit your group "yws-maps" on the web.
> >
> > To unsubscribe from this group, send an email to:
> > yws-maps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
> > ---------------------------------
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------
> >
> >
> > Visit your group "yws-maps" on the web.
> >
> > To unsubscribe from this group, send an email to:
> > yws-maps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
> > ---------------------------------
> >
>
>
>
>
>
>
> Visit your group "yws-maps" on the web.
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
• hi adbrown1967 wrote: I m sticking with my math this time. Take o look at http://mapnut.com/test.html It s rather mundane, but what
Message 1 of 19 , Jan 26, 2006
View Source
hi

adbrown1967 <adbrown@...> wrote: I'm sticking with my math this time. Take o' look at

http://mapnut.com/test.html

It's rather mundane, but what I did was pick a center, and - based on
image width and height and zoom level - calculate the coordinates of
five points, going diagonally across the image, from lower left to
upper right, and placed markers at those points. You can't see the
fifth marker immediately, because it's just out of range of the view -
however, I made the map draggable, so you can confirm that it's there.
You'll notice that marker one is *precisely* on the lower left corner
and marker five is *precisely* positioned on the upper right. I
picked a high zoom level (14) because the higher the zoom level, the
greater the distortion to the projection. Take a look at the source
code to get of sense of what I'm doing; looking at the image won't
tell you much. I'm confident I'm handling the zoom levels correctly;
the resolution difference between adjacent zoom levels is always a
factor of two.

I'd like to see someone adapt this so you click on the map, and a
marker, with the correct coordinate, would be placed there. Any takers?

--- In yws-maps@yahoogroups.com, <jeff@k...> wrote:
>
> Hey Alan-
>
> This does not look like a problem with gif vs png (I just explicity
tried both, and they both dont' work). It actually looks as if the
entire scale number is wrong for zoom level 2 and zoom level 4. Here
is an example:
>
>
http://api.local.yahoo.com/MapsService/V1/mapImage?appid=RunningBlogger&latitude=30.2539275&longitude=-97.7664355&image_width=600&image_height=600&zoom=4
>
> When I try to plot the resulting URL, my datapoints are in scale
relative to each other, but not the map. It looks like the "degrees
per pixel" is too large. I can experiement with this number until it
looks "right" and report back.
>
> ----- Original Message ----
> To: yws-maps@yahoogroups.com
> Sent: Tuesday, January 24, 2006 1:06:56 AM
> Subject: [yws-maps] Re: More Mercator projection math
>
> As far as I'm aware, the math is correct. However ...
>
> I hadn't checked it for awhile, but the last I looked, the map image
> API produced two sorts of images:
>
> 1) PNGs
> 2) GIFs
>
> The PNGs were the same images as used by the AJAX api. The GIFs,
> however, were the images generated by the "old" Yahoo maps. This is
> significant, because the "old" Yahoo maps did not use the Mercator
> projection - it used the Cylindrical projection.
>
> The cylindrical projection is actually simpler than the Mercator
> projection; it's just taking the longitude and latitude and plotting
> it on a square grid. Period. I would really need to spend more time
> than I have tonight to confirm my suspicion, but I think it's just a
> matter of dropping the MercatorProjectY and InverseMercatorProjectY
> functions from the formulas ... and, I suspect (have not confirmed!)
> the scale factor would go back to 0.000009 degrees per pixel.
>
> However, if you can make use of them, I'd suggest using the PNG tiles
> to get the Mercator projection. As I mentioned in my original
> posting, the beauty of the Mercator projection is that resolution in
> meters per pixel at any given point is the same in the north-south
> direction as the east-west direction. This results in the map having
> more accurate shapes in the far northern and southern latitudes; the
> stret maps of Fairbanks, Alaska, look correct. It also results in
> making Greenland look as big as South America; that's the drawback.
> But no flat projection of a sphere is going to be perfect.
>
> But - if you're happy with the cylindrical projection, the GIF tiles
> should work, with a few adjustments in the formula. I hope this
>
> -Alan
>
>
>
> --- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
> >
> > Upon even furhter review, I have determined that zoom level 4 is
> also broken.
> > At first, I thought this may be an even/odd issue, but zoom level 6
> works.
> >
> > Note that I am using the "Map Image API". Is it possible that these
> zoom
> > levels are different than JS api?
> >
> > thanks,
> > jeff
> >
> > --- Jeff Kalikstein <jeff@k...> wrote:
> >
> >
> > ---------------------------------
> > Well, everything is working well with one exception: zoom level 2.
> Is there
> > any chance that this is a special case that doesn't work with your
> original
> > formulas?
> >
> > --- Jeff Kalikstein <jeff@k...> wrote:
> >
> >
> > ---------------------------------
> > Perfect! I put in the new magic number and everything magically
> works great.
> >
> > Apparently I missed some later group discussions on this
> topic...have there
> > been any more progress on removing the star from the center of
the map?
> >
> > I will also be looking at adding tiling and stitching features to my
> app- I
> > know that the API mentions this but I haven't seen much technical
> info on it.
> > Any pointers?
> >
> > thanks!
> >
> >
> >
> > ---------------------------------
> > Yes - I made a mistake in the equations, which I corrected in a later
> > posting (dividing instead of multiplying). Also, you 0.000010728836
> > degrees per pixel instead of 0.000009 (for proper calibration - it's
> > 65536 tiles times 512 pixels per tile wide at the equator at zoom
> > level 1.). The math is used in an actual web page at
> > http://mapnut.com/testzoom.html.
> >
> > Sorry for the mistakes.
> >
> > -Alan
> >
> > --- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
> > >
> > > Oh, I already caught one problem (XDelta and YDelta should be
> > computed with a
> > > "/" instead of a "*"). The results are "close", but not spot on.
> > >
> > > FYI, this is for plotting running data with GPS, and when I plot
> > > Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the
> > data set is
> > > good. I am trying to use the Map Image API so that I can render my
> > running
> > > data on it.
> > >
> > > thanks,
> > > jeff
> > >
> > > --- runningblogger <jeff@k...> wrote:
> > >
> > >
> > > ---------------------------------
> > > Hey-
> > >
> > > Has anyone verified these equations? I just tried implementing
them
> > > and it's not quite working for me. I'm plotting gps tracks
onto maps,
> > > and there seems to be a shift associated with the data. There's a
> > > good chance that I have a bug, but just want to check that the
posted
> > > code is verified first.
> > >
> > > Also, put me on the list of those interested in getting rid of the
> > > center star.
> > >
> > > As others have stated, some sort of interface to convert lat/lon to
> > > pixel coord (or even just the map bounds) would be _most_
excellent.
> > >
> > > thanks,
> > > jeff
> > >
> > > --- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
> > > >
> > > > Alan, this is really terrific! Thank you for the detailed
> > > explanation and also for saving me a
> > > > lot of heartache in figuring out the math 8-).
> > > >
> > > > My wish list, however still stands. It would be very helpful to
> > > developers if Yahoo! could
> > > > return this information in the REST response rather than
requiring
> > > that every developer
> > > > implement their own degrees/pixel calculator.
> > > >
> > > > Cheers,
> > > > Keith
> > > >
> > > >
> > > >
> > > > --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...>
> wrote:
> > > > >
> > > > > > Another (probably simpler) idea would be to return the
scale as
> > > > > degrees/pixel of the map
> > > > > > in the REST response. Doing so would make it easier for
me to
> > > plot points
> > > > > via CSS.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > It's not quite so simple, but I'll give you some formulas that
> > > should do the
> > > > > trick. Caveat - not tested, but I'm pretty comfortable with my
> > math.
> > > > >
> > > > >
> > > > >
> > > > > Each zoom level has half the resolution of the previous level.
> > > Level one
> > > > > has 1 m/pixel resolution at the equator, but resolution varies
> > > with the
> > > > > cosine of the latitude in Mercator project; resolution is 1
> > > m/pixel / cosine
> > > > > (latitude). For any given point, the resolution in the
> north-south
> > > > > direction in meters/pixel is the same as the resolution in the
> > > east-west
> > > > > direction; that's the defining attribute of the Mercator
> projection.
> > > > >
> > > > >
> > > > >
> > > > > Meters per degree longitude varies with latitude, but meter per
> > degree
> > > > > latitude is constant over longitude. For a given zoom level,
> > > variance of
> > > > > the meters per degree longitude cancels out the change in
meters
> > > per pixel
> > > > > in the east/west direction as you move north and south in the
> > Mercator
> > > > > direction. Therefore, for all latitudes, the degrees longitude
> > > per pixel is
> > > > > constant. If an image is 600 pixels wide, and covers 60
> degrees of
> > > > > longitude, you have 0.1 degrees per pixel.
> > > > >
> > > > >
> > > > >
> > > > > Zoom level 1 is (1 m/pixel) * (90 degrees
longitude/10,000,000 m)
> > > = 0.000009
> > > > > degrees longitude/pixel. Each zoom level up from there, you
> > > double the
> > > > > degrees long/pixel of a map.
> > > > >
> > > > > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom
> level -1))
> > > > >
> > > > >
> > > > >
> > > > > The degrees latitude per pixel varies with latitude. If you're
> > > zoomed in
> > > > > close, the top of the map will have a scale similar to the
bottom
> > > of the
> > > > > map. However, if you're showing all of North America, there's
> > > significant
> > > > > variation; it why Greenland looks so big. At the north
pole, it's
> > > zero
> > > > > degrees latitude per pixel - regardless of zoom level. This is
> > > easily seen
> > > > > in the cosine effect:
> > > > >
> > > > >
> > > > >
> > > > > Degrees latitude per pixel = (0.000009 degrees
latitude/pixel)
> > > * (2 ^
> > > > > (zoom level -1)) * cosine (latitude).
> > > > >
> > > > >
> > > > >
> > > > > As latitude approaches 90 degrees, cosine(latitude) goes to
zero
> > > degrees
> > > > > latitude per pixel goes to zero. If you're walking north on a
> > > Mercator
> > > > > projection map, you never get to the north pole, because your
> > > progress per
> > > > > step approaches zero.
> > > > >
> > > > >
> > > > >
> > > > > So . while you can determine how many pixels you need to
move by
> > > taking the
> > > > > shift in degrees longitude and multiplying by the pixels per
> > > degree, you
> > > > > have to use integration to accurately determine the number of
> > > pixels a move
> > > > > of N degrees latitude translates into.
> > > > >
> > > > >
> > > > >
> > > > > I came up with a formula last night that used the longitude/
> > latitude
> > > > > bounding box of the current map; someone says the method for
> > > retrieving that
> > > > > information (getBounds) still isn't working. With some
alternate
> > > math, you
> > > > > can use the coordinate of the center of your image, and the
> > > current zoom
> > > > > level, to determine where to plot a point relative to that
center.
> > > > >
> > > > >
> > > > >
> > > > > The simplest way to do this is determine the number of pixels
> > > north of the
> > > > > equator the center point of the image is, the number of pixels
> > > north of the
> > > > > equator your desired coordinate is, and calculate the
difference.
> > > Using the
> > > > > function I defined yesterday, center coordinate (centerlat,
> > > centerlon), and
> > > > > target coordinate (targetlat,targetlon) :
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> > > > >
> > > > > function MercatorProjectY(latitude)
> > > > > {
> > > > > latradians = latitude * 3.1415927 /180.0;
> > > > > /(1 - sin(latradians))) / 2;
> > > > > return (YProjradians * 180.0 / 3.1415927);
> > > > > }
> > > > >
> > > > > YCenterProj = MercatorProjectY(centerlat);
> > > > >
> > > > > YTargetProj = MercatorProjectY(targetlat);
> > > > >
> > > > >
> > > > >
> > > > > XDelta = (targetlon - centerlon) * degperpixel;
> > > > >
> > > > > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> > > > >
> > > > >
> > > > >
> > > > > The point you want to plot is YDelta pixels above and XDelta
> > > pixels to
> > > > > the right of the center. If you have a 600 x 400 pixel
map, you
> > > could have
> > > > > YDelta values between -200 and 200, and XDelta values
between -300
> > > and 300.
> > > > > Anything beyond that is off the map.
> > > > >
> > > > >
> > > > >
> > > > > You can go in the opposite direction. Say you know what you
> > > position is
> > > > > relative to the center of the map (yes, I know the
coordinates you
> > > work with
> > > > > are relative to a corner of the
> > > > >
> > > > > Image, but I forget which one; you can make the appropriate
> > > > > Starting with XDelta, YDelta:
> > > > >
> > > > >
> > > > >
> > > > > function InverseMercatorProjectY(YProj)
> > > > > {
> > > > > YProjradians = YProj * 3.1415927 /180.0;
> > > > > latradians = 2 * atan(exp(YProjradians)) - 3.1415927 / 2;
> > > > > return (latradians * 180.0 / 3.1415927);
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > targetlon = (XDelta / degperpixel) + centerlon; // simple
enough
> > > > >
> > > > > YTargetProj = (YDelta /degperpixel) + YCenterProj; //
YCenterProj
> > > > > calculated above
> > > > >
> > > > > targetlat = InverseMercatorProjectY(YTargetProj);
> > > > >
> > > > >
> > > > >
> > > > > If you want the bounding box of your 600 x 400 pixel map, apply
> > > this formula
> > > > > to XDelta, YDelta pairs of (-300,-200) and (300,200),
> > > respectively, for
> > > > > minimum and maximum bounds.
> > > > >
> > > > >
> > > > >
> > > > > -Alan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _____
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Developer network
> >
> > > Building blocks
>
> > > Computer security
> >
> > > Computer training Map
> >
> > >
> > >
> > > ---------------------------------
> > > YAHOO! GROUPS LINKS
> > >
> > >
> > > Visit your group "yws-maps" on the web.
> > >
> > > To unsubscribe from this group, send an email to:
> > > yws-maps-unsubscribe@yahoogroups.com
> > >
> > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
> > >
> > >
> > > ---------------------------------
> > >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------
> >
> >
> > Visit your group "yws-maps" on the web.
> >
> > To unsubscribe from this group, send an email to:
> > yws-maps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
> > ---------------------------------
> >
> >
> >
> >
> >
> >
> >
> > Developer network
>
> > Building blocks

> > Computer security
>
> > Computer training Map
>
> >
> >
> > ---------------------------------
> >
> >
> > Visit your group "yws-maps" on the web.
> >
> > To unsubscribe from this group, send an email to:
> > yws-maps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
> > ---------------------------------
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------
> >
> >
> > Visit your group "yws-maps" on the web.
> >
> > To unsubscribe from this group, send an email to:
> > yws-maps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
> > ---------------------------------
> >
>
>
>
>
>
>
> Visit your group "yws-maps" on the web.
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

Developer network Building blocks Computer security Computer training Map

---------------------------------

Visit your group "yws-maps" on the web.

To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

---------------------------------

---------------------------------
Bring words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail.

[Non-text portions of this message have been removed]
• hi jeff@kalikstein.com wrote: Hey Alan- This does not look like a problem with gif vs png (I just explicity tried both, and they both dont work). It
Message 1 of 19 , Jan 26, 2006
View Source
hi

jeff@... wrote: Hey Alan-

This does not look like a problem with gif vs png (I just explicity tried both, and they both dont' work). It actually looks as if the entire scale number is wrong for zoom level 2 and zoom level 4. Here is an example:

http://api.local.yahoo.com/MapsService/V1/mapImage?appid=RunningBlogger&latitude=30.2539275&longitude=-97.7664355&image_width=600&image_height=600&zoom=4

When I try to plot the resulting URL, my datapoints are in scale relative to each other, but not the map. It looks like the "degrees per pixel" is too large. I can experiement with this number until it looks "right" and report back.

----- Original Message ----
To: yws-maps@yahoogroups.com
Sent: Tuesday, January 24, 2006 1:06:56 AM
Subject: [yws-maps] Re: More Mercator projection math

As far as I'm aware, the math is correct. However ...

I hadn't checked it for awhile, but the last I looked, the map image
API produced two sorts of images:

1) PNGs
2) GIFs

The PNGs were the same images as used by the AJAX api. The GIFs,
however, were the images generated by the "old" Yahoo maps. This is
significant, because the "old" Yahoo maps did not use the Mercator
projection - it used the Cylindrical projection.

The cylindrical projection is actually simpler than the Mercator
projection; it's just taking the longitude and latitude and plotting
it on a square grid. Period. I would really need to spend more time
than I have tonight to confirm my suspicion, but I think it's just a
matter of dropping the MercatorProjectY and InverseMercatorProjectY
functions from the formulas ... and, I suspect (have not confirmed!)
the scale factor would go back to 0.000009 degrees per pixel.

However, if you can make use of them, I'd suggest using the PNG tiles
to get the Mercator projection. As I mentioned in my original
posting, the beauty of the Mercator projection is that resolution in
meters per pixel at any given point is the same in the north-south
direction as the east-west direction. This results in the map having
more accurate shapes in the far northern and southern latitudes; the
stret maps of Fairbanks, Alaska, look correct. It also results in
making Greenland look as big as South America; that's the drawback.
But no flat projection of a sphere is going to be perfect.

But - if you're happy with the cylindrical projection, the GIF tiles
should work, with a few adjustments in the formula. I hope this

-Alan

--- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
>
> Upon even furhter review, I have determined that zoom level 4 is
also broken.
> At first, I thought this may be an even/odd issue, but zoom level 6
works.
>
> Note that I am using the "Map Image API". Is it possible that these
zoom
> levels are different than JS api?
>
> thanks,
> jeff
>
> --- Jeff Kalikstein <jeff@k...> wrote:
>
>
> ---------------------------------
> Well, everything is working well with one exception: zoom level 2.
Is there
> any chance that this is a special case that doesn't work with your
original
> formulas?
>
> --- Jeff Kalikstein <jeff@k...> wrote:
>
>
> ---------------------------------
> Perfect! I put in the new magic number and everything magically
works great.
>
> Apparently I missed some later group discussions on this
topic...have there
> been any more progress on removing the star from the center of the map?
>
> I will also be looking at adding tiling and stitching features to my
app- I
> know that the API mentions this but I haven't seen much technical
info on it.
> Any pointers?
>
> thanks!
>
>
>
> ---------------------------------
> Yes - I made a mistake in the equations, which I corrected in a later
> posting (dividing instead of multiplying). Also, you 0.000010728836
> degrees per pixel instead of 0.000009 (for proper calibration - it's
> 65536 tiles times 512 pixels per tile wide at the equator at zoom
> level 1.). The math is used in an actual web page at
> http://mapnut.com/testzoom.html.
>
> Sorry for the mistakes.
>
> -Alan
>
> --- In yws-maps@yahoogroups.com, Jeff Kalikstein <jeff@k...> wrote:
> >
> > Oh, I already caught one problem (XDelta and YDelta should be
> computed with a
> > "/" instead of a "*"). The results are "close", but not spot on.
> >
> > FYI, this is for plotting running data with GPS, and when I plot
> > Maps or the Yahoo Maps JS Api, the dots are spot on, so I know the
> data set is
> > good. I am trying to use the Map Image API so that I can render my
> running
> > data on it.
> >
> > thanks,
> > jeff
> >
> > --- runningblogger <jeff@k...> wrote:
> >
> >
> > ---------------------------------
> > Hey-
> >
> > Has anyone verified these equations? I just tried implementing them
> > and it's not quite working for me. I'm plotting gps tracks onto maps,
> > and there seems to be a shift associated with the data. There's a
> > good chance that I have a bug, but just want to check that the posted
> > code is verified first.
> >
> > Also, put me on the list of those interested in getting rid of the
> > center star.
> >
> > As others have stated, some sort of interface to convert lat/lon to
> > pixel coord (or even just the map bounds) would be _most_ excellent.
> >
> > thanks,
> > jeff
> >
> > --- In yws-maps@yahoogroups.com, "kalperin" <kalperin@y...> wrote:
> > >
> > > Alan, this is really terrific! Thank you for the detailed
> > explanation and also for saving me a
> > > lot of heartache in figuring out the math 8-).
> > >
> > > My wish list, however still stands. It would be very helpful to
> > developers if Yahoo! could
> > > return this information in the REST response rather than requiring
> > that every developer
> > > implement their own degrees/pixel calculator.
> > >
> > > Cheers,
> > > Keith
> > >
> > >
> > >
> > > --- In yws-maps@yahoogroups.com, "Alan D Brown" <adbrown@y...>
wrote:
> > > >
> > > > > Another (probably simpler) idea would be to return the scale as
> > > > degrees/pixel of the map
> > > > > in the REST response. Doing so would make it easier for me to
> > plot points
> > > > via CSS.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > It's not quite so simple, but I'll give you some formulas that
> > should do the
> > > > trick. Caveat - not tested, but I'm pretty comfortable with my
> math.
> > > >
> > > >
> > > >
> > > > Each zoom level has half the resolution of the previous level.
> > Level one
> > > > has 1 m/pixel resolution at the equator, but resolution varies
> > with the
> > > > cosine of the latitude in Mercator project; resolution is 1
> > m/pixel / cosine
> > > > (latitude). For any given point, the resolution in the
north-south
> > > > direction in meters/pixel is the same as the resolution in the
> > east-west
> > > > direction; that's the defining attribute of the Mercator
projection.
> > > >
> > > >
> > > >
> > > > Meters per degree longitude varies with latitude, but meter per
> degree
> > > > latitude is constant over longitude. For a given zoom level,
> > variance of
> > > > the meters per degree longitude cancels out the change in meters
> > per pixel
> > > > in the east/west direction as you move north and south in the
> Mercator
> > > > direction. Therefore, for all latitudes, the degrees longitude
> > per pixel is
> > > > constant. If an image is 600 pixels wide, and covers 60
degrees of
> > > > longitude, you have 0.1 degrees per pixel.
> > > >
> > > >
> > > >
> > > > Zoom level 1 is (1 m/pixel) * (90 degrees longitude/10,000,000 m)
> > = 0.000009
> > > > degrees longitude/pixel. Each zoom level up from there, you
> > double the
> > > > degrees long/pixel of a map.
> > > >
> > > > i.e. (0.000009 degrees longitude /pixel) * (2 ^ (zoom
level -1))
> > > >
> > > >
> > > >
> > > > The degrees latitude per pixel varies with latitude. If you're
> > zoomed in
> > > > close, the top of the map will have a scale similar to the bottom
> > of the
> > > > map. However, if you're showing all of North America, there's
> > significant
> > > > variation; it why Greenland looks so big. At the north pole, it's
> > zero
> > > > degrees latitude per pixel - regardless of zoom level. This is
> > easily seen
> > > > in the cosine effect:
> > > >
> > > >
> > > >
> > > > Degrees latitude per pixel = (0.000009 degrees latitude/pixel)
> > * (2 ^
> > > > (zoom level -1)) * cosine (latitude).
> > > >
> > > >
> > > >
> > > > As latitude approaches 90 degrees, cosine(latitude) goes to zero
> > degrees
> > > > latitude per pixel goes to zero. If you're walking north on a
> > Mercator
> > > > projection map, you never get to the north pole, because your
> > progress per
> > > > step approaches zero.
> > > >
> > > >
> > > >
> > > > So . while you can determine how many pixels you need to move by
> > taking the
> > > > shift in degrees longitude and multiplying by the pixels per
> > degree, you
> > > > have to use integration to accurately determine the number of
> > pixels a move
> > > > of N degrees latitude translates into.
> > > >
> > > >
> > > >
> > > > I came up with a formula last night that used the longitude/
> latitude
> > > > bounding box of the current map; someone says the method for
> > retrieving that
> > > > information (getBounds) still isn't working. With some alternate
> > math, you
> > > > can use the coordinate of the center of your image, and the
> > current zoom
> > > > level, to determine where to plot a point relative to that center.
> > > >
> > > >
> > > >
> > > > The simplest way to do this is determine the number of pixels
> > north of the
> > > > equator the center point of the image is, the number of pixels
> > north of the
> > > > equator your desired coordinate is, and calculate the difference.
> > Using the
> > > > function I defined yesterday, center coordinate (centerlat,
> > centerlon), and
> > > > target coordinate (targetlat,targetlon) :
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > var degperpixel = 0.000009 * (2 ** (zoom - 1));
> > > >
> > > > function MercatorProjectY(latitude)
> > > > {
> > > > latradians = latitude * 3.1415927 /180.0;
> > > > /(1 - sin(latradians))) / 2;
> > > > return (YProjradians * 180.0 / 3.1415927);
> > > > }
> > > >
> > > > YCenterProj = MercatorProjectY(centerlat);
> > > >
> > > > YTargetProj = MercatorProjectY(targetlat);
> > > >
> > > >
> > > >
> > > > XDelta = (targetlon - centerlon) * degperpixel;
> > > >
> > > > YDelta = (YTargetProj - YCenterProj) * degperpixel;
> > > >
> > > >
> > > >
> > > > The point you want to plot is YDelta pixels above and XDelta
> > pixels to
> > > > the right of the center. If you have a 600 x 400 pixel map, you
> > could have
> > > > YDelta values between -200 and 200, and XDelta values between -300
> > and 300.
> > > > Anything beyond that is off the map.
> > > >
> > > >
> > > >
> > > > You can go in the opposite direction. Say you know what you
> > position is
> > > > relative to the center of the map (yes, I know the coordinates you
> > work with
> > > > are relative to a corner of the
> > > >
> > > > Image, but I forget which one; you can make the appropriate
> > > > Starting with XDelta, YDelta:
> > > >
> > > >
> > > >
> > > > function InverseMercatorProjectY(YProj)
> > > > {
> > > > YProjradians = YProj * 3.1415927 /180.0;
> > > > latradians = 2 * atan(exp(YProjradians)) - 3.1415927 / 2;
> > > > return (latradians * 180.0 / 3.1415927);
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > targetlon = (XDelta / degperpixel) + centerlon; // simple enough
> > > >
> > > > YTargetProj = (YDelta /degperpixel) + YCenterProj; // YCenterProj
> > > > calculated above
> > > >
> > > > targetlat = InverseMercatorProjectY(YTargetProj);
> > > >
> > > >
> > > >
> > > > If you want the bounding box of your 600 x 400 pixel map, apply
> > this formula
> > > > to XDelta, YDelta pairs of (-300,-200) and (300,200),
> > respectively, for
> > > > minimum and maximum bounds.
> > > >
> > > >
> > > >
> > > > -Alan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _____
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Developer network
>
> > Building blocks

> > Computer security
>
> > Computer training Map
>
> >
> >
> > ---------------------------------
> >
> >
> > Visit your group "yws-maps" on the web.
> >
> > To unsubscribe from this group, send an email to:
> > yws-maps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
> > ---------------------------------
> >
>
>
>
>
>
>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>
>
>
>
>
>
>
> Developer network

> Building blocks
> Computer security

> Computer training Map

>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>
>
>
>
>
>
>
> ---------------------------------
>
>
> Visit your group "yws-maps" on the web.
>
> To unsubscribe from this group, send an email to:
> yws-maps-unsubscribe@yahoogroups.com
>
>
>
> ---------------------------------
>

Visit your group "yws-maps" on the web.
To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

[Non-text portions of this message have been removed]

Developer network Building blocks Computer security Computer training Map

---------------------------------

Visit your group "yws-maps" on the web.

To unsubscribe from this group, send an email to:
yws-maps-unsubscribe@yahoogroups.com

---------------------------------

---------------------------------
Bring words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail.

[Non-text portions of this message have been removed]
Your message has been successfully submitted and would be delivered to recipients shortly.
• Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
• Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer. We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.