OnWheels app (was: Create changeset API)

Hi everyone, sorry for the inconvenience with our On Wheels app. I have resolved all the issues in Maasmechelen. All missing deleted data should be back now.

joost_schouppe · 2024-04-20T11:12:48.390Z

Ik heb met Robin (de opdrachtgever voor het ontwikkelen van de OnWheels app). Normaal gezien kunnen zijn ontwikkelaars de problemen oplossen binnen enkele weken. Voorlopig het volgende:

Midgard heeft eerder al een heel krachtig script ontwikkeld om de gekende fouten (vooral verwijderen van tags) te corrigeren, en te rapporteren over de gevallen die best manueel moeten nagekeken worden (i.e. alle nieuwe punten, want er worden vaak dubbels gemaakt). Je kan het script hier in actie zien: Changeset: 150209690 | OpenStreetMap
Midgard gaat in overleg met Robin dat script een aantal keer draaien, Robin zal dan alle speciale gevallen die het script identificeert nog nakijken.
er zijn nog enkele teambuildings gepland de komende weken, waarbij er telkens 10-20 mensen aan de slag gaan (kleiner dan in Halle dus). Robin overlegt met Midgard om telkens snel na zo’n activiteit het script te runnen

Met andere woorden:

over enkele weken evalueren we opnieuw waar de app staat
de gekende fouten gaan snel hersteld worden
het is niet nodig om fouten die door de app gemaakt worden (te herkennen aan changesets zonder beschrijving of created_by tag) te corrigeren, aangezien we deze geautomatiseerd fixen

De app gebruikers kunnen niets doen aan het gebrek aan goede beschrijving van de changeset of aan de tag deletions. Het heeft dus geen zin hen hier op aan te spreken; als je hen toch iets wil duidelijk maken, hou er dan rekening mee dat ze heel weinig achtergrondkennis over OSM hebben.

Robin_On_Wheels · 2024-04-23T15:15:56.672Z

Heel wat mensen die mee deden aan de teambuilding kregen zeer ongepaste boze mailtjes van bxl-forever. Nogthans hebben we dit op voorhand uitgelegd via deze post en ook via een direct message vandaag. We werken aan een fix en gaan er ook voor zorgen dat er geen data verloren gaat. Ook merkte ik op dat al onze data in Brussel uit de grote import verdwenen is. Hopelijk kunnen we in de toekomst beter met elkaar communiceren.

Thibaultmol · 2024-05-14T12:07:07.674Z

Nog iets wat misgelopen is:

Er zijn nu 7 nodes in belgie waarbij een post_box (niet een kantoor maar een brievenbus) toegankelijkheid data heeft. inclusief dat er bij deze brievenbussen geen toegankelijke toiletten zijn. Graag fixen en checken of dit niet meer kan gebeuren.

overpass-turbo.eu

overpass turbo

A web based data mining tool for OpenStreetMap which runs any kind of Overpass API query and shows the results on an interactive map.

Was waarschijnlijk bedoelt voor postkantoren, maar is dus misgelopen

joost_schouppe · 2024-05-14T12:19:36.089Z

Goed idee om amenity=post_box uit On Wheels te verwijderen. Van wat ik heb gezien, gaan dat soort dingen toch niet zo vaak gebeuren denk ik. Je moet al een punt hebben dat er min of meer uitziet als het punt dat je wil bewerken, terwijl het correcte punt niet bestaat, niet getoond wordt (tot OnWheels ook ways laat zien…) of er naast ligt.
Bijvoorbeeld bij deze Node: 253842478 | OpenStreetMap zou ik gegokt hebben dat daar een POI ontbreekt. En effectief, niet alleen missen we een POI, maar die postbox moet ook weg.

EDIT: dit is een foutje in het import script dat OnWheels heeft gebruikt om hun bestaande data toe te voegen. Zie deze thread voor meer info over de import.

Robin_On_Wheels · 2024-05-14T19:10:00.457Z

Deze tag is ondertussen verwijderd in onze app. dit was inderdaad van 3 maand geleden. Heb ook de wheelchair data uit de node gehaald.

bxl-forever · 2024-06-18T13:39:29.255Z

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.

bxl-forever · 2024-06-18T14:24:42.082Z

Some recommendations for future changes in the app:

Do not add created_by on 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_width is incorrect and should be parking_space:width; comment should be wheelchair: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.

Robin_On_Wheels · 2024-06-18T16:44:45.690Z

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

bxl-forever · 2024-06-18T20:04:29.946Z

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.

joost_schouppe · 2024-07-06T08:24:12.736Z

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.

bxl-forever · 2024-09-17T09:36:05.901Z

@Robin_On_Wheels Could you please try to figure out why your users keep creating new nodes instead of enhancing existing data? Is it a problem with the app or a problem with users not using it correctly?

Here is an example, for this café:
It is a simple node and the accessibility tags were kept on the node itself, exactly as you required.

OpenStreetMap

Node: ‪Karsmakers‬ (‪3496856999‬)

OpenStreetMap is a map of the world, created by people like you and free to use under an open license.

Your users ignored it and created a new node next to it:

OpenStreetMap

Node: ‪Karsmakers‬ (‪12181785207‬)

OpenStreetMap is a map of the world, created by people like you and free to use under an open license.

I’ll wait a couple of days, then will try to clean up today’s changes, with a few streets now full of POI piled up on each other. If values differ (node 4874783128 vs node 12181788320 give contradicting information about whether there is a step to enter this restaurant) I will assume that the most recent data wins.

HannesVDB-icapps · 2024-09-23T17:57:56.773Z

Hi everyone,

Thank you for your valuable feedback on the OW app!

We’ll remind our users to avoid creating new locations if they already exist in the system.

In the meantime, we’re actively working on fixing all issues related to misconfigured tags or changesets in our API. Apologies for any inconvenience caused in the past. Rest assured, the latest changes will be thoroughly tested before they are deployed to production.

Regarding some issues we’ve faced in the field, especially when multiple users were interacting with the app, we encountered the following errors from OSM:

509: Bandwidth limit exceeded

We’re currently using the following endpoint:

map/?bbox

Do you have any recommendations on how to address these errors?
Also, is it possible for us to request access to the Data Working Group for further support?

Here are some resources we’ve been looking into:

Rate Limiting
Data Working Group

Lastly, could these issues be related to the fact that we use a backend that proxies all communication between our app and OSM?

Thanks in advance for your advice!

Robin_On_Wheels · 2024-09-23T18:40:52.251Z

Hi Joost, I was also thinking this would be very helpful to show our users. Is this a tag on the node or on the changeset?

joost_schouppe · 2024-09-24T07:21:39.238Z

That’s a tag on an object. See Key:check_date - OpenStreetMap Wiki for more details.