> On Mon, Oct 27, 2008 at 9:39 PM, Michal Migurski <[EMAIL PROTECTED]>
> wrote:
>> I'm liking Jochen Topf's suggestion here:
>>
>> "If the planet dump plus the diff from the same day is what
>> everybody
>> wants anyway, why not do this on the server side and hold the planet
>> back after
On Tue, Oct 28, 2008 at 7:39 AM, Michal Migurski <[EMAIL PROTECTED]> wrote:
> >> Finally, the boundaries between the hourlies and dailies seem
> >> misaligned.
> >>
> >
> > This shouldn't be the case.
> >> After running the remaining hourlies for the 22nd, I attempted to
> >> pick up on the 23rd
On Mon, Oct 27, 2008 at 9:40 PM, Michal Migurski <[EMAIL PROTECTED]> wrote:
>> Now that I think about it though, I think what I did was take one of
>> the planet dumps from http://hypercube.telascience.org/planet/ (which
>> *are* consistant snapshots), and run the dailies from there.
>
> Is there a
On Mon, Oct 27, 2008 at 9:39 PM, Michal Migurski <[EMAIL PROTECTED]> wrote:
> I'm liking Jochen Topf's suggestion here:
>
>"If the planet dump plus the diff from the same day is what everybody
> wants anyway, why not do this on the server side and hold the planet
> back after the first diff
On Oct 27, 2008, at 12:59 AM, Martijn van Oosterhout wrote:
> On Mon, Oct 27, 2008 at 1:10 AM, Michal Migurski <[EMAIL PROTECTED]>
> wrote:
>> The final event in each weekly planet dump does not fall on an even
>> day boundary. In the case of the most recent Oct. 22nd planet.osm, it
>> was neces
>> Yep, as others have commented there are two tables types in the osm
>> database; current tables, and history tables. The planet dumper
>> just reads current tables which is the fastest approach.
>> Unfortunately the current tables change constantly during the
>> planet generation proce
Hi,
Brett Henderson wrote:
>> Brett Henderson has offered to look into creating the dailies from
>> history as well, but I don't know about the status of that.
>>
> Are you referring to the daily changesets?
[...]
> Or did you mean planets instead of dailies?
Mix-up on my part, sorry, yes I
Jochen Topf wrote:
> If the planet dump plus the diff from the same day is what everybody
> wants anyway, why not do this on the server side and hold the planet
> back after the first diff is available, run this over the planet and
> then publish that as the planet?
>
It would add delay to the p
Frederik Ramm wrote:
> Hi,
>
> Michal Migurski wrote:
>
>> I've noticed some misalignments between the data in the dumps and the
>> osm2pgsql importer that leads to unavoidable holes in the data.
>>
>
> As TomH has already said, this is not a bug, it stems from the fact that
> the full p
Others have already commented on most of your points but I'll add my
thoughts in case there's some gaps.
Michal Migurski wrote:
> Hi,
>
> I've been trying to keep up to date with the dumps and diffs from
> http://planet.openstreetmap.org/
> , and I'm running into a number of bugs related to cut
On Mon, Oct 27, 2008 at 08:22:32AM +, Tom Hughes wrote:
> Shaun McDonald wrote:
> > On 27 Oct 2008, at 00:50, Michal Migurski wrote:
> >
> >>> Planet dumps are not snapshots - they do not represent a consistent
> >>> view at any particular point in time because they take a number of
> >>> hour
Shaun McDonald wrote:
> On 27 Oct 2008, at 00:50, Michal Migurski wrote:
>
>>> Planet dumps are not snapshots - they do not represent a consistent
>>> view at any particular point in time because they take a number of
>>> hours to generate, during which time new changes are constantly
>>> being ma
On Mon, Oct 27, 2008 at 1:10 AM, Michal Migurski <[EMAIL PROTECTED]> wrote:
> The final event in each weekly planet dump does not fall on an even
> day boundary. In the case of the most recent Oct. 22nd planet.osm, it
> was necessary to experiment with hourly diffs from that day to find
> that the
On Sun, Oct 26, 2008 at 06:11:04PM -0700, Michal Migurski wrote:
> What is the difference between osmosis and osm2pgsql, with regards to
> postGIS?
osm2pgsql creates the structure needed for Mapnik. Osmosis creates a
structure more simliar to the one in the OSM central database.
> If I've been
On 27 Oct 2008, at 00:50, Michal Migurski wrote:
>>> The final event in each weekly planet dump does not fall on an
>>> even day boundary. In the case of the most recent Oct. 22nd
>>> planet.osm, it was necessary to experiment with hourly diffs from
>>> that day to find that the boundary was a
On Oct 26, 2008, at 5:50 PM, Frederik Ramm wrote:
> Brett Henderson has offered to look into creating the dailies from
> history as well, but I don't know about the status of that.
>
> If you use osmosis, it is safe (and in fact recommended) that, after
> loading the database with a planet fil
>> The final event in each weekly planet dump does not fall on an
>> even day boundary. In the case of the most recent Oct. 22nd
>> planet.osm, it was necessary to experiment with hourly diffs from
>> that day to find that the boundary was approx. 2:00pm. Hourlies up
>> to and including
Hi,
Michal Migurski wrote:
> I've noticed some misalignments between the data in the dumps and the
> osm2pgsql importer that leads to unavoidable holes in the data.
As TomH has already said, this is not a bug, it stems from the fact that
the full planet export reads the "current" tables and as
Michal Migurski wrote:
> The final event in each weekly planet dump does not fall on an even
> day boundary. In the case of the most recent Oct. 22nd planet.osm, it
> was necessary to experiment with hourly diffs from that day to find
> that the boundary was approx. 2:00pm. Hourlies up to an
Hi,
I've been trying to keep up to date with the dumps and diffs from
http://planet.openstreetmap.org/
, and I'm running into a number of bugs related to cutoff dates.
In keeping my Bay Area tiles
(http://mike.teczno.com/notes/cascadenik-openstreetmap.html
) up to date, I've been grabbing com
20 matches
Mail list logo
