new data files?

[ghost]

I noticed yesterday evening, an update of the data files at http://brouter.de/brouter/segments3/ from 23.07 to 30.07.

I mapped several cycleways in between, at the 27.07. for example. But I cannot get a route on this way. I moved also a main road a bit. You can see the brouter graph follows an old version.

[nrenner]

Hosting is all done by @abrensch, but I assume the data files are based on the latest planet which has a timestamp of 2015-07-29 14:30, so should be included.

Can you give an example link?

[abrensch]

but I assume the data files are based on the latest planet which has a timestamp of 2015-07-29 14:30

it is, but current latest links to "planet-150727.osm.pbf" which indicates the database-snapshot time is some time at the 27.7. So the biggest part of the processing chain delay is not at my side, but at OSM...

[nrenner]

According to the Planet.osm Wiki page, the planet dump starts early Monday morning and takes about two days. So this is why the file name date is 27.07. and the last modified timestamp is 29.07.

The file itself contains a timestamp to indicate up to when data is included, in this case:

curl -L http://planet.openstreetmap.org/planet/planet-latest.osm.bz2 | bzcat | head -n 2

gives:

...  timestamp="2015-07-27T01:59:39Z">

[poutnikl]

Additionally, there is a delay for merging the user map change into master data, because of processing queue. I remember it was once up to 1 day, maybe much shorter now. So even if a change to data is made shortly before Planet snapshot is used, it may still not to be included.

But , I may be wrong, if snapshot timestamp means covering all data changes made before that time.

[nrenner]

@poutnikl According to this part from the Wiki, it is based on a native database dump, which should reflect the database state at that time:

The weekly dump normally starts at around 01:10am UK time on Monday morning and is guaranteed to contain all updates prior to that time. The dump is constructed from a database dump using conversion software, and the result should ensure referential integrity.

What you are probably referring to is the rendering process for the map view, which is separate, see Component overview.

[poutnikl]

No, I do not mean rendering.

If I understand correctly, then referred timestamp is not time when Osmosis starts producing Planet dump from Native OSM DB as I thought, but deadline time for OSM changes.

What is different , as I may perform change at 01:09 UK Monday, but it may be reflected in native DB e.g. 01:11 UK Monday, as I can imagine there is a queue of DB change scripts.

In my previous understanding my change would not get into Planet file, ( 1 minute after deadline )
in my current understanding it would. ( 1 minute before deadline ).

I have no clue what real delay can be expected. But I am aware some tools like JOSM allow to perform some complex batch changes, so the delay may not be short, if there is lot of such batches around the world..

[nrenner]

Ok, then I agree with your first statement, I only associated day long delays with rendering, not with change uploads, but may well have been.

As I understand, dumps are a snapshot of the main database state at that time, changes that have not been written to the main database yet will not be included. So my take is your upload at 01:09 will not be included in a 01:10 dump if is still queued and only written at 01:11.

[ghost]

Here is one example cycleway: http://www.openstreetmap.org/way/362613338

[nrenner]

Now that I know that the "deadline" for the current latest planet was early morning 27.07., it explains that this change later that day is not included.