OnWheels app (was: Create changeset API)

CR25_4DA1 is an account associated with me. We (me and emmaus111) are testing OSM-editors in educational settings (e.g. StreetComplete, MapComplete and onWheels). The edits made with OnWheels all had issues and have been reverted.

It is also the reason I’m checking this thread again.

1 Like

Hey Robin,

Ik voel mij nogal hard aangesproken door dit zinnetje, want, laat ons eerlijk zijn, ik ben een van die devs die “zijn kop in het zand gestoken heeft” en dit volledig heeft losgelaten, zelfs als was ik bij het begin vrij hard betrokken. Meer zelfs, ik ben wat de aanstoker geweest om je naar OSM te laten overschakelen. Als maker van MapComplete heb ik bovendien bijzonder veel ervaring met het soort app die jullie willen maken.

Bij deze wil ik even mijn ervaringen en observaties delen.

Osoc

In juli 2022 maakten we, binnen de organisatie van Open Summer of Code, het MapComplete thema. Dit werd gefinancierd door BOSA, een Belgische overheid. Je uitleg en expertise over (rolstoel)toegankelijkheid waren erg interessant - het zijn lessen en inzichten die ik nog steeds vaak bovenhaal.

De studenten konden dit thema opzetten bovenop MapComplete. Dit ging relatief snel, want ik had met MapComplete al de fundamenten gelegd voor een POI-editor. Een aantal technische barrieres (inloggen, nieuwe punten toevoegen, attributen van “ways” aanpassen, achtergrondlagen, …) waren immers al weggewerkt. Bovendien was er ook erg veel OSM-expertise in het team: naast mezelf was ook Robin van der Linde er. Hij had ook het jaar ervoor al op MapComplete gewerkt en is ook vandaag nog een (sporadische) bijdrager. Zelf sta ik soms stomverbaasd te kijken naar wat voor bijzondere dingen hij met MapComplete maakt!

Ook Alexander was een bijzonder goeie student. Hoewel hij bij aanvang geen OSM-kennis had, heeft hij erg snel die kennis geabsorbeerd en was goed mee in het hele verhaal.

ICAPPS - de begindagen

Na OSOC kreeg ik te horen dat je het belangrijk vond dat de app volledig “native” ontwikkeld werd. Geen website, maar een échte Android app. Je bent dan ook in zee gegaan met een bedrijf dat veel kennis heeft hierover - ICAPPS. Eerlijk is eerlijk, ik vond het jammer want ik had met veel plezier de toepassing verder uitgewerkt. En ja, MapComplete kan altijd gebruiksvriendelijker en sneller, zeker in 2022 was het niet echt een cosmetisch ding te noemen, dus ergens snap ik je nog wel.

Eén van de OSOC-studenten (Alexander) had bovendien gesolliciteerd om bij ICAPSS stage te lopen. Kortom, ICAPPS kon gratis (!) voor enkele weken of zelfs maanden een expert in de materie in huis halen, maar dit is uiteindelijk afgesprongen langs de kant van ICAPPS - een eerste gemiste kans.

Nu, na enkele maanden kwam er de vraag om eens samen te zitten met het team van ICAPPS. Dit ging echt niet vlot. Ik had verwacht dat ze wel al ietwat hun huiswerk gedaan zouden hebben, maar dit bleek niet het geval. Ze wisten bv. niet wat een “changeset” was. Hieruit kan ik afleiden dat ze nog geen praktijkervaring hadden en nog geen andere editors (zoals iD, JOSM, StreetComplete of MapComplete) hadden getest. Lijkt me een beetje raar, want ook ik gebruik regelmatig deze (andere) tools wanneer die meer geschikt zijn dan MapComplete of uit nieuwsgierigheid om eens te zien hoe “de concurrentie” het aanpakt.

Een andere afleiding die ik hieruit maak is dat ze toen ook nog niet hadden onderzocht hoe de API werkt - iets wat nochtans best goed beschreven is op de wiki - een beschrijving die mij in staat stelde om een eerste versie van MapComplete op poten te zetten.

Een tweede voorval dat me is bijgebleven was dat, om addressen aan te vullen, ze “wel gebruik zouden maken van de Android/Google Play API’s voor reverse geocoding” - iets wat vanuit copyright/legaal perspectief helemaal niet mag. Gelukkig hebben jullie toen wel geluisterd, maar dit toont toch een ernstige nonchalence naar licenties en wetgeving toe.

Als je er dan bij optelt dat ik die kennis heb én ik er vrijwillig zat, terwijl dat zij al een paar maand betaald werden voor deze job en er nog niet veel van kenden, dan gaf mij dit een raar gevoel en niet echt zin of vertrouwen om hier nog meer tijd in steken. Ik was wat bang voor een bodemloos gat.

Alle problemen in een notendop

Er zijn immers een groot aantal keuzes en fouten geweest waar jullie op zijn aangesproken. Soms door mij persoonlijk, soms door de community. Enkel voorbeelden:

  • Het werken met één gedeelde account voor alle onWheels gebruikers. Dit is pas veranderd nadat we duidelijk hadden gemaakt dat deze account vroeg of laat geblokkeerd zou worden.
  • Het werken met nog een eigen backend wat alles complexer maakt
  • Géén relevante metadata toevoegen aan de changesets en…
  • …wanneer daar na maanden eindelijk verandering in komt, wordt deze metadata toegevoegd aan de OSM-objecten zélf ipv de changeset …
  • … wat ook weer maanden aansleept
  • Relevante attributen van objecten verwijderen
  • Irrelevante attributen toevoegen aan OSM-objecten
  • Duplicaten toevoegen
  • Een gebruikersinterface die uitnodigd om data fout in te geven, zoals deze leisure=frituur
  • Nu het verwarren van way-ids en node-ids…
  • … en het toevoegen van duplicate data omdat “ways” (vroeger) niet getoond werden.

Wanneer ik MapComplete ontwikkel, denk ik altijd na over hoe ik fouten en inconsistente data kan vermijden. Op de tweede plaats komt gebruikersgemak en een heldere interface, want dit gaat hand in hand met het vermijden van foute data. En ook ik heb daar soms in gefaald. Soms door technische bugs, soms door een onduidelijke interface. Soms had ik het zelf gezien, maar nog vaker kwamen mensen klagen tegen me waarna ik deze fouten zo snel mogelijk probeer recht te zetten (eerst door MC te fixen, dan door de data wereldwijd te gaan corrigeren).

Deze attitude zie ik helemaal niet bij ICAPPS. Datafouten slepen maanden aan en communicatie duurt lang. Wanneer deze fouten gefixed worden, komen er vaak andere bugs in de plaats. Ook dit wekt natuurlijk geen vertrouwen.

Waarom zou ik, als expert, de moeite doen om feedback te geven als het eerst al heel veel moeite kost om jullie ervan te overtuigen dat jullie op het verkeerde spoor zitten en als het daarna nog maanden duurt voordat het eindelijk misschien gefixed raakt? Meer zelfs, het is bijzonder pijnlijk om de OnWheels app deze beginnersfouten te zien maken na bijna 3 jaar (!) ontwikkeling. Nochtans is de nodige documentatie gewoon op de wiki te vinden. Ook ChatGPT heeft een goeie kennis over de werking.

En deze reputatie snelt jullie natuurlijk ook vooruit, want ook voor andere experts is het dus weinig aantrekkelijk om in jullie verhaal in te stappen.

Communicatie: tagging uitwerken?

OpenStreetMap is een gemeenschappelijk project. We hebben ondertussen meer dan 1 miljoen accounts die al een wijziging hebben gemaakt. Om zo’n project te structureren, is goede communicatie vitaal - zeker als het aankomt op de attributen (tags) die we gebruiken in de databank.

Hier knelt ook nog een schoentje. OnWheels heeft een aantal tags geintroduceerd zonder voorafgaand overleg. Ook hier hebben jullie heel wat kansen laten liggen. Een discussieronde over de tagging gaat vaak verborgen gebreken aan de attributen bovenhalen, maar gaat ook de bekendheid van de tags verbeteren en voor een goede, sluitende definitie zorgen. Zo kunnen ook andere editeer-programmas die makkelijk adopteren.

En ja, deze discussieronde is bijzonder tijdsintensief - dat weet ik. Ik heb er al een aantal met success doorlopen, maar ik heb er al evenveel gefaald. En ook ik heb er me al schuldig aan gemaakt om een paar kleine tags te introduceren zonder dit eerst (uitgebreid) te overleggen - al hou ik steeds een vinger aan de pols. Wanneer blijkt dat tagging niet (meer) goed is, pas ik die dan ook vlot aan.

Communicatie: algemeen

Maar los van de taggingdiscussies is er erg weinig communicatie met het ICAPPS-team. Een publieke issue tracker waar de problemen zichtbaar op zouden zijn en waar we direct bugs kunnen melden zou de community erg appreciëren. De volledige app open-source beschikbaar maken zou ook wat meer vertrouwen kunnen wekken - al is dat wellicht een brug te ver op dit moment.

Maar ook het feit dat het forum-account van @HannesVDB-icapps al een jaar niet actief is geweest hier en zich niet in de discussies mengt vinden we een beetje raar.

Een andere korte communicatielijn is de belgische chat op Matrix: https://app.element.io/#/room/#osmbe:matrix.org. Als ontwikkelaars daar af en toe zouden langslopen, kunnen we niet alleen bugs melden, maar ook advies geven of hun vragen beantwoorden (al moeten ze natuurlijk eerst zelf in de wiki kijken)

Als mensen van het ICAPPS-team af en toe zouden langskomen bij de OSM-meetups zou dit ook al bijzonder veel verhelpen. Dat is immers een moment waarop alle technische expertise samenzit én met veel plezier je verder zal helpen, en bovendien ook nog gratis! En dan hebben we het ook nog niet over de informele waarde om te netwerken, een vinger aan de pols te houden, te horen welke technische innovatie er beschikbaar is, …

We moeten elkaar kunnen vertrouwen om samen te kunnen werken, en dat is er op dit moment gewoon niet. Wellicht projecteer ik mijn gevoelens, maar soms lijkt het me dat ook van jullie kant weinig vertrouwen is in ons advies; vaak voelt het alsof ons advies genegeerd wordt. Ik krijg de indruk dat er vaak de -op het eerste zicht- makkelijkere oplossing gekozen wordt (hoewel wij weten dat deze niet werkt) en pas bijsturen nadat jullie de tekortkomingen zelf merken.

De weg vooruit

Tja, hoe gaan we dit allemaal fixen?

Zelf denk ik dat meer transparantie en communicatie met het ICAPPS-team nodig is. Dat kost inderdaad tijd, maar moet je zien als een investering. Dit zal zichzelf op termijn terugbetalen.
Het ICAPPS-team zit nu op een eiland, waar de enige brug naar de OSM-community jij bent, @Robin_On_Wheels . Dit is te weinig.

Concreet zou het al veel helpen als de ICAPPS mensen af en toe langskomen op de meetup (of wie weet, mss zélf eens eentje hosten?) .

Als een ICAPPS-ontwikkelaars in de de matrix-chat zouden rondhangen, zou dit ook een waardevolle, korte communicatielijn kunnen zijn.

De issue tracker publiek maken (én toelaten dat iedereen issues maakt) zou ook al veel helpen. Overwegen om alles open source te maken zou ook een mooie stap zijn (of duidelijk uitleggen waarom jullie dit niet zouden doen)

Tenslotte: wanneer er een ernstige bug gevonden wordt (eentje die data kapotmaakt) moet dit ook sneller gefixed worden (liefst binnen 48u, als is binnen een werkweek ook acceptabel).

Laat het aub niet op het punt komen dat we de DWG moeten vragen om de volledige app te blokkeren.

.

.

Bon, bij deze hele boterham ook uitgeschreven. Neem even je tijd ervoor om deze te verwerken, ik vermoed dat mijn bericht heel wat emoties gaat opwekken; ik hoop dat je me dit niet kwalijk neemt.

8 Likes

Dag Pieter, en anderen

Ik lees deze thread wel en volg deze ook op.
Eerst en vooral maar ook nogmaals (mijn) excuses voor het ongemak.

Ik moet echter wel zeggen dat ik mij aangevallen voel door jouw “rant”. Ik begrijp zeker je reactie, maar jullie spelen nu heel hard op de man. En zijn nu niet altijd even constructief.

Daarom ook bedankt @joost_schouppe om de voorbeelden aan te halen. En mee te debuggen. Het probleem ligt momenteel bij een edit flow van onze backend die niet compatibel is met de bestaande versie van de app.
Deze zijn we momenteel aan het oplossen.

Daarbij wil ik graag even kaderen:

Wij werken momenteel met een BFF tussen onze app en OSM gezien er nog een aantal andere functionaliteiten in de app zitten die geen plek hebben momenteel bij OSM.

De backend developer die de eerste implementatie gedaan heeft van onze backend werkt echter niet meer voor ons. Waardoor wij (lees ik) nu alle fouten van het verleden proberen recht te zetten. Ikzelf ben geen OSM expert dat geef ik eerlijk toe.
Daarom dat ik ook niet zomaar iets doe op productie en alles probeer door te testen op de test omgeving. Meer zelfs ik doe deze zaken nu vooral in mijn vrije tijd om er voor te zorgen dat dit opgelost geraakt. Waardoor het dus ja, langer duurt!

Tot slot proberen we elk stuk van feedback te verwerken die de community ons geeft. Het issue dat gisteren gemeld werd hebben we gisterenavond nog teruggedraaid.

1 Like

Dag Pieter,

Bedankt voor je openhartig bericht en het delen van jou ervaring. Mijn opmerking van kop in het zand steken was zeker geen verwijt naar jou of de andere mensen toe. Jij bent inderdaad de grootste reden waarom we de stap naar OSM hebben durven doen. Zeker onze samenwerking tijdens OSOC was ook de druppel en was echt een heel leerrijke ervaring voor mij. Ik ben ook zeker een fan van MapComplete en verwijs ook vaak mensen door die meer willen weten over OSM. Je mag er ook zeker trots op zijn. Robin en Alexander waren ook echt top studenten. Ik vond het ook heel jammer dat Alexander niet bij Icapps kon werken, ik had dit ook van onze kant gesteund om dan aan ons project mee te werken met de OSM kennis die hij had.

Ik had zeker graag verder met jou samengewerkt en we hebben hier intern ook lange discussies gehad. Er waren voor mijn tijd bij On Wheels ook al gesprekken gebeurd om over te stappen naar OSM en dan was onze raad van bestuur nog niet overtuigd. Ik heb er dan ook voor gevochten om nu toch die overstap te doen. Nu hebben wij ook een grote discussie gehad van hoe onze nieuwe app er uit moest zien en moest werken. Zowel intern als met onze gebruikers. De keuze voor een eigen native app kwam hieruit. Dus dan viel MapComplete wat uit te boot, wat ik ook jammer vond. Ik beslis nu eenmaal ook niet alle zaken alleen en soms moet ik ook de richting volgen die beslist is intern. We hadden echt heel weinig budget voor wat we wilden doen met de app. Er zijn ook heel veel zaken die belangrijk zijn voor ons en onze gebruikers die niets te maken hebben met OSM. We kwamen uiteindelijk bij Icapps terecht die ons project ook wou ondersteunen binnen het budget.

Het is inderdaad zo dat de OSM kennis bij Icapps het grootste struikelblok is geweest. Wij hebben hen heel wat info enzo doorgegeven om te bekijken, maar dit werd wel onderzocht, maar ook onderschat. En Icapps is ook een heel groot bedrijf, waar mensen komen en gaan. Er zijn dan ook tijdens de development wat verschuivingen gebeurd, waardoor de mensen die al kennis van OSM hadden opgebouwd op een ander project moesten werken. Het bleek al snel dat binnen ons fixed price contract er heel wat meer uren moesten geklopt worden dan verwacht binnen Icapps. Ik denk dat ze normaal gezien ook niet veel werken met een fixed price, dus was ook een geste naar ons toe. Ook de uren voor de andere functies van de app bleken wat onderschat. Het was dan ook niet altijd evident voor bijv Hannes om de extra uren te verantwoorden en ook andere projecten te moeten doen. Gelukkig hebben we nu wel Hannes die naast zijn uren ons helpt om de afgesproken functies van de app af te werken en te helpen met de OSM zaken. Daarom duurde het ook vaak langer om zaken te fixen.

Tijdens het proces en het verdiepen in OSM hebben we ook heel wat zaken aangepast in onze interface van de app om fouten door gebruikers zoveel mogelijk te vermijden. Maar daar kunnen en moeten we ook nog verbeteren. Daar hebben we extra investeringen gemaakt omdat we echt ook naar OSM ons willen engageren om goede zaken te doen. Dat had ook vaak grote implicaties voor de code van de app zelf. Het is ook echt een leerproces geweest en als we de kennis die we nu hebben hadden gehad, dan zouden we het waarschijnlijk anders aanpakken. Dus ja we hebben ook vaak gefaald en moesten op zoek naar een oplossing. Dat had natuurlijk ook een grote impact op het vertrouwen van de OSM community en alle opmerkingen waren ook altijd terecht, de toon was misschien wel niet altijd even constructief. Maar ok het waren onze fouten. Eerlijk gezegd heb ik er ook vaak aan gedacht om er de brui aan te geven en OSM niet meer te gebruiken. Maar ik ben ondertussen ook wel een OSMer geworden en was te koppig om het op te geven. Ik denk dat we ons vanuit On Wheels wel goed hebben opgesteld naar de community. Maar inderdaad had het ook heel interessant geweest voor Icapps om zicht ook meer te verdiepen en ook deel uit te maken van de community.

Het proces van de tagging was inderdaad ook geen makkelijke rit. We hebben wel heel wat discussie gehad over alle tags die we wilden introduceren, maar na maanden discussie waar iedereen iets anders zegt is het dan ook heel moeilijk om verder te gaan. Zelf had ik ook nul kennis van hoe je zo’n discussie moest opzetten op de juiste manier en een stemming organiseren. Maar wat doe je dan als bijv mensen zeggen dat ze onze tags gewoon niet nuttig vinden in OSM? Gewoon opgeven? Als ik nu alles opnieuw zou doen dan had ik eerst alle tags grondig afgesproken met de community en dan pas de development van de app opgestart. Maar nu hadden we al het budget uitgegeven en konden we dus niet meer terug. Ik denk nu wel dat we onze tags grondig hebben besproken en die op een juiste manier hebben gebruikt. Maar het is natuurlijk wel even verschieten voor sommigen als er opeens 10 extra tags aan een restaurant worden toegevoegd natuurlijk. Ik heb ook heel wat tijd gestoken in het maken van een uitgebreide wiki pagina met uitleg van alle tags (die ik up to date ga houden). Nu als er tags zijn die veranderd moeten worden in de toekomst dan is dit ook mogelijk. Hoewel OSM een mooie tag wiki website heeft is het echt wel een kluwen om de juiste tags voor alles te vinden. En ik vond na een jaar zoeken dan ook weer nieuwe zaken. Dus we doen echt ons best om de juiste tags te vinden en ook te veranderen als dit nodig is.

We komen nu op het einde van de afgesproken development en contract met Icapps en gaan intern ook heel het proces eens grondig bekijken en zien waar we in de toekomst beter moeten doen. Daar zal ook een gesprek met Icapps gebeuren waar we hen ook willen bedanken voor al het goed werk, maar ook de zaken die wat minder vlot verliepen. Ik zal dan ook de communicatie naar OSM bespreken en hoe we onze partnerschap kunnen verbeteren in de toekomst. Ons doel is echt om dan te kijken hoe we naar een volledig open source platform kunnen gaan waar we issues openbaar kunnen zetten (of laten zetten door iedereen) en beter kunnen samenwerken met de community. Nu was dit naar budget en server hosting via Icapps gebeurd, maar wel altijd met een contract dat On Wheels eigenaar is van alle code. We hebben nu binnen On Wheels financieel ook wat meer beweegruimte om bijv ook een eigen server te betalen. Ik wil graag afronden dat ik een soort van rapportje ga opmaken van het proces die we hebben doorlopen en tips en onze bevindingen wil delen met iedereen die als leek aan de slag wil gaan in OSM. Ik ben bezig met een Github waar we alles open source willen delen, ook onze andere projecten.

1 Like

Update langs onze kant:

Probleem ondertussen gevonden. En opgelost

Gezien de historiek; lijkt het me geen slecht idee @Pieter_Vander_Vennet / @joost_schouppe / @M_dgard of anderen om nog eens een sessie in te plannen, als jullie dat zien zitten om onze komende release nog eens door te testen zodat we geen zaken missen?

Het spijt me, maar langs mijn kant voel ik me niet geroepen om samen te zitten. Enerzijds heb ik het erg druk, anderzijds vind ik niet dat ik vrijwillig mijn expertise moet delen met een commercieel bedrijf dat hiervoor betaald worden én een directe concurrent is. Ofwel komen jullie langs op een informeel moment (meetup), ofwel kan je me als consultant vragen.

1 Like

Geen probleem Pieter. Ik heb het zelf getest en ook Joost heeft het getest. Je mag mij altijd een mailtje sturen met wat je vraagt als consulent voor bijv een uurtje samen te zitten.