Deze tag is ondertussen verwijderd in onze app. dit was inderdaad van 3 maand geleden. Heb ook de wheelchair data uit de node gehaald.
Here is a general comment about how the OnWheels edits are currently processed.
Users who participate to team-buildings now use the teambuildingonwheels user account. As far as I can see, changesets issue the “created_by=OnWheels 0.1” text string. In general, a bunch of tags related to accessibility for people in wheelchairs are added, namely changing_table, changing_table:adult, entrance:step_count, entrance:width, wheelchair:turning_circle.
The good thing: recent edits from this account are not destructive anymore. They merely add “their” tags but will now preserve all the existing tags. 
They can either edit an existing node (Adding accessibility tags to existing node) or create a new node (Creating new node with accessibility information). The template for new nodes still has some problems, e.g it adds “created_by=On Wheels 42” on the node itself (it shouldn’t). Some presets seem to use incorrect tags.
In addition, Robin On Wheels seems to review all the edits afterwards (using iD) for some general cleanup. Again, this is good, thanks, Robin.
Once in a while there are surprises.
For instance, today a new account popped up and uploaded changes which also have “created_by=OnWheels 0.1” in the changeset tags but which produces nodes with incorrect values. Not only does the user add node for a restaurant where a way/area already exists, but it also adds new nodes when a node exists. The most surprising thing is that this node had been edited a few days ago by another OnWheels user. This is very puzzling, it would be useful to check with the users why they feel they must add missing places. Either their app does not show existing OSM data properly, or some users are using an outdated version of the app, or users lack proper training.
Some recommendations for future changes in the app:
- Do not add
created_byon new nodes. This tag is only for changesets. - Ensure that the app can deal with ways and relations, not just nodes. As long as this is lacking, users will incorrectly assume that some businesses are missing and will add duplicates to the map. (It is okay to create nodes for new objects but the minimum requirement will be that the app can show ways/relations and if possible edit them directly).
- Have someone review the tag presets you use when creating new nodes (
parking_widthis incorrect and should beparking_space:width;commentshould bewheelchair:description, and more). - Consider whether all those accessibility tags are relevant for every place.
Another problem we have is that some larger shops have several doors, where only some of them have appropriate dimensions for people in wheelchairs. That is the main reason why I prefer mapping entrance:step_count and other such geometry tags directly on entrance nodes where they exist. I understand that OnWheels would prefer querying shop nodes directly to see whether they are accessible. To achieve this we can possibly duplicate all values—but first settle a rule: if there are two doors with different dimensions, which value do we want to copy onto the shop node—but I’d rather have a more elegant solution.
Hi today we had another teambuilding and asked people to log in with our teambuilding account. Some people made their own account and used this. I will check all the data tomorrow. If you know the user name you can send this to me. I will check all the edits. We are working on an update that will not send the edit tag in the tags anymore, but on the changeset instead. We have an issue we’re the OSM data sometimes is not showing and people add then create new nodes with the app. In principle people only edit a list of existing nodes. Ones we fix this issue we shouldn’t have this problem anymore. The update will also not send the empty tags like baby changing anymore. Now I manually remove these tags afterward.
Greets Robin
Thanks for the follow-up.
For today’s teambuilding, there was one new account, Elsanightingale123, causing data corruption.
For instance here: user correctly edited Foot Locker store, and in a separate changeset created a brand new node for Foot Locker on the other side of the road, with other entrance:width values.
Same for this, the Museum of Illusions is a reputed museum, yet this user created a duplicate for it, even uploading 4 identical copies of this museum, tagging at as an “exhibition center”.
As for Hairdis, the user uploaded 7 new nodes beside the existing one, with wheelchair:turning_circle set to yes on 4 nodes and set to no on 3 nodes. Good luck to you to determine which value is the correct one.
In fact, every new node added by this user is duplicating existing POI, the map is currently very dirty in this area.
Hey, I was just thinking about longer term datamanagement. I think it would be quite useful to add a check_date:accessibility=[today] whenever the app us used. That way, longer term, the app can show places that have not been checked in a while.
Technically, it is possible to track when a tag was created, but this is quite a complicated calculation that you can’t easily do on the fly.