[OSM-dev] Defining aread for re-rendering; Was: JOSM patch to request T at H renders

Robert (Jamie) Munro rjmunro at arjam.net
Fri Mar 23 16:45:27 GMT 2007

Hash: SHA1

Robert Hart wrote:
>> -----Original Message-----
>> From: dev-bounces at openstreetmap.org
> [mailto:dev-bounces at openstreetmap.org]
>> On Behalf Of Martin Spott
>> Sent: 23 March 2007 15:18
>> To: dev at openstreetmap.org
>> Subject: [OSM-dev] Defining aread for re-rendering;Was: JOSM patch to
>> request T at H renders
>> Hi Frederic,
>> Frederik Ramm wrote:
>>> [...] The ideas have already been laid out
>>> - the API must, on upload, compute the tile number affected by the
>>> upload and either increase a "version counter" or set a "dirty flag"
>>> for this tile [...]
>> Just a side note:
>> I'm preparing for doing something pretty similar with my Landcover DB
>> and FlightGear Scenery. Here I'm defining the area for re-processing
>> the Scenery by calculating a bounding box around a change set and
>> storing this in a separate table - which makes the whole thing
>> work independently from the chosen tile-size.
> In OSM uploads occur for individual objects, i.e. one upload per node,
> segment or way. It would therefore be necessary to merge nearby
> bounding-boxes, otherwise you will end up with a large number of very
> small boxes.

What's wrong with a large number of small boxes? Personally, I'd store
them as an OSM xml file with all the changed elements in and rotate it
every 10 minutes or so. Any client can then poll every 10 minutes (or
less and grab more than one file) and get all the changes. You could use
this feed to mirror all the data. Even Mapnik PostGIS users could merge
the changes into their datasets. All the change files could be deleted
when the next whole planet dump is generated.

Robert (Jamie) Munro
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the dev mailing list