My suggestion to API (OSM XML)

General talk
1

Hi,

I think it is good idea to use compression (e.g. Deflate ZIP level Normal) in API (RESTful Web Services are MIME enabled e.g. application/zip). For example I downloaded map.osm, which size is 7.95 MB (8 337 860 bytes), but ZIP file of this OSM i just 791 KB (736 773 B) ! It is easy to calculate that is ~91.2% bandwidth savings. I think it is especially great idea for large data sets. I know that ZIP compression/decompression means additional computation power, but I think that Deflate (level normal or less) is enough fast.

Pluses:
a) everybody have ZIP decompression tools (Windows, GNU/Linux, Mac OS X)
b) it is green solution (less time = less power consuming)
c) larger data sets can be available to download in standard API way (see http://api.openstreetmap.org/api/capabilities))
d) much more XML availability for users with slow Internet connection

Minuses:
a) using additional computation power to compress/decompress (maybe use lower compression level e.g. fast instead of normal)
b) additional effort for OSM API programmers (if you need help I am open to collaborate)

For example Microsoft is using that method in Office 2007/2010 formats like docx, xlsx, pptx. It is all just zipped XML documents (you can change docx to zip extension and see that thing).

Maybe it will be good idea to allow people choose by API parameter, that they want ZIP or normal OSM format.

2

It does use compression if the client supports it. If the client sends the correct HTTP headers (Accept-Encoding), the response is returned using a gzip transfer encoding. However it doesn’t mean that it can return larger areas though, as the reason for the limit isn’t due to size of the returned .osm file, but due to the load it puts on the database server.