[OSM-dev] Osmupdate 0.4.5 fails (osmctools)

Yves ycai at mailbox.org
Tue Feb 23 19:25:56 UTC 2021

The hourly diff option seems a good idea.
One to one replacement with pyosmium is also doing the trick but disk and cpu use patterns are quite different than osmupdate, so on a machine also running a tile server, it will require some tuning.

Le 23 février 2021 17:56:25 GMT+01:00, mmd <mmd.osm at gmail.com> a écrit :
>On 2/23/21 10:31 AM, Stephan Knauss wrote:
>> On 23.02.2021 08:42, mmd wrote:
>>> I doubt this will work. The new state.txt format only applies to
>>> minutely diffs. If you happen to process hourly or daily diffs which are
>>> still being generated using the old format, this will obviously no
>>> longer work. When catching up, osmupdate would choose the most suitable
>>> format (out of minutely, hourly and daily) to reduce the number of
>>> downloads, so this is a real issue.
>> You are absolutely right. I only looked at the minutely state file. In
>> the hour/state.txt the comment is still present.
>Perhaps that would be an option for users who can't patch their
>osmupdate binary and want to update their local OSM data even though a
>new osmupdate release is not yet available.
>osmupdate has a few command line parameters to restrict the kind of diff
>files it uses to update local OSM files.
>From the osmupdate help:
>        By default, osmupdate uses a combination of minutely, hourly
>        and daily changefiles. If you want to limit these changefile
>        categories, use one or two of these options and choose that
>        category/ies you want to be used.
>By specifying --hour (or additionally --day) on the command line,
>processing is limited to hourly and daily diffs, which as we've seen
>earlier on are still using the old format.
>The data would no longer be up to date to the minute. Depending on the
>use case, hourly updates may just be fine.
>This is not meant as a permanent solution and should only be seen as an
>option to get people going again that are stuck with their broken
>pipeline. If you try this out, make sure to create a backup first.
>Once a new osmupdate release is available, this workaround should be
>removed asap.
>dev mailing list
>dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20210223/7ed8b901/attachment.htm>

More information about the dev mailing list