De bug fixes laten inderdaad wat langer wachten dan we hadden gehoopt. We hadden een groot probleem met de bug vanuit OSM (509: Bandwidth limit exceeded), die we eerst moesten oplossen. We zijn nu bijna klaar met het fixen van de volgende zaken:
Data op data. Dit heeft te maken met het feit dat OSM soms data van bijv pubs op een node zet en some op een way. De nieuwe versie van de app zal ook ways kunnen herkennen en zal de data direct in de way zetten. Nu zien mensen geen pub staan in de app en maken dan een nieuwe poi aan. Zoals Joost ook zegt kijk ik altijd de dag na een opmeting alles na. We gebruiken altijd een speciale login tijdens een teambuilding zodat het nadien makkelijk te fixen is.
We zullen ook geen zaken meer invullen met hoofdletters.
Doorsturen van lege velden met no
We doen echt ons best om alle OSM richtlijnen en opmerkingen vanuit de community te volgen en correcte data door te sturen. Als er zaken zijn stuur deze gerust door via een direct message. Ik krijg blijkbaar geen mail als iemand hier iets nieuw post.
Dag Midgard, we hebben het laatste jaar echt ook heel veel hulp gevraagd van de OSM community, maar iedereen steekt liever zijn hoofd in de grond dan te helpen. Ik begrijp dat de development van de app niet perfect verloopt en dat sommige van jullie misschien een beter job hadden gedaan voor het OSM deel, maar er zijn naast het OSM deel van de app ook heel veel andere uitdagingen. We hebben ook gekeken naar OSM expert devs, maar deze zijn heel moeilijk te vinden. Zeker ook met de andere expertise die we nodig hadden. Misschien moet er vanuit OSM ook eens gekeken worden hoe we apps en devs die met OSM willen werken beter kunnen ondersteunen. Want dit is echt geen evidentie. Ik kan er een boek over schrijven (OSM voor dummies). Of dat er een lijst komt met alle devs die genoeg OSM expertise hebben.
Met de app kunnen we geen ways veranderen dus dit moet via de OSM editor gebeurd zijn. Wat wel kan is dat er ook nieuwe nodes is gemaakt en dat de positie van de gps niet klopte. Maar normaal bewerken we gewoon bestaande nodes en worden deze niet verplaatst. Ik weet dat er een student wat handelszaken heeft toegevoegd in Maldegem een tijdje geleden en ik heb dan alles nagekeken. In Maldegem stonden er ook heel weinig gebouwen in OSM, dus heb ik een paar uur gebouwen zitten intekenen. Misschien dat er daar iets is verschoven? Maar vind het wel raar dat het dan naar de andere kant van de wereld is verschoven.
Het ligt voor de hand dat de OnWheels-app een centroïde voor way 1238930913: de bibliotheek van Maldegem heeft gegenereerd, dat de app “vergeten” is dat daar eigenlijk een way achter school, en dan een nieuwe versie van de bibliotheek geüpload heeft naar de node met hetzelfde ID-nummer. Alle feiten aan de OSM-kant kloppen met die interpretatie.
Vandaar dus dat ik uit mijn krammen schiet: dit had absoluut vermeden kunnen worden als deze functionaliteit in de dev-omgeving getest was.
Ik heb de data die toegevoegd was door een user met de app verplaatst naar het juiste gebouw. Onze huidige versie van de app herkend geen ways en toont deze dus niet als een bestaand gebouw in onze app. Komt wel vaker voor dat een gebouw niet in OSM staat, dus dan maken we een nieuwe poi aan als een node. Ik heb die dan nadien in de bestaande way gezet. Soms staan functies in gebouwen als een way en soms als een node in OSM. We hebben dan de beslissing genomen om een extra investering te doen en ook way toe te voegen aan de app. Dus met de nieuwe versie gaan we dus ook dit soort gebouwen zien staan in onze app en voegen we onze data toe rechtstreeks aan de way. Dan gaan we ook minder van deze problemen tegenkomen. Tijdens de development van de app ontdekken we constant nieuwe zaken in OSM, waar we ons aan moeten aanpassen.
Hi Andy, I know this list from my extensive research before the development. I contacted some of these devs and got no respons or it was not possible technically or within our budget.
Ik snap jouw frustratie hoor, dit heb ik zelf ook soms. Ik denk dat het beter is om zulke zaken aan mij te melden omdat ik dan kan terugkoppelen met onze devs, samen met de andere zaken die moeten gebeuren. Gezien ik de projectleiding op mij neem is het wel handig als ik het overzicht heb van bugs of zaken die we kunnen verbeteren. Ik check dan ook dat deze zaken juist uitegevoerd worden. Morgen zit ik samen met hen en zal dan ook aangeven om geen tests te doen in de main server. Ik denk wel dat ze dit niet doen, want de nieuwe alpha built van de update werkt met de test omgeving. Wanneer we een beta built hebben dan doe ik altijd zelf een test in de main server om zeker te zijn dat alles klopt. ik weet dat dit niet de bedoeling is, maar zo ben ik 100% zeker dat we geen slechte update online zetten. Meestal maak ik een nieuwe poi/node aan en kijk ze na in OSM en verwijder ze meteen. Ik weet ook niet hoe ik dit anders kan doen.
Dat is allemaal goed en wel, maar het ziet er nog steeds naar uit dat er een functionaliteit van gebouwen als node tonen, toch ontwikkeld wordt/werd op de live DB, met account Wheelpov. Ik probeer hier nu niet met de vinger te wijzen, maar het moet wel écht duidelijk zijn dat dit niet kan:
OSM-data op deze manier breken en blijven breken kan gewoonweg niet door de beugel. Hoe het ook moge gebeuren.
De devs doen er goed aan iets te veranderen in hun proces dus.
Ok ik bespreek dit morgen met de devs. Ik vraag ook eens na of de Wheelpov account van hen is, want ik herken deze niet. Alleszins geen account die wij met On Wheels gebruiken. Wanneer wij een restaurant toevoegen via de app dat niet in OSM staat dan zal dit wel altijd als een node zijn. Bij bestaande ways gaan we wel gewoon de data op de way zetten, maar nieuwe zaken zal een node zijn. Het is wel zo dat we nadien de data via OSM kunnen veranderen naar een way als dit de voorkeur heeft. Maar in principe worden de meeste zaken die wij toevoegen ook als een node getoond in OSM. Er is ook niet echt een eenzijdige manier in OSM, dus we proberen dit zoveel mogelijk op dezelfde manier te doen en flexibel te zijn dat OSM gebruikers het nog kunnen aanpassen indien nodig.
Dag Midgard, ik heb net een meeting gehad met onze devs en eens gevraagd naar hun testproces en Wheelpov account. Dit is geen account van hen en zij testen altijd alles via de testserver. Dus ik weet niet goed wie dit dan is eerlijk gezegd.
What is possible is that we created a new node with the app with wrong gps location
Nee, een reeds bestaande node is verplaatst en hertagd naar zijnde de bibliotheek van Maldegem.
someone changed the location of this node in OSM editor.
In dat geval moet Wheelpov haast wel ter kwader trouw de created_by van hun wijzigingenset aan het vervalsen zijn. Of On Wheels zou een reeds open wijzigingenset moeten overgenomen hebben zonder zelf een bewerking te doen. (Kan in theorie, maar zeer onwaarschijnlijk dat Wheelpov dat per ongeluk drie keer gelapt heeft.)
Tenzij er een enorm zware bug zit in de OpenStreetMap-serversoftware zelf (zeer onwaarschijnlijk), zijn dit harde feiten, die je mogelijke verklaringen dus rechtstreeks weerleggen.
In our app we show existing nodes and ways and we edit these and we can’t move them in the app.
“Verplaatsen” is geen operatie in OSM: elke versie moet de nieuwe locatie doorsturen. Dus bij elke nieuwe node-versie bestaat de mogelijkheid op onverhoopt verplaatsen. Daarmee blijft nog steeds mijn mogelijkheid overeind.
De enige mogelijkheid die volgens mij nog te goeder trouw resteert is dat deze fout al live in jullie app zit. @Robin_On_Wheels, zou je misschien kunnen nagaan wat er gebeurt als je met je eigen account met de nieuwste On Wheels-versie De Krook in Gent bewerkt? (De node met overeenkomstig ID-nummer, Node: 323711813 | OpenStreetMap, is momenteel niet in gebruik dus dit zal niet veel schade aanrichten.)
P.S.: Het zou jullie zelf bij nazien van zulke fouten trouwens enorm helpen als het versienummer (bij releases) en de commit (bij dev-versies) gerapporteerd zou worden in de created_by in plaats van een statische 0.1.
Hey bedankt voor de tips. Ik bekijk het. Het lijkt we wel bizar dat deze bug enkel voorkomt bij de gebruiker Wheelpov. Als het een bug is in de app dan zou dit toch ook bij andere gebruikers en locaties moeten voorkomen? Hebben we nog niet bij andere gebruikers en locaties gehad. Ik onderzoek het verder.
Ja we gaan met de volgende versie de juiste versienaam doorsturen (OnWheelsapp 3.0.3). Deze komt dan ook overeen met de versie nummer dat in onze wiki staat. Hebben we overkeken in het verleden, sorry en dit maakt het ook duidelijker. Ik heb nu ook een update en bug fix overzicht toegevoegd aan onze wiki pagina, dan zie je welke updates en bug fixes we hebben gedaan in een bepaalde versie en wat er gepland staat.
Er zijn recent geen andere wijzigingen gebeurd waarbij een feature aangepast werd die al als way ingetekend werd, dat kan een mogelijke verklaring zijn. Vandaar mijn vraag om eens met De Krook te prutsen.
Ik heb dit even getest, er zit effectief een bug in de software. Als je een way probeert de editeren, dan krijg je doorgaans een error. Maar af en toe niet. En dan krijg je dit: Changeset: 163536234 | OpenStreetMap
Met andere woorden:
het lijkt erop dat de app weigert ways te editeren als het geen (volstrekt niet ter zake doende) node met hetzelfde volgnummer vindt.
Als die er wel is, dan is de app nogal, euh, “creatief”. Ik was dus Way: 513973135 | OpenStreetMap aan het bewerken. Bij het opslaan gaat hij die way ongemoeid laten, maar wel de node met toevallig hetzelfde volgnummer Node: 513973135 | OpenStreetMap gaan verrijken met nieuwe tags. En dat punt verplaatsen van zijn rustig veld in Frankrijk naar de centroid van die oorspronkelijke way…
Hieruit blijkt toch wel een diep onbegrip van hoe OSM in elkaar zit.
Bij het testen viel me overigens op dat er nogal wat verplichte velden zijn alvorens je iets kunt opslaan. Het veld “naam” is bijvoorbeeld verplicht voor een parking, maar zo’n ding heeft nu eenmaal vaak geen naam. Voor de zwemvijver in mijn tuin kon ik aangeven dat er geen WC was, maar enkel op voorwaarde dat ik de breedte van de deur doorgaf… Dat maakt dus dat je enerzijds edits gaat missen als mensen onvolledige kennis hebben, en anderzijds dat ze onzin gaan invoeren om door de verplichte velden te geraken.
Aangezien way nummers veel kleiner zijn dan node nummers, zou je deze fout toch wel vrij courant verwachten. Het moet zijn dat er toch vrij veel nodes alweer gedelete zijn.
Bedankt voor de melding hiervan. Er was een deel van de nieuwe onafgewerkte api van de back end online gezet. De oude api zonder deze fout staat normaal gezien terug online. Morgen wordt de bug bekeken en de fix wordt in de nieuwe update gedeployed. Ik ga ook een test beta versie sturen naar Joost om de nieuwe update uit te testen voor we die online zetten in de store.
Dag Joost, de verplichte velden zoals naam bij een parking hebben we ook al optioneel gemaakt in de nieuwe update. Dat was inderdaad niet handig en onnodig. Normaal gezien voegen wij geen zaken zoals zwemvijvers toe, enkel gebouwen, parkeerplaatsen, toiletten, zitbanken en obstakels. Stond die zichtbaar onder een bepaalde categorie? We maken het verplicht bij gebouwen om minstens de deurbreedte en hoogte treden toe te voegen omdat onze gebruikers deze info nodig hebben. Nu sturen we ook standaard zaken door zoals fee=no, maar in de nieuwe update sturen we enkel velden door die mensen hebben ingevuld. Het is zeker ook een uitdaging om mensen zonder veel kennis juist te laten opmeten. We gaan daar ook sterker op inzetten, met bijv een introductie over de app/handleiding die je ziet wanneer je de app voor de eerste keer open doet. Maar we hebben nu ook nog heel weinig gebruikers die zaken toevoegen via de app. We doen dit vooral met de teambuildings, waar we ook een uitleg geven vooraf.