[OSM-dev] production site disk use question
jeff at gwhat.org
Wed Jan 2 01:28:46 GMT 2013
Mike, Frederik -
Muchas gracias & happy new year!
I'm going to need to go back to the drawing board a bit. I started this
experiment on AWS, then switched to Linode, but may need to go back to AWS.
It seems like running the OSM stack has some bursty processing dynamics
that might be better suited with flexible compute & disk capacity. I have a
feeling that the most effective tiling strategy might involve a hybrid of
some slower tiling for editors to see their changes and static tiles /
mbtiles type approach for general viewing, but that's probably fodder for a
Thanks & more to follow,
On Tue, Jan 1, 2013 at 12:37 PM, Frederik Ramm <frederik at remote.org> wrote:
> On 01.01.2013 18:52, Jeff Meyer wrote:
>> So, it seems like I'll need both the history & the
>> current tables. In a non-history planet.osm extract,
> Yes, if you want any kind of write access *and* read access through the
> API (instead of reading with specialised queries) then I guess you'll need
> both. The current tables always duplicate stuff that is in the history
> tables already, and in theory you could always make queries of the kind
> "where version=(select max(version) ...)" against the history tables to get
> the same you find in the current tables, but that would be too expensive.
> should those tables
>> be the same in an initial import?
> Yes, with the exception that foreign keys contain the version number in
> the history tables but not in the current tables (since the current tables
> only contain ONE way ID #1234, the current_way_tags can afford to reference
> only the way ID, whereas in the history table it must reference way ID and
> Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
Global World History Atlas
jeff at gwhat.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev