[OSM-dev] Osmupdate 0.4.5 fails (osmctools)
ycai at mailbox.org
Sat Feb 27 14:09:48 UTC 2021
Checking osmium-based tools, Ijust saw that the comment is back in
miuntely diff state.txt.
Is it now a feature, Tom ?
On 23.02.21 20:25, Yves via dev wrote:
> 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
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev