<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">> Il giorno mer 13 mar 2019 alle ore 12:16 Tom Pfeifer <<a href="mailto:t.pfeifer@computer.org">t.pfeifer@computer.org</a>> ha scritto:<br><br><div>> I think you misunderstand. OSM is based on locally sourced, handcrafted data. That creates the high quality<br><br></div><div>Have youi ever seen hot tasks results? Huge building polys, mixed misalignments, nonxistent tags... lots of poor quality stuff and, worst of all, everything mixed to (few) high quality surveys... but it seems they are useful...of course they are: later you can improve them.<br><br></div><div>> Import means data are copied from another database into OSM. That means, somebody else collected the data. This collector has made his own mistakes. All databases contain errors, or outdated items, even if they are labelled official, governmental etc.<br><br>The collector, whoever he is, is not error free (he is human). OSM mappers are humans.</div><div><br>The 53 POIs were not simply copied: they were geocoded, (possibly, tag mapped (if this ML gather some verdicts), location checked, conflated. If you write "Import means data are copied from another database into OSM", you are saying mine is not an import. Hence I think we lack a proper, better import definition, rather then the extremely generic version updated yesterday.</div><div> <br>> IIRC the dataset you are using is several years old, last updated 2017. The items in your Umap do<br></div><div>> not say when the database entry was last checked.<br>> Thus when copying these data into OSM, they appear as freshly updated, March 2019, although the<br></div><div>> information is much older and the hotel might have closed or changed ownership/pet policies/wifi in<br>> 2018.</div><div><br></div><div>Again, "freshly" word is subjectiive. Is a 2 y/o address "fresh"? Is a 3 mo old payment method "fresh"?Probably you are right, there could be some hotel diisused, less likely dismantled, several may have canceled visa payments,,,but I think that no data in worse.</div><div><br></div><div>In sept 2015, in the same region, an import was performed involving >400k address nodes. Same hotel source, same method: dataset built collecting gathered municipality surveys; data published in may 2014, survey dates unknown. Until today nobody complained about that import, even if some addresses were void, even if some we discovered be replaced. AFAIK those addresses are anyway in use and are a good base for geocoding: should we had abort that import?</div><div><br></div><div>> Thus your task is to discuss with the Italian community if your import, i.e. copying the other data,<br></div><div>> improves or decreases the OSM data quality. The changeset size is less important, though I would<br>> prefer an community-approved import to be traceable in not too many changesets.<br><br></div><div>Due to the nature of the umap editing, this "import" couldn't be performed in one shot. neither uploaded by a dedicated account. What I was aiming, when I started asking suggestions n this ML, was to set a tagging plan for a commnity based, umap supported "import". If this doesn't fit anymore the official import definition, let's forget about it.<br><br>Sincerely, thank for your feedback. <br><br></div></div></div></div></div></div>