JOSM is built with JAVA. Everything on the computer is scripts. But if the data points that end up in OSM come from people taking pictures of trees and sharing the coordinates of them, then that isn’t a bot edit or mechanical edit as commonly defined in OSM.
Then logically speaking they should follow the import guidelines, not the Automated Edits CoC.
I’d say they should be following both!
“Automated Edits” is an umbrella term that includes imports. If you look under scope on its wiki page is says it includes “data imports, including both fully automated imports and ones where a standard editor is used;” But, yes, it is good to explicitly point out here the import guidelines as well.
" The Import Guidelines, along with the Automated Edits code of conduct, shall be followed when importing data from external sources…"
Source: Import - OpenStreetMap Wiki
I could throw that straight back at you as Why not? 
But, they’re doing an, at least, semi-automated, import, which is also (as I was also going to mention earlier but forgot) being done by an Organised Group, so lets throw those rules in as well, shall we? Organised Editing - OpenStreetMap Wiki
They basically say the same anyway: never copy from copyrighted sources without explicit permission, write documentation for the proposed edits, get community support and make very sure that there’s QA involved (and document that too).
I already answered this question:
Luckily the OEG largely overlap with the other guidelines, and apparently the DWG won’t even enforce this guideline 
Hello all. I hear you loud and clear. Will start answering questions below:
We need to see the script, and some sample output (i.e. .osm file) before this all starts.
edits_payload = f"“”
“”"
edits_headers = {
"Authorization": f"Bearer {access_token}",
"Content-Type": "text/xml"
}
edits_url = f"{sandbox_api_url}/api/0.6/node/create"
response = client.put(edits_url, data=edits_payload, headers=edits_headers)
if response.status_code == 200:
print("Tree added successfully!")
print("Response/Node ID: ", response.text)
else:
print("Failed to add tree. Status code:", response.status_code)
print("Response:", response.text)
I have not included the full script here for security measures. This is just the code to add a node/tree. We are using kmeans clustering from sklearn.cluster to add the 7 changesets each containing trees.
What validation have you done on the accuracy of the tree locations? For accuracy, we are still relying on photos. Of course, since a full picture of the tree has to be submitted to the app, inherently the GPS from the picture will be a little off from the actual tree base. However, a user does have the option to change the GPS coordinates manually on their side before submitting the data, but this is then subject to trust that the user can do this accurately. They would do this by going in the built in app, seeing on the map where the tree was recorded, and then drag that pint to where they currently are at the base of the tree. Alternatively, the user can walk to the base of the tree before submitting, and that GPS will be recorded. So hopefully that can resolve the disconnect between the tree location from photo and actual tree location.
OSM doesn’t contain images per se. → I looked at this to find it: Key:image - OpenStreetMap Wiki. Seems like the key was was never accepted, so we may not proceed with image
The app is open to all users, not necessarily only trained or vetted ones
Why 14 trees at the time? Are you going to create 14-tree groups randomly in a forest? 14 is a arbitrary number we choose because we do not want our chnagesets to expand a large area, we wanted to keep them local as per the guidelines. 14 will ensure at least some degree of locality per changes
A more in-depth explanation of the mapping/validation process seems in order. → First users take a picture of a tree. GPS is calculated. Then, the python script is run every 30 min. It takes in a picture, sees if there is already a node with that GPS in OSM. If not, it will go ahead with making the 7 change sets and adding the tree node into OSM. I want to reassure that we have made all our changes so far in the master api as per the osm guidelines. Nothing in the real map has been changed yet.
We will look into the import guidelines and try to follow those as well. Hopefully step 2 fixes the GPS concerns. I also have the ability to only allow tree submissions if the Horizontal accuracy is within X (my choice) meters. In my code, I can even make it so that trees that are close but not nessarily at the same GPS will not be added to OSM to avoid duplicates. The way we have it right now is no 2 trees at the exact same GPS can be added, but we can change it to no 2 trees within x degrees lat and long can be added.
Hope this address the concerns
Hello! I am also a team member of this application. Thanks for helping out with our concerns so far.
In the application we’re making, the approximate error while getting GPS location varies from 20 meters to around 5 meters at a time, and that error is printed on the user’s input dynamically so even if we do stand exactly by the base of the plant, we might be off by 5 meters, and the user will know of it. And since we’re giving them the allowance to re-place the pinned GPS coordinate, we are allowing the users to provide the most accurate location result.
This is the question that should be obvious to everyone. Hide this post if you will, but it’s just nuts ( and obviously not from the tree type).
That does not really sound like a good enough approach to me. Due to the height of most trees, every photo of almost every tree will be off by 5 to 20+ meters. Because it applies to almost every single tree, the GPS correction should be on a somewhat mandatory and at the same time intuitive basis.
Otherwise I can see many (especially new) users who either don’t know about the manual tree location correction or they don’t care about it and just want to take photos or think it’s too complicated.
One idea would be to ask users to take three photos: overall shape, a leaf, and a close-up of the trunk. That will help with species identification and could be a very useful database generally. You then take the co-ordinates of the bark photo as the tree location. “Enforcement”, but actually useful, too.
Proposing to fork this thread here: aside from the technical stuff, and community acceptance, can you say who is behind this project and what the motivation is? What is the useful data that will result?
Asking because I’ve had exactly this idea for a while, with zero time, money or skill to do anything about it. (Fwiw my own motivation is to map the trees in my city to promote their conservation, and track climate change.)
Hi, thanks for the response, I’m not sure I follow this though.
My other question is still to be answered:
What are you doing to conflate your data with existing OSM data?
Hello again,
To answer your questions:
To answer your main question:
With this data, we aim to map trees in onto OSM(which is not as popular as mapping buildings roads and utlities) so for this mapping is helpful for:
That sounds very hit-and-miss to me.
Did you see my suggestion that you have users take a close-up picture of the bark of the trunk to complete the workflow, and take reference coordinates from the photo of the trunk? This helps with identifying species, age and health of tree anyway, and would build a “true” GPS location* into the primary workflow.
*or at least, best possible
P.S., my OutdoorActive app shows the GPS error: I can watch it improve in real-time, so when I need a highly accurate location I can wait for it. This is immensely helpful.
Would still be good to know which organisation is behind this.
But some of my questions here have been answered elsewhere on this thread:
I agree with all of this. ^
Honestly, no answers from the project have made me confident that an automated/scripted approach is the best way to add this data. It would be much better to make the geotagged photos available to OSM so that users can manually review and add data. See https://openbenches.org/ as an example.
I think many doubts and fears have been created with this topic. Most derived from the initial post of this thread which refers to a somewhat ambiguous query to the community regarding the import of tree nodes. They have described the process that will be done for mapping trees and that it is basically similar to what other tools do for mapping specific elements. MapComplete and MapContrib do the same process described= see a tree, map it, correct the position manually using satellite images if it has been misplaced. I wonder if the same fears have been expressed before the announcement of other mapping tools coming from well-known developers in the OSM world? On the contrary, before the announcement of new OSM mapping tools by those who make a first approach to this world, it is possible to read a cascade of comments related to the fear of doing something wrong. Regarding the correct positioning of any element, it must be taken into account that it is a process that has already been overcome with the different developments implemented to do so. And mapping a tree is not the most difficult thing to do in OSM, I think that was my first edition , a tree in the middle of a meadow, I don’t remember anyone writing to me asking if the GPS was ok, what was the margin error of my device or to take a photo of the bark of the trunk to later take the coordinates of that photo and thus know if it had been well positioned.
Suggesting that 3 photos per tree be taken, I don’t think it’s the best suggestion I’ve heard, saturating the OSM database even more with unnecessary elements and that I think are not the objective of the tool moderately described on this site, the usual would be a single image well taken.
How many images can be linked per node?
One: image=* (unless you collage and edit all 3 photos to fit in one frame); plus Wikimedia and Mapillary, that would force developers to upload the images to other databases or use existing ones, a difficult process for one tree and almost impossible for thousands of trees, which would force the use of a generic photo per species and that would annul the initial thesis of the project. I think the photos are going to be used to recognize the tree species by a recognition engine, but not to be linked to the OSM node. What engine will be used? Will it be based on Google images?
My understanding is what is being proposed here is different. With MapComplete, etc. each user is logged in under their own OSM username, they are making edits while looking at existing OSM data (avoiding duplicates and topological errors such as trees on top of buildings [not entirely impossible, but unlikely]), and the resulting edits are uploaded to OSM rather quickly. My understanding of the proposal is that the edits from all of their users will be grouped together, and then uploaded at some later time by one of their employees, presumably under an OSM account dedicated to this task. Further, the user will not be directly interacting with OSM data, so cannot reasonably avoid duplicates nor topological problems, and those things will have to be dealt with through the bulk upload script.
Even if their users did a perfect job of collecting trees, the bulk upload process provides a lot of opportunities for things to go wrong, which is why we want to see the full script/program and the data.
If an individual OSM mapper uses something like MapComplete to add a few trees, the community has a chance to review before too much damage is done, and has the ability to provide feedback directly to that user through change set comments, but that would not be the case with what is being proposed here.
Hi!
So based on this whole conversation, we would like to confirm that we are using GeoTagged photos, the photo taken of the tree will have a default corresponding lat. long.
Based off our testing, the location of image is quite accurate to where it should be. We also have a manual intervention option for the users to change the location pin if it is not that accurate.
The current version of our app is saving such info onto a feature layer on a private map, just like the openbenches website, we currently are hosting trees sent in by users in a database.