I know that I've mapped dozens of substations in the midwest with polygons. Are you accounting for those? How about full power stations?

@Geonick: yes, this really does follow the XAPI query syntax. You can indeed supply multiple tag predicates. It will eventually be possible to include multiple bounding box predicates, but at the moment I only allow one.

It bounced a few more times and is down hard now. There appear to be some ECC memory errors, but I put fresh memory in a while back. Looks to be a bad motherboard. Thanks for the stress test, everyone!

The machine restarted itself at 16:00UTC or so, which lines itself up with your request fairly well.

But yes, large bounding box queries are mildly slow -- I don't remember them being particularly fast on the other system, though.

Dude, learn how to modify the style files yourself and contribute or shut your trap. Yelling about old bugs is not a way to attract developer attention to your cause.

Hi PJ! Great to hear that Portland is using OSM data. I recommend that you sign up for the talk-us mailing list and point everyone to this post. Keep us informed about how you're coming along and if you need any help or have questions! There are lots of people in the US interested in how governments can use and contribute to OSM, and Portland seems to be partly leading the way.

Great work!
Ian (@iandees on Twitter)

@andrewpmk: ESRI didn't claim any size when it confirmed the 400M for its map count. Each OpenStreetMap tile is indeed a discrete map, so I counted it that way.

I wrote the new Add WMS dialog and will go ahead and allow the dialog to change size. It definitely doesn't need to be that tall!

Perhaps all of these usability things that you could go on and on about should be written as bugs against JOSM? I certainly would enjoy having an "afternoon project"-sized bug to pick off every once and a while.

This is a pretty large task! The issues mentioned here are common to all imports and have not been solved yet. I invite you to join the talk-us mailing list so we can include you on any discussion around this topic.

Can you post a screenshot of the result? Have you tried using the SVG symbolizer to allow for arbitrarily-sized symbols?

Data that has not been loaded into the OSM database yet should use negative ID numbers. There are no "safe" positive ID ranges as they will all be used eventually.

Have you seen Lars Ahlzen's TopOSM stuff? I'm working with him on covering the entire US with TopOSM right now. Looks like you guys might be duplicating effort! http://toposm.com/ and osm.wiki/TopOSM

Can you describe what you would be looking for in such a tool?

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.