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.
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.
@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?
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
}
]}
)
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.
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.
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
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
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.