<div dir="ltr"><div>I'm starting to sense a trend of repetitive feedback between import discussions. I think the <a href="https://wiki.openstreetmap.org/wiki/Import/Guidelines" target="_blank">import guidelines</a> could be expanded somewhat to be more clear and concise in a few areas which are relevant to the majority of imports. Or have special guidelines relating to specific types of imports such as trees. Then this discussion would be more about that guideline and this import would follow that guideline. This would help improve consistency in OSM, and save people's time for both the import and feedback process.<br></div><div dir="auto"><div dir="auto">Here are a few things I've noticed sofar which seem to repeat in discussions:</div><div>  • putting source tags in changeset, not each object. And I think it would be nice to see changesets better documented using more from <a href="https://wiki.openstreetmap.org/wiki/Proposed_features/changeset_tags" target="_blank">Proposed features/changeset tags</a><br></div><div dir="auto">  • having a feasible plan for quality assurance. Try to analyse it more objectively, less subjectively to help achieve more conclusive community discussions on it.</div><div>    − creating and documenting tools not only to help the community but also to be transparent for critical analysis and improvement.</div><div>  • how to include the key of the imported database.</div><div>I also think discussions like this should be documented more frequently in the wiki to help people find relevant discussions. Otherwise this will get lost in time just like happens in forums unless you're lucky to find it in a search. The wiki is much more concise and well organised. My vision with OSM is to make mapping faster and easier while not compromising on the quality.</div></div><div dir="auto"><br></div><div dir="auto">For breast height diameter, I think it is relevant to include in OSM. It could be used to render relative tree sizes which could be useful landmarks (eg easy to distinguish a particularly large tree on the map).  Most trees aren't particularity fast growing so data won't go stale very fast. But might be nice to have a survey year associated with it like diameter:survey_date=. Not to mention the database could be updated in the future.</div><div dir="auto">I don't believe it should be converted into circumference since bhd is clearly a pre-existing standard. I read that people routinely measuring the circumference will use a tape with the graduations divided by π so they can read the bhd directly. And even without that, it's very easy to convert. Although keeping it most practical for mappers does make sense too. Sounds a little like the imperial vs the metric system.<br></div><div dir="auto">And if it's to be diameter, I like the idea of avoiding abbreviations if possible. How about just keeping it simple with the <a href="https://wiki.openstreetmap.org/wiki/Key:diameter" target="_blank">diameter=</a> tag to imply bhd when it is used along with natural=tree? Or maybe diameter:breast_height= if there's another conflicting diameter.<br></div><div dir="auto"><div><br></div><div>For the index of the imported database, it potentially has no meaning other than to the original database. So should it even be included? I'd say yes because it could make future import updates easier. For example maybe in second edition, tree 5001 was removed or the diameter updated. It would be much easier to match the database key. However I don't agree with <a href="https://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_the_right_tags">how it's suggested</a> in the import guidelines by inventing a new top-level tag for each import such as the example of "tiger:tlid". It would be much better to have under a documented toplevel tag so people know right away that it refers to an external ID. So for example "ref:import:cityofottawa="</div><div dir="auto">Some trees in Ottawa are physically tagged using identification tags with a number. Are those the same numbers as the database key? If so then ref= should be fine.</div><div dir="auto"><br></div><div>For the local <a href="https://wiki.openstreetmap.org/wiki/Key:species">species</a> name, it's strongly region based, likely not so much language based. And plants commonly have a one-to-many and many-to-one relationship when it comes to the common and botanical names. So some care should be taken for matching. For example <i><a href="https://en.wikipedia.org/wiki/Acer_negundo">acer negundo</a></i> is commonly known as Manitoba maple in Canada but has many other common names in English. I think it's fine to put the most common name for that region and thus the importance of including the latin name, but just to be aware of this.</div><div><br></div><div>For data quality analysis on <a href="https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Trees#Issues" target="_blank">the project page</a>:</div><div>• For conflating with existing trees, of course none of the current trees overlap with the import database. Two points (nodes) are highly unlikely to overlap. Even a separation of 1mm is not overlapping. Thus need to turn them into areas by giving them a radius and re-run that test. It its highly improbable that not a single tree in the dataset are duplicates out of the ~6000 pre-existing.</div><div>• The data was tested for intersecting with water=*. Shouldn't it be tested with natural=water ?</div><div>• What tools/scripts were used for checking overlaps? It'd be nice to have all tools referenced for transparency and helping other mappers with similar projects in the future.<br></div><div>• Some simple data visualisation and analysis like Rory McCann mentioned would be useful. Look for statistical anomalies such as outliers. eg a plot of trunk diameter and check for nonsensical data.</div><div>• In general, I think the objective should be to get overall sense of the data quality, not just using the easily detectable outliers. It's hard to achieve perfection and it will always be possible to find an error, especially in large data sets. I think better questions to ask include how reliable is the data overall, and what level of reliability is deemed acceptable to bring into OSM for the data in question? Is an error in 1 in 1000 trees acceptable or 1 in 10? After that, manually check the easily detectable outliers such as trees in water, buildings, soccer fields, etc.</div><div>  − I think one good starting point on the data quality is to check samples of the data to surveys of the area and see how well the data agrees with observations. For example the positional data could be compared it to aerial imagery. From my observations, with a small alignment of the Bing imagery, looking at about 1000 trees around the city, they all align very well with the trees in the imagery with relatively low variability. I'd say the vast majority appear within 3m of the tree. Some areas appear to have higher incidences of trees with the occasional tree clearly incorrect positioning up to 15m away in the middle of roads while other areas are consistently good which is likely due to the operator/instrumentation used in specific areas. I'd say maybe up 1 in 100 trees have poor positioning. The size of the tree canopy and shadow also seems to correlate well with the breast height diameter. Overall I'm pretty impressed with the level of data quality.</div><div><br></div><div>If it hasn't been mentioned already, it should be noted there is <a href="https://www.meetup.com/openstreetmap-ottawa/events/241142743" target="_blank">a meetup</a> planned for this Friday for this import. Incase any locals following this mailing list who are not yet aware of the meetups. Is that meetup for discussing or conducting the import?</div><div><br></div><div> - Devon</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 5, 2017 at 10:19 PM, Kyle Nuttall <span dir="ltr"><<a href="mailto:Kyle.Nuttall@hotmail.ca" target="_blank">Kyle.Nuttall@hotmail.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">
<div id="m_7940459897592176658divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir="ltr"><span class="">
<p><font size="2">><font size="2"><span style="font-size:10pt">But i understand that as Canadians you have a reputation to defend</span></font><br>
</font></p>
<p><font size="2"><br>
</font></p>
</span><p>I'm not sure what this is supposed to mean. I was in a bar with a dying phone so I made the email quick. I tried to be general by saying
<i>most</i> issues had been fixed, not <i>all </i>issues.</p>
<p><br>
</p>
<p>That said, the diameter values have been converted to circumference (in metres) and the
<i>species:en</i> tags have been 'flipped' and now read correctly (Sugar Maple vs. Maple Sugar)</p>
<p><br>
</p>
<p>That's the latest change to the data, and I'm only posting this to keep everyone informed of said changes.</p>
<p><br>
</p>
<p>Cheers,</p>
<p>Kyle<br>
</p>
</div>
</div>

<br>______________________________<wbr>_________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/imports</a><br>
<br></blockquote></div><br></div>