Import: Trees of Yerevan Initial Baseline - General talk - OpenStreetMap Community Forum
Import: Trees of Yerevan Initial Baseline
General talk
import
import-proposal
umonkey
(Justin Forest)
April 14, 2026, 12:29pm
Hello OSM Community, I am proposing to formally document the import of the Kanach Yerevan Tree dataset, sourced from field surveys by volunteers of the Kanach Yerevan initiative.
We initially posted about our activity here, but are formally submitting this as an import to comply with the DWG guidelines for our initial baseline dataset of ~11,000 trees.
Documentation
This is the wiki page for my import:
Import/Trees of Yerevan - OpenStreetMap Wiki
This is the organized editing activity for our ongoing work:
Organised Editing/Activities/Trees of Yerevan - OpenStreetMap Wiki
License
I have checked that this data is compatible with the ODbL. The data is collected by volunteers who agree to release it into the public domain for OSM use.
Abstract
Kanach Yerevan is an urban forestry movement in Yerevan. We map urban trees to protect green areas.
Relationship:
I am a co-founder of Kanach Yerevan.
Dataset Contains:
Point data (nodes) of individual trees, including species, height, and circumference.
Size:
~11,000 trees.
Method:
We have a bidirectional sync tool that pushes verified trees from our database to OSM.
Changeset Size:
Rate-limited to a maximum of 1 changeset per hour, containing up to 100 nodes per changeset.
Conflation & Verification:
Data is manually collected in the field by volunteers. Where applicable, locations are verified against our own custom drone orthophotos, which we publish openly on OpenAerialMap. The script checks for existing nodes at the coordinates to avoid duplication.
Note on Continuous Editing:
While this import covers our existing ~11,000 trees, our ongoing weekly mapping (approx 100 trees/week) is handled under our Organized Editing Activity.
2 Likes
ivanbranco
(ivanbranco)
April 14, 2026, 1:02pm
I like the 2d circumference rendering on your website
I added a category to the import page.
I was wondering if there is a reason not to link the image directly, for example:
instead of
The linked image should depict the specific tree, the link above is used on two different trees, while
image=https://yerevan.treemaps.app/tree/149183041011585024
is used for seven different trees.
We have collected a baseline of approximately 11,000 trees which we intend to formally import/synchronize with OSM.
How the synchronization works in detail? If someone updates yerevan.treemaps.app, is OSM automatically updated, and does it work in the opposite direction as well? If not, what happens when a feature is edited in OSM with more recent or more accurate data? Is there a risk that it gets overwritten by older data from yerevan.treemaps.app, or is there some conflict resolution mechanism in place?
umonkey
(Justin Forest)
April 15, 2026, 7:46am
Thank you! Yes we can put a direct link to an image in the
image
tag. The idea was that there are many photos of a tree that come and go, and a link to the tree page gives access to all those images, while a single jpeg link doesn’t. We normally take images from different angles and distances, which also helps better identify tree position.
I had a look at the seven trees you mentioned, and their history, and they seem to come from user SMkrtich, so I don’t know how exactly this happened. Probably they just copy-pasted a node?
How the synchronization works in detail?
We have an
osm_id
and
osm_version
on our local trees. We get all trees for a specific boundary from Overpass, then update our local trees with new data if a node was changed, so our users can see the updates. New nodes we just add, no conflict resolution needed.
When pushing to OSM, we only send trees that don’t have
osm_id
, so were added on our side. After that, we assign the
osm_id
and only pull new updates from OSM, we don’t send any changes for now so there is no risk of overwriting anything.
We also have an additional step that finds seemingly duplicate trees, which are within 5 meters from each other. We then manually review and correct each case if needed.
The algorithm is described in the
OSM Integration
documentation page in our git repo, with links to the source code.