WMS on Google Maps JavaScript API v3?

[Geostrophic]

I'm part of a development team for NWS radar web pages. Progress has
been slow - but we're getting there:
http://radar.srh.noaa.gov/

We ended up using OpenLayers as our API. The slow loading can mostly
be attributed to load on our WMS server and PostGres DB (warning
layer).

...that's not my question though :)

I've attempted to use the same method of WMS overlay I've made work
with the Google Maps API v2 before, to overlay a warnings layer on v3
for a simple mobile interface - and I can't get things to click.

Here's a simple v2 example that does work:
http://www.srh.noaa.gov/ridge2/.corey/mobile/apiv3/wms/main.php

And my v3 example, that fails miserably:
http://www.srh.noaa.gov/ridge2/.corey/mobile/apiv3/wms/main_APIv3.php

Any help would be greatly appreciated.

Thank you.

[John Coryat]

As far as I know, tile layers aren't currently available in v3. Check the documentation to be sure.

-John Coryat

http://maps.huge.info

http://www.usnaviguide.com

http://www.zipmap.net

[Geostrophic]

Thanks, John!

I wasn't too hopeful, until I found this:
http://gmaps-utility-gis.googlecode.com/svn/trunk/arcgislink/examples/simpleags.html

I may just resort to this until tiling catches up (if it does):
http://www.usnaviguide.com/v3maps/ProjectedOverlayTest.htm

[Nianwei]

Unless your WMS service are siting behind a caching service, it is
generally not a good idea to request WMS services as tile layer (if
you have worked with AGS .NET ADF 9.2 you know what I mean).

Also, Google API's tile fetching process is very aggressive, making
things worse if your tile is dynamically generated. I've fired a
feature request a while ago (http://code.google.com/p/gmaps-api-issues/
issues/detail?id=336) to adjust this but so far it's not available
yet.

Use the WMS service as an overlay is the best option (as in the AGS
sample you mentioned). If you really want the 'seamless pan', you can
fake it by generating a larger map to cover some areas outside the
view port, that probably still a lot faster than generate 16-25 tiles
per view change.

If your data changes frequently, tile layer probably should not be
used cause there is no reliable way to force tile reload yet.

On Aug 3, 1:15 pm, Geostrophic <coreypie...@gmail.com> wrote:
> Thanks, John!
>

> I wasn't too hopeful, until I found this:http://gmaps-utility-gis.googlecode.com/svn/trunk/arcgislink/examples...

[bratliff]

On Aug 4, 10:59 am, Nianwei <nian...@gmail.com> wrote:
> Unless your WMS service are siting behind a caching service, it is
> generally not a good idea to request WMS services as tile layer (if
> you have worked with AGS .NET ADF 9.2 you know what I mean).
>
> Also, Google API's tile fetching process is very aggressive, making
> things worse if your tile is dynamically generated. I've fired a
> feature request a while ago (http://code.google.com/p/gmaps-api-issues/
> issues/detail?id=336) to adjust this but so far it's not available
> yet.
>
> Use the WMS service as an overlay is the best option (as in the AGS
> sample you mentioned). If you really want the 'seamless pan', you can
> fake it by generating a larger map to cover some areas outside the
> view port, that probably still a lot faster than generate 16-25 tiles
> per view change.
>
> If your data changes frequently, tile layer probably should not be
> used cause there is no reliable way to force tile reload yet.

I agree. Tiles are a really bad idea for time sensitive images like
radar scans. Two adjacent tiles may be derrived from different
scans. You will see tile boundaries in your composite image unless
you force a complete reload of every tile which will kill performance.

What is wrong with the GIF images already available. ?

[Geostrophic]

There are a couple of problems that crop up with the current images,
that I was never able to get around (but you all likely know more than
I do):

1. I overlay the gif in this example (using a non-xparent gif - so,
It's ugly - and just done to proove to me that the API can do animated
gifs): http://www.srh.noaa.gov/ridge2/.corey/mobile/apiv3/projectedoverlay/changeradars/?id=IND&prod=N0R&lat=39.76702&lon=-86.15626
It's "okay"...but the gifs we produce (including the ones that are
transparent and not looping) are unprojected - and get further and
further "off" the further north the radar is. I do the overlaying
using ProjectedOverlay.js

2. (you'll need an iPhone for this one). Once you zoom in on the
example url above in the iPhone safari - the overlay disappears.
Likely because of the image size.

[Geostrophic]

Nianwei,

We're using MapServer WMS behind TileCache for our production web
pages.

Are you suggesting that I can try and do a TileCache call for 1 big
tile for the entire viewable domain?

...I know it's likely an elementary concept - but would you be willing
to help me with the JS code that generates the appropriate query?

[bratliff]

A cache works well for static tiles. Your tiles will be dynamic.
Every five minutes, your images change. Caching something with a very
short shelf life is not particularly useful.

If you are focusing on individual radar stations rather than the
entire nation, you only have to build images the size of each bounding
box. Building tiles will not help. You can limit your zoom levels
because very deep levels will just display large pixelated squares.
Zoom levels 4 through 7 look fine. The other zoom levels are not very
useful

[bratliff]

Also, if you do decide to use tiles, which I do not recommend, look
at:

www.polyarc.us/experimental

It is a V3 replacement for GTileLayerOverlay with a few little
extras. It can handle multiple tile sets in the same overlay without
the overhead of multiple overlays. It can be limited to just the
bounding boxes to avoid requesting non-existant tiles. It can adapt
to different tile sizes.

I have not adapted it to handle International Date Line issues. It
might not work for Alaska.

[Geostrophic]

We've actually been using TileCache to great effect for a few months.
We simply rotate the cache every 5 mintues. With the volume of hits
the we recieved on our radar pages, any cahing is benefficial - and if
the font end is built properly, the user would rarely know the
difference.

We're now experimenting with utilizing what's known as wms-t in
MapServer, allowing users to utilize TileCache results through the
duration of the radar loop we've allotted (~45 minutes) - while
rotating in a new layer for the newest. It's greatly improved our back
end processing speed - and will soon be implemented on our Beta site.

[Geostrophic]

Thanks! I'll have to give this a shot for my v3 example.

[Nianwei]

I am simply suggesting a plain dynamic image overlay. However if your
tile rotation works as expected then it is a valid solution.
About the unprojected image (I assume you mean raw WGS coordinates),
can't you have map server generate a mercator image? As far as I know
may service supports sphere mercator,

[Bryan Field-Elliot]

I'm using the v3 API on an iPhone 3G (over 3G), with my sandbox web
application. I'm using Safari's geolocation API to keep the map
centered on my current location -- basically, whenever the phone's lat/
lng changes (via an event from the geolocation API), I call
map.set_center().

Driving down the freeway, the smoothness of this technique is night
and day different from the native Maps application (on the iPhone).
The native maps application is great, always gently scrolling as we're
headed down the highway. By contrast, my web app is extremely jerky.
The map tiles are updated with the current position about every 30
seconds or so, though my own markers are scrolling smoothly. I'm in
"hybrid" mode (satellite + map), on both the native app, and the web
app. And I have both apps at the same zoom level.

Is there some other technique I should be using, to get constant
scrolling with the V3 API in a way which is visually comparable to the
native app? (in other words, nice-looking)?

Thank you,

Bryan

[Bryan Field-Elliot]

Following up on this (because I haven't seen any response from
Google)....

I've coded up a sample app to illustrate this. Go ahead and load this
on your iPhone (3G):

http://strategoit.s3.amazonaws.com/track.html

Drive down the freeway and see how it tracks you. Compare this to the
native Maps application on the iPhone. It's a night and day
difference. And we all know that the underlying platform is the same,
so, we should be able to get the Safari experience to be comparable to
the native maps app. But it isn't.

Is there any variation of this technique we should try, in order to
smooth things out?

Also, is there any way to "move_to" another center location, rather
than "set_center"? If we could do that, and it would pan smoothly to
that new location, it might a long way towards making the mobile
Safari experience better.

Thank you,

Bryan

[bratliff]

Please do not change the subjects of other people's threads. Start
your own thread with your own subject.

[bratliff]

On Aug 8, 6:50 pm, bratliff <bratl...@umich.edu> wrote:
> Please do not change the subjects of other people's threads. Start
> your own thread with your own subject.

Apologies to Nianwei if my comment seemed misdirected. I just
responded to the last message with the correct subject.

[Geostrophic]

BTW...thank you all for your help.

I haven't had a chance to try my next iteration yet - but I'll post
the results here, once I have.

[pamela (Google Employee)]

Hey Bryan-

We now have the panTo functionality in the latest release. Can you try
that and see how the performance compares now?

- pamela