In recent weeks, I’ve taken a closer look at the mapping behavior of the “defikarte.” After making some changes, I contacted them and left some comments, see OSM changeset discussions of the_third_man
Unfortunately, the operators of the defibrillator map don’t seem to be taking the comments seriously and are happily continuing to map in the same way. My specific complaints are:
• Source information: “local knowledge.” This is definitely not true.
• Obfuscation of the data origin. No information is provided about where or from whom the data comes.
• The area around the AED is not taken into account. See here: Changeset: 175959572 | OpenStreetMap . People are being sent to a location far from their actual location. Is this what saves lives???
• In some cases, the defibrillators are “updated” several days in a row. Why? Why so many updates? Why isn’t the data collected properly just once?
Conclusion:
I propose that the defibrillator map project be suspended immediately until proper quality assurance has been demonstrated.
Two years ago, this was already pointed out:
“Isn’t it a bit dangerous when people simply place a node in OSM based on a text description, and then the defibrillator turns out to be somewhere completely different?”
I will, in the future, delete/revert any obviously incorrectly tagged AEDs without further ado.
As far as I understand, the operators of the “defikarte” do not map anything themselves, but instead it is is the users of the app/website that contribute to OSM via the “proxy” of the defikarte user? And the app/website makes the assumption that whoever uses it has local knowledge? But I might be wrong about this. Certainly the changeset discussion Changeset: 175959572 | OpenStreetMap that you pointed to doesn’t sound like anyone had local knowledge but then it wasn’t claimed either?
Any “proxy editing” that takes place should certainly be looked at in detail, especially with regards to potential copyright/vandalism issues. It is important for OSM to be able to contact the person who has contributed the data in case of questions.
The AED where you said “access=no” was correct had been mapped with a “description” tag of “accessible 24/7” from day one; clearly that is a contradiction to “access=no”. Do you have actual local knowledge about that particular AED? What use is an “access=no” AED in OSM anyway?
Your complaints about “many updates in one day” and “lack of quality assurance” are ones I cannot take seriously because that is true for OSM as a whole - lots of things are edited more than once in a day (by the same person or different persons) and QA only happens on a volunteer basis. So in that regard these AED edits are not different from how everything else in OSM works.
The AED where you said “access=no” was correct had been mapped with a “description” tag of “accessible 24/7” from day one; clearly that is a contradiction to “access=no”. Do you have actual local knowledge about that particular AED? What use is an “access=no” AED in OSM anyway?
The building in question is a volunteer fire station. It’s only staffed at indefinite times—unlike a professional fire station.
Here, the 24/7 and the reference to “indoor=yes” suggest that the AED is accessible at all times within the building. But is it really, or is the building mostly locked? You don’t need to know the layout to understand this; you can figure it out by thinking.
The useful thing would be to describe the access authorization as a whole, as it’s stated in the wiki. The definition there is very clear and essentially describes the (building) access rights very well.
So, knowingly and/or intentionally posting false/incomplete emergency tagging is allowed? Or am I reading this as resignation in the face of the sheer volume of data that should/must be carefully validated, but isn’t? OSM is a community project. At least, that’s how it comes across. It’s regrettable.
Does anyone really just enter whatever they want? We want to save lives, right? Does the database belong to the “defikarte”?
Furthermore, I would appreciate it if the points I raised—all of them—were addressed.
As discussed in the changeset comments, we are happy to make adjustments to improve quality. This has been done several times in the past, as @habi mentioned.
But at the moment, it’s just a changeset finger-pointing exercise and difficult for us to track each one individually.
I have already explained this to you in the comments. Our web application only maps defibrillators, which means we cannot monitor the surrounding area to see if there really is a house there and, if so, offer the user the option of mapping it.
In my opinion, “local_knowledge” is correct, as it is created by users who are on site or have knowledge. For example, a municipality that wants to put its devices on the map.
We cannot require all users to create accounts, as this would prevent the devices from being added to the map and thus prevent even fewer lives from being saved. We operate the map precisely because otherwise these devices would not be added to the map. We are aware that not everything is always 100% perfect and we fix all errors wherever possible. But if you see that the data is improving on its own, I hope you won’t want to shut down the project right away.
Nothing against you, but I find this kind of behavior a bit off-putting; there has been a certain aggression from the beginning. What bothers you about the project?
We are in close contact with experienced mappers and the Swiss OSM community and want to do a really good job. However, a certain level of friendliness is expected here, especially from new mappers.
I have no stake at all related to the Defikarte. I am interested in the best data possible in OpenStreetMap, I edited a lot of Defibrillator to improve data quality: Automated edits/Habi - OpenStreetMap Wiki
Finger pointing doesn’t help, ideas on how to address inconsistency and problems does.
The data from the defikarte App is entered by (anonymous) volunteers, which can enter false data. This is unfortunately a fact.
We could collect the reporter’s email address using our form and store it with us or, if necessary, write it in the changeset if that would help? However, we want to communicate this clearly to the user.
I think that if your users have a very limited range of options - perhaps only marking an existing amenity as functional or not but not adding new amenities or moving/removing existing ones - then “anonymous” proxy editing can be an option (but even then it might be that someone in OSM wanted to ask a question of such a mapper).
As soon as there’s a potential for larger scale editing - which might also take the form of vandalism, unwanted automated edits or even copyright infringement - then proxy editing should be avoided, since OSM might have to remove all edits by a certain user in such cases, and this would then lump together good and bad proxy edits because they are all made with the same OSM account.
Also historically when OSM has been approached by app developers about such “proxy editing” one of our main reasons for saying no was that we wanted contributors to know that they were contributing to OSM, and we hoped to make these people part of our community rather than having them shielded behind an app and its operator.
I understand your point of view and your input, which I greatly appreciate. Our project thrives on enabling AED reporting with relatively few obstacles. If everyone had to create an OSM account first, we would not have nearly as much data and the quality across OSM would be much poorer. I would argue that, overall, the data quality is high despite the proxy mapping, and where necessary, we make a conscious effort to delete the data. If we cannot verify something, we would rather delete the data to be on the safe side. We are available as a point of contact for everyone and take care of things.
However, if it were important for any reason that every user had to have an account on OSM, then OSM would not be the right place for our project, which would be very unfortunate and a great pity. But I have always been convinced that we do more good than harm to the community.
… but given that this thread exists, that I find very hard to believe. At best, clearly you have more work to do to persuade people of that.
People who have been involved with OSM over the years have seen numerous “proxy mapping” projects come and go. Most have failed, because the people behind them didn’t realise how much work is involved.
Other projects (and “StreetComplete” is just one example here) have instead looked at how to make non-proxy signup easy, and are still around.
To put it into perspective, yes. In any other OSM editor I can enter whatever I want, emergency-related or not. In apps like EveryDoor or StreetComplete I can add AEDs with conflicting tags and the data goes live without a second check.
For me it’s a question of percentages. How many percent of AEDs are wrong? Are 10,000 of them ok and the_third_man just found the 3 bad ones? Or are 10 % bad?
In my opinion OSM should operate under a model of gradual improvement. Entering an AED in a rough position without access tags is better than not having it at all. By showing it in maps and apps, and by asking about details in StreetComplete, we get more eyes on the data and mistakes will be fixed.
OSM contains lots of bad data that might have consequences in the real world. Emergency services not finding a person in need because the address or the access road is not mapped. Hiking routes taking inexperienced hikers into dangerous terrain. Shops losing business because their data is not up to date. The QA tools are full of issues. None of this is a reason to expect 100 % correct data from mappers or apps. Instead, we rely on gradually fixing it.
Publicly posting email addresses in the changeset is not a good idea. The best way to handle this would be to
Provide a way for users to make the edits with their own OSM account / promote creating OSM accounts
Store contact information (/email addresses) internally and forward comments on the changesets to the reporters. That only solves the problem for one way though, reporters will still only be able to reply if they have an OSM account.
The problem or task described here doesn’t just affect OSM. Every type of database has this issue. If the data from the @defikarte is to be valid, it must be verified before being entered.
Saying afterwards, “Oh yeah, sorry, that was bad,” leaves a bad taste in the mouth.
Why should the entire community have to go to the trouble of fulfilling your task?
Please also consider this: There are other people who can and want to analyze and use the data. They then refer to the volunteer project OSM and find errors. What’s the state of the OSM world then?
Emergency data is being collected here. In my opinion, the security level should be 99.9999% for us as a community to appear credible. The data I’ve looked at shows doubts at 10-15%.
I just don’t see what your issue is, if you know an AED location to be wrong, fix it, -that’s the principle of OSM- not lofty quality goals that literally are not and can’t met by anybody (and anybody literally means anybody including swisstopo, emergency services and so on).