All GNIS data was imported as of this past Summer. If they aren't showing up in the map on openstreetmap.org, it's most likely because they weren't tagged in a way that the renderer would draw them.

I believe all of the interesting MassGIS data has already been imported by user crschmidt.

What area are you talking about?

The United States does a great job giving all of its forecasting data out for free: http://www.weather.gov/

In fact, most of the weather forecasts I've seen from local weather stations just pull data from this website.

I've been working for a while on getting the hydrography data imported into OSM. There's a *huge* amount of data to add for just Alaska (think a few gigs of OSM files), so it's been slow going getting the data I received imported.

Anyway, keep an eye on the Talk-US mailing list for more updates on my NHD work.

It could be relatively easy to map the GPX traces "in real time" if the OSM database kept track of the timestamp of each point. I don't think they do...

Hey fellow t@h user. I definitely agree with this statement. Both A and B are show stoppers. Perhaps this discussion should be moved to the t@h mailing list, because I'll bet there are others that would love to weigh in on this.

For A (server side), I think the software needs to be streamlined. We should come up with a list of use cases that the server needs to support and then either rewrite from scratch or rewrite the existing code to speed it up. I've started toying with an alternative implementation on Google App Engine (which is "infinitely scalable") here: http://taggr.appspot.com/browse.

For B (client side), I imagine that some piece of the system needs to determine if a tile is too complex for the client to render (based on memory) and prevent that client from taking the job. The more complex tiles could be rendered by clients that have the capability of rendering them.

This doesn't solve the overall problem, but it does buy us some time.