Create changeset API

Dag iedereen,

Voor een applicatie die we momenteel aan het bouwen zijn gebruiken wij: API v0.6 - OpenStreetMap Wiki om een nieuwe changeset aan te maken.

Deze gebruiken wij om specifieke tags via de app te laten aanpassen als het gaat om toegankelijkheid.
Echter gebruiken wij niet alle tags die terug komen van de API wat er voor lijkt te zorgen dat er data overschreven werd. Lees: data die wij niet meer terugsturen in de changeset lijken verdwenen te zijn…

Lijkt ons niet de bedoeling. Maar als ik de API documentatie lees staat hier niets over geschreven.

Voor dit endpoint: https://wiki.openstreetmap.org/wiki/API_v0.6#Update:_PUT_/api/0.6/[node|way|relation]/#id staat dit duidelijk wel vermeld…

Iemand enig idee? Mogelijks iets mis met de API of is de oplossing om toch alle tags terug mee te sturen?

Alvast bedankt!

Beste Hannes,

Blij dat u om raad vraagt.

De eerste link die u stuurt gaat over het openen van een changeset. Een changeset zelf kan tags hebben. Bij het openen van een changeset worden geen dataelementen doorgestuurd.

De tweede link gaat over het maken van een nieuwe versie van een dataelement. Ook een dataelement kan tags hebben.

Een groot probleem met uw huidige app is dat uw changesets geen tags hebben. De oplossing daarvoor is bij PUT /api/0.6/changeset/create tags die op de changeset horen, door te sturen. Bemerk dat created_by en comment verwacht worden (hoewel technisch niet vereist). Beide horen dus op changesets, niet op dataelementen.

Een voorbeeld van wat u dus kunt sturen is

PUT /api/0.6/changeset/create
<osm>
	<changeset>
		<tag k="created_by" v="OnWheels 0.1"/>
		<tag k="comment" v="Adding accessibility tags to existing restaurant"/>
	</changeset>
</osm>

wat dan een changeset-ID teruggeeft, dat u daarna gebruikt om nieuwe versies van dataelementen door te sturen via PUT /api/0.6/[node|way|relation]/#elementid, of via de modernere diff upload die toelaat nieuwe versies van meerdere elementen tegelijk door te sturen.

Alle operaties die tags doorsturen (dus ook PUT /api/0.6/changeset/#changesetid waarmee u de tags van een open changeset kunt wijzigen), moeten altijd alle tags die in de nieuwe versie moeten bestaan, doorsturen.

Hopelijk helpt dit om alles wat duidelijker te maken. Stelt u gerust nog vervolgvragen.

1 Like

@M_dgard bedankt voor de verduidelijking.
Echter enkele bijkomende vragen en bemerkingen.

Wij gebruiken volgende open source package voor de OSM API calls.

Concreet refereer ik graag even naar:

Een changeset wordt dus effectief wel aangemaakt en een upload van de changeset wordt dan gedaan zoals jij beschrijft. Of interpreteer ik het mis?

Wat ik in onze code even zal laten nakijken is dat de comment en created_by zeker worden ingevuld. Waar ik dus voor vrees en waar het eerste probleem zit.

Tweede probleem is dan inderdaad dat wij de niet geupdate velden niet meer meesturen. Maar dat is dus effectief verwacht?

Bedankt voor jullie snelle reactie trouwens!

Ideaal!

Inderdaad is het nodig om alle tags die de nieuwe versie van een object moet hebben, door te sturen. Je moet in feite de nieuwe versie van een object doorgeven, niet de “wijzigingen” eraan. Het is ook absoluut noodzakelijk om tags die de gebruiker niet wou bewerken, letterlijk terug door te geven. Bijvoorbeeld is het onder geen beding aanvaardbaar om amenity=fast_food te veranderen naar amenity=restaurant gewoon omdat jullie applicatie fast_food niet als aparte categorie beschouwt.

Als ik de code die u stuurt zo even lees, lijkt een geldig voorbeeldgebruik ervan als volgt:

uploadChangeset(
   {
      "created_by": "OnWheels 0.1",
      "comment": "Adding accessibility tags to existing restaurant"
   },
   {modify: [
      {
         "type": "node",
         "id": 123,
         "tags": {
            // Alle tags die de nieuwe versie dient te hebben hier
         },
         // Andere eigenschappen hier
      }
   ]}
)
1 Like

@M_dgard, we hebben dit op onze test omgeving aangepast en lijkt nu goed te verlopen.
Tags die voordien bestonden blijven nu bewaard.

Merci voor de input!

1 Like

Here is an observation about recent changes on the map.

User On Wheels app created 9 changesets on Feb 27.

The good thing is that those changesets now contain tags (e.g. created_by) and that they no longer erase existing tags on objects.

There have been a few concerns, though.

If I understand correctly, you are now dumping existing information from the On Wheels database to OSM. The problem is that several changesets are very large, some of them covering one-third of the country at once. Large changesets are ofted viewed as an annoyance by those who review latest changes on a given territory. Those 9 changesets modified a mere 3,991 nodes.
Since those changesets seem to be scripted—and could be filtered by min/max longitude and latitude of objects—it would be advisable to import smaller packets of data per changeset, to generate smaller bounding boxes.

1 Like

Dit is geen ramp voor een one-off, en het is nu gebeurd. Als er nog imports gebeuren, kun je er rekening mee houden. Maar dat de app het juiste doet, is nu belangrijker.

2 Likes

Hi sorry for the inconvenience. I believe we tried to import the data into smaller changesets per big city to avoid one huge changeset. In what way can we make a changeset easier to review? Per city? Several changesets per city? A max changed nodes per changeset? We have imported all our data about buildings now, but are planning to also do this for disabled parking spaces in the future. But we still have to talk to the community what the best way is. I made a OSM wikipage for our app and the tags we use and the discussions going on: https://wiki.openstreetmap.org/wiki/On_Wheels_app#On_Wheels_organisation

Hi,
This change was reported to me: OSM Deep History (in Changeset: 149856073 | OpenStreetMap)
There’s still tags being deleted by this OnWheels user!

In his most recent change, there is a created_by tag mentioning onwheels - but unfortunatemy not on the changeset but on the object!

1 Like

value in lowercase not uppercase except for proper names the first letter.
is this auto genereted by the app ?
toilets:wheelchair:accessible_via=GROUND_FLOOR

1 Like

Wheel app deleted possible other tags see
https://overpass-api.de/achavi/?changeset=150129704&relations=true

Wheel app
https://overpass-api.de/achavi/?changeset=150130294&relations=true

barrier not on highway s

https://overpass-api.de/achavi/?changeset=150130280

Brand werd verwijderd door app ?
https://overpass-api.de/achavi/?changeset=150129655&relations=true

meerdere gegevens zijn verdwenen door ?

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.

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.

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.

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.

Was waarschijnlijk bedoelt voor postkantoren, maar is dus misgelopen

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.

1 Like