I just realised. You have also created a parse_wkt, which opens up the path to limited relation processing even in non-slim mode. (It doesn't solve the problem completely, since the whole problem is that non-slim doesn't store most of the info required, but for certain types of relations it might be sufficient.)
On Sun, Feb 8, 2009 at 12:37 PM, Martijn van Oosterhout <[email protected]> wrote: > Looks like a pretty cool idea. I only have a few small comments. > > - The use of -o. Is there any other output osm2pgsql could produce > that would be more logical. Not really a big deal, the long option > expire-output is there which is good enough for me. > > - There a whole new file added (expire-tiles.c) which seems to have > some kind of tree structure. Do you think you could add a comment at > the beginning what kind of structure it is and any relevent invariants > (like middle-ram.c does). > > - Does middle.h need to include osmtypes.h? > > - You've got a definition of EARTH_CIRCUMFERENCE. Does that match with > what's used in the projection code? > > Other than that I have no objections (I assume it doesn't change > anything when not run in this mode). > > Have a nice day, > > On Sun, Feb 8, 2009 at 11:23 AM, Steve Hill <[email protected]> wrote: >> >> I've been working on code to generate a list of dirty tiles while importing >> the deltas. The attached patch introduces 2 new commandline options: "-e >> <zoomlevel>" and "-o <dirty tile list output file>". So, specifying "-e 17 >> -o /tmp/dirty_tiles" when importing a delta will cause osm2pgsql to generate >> a list of all zoom level 17 tiles which the delta has made dirty and store >> it in /tmp/dirty_tiles. >> >> Proviso: for polygons, it currently takes a simplistic approach of drawing a >> bounding box around the whole polygon and marking every tile in the box as >> dirty. If the bounding box is large (over 30x30Km) the polygon is treated >> as a line instead, so only the perimeter will be marked as dirty (this is so >> that huge polygons don't expire vast numbers of tiles and is based on the >> assumption that we probably aren't going to shade the area of massive >> polygons). >> >> The dirty tile list is maintained in memory as a binary tree and dumped to >> disk at the end of the run. >> >> I'm running this code on OpenPisteMap and it seems to be working ok. Does >> anyone have any objection to me committing these changes to the >> OpenStreetMap subversion server? >> >> - Steve >> xmpp:[email protected] sip:[email protected] http://www.nexusuk.org/ >> >> Servatis a periculum, servatis a maleficum - Whisper, Evanescence >> >> _______________________________________________ >> dev mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/dev >> >> > > > > -- > Martijn van Oosterhout <[email protected]> http://svana.org/kleptog/ > -- Martijn van Oosterhout <[email protected]> http://svana.org/kleptog/ _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
