<br><br><div class="gmail_quote">On Wed, May 13, 2009 at 10:28 AM, Jonathan Bennett <span dir="ltr"><<a href="mailto:openstreetmap@jonno.cix.co.uk">openstreetmap@jonno.cix.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Ian Dees wrote:<br>
> Woah! Since when can OSM tell me what sort of applications I can and<br>
> can't write with the open source data that OSM is providing**?<br>
<br>
</div>You're not being told what to do with the data, but it's being suggested<br>
to you that you can't have it in a particular, resource-intensive format<br>
unless you can justify why you need it over and above an existing, less<br>
resource hungry format, for an application that does something other<br>
than go "Ooooh, shiny!"</blockquote><br>The whole argument I'm making is that after the initial implementation**, streaming the data is a lot less resource intensive than what we are currently doing. Perhaps I don't have the whole picture of what goes on in the backend, but at some point the changeset XML files are applied to the database. At this point, we already have the XML changeset that was created by the client. The stream would simply be mirroring that out to anyone listening over a compressed HTTP channel.<br>
<br>Of course it could then by propogated to other servers if the bandwidth load was too great.<br><br>One of the clients to this stream might be Osmosis, saving off chunks of data one minute wide and sending it to <a href="http://planet.openstreetmap.org">planet.openstreetmap.org</a>, for example.<br>
</div><br>** ...and I've always said I would be willing to impelement this if we discussed it and decided there was a way to source the data in a technically feasible way.<br>