[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.
Regards,
Yves 

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:
>
>>>>
>
>--hour
>--day
>        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
>https://lists.openstreetmap.org/listinfo/dev
-------------- 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