[OSM-talk] Idle thought time, PBF and JOSM

john whelan jwhelan0112 at gmail.com
Thu Dec 22 01:52:47 GMT 2011


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
request to the main server and flip back either OSM or PBF depending on the
resources available.

If your copy of JOSM has the plugin you point it at the PBF server for
downloads if not the conventional OSM server.  All uploads would go to the
conventional OSM server other than a mark this tile dirty cache marker.  It
might need a line or two of coding in in JOSM to handle this.

Marking something dirty is a way of handling cached databases.  If you
change something in the original database you set a dirty tag so you know
you have to recache it in slow time.

I'd probably do the "tiles" based on the number of nodes and it basically
becomes a cost matter where you draw the line.

The nice thing about throwing out ideas is you don't have to make them work.

Cheerio John

On 21 December 2011 17:52, Frederik Ramm <frederik at remote.org> wrote:

> 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.
> client sends to server "I can accept PBF", server then, if implemented,
> replies with PBF document rather than XML. It would have to be implemented
> in Matt's cgimap program (no use to implement it in Rails I'd guess - if
> someone chooses to install a rails port without cgimap then everything is
> still usable, just he won't have PBF replies).
>
> A possible disadvantage (that would have to be investigated) is the
> allegedly high memory usage of PBF writers. That could be a show stopper
> for our production environment.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
>
> ______________________________**_________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk<http://lists.openstreetmap.org/listinfo/talk>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20111221/de632692/attachment.html>


More information about the talk mailing list