<div dir="ltr"><div dir="ltr"><div>Hi Yves, Simon, Roland and mmd</div></div><div dir="ltr"><br></div><div>Do we agree about nodes lat/lon presence in an osc file as shown in the first example here?</div><div><a href="https://wiki.openstreetmap.org/wiki/OsmChange">https://wiki.openstreetmap.org/wiki/OsmChange</a></div><div><br></div><div>At least we have the nodes geometry for each version, however the ways caveat mentioned by Roland below.<br></div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 21 mars 2021 à 21:26, Roland Olbricht <<a href="mailto:roland.olbricht@gmx.de">roland.olbricht@gmx.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If your process allows to load data over the internet during processing<br>
then Overpass API (or potentially other OSM APIs) will allow you to<br>
fetch the missing data on the fly.<br></blockquote><div><br></div><div><div>In my situation, I have to get all modifications done in France in a time range up to 3 years.</div><div>I'm not sure Overpass API is suitable to get such an amount of data in one query, isn't it?<br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

If it is easier for you to maintain a full database, run a patch and<br>
extract then on the fly then you should look at what Osmium (and again,<br>
some other tools) do.<br></blockquote><div><br></div><div></div><div>Reload a full database on the same area and filtered on the appropriate time window will be probably long as well.<br></div><div>I've no experience in it, can you tell me if I'm wrong here?<br></div><div><br></div><div>A third (and current behavior actually) solution is to filter the French osc file with osmium on the appropriate time window and then filter again day by bay on each of my 40k admin boundaries</div><div>This have to be tremendously long too (and I'm here to abandon this)<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

In any case, there is a caveat that the timestamps in the database are<br>
not strictly in line with the minute updates. As there is no direct<br>
connection between events on nodes and events on ways or relations, it<br>
may happen that a way get it final geometry not before half an hour<br>
later. The new diff process should have mostly mitigated the situation.<br>
Keep this in mind when the basic process has been set up.<br></blockquote><div><br></div><div>This will certainly prevent to rebuild ways linestrings from nodes ids in osc file, thank you to bring this to my attention<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

I'm sorry, from<br>
<a href="https://github.com/vdct/ProjetDuMois/blob/master/db/10_project_update.js#L275" rel="noreferrer" target="_blank">https://github.com/vdct/ProjetDuMois/blob/master/db/10_project_update.js#L275</a><br>
I have not been able to figure out what is in "osh.pbf" to decide<br>
whether there is already somewhere the geometry.<br></blockquote><div><br></div><div>osh.pbf is a file format, not an actual file</div><div>This is documented here : <a href="https://docs.osmcode.org/osmium/latest/osmium-file-formats.html">https://docs.osmcode.org/osmium/latest/osmium-file-formats.html</a></div></div></div><div><br></div><div>This is really interesting, looking forward to go on these things :)</div><div><br></div><div>All the best</div><div><br></div><div>François<br></div></div>