Hello.
I was preparing a second block to address this topic but you have described and summarized it better than what I had prepared, in all the conversation of this topic it was not clear correctly how to enter data into OSM, except for a reference to the script.
The method of creating OSM data (collection of data from different users to be injected into OSM) has already been clarified, new questions open=
What would be the verification and validation method before uploading data to OSM?
How to verify that the data is not already present in OSM?
How to avoid duplication of data?
I live in a medium-sized city (500,000 inhabitants) and the issue of trees caught my attention, the municipal administration makes certain data of public interest available to the general public. I got the database of all the trees registered in the city during the last 2 years.
This I face a number of problems already expressed in my previous questions. What bothered me the most is that the duplicate validation process became quite cumbersome and complicated, And this was only the first step focused on the geographical position, to which was added the verification of TAG’s related to the species of each tree. And the questions keep growing=
Who does the verifications and validations knows about labeling of tree species in OSM?
Does this person have enough experience to determine by means of a photograph if the labeled species is correct or, on the contrary, it must be corrected?
When reading “worldwide” in the title of this thread I imagine that an infrastructure has been created corresponding to what is intended to be done= this would be both the mapping tools and the validation and verification tools, training of a work team that corresponds to the challenge being addressed, …
I hope that this challenge will be addressed responsibly.
I wasn’t proposing those images go into the OSM database: rvaisnavi said the aim is to track ecological changes, as well as get to know tree locations, and as you say, the photos will presumably be processed somewhere else. If you want to know tree health, a distant shot is not that helpful.
Even if the aim were just to locate the tree, then a “useless” photo up close gives a silent GPS fix on the trunk: it works with the grain of human behaviour because it asks a user to do something intuitive that they set out to do anyway.
I don’t think we’ve been told how expert the users are, but I’ve inferred they’re novice (hence a hand-held app). But I think we still don’t know which organisation is behind the project, so maybe I have that wrong. @rvaishnavi ?
But it would be taking the position of who took the photo, but not the position of the tree. It must be taken into account that there are hundreds of data around and that this data must be preserved so that simply because of a position error a tree is not placed in the middle of an highway or on the roof of a house I read earlier that the position will be corrected manually but here you insist again that the exif data of the photos will be used mostly.
Personally I would not recommend using the exif data of the photos, to photograph a tree correctly the user will be an average of 5 meters away from the tree.
I suggested they take a close-up photo of the trunk [edit: of the bark of the trunk]. That helps enormously with identification, and it puts the user in the same place as the tree.
Interesting on the limitations of EXIF - or did you mean the limitation is that (to correctly cover the tree) the person will be standing at least 5m from it?
Hello everyone, really do appreciate all the feedback and advice that we are getting from the community to help us make our open science contributions more in line of the standards of OSM.
To answer the common questions, we’re getting:
The purpose of this application is for usage by the environmental enthusiasts to map the trees, to help report on the ecological conditions of an area. So similar to how OSM mapathons happen, we (our organization) too plan on hosting a mapathon to get people to enthusiastically and easily map trees in their surroundings.
We are not zooming in for any of the photos, in fact, while giving instructions for better photo quality of the plant, we urge users not to use the zoom function on their phone cameras.
Reiterating my college: we 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 necessarily 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 (which we plan on doing soon, based off the responses we got from this community today)
We also received a suggestion from the talk mailing list, to keep a buffer of 49 feet from existing trees in OSM to avoid duplicates. We will look into that too.
We’re using a citizen science project - https://identify.plantnet.org/ - to help with the plant identification part. They have a state of the art accuracy approximately 90% accuracy for classifying plants based of plant images alone.
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, where users can see the point pinned on an Imagery Basemap before submitting the geotagged photo. In this way, it is as easy as pinning your pick-up location on Uber, thus making it very simple for the user to move the point to a real existing tree on the Imagery Basemap.
As for the idea of taking an image of the bark of the tree to get more accurate GPS results like @eteb3 suggested, our app only takes in ONE full picture of a plant for every submission.
Also just wanted to follow up on my colleague’s message. We can turn the verification process on by using the following tag for our changset: review_requested=yes
Therefore, until we can ensure a verification process in our own team, we will keep this tag on. We understand OSM users care about the accuracy of their data. As for our organization, we are associated with the FGDC or Federal Geographic Data Committee.
They do it mainly by caring about their fellow contributors being accurate. The “review requested” flag is not intended to ask other contributors to correct low quality contributions but to ask feedback and help from confirmed contributors so that the next time quality will be better.
In your case, as we cannot contact your users, it is your job to ensure decent quality of their contributions by guiding them, verifying their contributions and providing feedback to them.
Anyway, there will be changeset comments from the OSM community and you should react within reasonable time and in a competent way if you don’t want to loose confidence of the community. This requires probably that you contact your users to get “on the ground” information on controversial contributions. I hope you took into account the effort needed for all of this.
I can’t speak authoritatively about this subject (I’m sure someone who can will be here soon), but this doesn’t feel appropriate for an automated edit where we do not know the data’s origin. The review should happen before the data is uploaded to OSM.
If I am understanding correctly, the tag review_requested is to get feedback. So, if all of our changesets turn this on, then we (the app creators) have to manually respond to the comments posted by the larger OSM community about their concern on the automated changesets. Some of these concerns will require us to get in contact with the users who submitted the tree data in the first place. Is that right?
app uses the GPS position to open a sat image (prefsrrably one that has been shown to be somewhat well aligned in the area). Then the user has to manually adjust the marker.
you might still have an error if the trunk base and the crown are shifted but much less than just GPS from photo. And of course sat image alignment is important as it is for all editor uses
The review_requested is just a flag on the changeset. Your changes still get into the database immediately. I just raises awareness for volunteers who wanna help out with difficult changes or new people being unsure of their changes.
review_requested on every of your changeset would be waaaay too much for volunteers to handle. But people will probably still have an eye on your automated changes and you’ll have to respond to questions and changeset comments that come up
Ok. So if we do not use the review_requested flag on each of our changesets, we are still thinking of other ways to verify. We were mostly relying on volunteers who have the ability to review help us in this process. We were thinking of having users go into OSM and see if their tree was mapped accordingly once they have the changeset number and node number. Are there any other ways to ensure proper verification, as we have not created an internal team designated to that task?
We are exactly following the stepped approach mentioned. I might have confused you with saying Imagery Base map, but that means a satellite Imagery map being used as the base map, and the pins, i.e. the markers are moved around to change the location to exactly where the point occurred.
Can you say exactly what you mean here? If you mean go to openstreetmap.org to check, you will immediately get users tell you their tree “isn’t on the map”. This is because map tiles presented there take a while to update: see here.
I’m keen to be as positive as possible here: we need to make editing the map easy, and the community needs to be an open one.
At the same time, if the above is what you meant, the tile refresh issue is very, very basic OSM knowledge: it’s most novice users’ first question. I’m wondering if you would all benefit from several weeks editing the map yourselves, so you get a sense of how it works? OSM appears to be a major pillar of the project, and your profiles appear not to show much experience (I may be missing something, of course).
My question for the leader of this project is why this is not the case. As @rainerU said earlier, OSM users are not here to QA a project funded by a US government department.
You can see on this thread the level of commitment to helping you get it right, and my experience suggests you can expect the same level of support going forward if you proceed thoughtfully and carefully. But the fastest way to rile the community is to encourage a lot of people who don’t know what they’re doing to make a lot of low-quality edits.
My view, as a mapper all too aware of my own limitations, is that you really should not roll out this project before running it on a small scale under close scrutiny. You should validate the initial edits yourselves, and seek the views of the community on the quality of your validation. Apart from anything else, this would help build confidence in the project among the community whom you hope will support it.
Getting trees in the map is a great idea. Like all great ideas it’s the execution that counts!
Yes, tile refresh is a issue for sure that would need to be solve in some way.
However sending an app user a message to see the results of their work a few days later is a good idea to keep more contributors, and not only trees.
Would it show the 1 tree that that particular user has added, or would it show the Changeset with 14 trees added? From what’s been said about the planned upload process, I’m thinking the batch of 14 trees?
& will those trees be in “reasonably” close proximity, or could that one CS span worldwide?
One thing that hasn’t been touched upon yet is the “[plantnet] to help with the plant identification part” thing. What does that mean exactly? Does it mean “Human provides the tree location, plantnet tags the species afterwards?” or does it mean that the users get suggestions from plantnet to choose from? What happens if they are unsure about the suggestions? Will there only be a tree node with no species tagged, or a tree node with an unchecked machine guess added? 90% accuracy doesn’t seem all that good, that’s wrong data for 1 in 10 objects!