[osmosis-dev] applying diffs to the new planet

[Brett Henderson]

On 18 September 2012 22:50, Shaun McDonald <shaun at shaunmcdonald.me.uk>wrote:

>
> On 18 Sep 2012, at 12:56, Brett Henderson <brett at bretth.com> wrote:
>
> On 18 September 2012 21:46, Shaun McDonald <shaun at shaunmcdonald.me.uk>wrote:
>
>>
>> On 18 Sep 2012, at 12:39, Brett Henderson <brett at bretth.com> wrote:
>>
>> On 17 September 2012 02:57, Frederik Ramm <frederik at remote.org> wrote:
>>
>>> I didn't know that it works without a state file at all!
>>>
>>
>> If no state file is available, it will initialise itself to the latest
>> sequence.  In other words, on first run it will download the latest state
>> file and exit without making any changes.
>>
>>
>> I'm thinking that this is a poor default, and a better default would be
>> to use a state file for the current planet file, possibly going as far as
>> adding a comment to state that if was auto generated, and include the
>> previous plant date as an alternative.
>>
>
> It seemed like a good idea at the time :-)
>
> I'm not keen on automatically setting it to planet timestamps.  That would
> require knowledge of the planet server layout, and assumes that the data is
> being downloaded from the planet server.  Currently the only URL required
> is the URL of the replication files, and that is defined in the config file.
>
> How about aborting with an error message stating that it can't run without
> being initialised with a state file?  That's a fail safe approach that
> avoids silently missing data.
>
>
> Aborting with an error message is a good idea. More importantly the
> information on how to work out what should go in the state file is
> important. Maybe including a link to a wiki page with further detailed
> information.
>

I've made this change, although it wasn't quite as simple as I thought.
The --read-replication-interval and --merge-replication-files tasks share a
lot of code.  They both download change files from the server, and both
track state in a local state.txt file.

In the case of the --read-replication-interval task it makes sense to
require the user to initialise the state.txt file.  But in the case of
--merge-replication-files it's usually sufficient to start from the current
point in time, and is actually much more difficult to initialise a
state.txt because there are two of them (one for tracking server state, and
one for tracking the state of merged output files).

Anyway, I've been able to trigger an exception for
--read-replication-interval without impacting the --merge-replication-files
task.  The following exception message will be provided.
"The local state.txt file doesn't exist. See
http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--read-replication-interval-init_.28--rrii.29for
more details on how to create the state.txt file."

Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmosis-dev/attachments/20120929/ce6d03af/attachment.html>