OnWheels app (was: Create changeset API)

Communities België / Belgique / Belgien (Belgium)
21

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

22

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. :+1:

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. :+1:

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.

23

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.

24

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

25

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.

26

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.

27

@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.

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

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.

28

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:

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!

29

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?

30

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

31

Dag Hannes,

Een aantal zaken die men moet weten om het probleem te vinden:

  • Hoe worden data gedownload en geupload? Overpass of api osm?
  • Hoe wordt de data geuerried?
  • Downloaden we alle data terwijl we een poi uploaden?
  • Wanneer stuurt onze backend een foutmelding naar onze frontend? Het zou kunnen zijn dat er wat een delay op signaal foutmelding van api osm is en dat onze backend niet direct een signaal krijgt dat het doorgestuurd is, terwijl de locatie wel is aangepast. Misschien standard een pauze van 5 seconden inlassen op onze frontend voor je iets kan doorsturen en voor je het signaal goedkeuring of foutmelding krijgt.
  • als we een poi editen halen we dan alle data van de map box binnen en sturen we alle data terug door naar osm? Of enkel de data van de poi?
  • Halen we alle data binnen binnen de box vanaf een zoom level of ook data buiten die box?
32

@Robin_On_Wheels:

  • Voor het ophalen van de data gebruiken wij OSM
  • Voor het uploaden van de data gebruiken wij OSM
  • Voor het zoeken gebruiken wij Overpass
  • Voor we een nieuwe POI uploaden gaan we eerste de huidige tags gaan ophalen. Om zeker te zijn dat er niets verloren gaat. En wij hallen alle tags op die er zijn
  • Wij sturen de error door die we van OSM krijgen.
  • Wij sturen een bbox mee in de map api call. Dus krijgen enkel die data terug
33

Nog iets wat me opgevallen was:
onwheels acount heeft in deze changeset:

gegevens toegevoegd aan een lokale bakker maar ipv op de bakkerij is op het op de automaat van de bakker gezet.
Ik kan dit manueel aanpassen natuurlijk maar weet niet of er misschien een link ergens verkeerd zit in onwheels die moet veranderd worden voor ik het fix of zo?

34

Dag Thibault,
Dit was inderdaad niet op de juiste node, ik heb het aangepast.
Ik vermoed dat dit nog een foutje was van een tijd geleden.
De app edit enkel amenity=shop nodes en niet de vending machines.

35

Dag Hannes,

Ik vond dit artikel en link die misschien wel ons probleem kan zijn: