[Imports] Ottawa, Canada Tree Import

Thu Jul 6 05:14:05 UTC 2017

I'm starting to sense a trend of repetitive feedback between import
discussions. I think the import guidelines
<https://wiki.openstreetmap.org/wiki/Import/Guidelines> 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.
Here are a few things I've noticed sofar which seem to repeat in
discussions:
  • putting source tags in changeset, not each object. And I think it would
be nice to see changesets better documented using more from Proposed
features/changeset tags
<https://wiki.openstreetmap.org/wiki/Proposed_features/changeset_tags>
  • having a feasible plan for quality assurance. Try to analyse it more
objectively, less subjectively to help achieve more conclusive community
discussions on it.
    − creating and documenting tools not only to help the community but
also to be transparent for critical analysis and improvement.
  • how to include the key of the imported database.
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.

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.
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.
And if it's to be diameter, I like the idea of avoiding abbreviations if
possible. How about just keeping it simple with the diameter=
<https://wiki.openstreetmap.org/wiki/Key:diameter> tag to imply bhd when it
is used along with natural=tree? Or maybe diameter:breast_height= if
there's another conflicting diameter.

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 how it's
suggested
<https://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_the_right_tags> 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="
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.

For the local species <https://wiki.openstreetmap.org/wiki/Key:species> 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 *acer negundo <https://en.wikipedia.org/wiki/Acer_negundo>* 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.

For data quality analysis on the project page
<https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Trees#Issues>
:
• 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.
• The data was tested for intersecting with water=*. Shouldn't it be tested
with natural=water ?
• 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.
• 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.
• 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.
  − 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.

If it hasn't been mentioned already, it should be noted there is a meetup
<https://www.meetup.com/openstreetmap-ottawa/events/241142743> 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?

 - Devon

On Wed, Jul 5, 2017 at 10:19 PM, Kyle Nuttall <Kyle.Nuttall at hotmail.ca>
wrote:

> >But i understand that as Canadians you have a reputation to defend
>
>
> 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 *most*
> issues had been fixed, not *all *issues.
>
>
> That said, the diameter values have been converted to circumference (in
> metres) and the *species:en* tags have been 'flipped' and now read
> correctly (Sugar Maple vs. Maple Sugar)
>
>
> That's the latest change to the data, and I'm only posting this to keep
> everyone informed of said changes.
>
>
> Cheers,
>
> Kyle
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20170706/41d6a432/attachment.html>