On Dec 22, 2011, at 8:48 AM, Tom Hughes wrote:
> On 22/12/11 16:14, Michal Migurski wrote:
>
>> +1 on Frederick's suggestion, with the caveat that it should be possible to
>> override the Accept request header with a "?type=pbf" argument or similar.
>
> Why on earth are we still bikeshedding th
On Thursday, December 22, 2011 10:48:19 AM UTC-6, Tom Hughes wrote:
> On 22/12/11 16:14, Michal Migurski wrote:
>
> > +1 on Frederick's suggestion, with the caveat that it should be possible
> to override the Accept request header with a "?type=pbf" argument or
> similar.
>
> Why on earth are we
On 22/12/11 16:14, Michal Migurski wrote:
+1 on Frederick's suggestion, with the caveat that it should be possible to override the
Accept request header with a "?type=pbf" argument or similar.
Why on earth are we still bikeshedding this?
It's not rocket science to add extra response formats
PBF is also a more efficient file structure to read data from than compressed
XML.
-mike.
On Dec 22, 2011, at 8:23 AM, Simon Poole wrote:
>
> What I haven't seen to yet, is a justification for even contemplating this.
> Is download bandwidth to editing clients even remotely an issue (even in
What I haven't seen to yet, is a justification for even contemplating
this. Is download bandwidth to editing clients even remotely an issue
(even in not so well developed countries)?
Simon
Am 22.12.2011 17:14, schrieb Michal Migurski:
+1 on Frederick's suggestion, with the caveat that it sh
+1 on Frederick's suggestion, with the caveat that it should be possible to
override the Accept request header with a "?type=pbf" argument or similar.
-mike.
On Dec 22, 2011, at 5:09 AM, Peter Wendorff wrote:
> I like the idea Frederick mentioned, to use standard http techniques for that.
> Tha
I like the idea Frederick mentioned, to use standard http techniques for
that.
That would allow to support different compression algorithms on the
server side, while server and client/editor would be able to decide
together about the format used.
regards
Peter
Am 22.12.2011 12:39, schrieb Mik
of course, there is not anything there. api.openstreetmap.org/pbf/ is
just my suggestion of what we could use instead of >>
api.openstreetmap.org/
mike
On Thu, Dec 22, 2011 at 11:39 AM, Parveen Arora wrote:
> On Thu, Dec 22, 2011 at 7:35 AM, Mike Dupont
> wrote:
>> you could also use a differen
On Thu, Dec 22, 2011 at 7:35 AM, Mike Dupont
wrote:
> you could also use a different base user or api/pfb or something.
> api.openstreetmap.org/pbf/
File not Found at this link.
--
Parveen Arora
www.parveenarora.in
E-Mail: m...@parveenarora.in
___
ta
you could also use a different base user or api/pfb or something.
api.openstreetmap.org/pbf/
On Thu, Dec 22, 2011 at 2:52 AM, john whelan wrote:
> So continuing idle thoughts, two servers, the first set up to handle PFB
> only, looks at its own local cached database which would be tiled in PFB
>
So continuing idle thoughts, two servers, the first set up to handle PFB
only, looks at its own local cached database which would be tiled in PFB
format with a tag to say either dirty or clean. If clean it would serve up
the data as pre-compressed PBF tiles if dirty it would pass through the
reque
Hi,
On 12/21/2011 07:09 PM, john whelan wrote:
I think it could still return any edits or additions in OSM format but I
think more bandwidth is consumed downloading than adding a couple of
street names in an upload.
It could potentially be done via standard HTTP format negotiation, i.e.
clien
I think that is a great idea!
is that not why google developed PBF so you can use it for streaming?
mike
On Wed, Dec 21, 2011 at 7:09 PM, john whelan wrote:
> Since JOSM can now read PBF files could JOSM request the area of the map to
> be downloaded to be in PBF format?
>
> It would lower the ba
Since JOSM can now read PBF files could JOSM request the area of the map to
be downloaded to be in PBF format?
It would lower the bandwidth requirements.
I think it could still return any edits or additions in OSM format but I
think more bandwidth is consumed downloading than adding a couple of s
14 matches
Mail list logo
