<div dir="ltr"><div dir="ltr"><div>Hi Sarah,</div><div><br></div><div>Thanks for your reply. <br></div><div>To return quickly to the first point, It really was only for theoretical knowledge purposes. I am completely aware that It doesn't guarantee anything and that there is a lot of competition on the overall openstreetmap organization. <br></div><div>Anyway thanks for your honesty on this point, it is good to know that there is not necessarily only one student working on Nominatim.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>No, the tool should be regulary run against an existing database. The idea<br>
is the following: we have the global instance of Nominatim running at<br>
<a href="https://nominatim.openstreetmap.org" rel="noreferrer" target="_blank">https://nominatim.openstreetmap.org</a>. Once a night, we would stop the regular<br>
update, let the tool run over the database and create the error reports<br>
in the form of vector tiles that are suitable for being displayed with<br>
Osmoscope, then continue upating the database with the newest data from OSM.</div></blockquote><div><br></div><div>This is not completely clear for me, as I understand the tool should be run during the night before starting the process of updating the database with the newest data from OSM, is it correct? <br></div><div>Because as you wrote this, it seems that the tool should run in the middle of the regular update (like stopping the update, running the QA analysis tool and then continue the update).</div><div>If it should be started beside the update process, why shouldn't it be after the update process so that the new data will be analysed too?<br></div></div><div><br></div><div>I am still learning the database structure and some OSM mapping structures. As I am running through the main Nominatim tables structures I also try to create very basic documentation for them.<br></div><div>I tried to imagine a basic solution for some data issues, for example, could you tell me if  these basics examples are correct (of course it is still very global logic and not totally accurate):<br></div><div>- For "admin boundaries with more than one member with role 'label'" we would need to lookup "placex" table to find relation with class=boundary and type=administrative. Then for the finded relations we would lookup "planet_osm_rels" find each previously selected relations and check their node members with a role label.</div><div>- For "same Wikidata IDs appearing on more than one place node" we would need to lookup placex and finded duplicate Wikidata IDs, for example I made a quick and simple SQL query for tests purpose:</div><div>SELECT * FROM placex p1 WHERE <br></div><div>(SELECT count(*) from placex p2 where p1.osm_type = 'N' AND p2.osm_type = 'N' <br></div><div>AND p1.extratags->'wikidata' = p2.extratags->'wikidata') > 1</div><div>- Others will be more or less tricky but will always need some lookup on the database too in order to check osm objects.</div><div><br></div><div>After an initial thought, I think the main difficulties of the project lies in the fact of having a modular and performant tool. <br></div><div>For the modular part, it should be easy to plug to the tool a new "rule" of QA analysis like "place nodes of the same type and name close to each other" for example. <br></div><div>For the performance part, as each rule may need to lookup the database (and a lot of time on the same table), the tool will need a mechanism to make everything smooth by limiting lookups, caching some results and by coordinating the "rules" executions.</div><div><br></div><div>The first ideas I have concerning the structure of the tools (very global one, I didn't had the time to really design it yet) are:</div><div>- Something like a QAUnit or QARule object will define a specific unique rule (like "place nodes of the same type and name close to each other"), so that each rule will be independant and it would be easy to add a new one.</div><div>- A core part where every QAUnit or QARule will be plugged (like registered). It will be the main process responsible for the execution of each QAUnit and their coordination.</div><div>- I haven't a really good idea on this yet as it is the hardest part but, the core (or another module linked to the core) should handle the most consuming processes, for example the lookup of a big table which is needed by multiple QAUnit. So the idea would be that each QAUnit requests some data or "informations", for example objects from the "placex" table with some characteristics, and it would be optimized by the core which would anticipate and store these information for the plugged QAUnits.</div><div>- When every QAUnit has been processed, a module will be responsible to write a vector tile (or GeoJSON file) based on templates for each QAUnit (at the moment I imagine one file per rule but maybe it would need to be different for some rules).<br></div><div><br></div><div>If you could tell me what you think about what I said, it would help me to understand if I am pointing out the right issues of the project. I know it is still very abstract, but I want to design the global idea and then dive deeper into it and design a more concrete POC if I am on the right tracks.<br></div><div><br></div><div>Thanks for your time and have a nice day!</div><div><br></div><div>Regards,</div><div class="gmail_quote">Antonin<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
</blockquote></div></div>