Hack, but not terrible. Platforms are platforms, not highway=pedestrian. Use the tag railway=platform (already in map_features) and either change the renderers to render it yourself or ask (via the mailing lists) that someone else do it. Then encourage routing program authors to include it since platforms are clearly an important transport interchange.

If you want to extract a small area, such as a small town, you can zoom to the area and use the Export tab to download the XML. You can get the whole of OSM's current data by downloading the planet dump: look at the wiki page. One mid-range solution is XAPI, but that has had a problem and is rebuilding now. Third parties provide very good data sources such as the downloads at Geofabrik.

Look at the history of the border way (press H in potlatch) then contact the person who drew the current border with a send message to see what they think.

Does this map have the National Byway on it?

"So there's still nothing better than to go out and see for yourself what it looks like before putting it in OSM."

I completely agree. You gain so much more by getting out there and looking. This is the way to build a truly wonderful map and is best done by crowd-sourcing.

Importing data is a short cut, but not as good as gathering data on the ground. Overwriting hand gathered data is bad form. This business of not amending imported data to allow a later import is also very dubious - how do we encourage people to improve the data if you don't want them edit it? Never mind smarter renders - why not smarter imports?

Maybe a road that's unsuitable for motors is a track, with a suitable surface?

Chris

If you think you can improve the accuracy of a road then just do it. It is a wiki, so your improvements can always be improved again. Using multiple GPS tracks, taken on different days, to estimate the best place for a road helps, but if you know you have an good accuracy then use it. It is best to move an existing road rather than to delete it and add a new one.

Careful - that's how I started. Before you know it you'll be tackling whole cities.

It's great to see your enthusiasm - I think that's what drives OSM.

The quirk seems to have disappeared now, but looking at the complex junction there are no bridge tags. I think these would help to make it clear which piece of road is above another.

A trench that carries a road or railway is known as a cutting and is tagged as cutting=yes. I'm not sure how it renders.

That's part of the point of OSM, we get it right, no easter eggs and and mistakes can easily be corrected. Ignore G maps and just record what you find.

Even solar panels have a limited life, especially in space where hits from debris and micro meteorites slowly kill the panel. Cosmic rays can damage any electronics especially a big flat panel outside the shield of our atmosphere.

Saving any substantial change in Potlatch has been noticeably slower since APIv0.6. I have even given up. Sometimes downloads are slow too. Downloads to JOSM have also usually taken longer. Downloads of quite large areas of a city in JOSM, which used to work well, now give an error (can't remember what), so I have had to edit in chunks. Uploads in JOSM seem about the same as before the change.

I have an example of a (small) section which had rendered and now has reverted. The data is still present. I have added a small change so maybe this will trigger another render. osm.org/?lat=53.73664&lon=-0.45103&zoom=16&layers=B000FTF

The fact that you are asking questions about whether it is wrong means you are not sure, if you are not sure if using the source is copyright-safe, then don't use it. I can map a zoo by walking around it. If I see a sign saying "Monkey Street" I'd name the way on the map, but if I need someone else's map then I'll trace my GPS track and tag it without a name. I might estimate the lion enclosure based on some tracks and photos and name it lions based on a name plate or the fact that it has lions roaming around in it, but not because someone else's map says that the lions are over there.

I don't think fetching the data is a good idea because of the huge load you impose on the API server - which is our most important server. The other ways of displaying the map render tiles once for each zoom level (some on demand) and then deliver that from a store of these tiles (often using AJAX in OpenLayers). This reduces the impact on the API server to an acceptable level. Using your system if many people all want to view Amsterdam they will each make a massive request of the API server, all asking for the same or similar data which will probably overload it. At lower zoom levels (about 14 and below) the waiting time for the API data is already very long.

The rendering time also grows exponentially as you zoom out as the area covered by the visible map is four time larger the previous zoom level, so you have to extract four times as much data from the API server. Even if you choose to ignore some features at lower zoom levels you will still get all the data.

I think it is great that people try new things - but some things are best tried then abandoned. Why not try using AJAX in new ways using the tile servers, such as smooth zooms and pans.

I'm not sure that fetching data from the API for rendering in a browser in real time is a good idea at all.

The accuracy of GPS means that tracing a road from the side-walk is usually pretty good and certainly much better than nothing. If I drive or cycle down a road I'm still not on the centre line.

You want to tag music? ;-)

Just draw the roads, with junctions where they should be then mark the junctions as mini roundabouts. This looks like what you have done. The mini roundabouts effectively mark the centre of the junction, their real sizes vary. The fact that there looks like a short road between is a limitation of the representational nature of a map: it is a map not the real world. People, routing s/w and other users of the data will understand perfectly. Eventually we may draw everything as an area rather than simply a line and dots then perfect representation may become a little closer.