Masto Reader
mastoreader.io

Super spændende forløbsbeskrivelse af hvordan østrigske Mario Zechner (@badlogic@mastodon.gamedev.place) fik nok af regeringens tomme løfter om et “kig på dagligvarepriserne”, og på 2 timer havde første version af en prissammenligner stykket sammen, fangede mediernes opmærksomhed, gjorde den relevante minister til grin, og afslørede meget sansynlig stiltiende samarbejde (†) omkring priserne.

Jeg har selv været lidt skeptisk omkring den nuværende inflation (greedflation?) af dagligvarepriser (††), og samtidig super frustreret over udbredelsen (måske nærmere eskaleringen?) af ‘shrinkflation’ (†††). Men det er vildt svært at regne ud hvad man skulle kunne gøre selv, både fordi man måske - som jeg selv - ikke er programmør, og fordi man ikke ved hvor man skal starte.

Enormt forløsende at læse om Marios (overvejende) succes på området (med ministeriske benspænd, selvfølgelig…), og der er allerede mange forks af projektet for at tilpasse det andre landes indkøbsmuligheder (har dog ikke fundet en dansk fork endnu).

Tænk hvis vi kunne få adgang til den data for Danmark! Men ak, tror det kan blive en smule svært at genbruge dette projekt, da vi stort set ikke har nogen supermarkeder der er online, og jeg ikke ved om man overhovedet kan få adgang til deres API (et krav for at HeissePreisse kan fungere).

Så vidt jeg kan se er der kun:

Kan også være Danmark er for lille til at man overhovedet ville kunne gøre noget hvis man fik dataen, men synes tanken er interessant. Er der nogen af jer der ved om den slags data er tilgængelig (næppe, men skader ikke at spørge)? Andre idéer til hvad man kan gøre, om noget?

Er desuden også interesseret i hvordan man kunne forsøge at tackle overemballering og unødvendig brug af plast i emballage i dagligvarer - sig endelig til hvis der er nogen der har hørt om nogen projekter på det område!

. . . . . .

Update 1

De tre butikker jeg nævnte har alle en API, men to af dem bruger POST uden den relevante query i URL’en, og ser ud til at det er ud over mit niveau at tilpasse koden til at kompensere for dette.

Den sidste bruger GET til at snakke med sin API, med søgningen synlig i URL og det hele, men jeg får nogle fejl når jeg kører den tilpassede kode, og indtil videre har jeg ikke fundet en løsning.

Tror jeg prøver at skrive til Mario for at høre om han har idéer til hvordan man kommer ud over de to issues. Umiddelbart ville det hele være nemmere hvis der bare var en enkelt fil per butik man skulle tilpasse, baseret på en simpel skabelon, men det er ikke helt tilfældet.

Hvis der er nogen der har lyst til at give det et skud er det Nemlig.com der lader til at være den bedre kandidat, selvom jeg tænker at det må være muligt med alle tre.

Det er måske også værd at nævne at selvom der er tale om offentligt tilgængelig data ved jeg ikke om butikkernes TOS brydes, og der dermed kunne være juridiske konsekvenser.

. . . . . .

Hovedlink er en roll-up af denne Mastodon-tråd: https://mastodon.social/@badlogic@mastodon.gamedev.place/111071396843370282

Projektet på GitHub: https://github.com/badlogic/heissepreise

. . . . . .

† Stiltiende samarbejde / koordinering: jeg kunne ikke finde på en bedre oversættelse. Fra den originale tråd:

“…tacit collusion, meaning, oligopolic price coordination without explicit coordination.”

†† Relevant artikel om inflation/greedflation fra Cory Doctorow: Look at all the great stuff we lost because of inflation scare-talk (pluralistic.net)

††† Shrinkflation (også kaldet ‘downsizing’): inflation der skjules ved at mindske varens mængde/indhold, typisk uden at ændre på emballagens størrelse, og stadig sælge den til samme pris.

Eksempel: Kleenex Balsam box:

  • renard_roux@beehaw.orgOP
    4·
    1 year ago

    Det virkede! Her kommer andel del…

    Shrinkflation

    Så enig, det er røvirriterende. Er også selv meget opmærksom på kilopris, men mest ift. prissammenligning af produkter; synes det er svært at huske hvad kiloprisen på et specifikt produkt er/var, men kan være et regneark er vejen frem, omend irriterende ekstraarbejde.

    (…men sig endelig til hvis der er nogen der vil have mit regneark med pris per anbefalet DOSIS for alle varianter af Omega3 kapsler man kan købe i Netto. Tog mig en halv time forleden, men yderst tilfredsstillende bagefter!)

    Jeg tænker også at der vil være for megen modstand imod regulering af indholdsmængde vha. interval/faktor, også fra Folket, og det ville sikkert også være svært ift. EU regulativer (det gælder nok mange af de mulige tiltag…).

    Jeg kan godt li’ krav om tilpasning af emballagestørrelse, men der kan være issues ift. tooling til emballagen. En stands til en foldet papæske koster ikke det store, men en støbeform til blow-molding af en plasticdunk til vaskemiddel (grrr, findes i ark-form der vejer 1/25 af de flydende sæber (†), og kan leveres i simpel pap; flydende vaskemiddel burde forbydes 😡) er ikke billig, og det kunne være frustrerende for virksomheder at skulle re-designe og købe nye værktøjer til emballage hver gang de… hey, måske slet ikke så tosset 😅

    Mit ideelle scenarie er noget i stil med:

    1. Der laves en fælles database over alle dagligvarer.

      • Alle dagligvarer skal registreres i databasen inden de er lovlige at sælge.
      • Alle unikke produkter registreres som et “hovedprodukt”, e.g. “Buko Pikant”. Hovedprodukt har info om ingredienser, men ikke mængder, emballage, dimensioner, etc.
      • Alle varianter af produktet skal registreres separat som et “underprodukt” af hovedproduktet. Buko Pikant: 120g, 200g, 300g, etc. Dette gælder også hvis der kun findes én version af produktet. Lidt ligesom CVR og P-enheder. Produktet på konceptuelt plan + alle fysiske manifestationer af produktet som underenheder.
      • Hvis en variant af en vare udgår skal det registreres. Hvis den erstattes af en ny størrelse skal det nye produkt angives/linkes (ikke sikker på at dette er nødvendigt efter tilføjelse ovenfor af “registrering af udgået variant” og variant-systemet generelt).
      • Alle nye varianter skal registreres inden lovligt salg.
      • Alle historiske data bevares. Ideelt set for evigt.
      • Varekategorier + underkategorier: fødevare > bagværk > kage.
      • Alle fødevarer skal registreres med fulde ingredienser (+ allergener/spor af).
      • Alle varianter registreres med vægt (både brutto og netto), måleenhed og mængde, etc. Måske også dimensioner af emballeret vare i form af omsluttende kube med XYZ angivet i cm?
      • Imens vi er i gang kunne det være fedt at have procentvis opdeling af emballagens materialer, e.g. 20% papir, 10% metal, 70% plast (HDPE/LDPE/PET/PP/PA/etc.).
      • Alle varianter registreres med unik kode (EAN/GS1 Stregkode/GTIN, allerede en ting).
      • Alle ændringer af produkter skal registreres! Vægt (brutto+netto), ingredienser, dimensioner (XYZ), emballage komposition.
      • Oprindelsesland, oprindelsesland for ingredienser/komponenter, etc. Tilsvarende eksisterende lovkrav.
      • Databasen er offentlig tilgængelig. Jeg har eks. et barn med meget alvorlige nøddeallergier, og vi forlader ikke vores hjem uden en EpiPen; adgang til ingredienser/allergener for alle fødevarer ville være uvurderlig i forhold til vores evner til at A) finde ting hun må spise og B) kommunikere hvad hun må spise til andre når vi ikke er til stede.
      • Det skal være muligt at lave en app der kan slå varer (nærmere specifikke varianter) op i databasen via stregkoden. Åben API?

    2. Lovkrav - tydelig beskrivelse på emballagens forside når:

      • En variant har nogen form for ændring (vægt, antal enheder i pakke, etc.), hvor XYZ dimensioner er uændret (eller ændring større end X%).
      • Emballagens fremtoning efter en ændring af variant (æske, ca. den her størrelse / flaske i alm. størrelse og grøn farve / etc.) må forventes at kunne forveksles med den tidligere emballage.
      • Emballagens XYZ ændrer sig uden at produktets nettovægt gør.
      • En ny variant tilføjes.

    3. “Tydelig beskrivelse” defineres med meget specifikke regler for størrelse og synlighed:

      • Beskrivelsen skal udgøre mindst X% af emballagens forsides areal, dog minimum X * Y cm.
      • Se EUs regler for labels på fødevarer - de er rimeligt dygtige til regler 😅
      • Beskrivelserne skal fremgå af emballagen mindst 6 måneder (?) fra første salgsdato.
      • Eksempler på beskrivelser:
        • Uændret XYZ, lavere nettovægt = X% mindre indhold, emballage uændret
        • Ændring i ingredienser = Ny opskrift - se specifikke ændringer på bagsiden under “ændringer”
        • Ændring af ingredienser, nye allergener = NYE ALLERGENER! Se specifikke ændringer på bagsiden under “ændringer”
        • Ændring af ingredienser, allergener fjernet = Nu uden [allergen] / Nu uden spor af [allergen], læs mere på bagsiden
        • Uændret XYZ, lavere antal enheder i pakken = X færre [enhed] i æsken!
        • Osv.

    I forhold til den data ovenstående ville kræve findes 99% af det allerede, et eller andet sted, og sikkert flere. Der er bare ikke noget sted hvor det er samlet, og hvis der er er det ikke et sted vi har fri adgang til. Og det er fucked, for der burde ikke være nogen som helst del af det der er hemmelig. Stort set alle informationerne kan vi få i supermarkedet, men ingen af os ville nogensinde kunne registrere dem manuelt og skabe adgang til dem i et fælles system.

    Det er obfuskering via besværlighed, og det er fucking nederen. Hvis DK ikke lovligt kan lave sådan et system, så må EU gøre det. Det er sikkert også bedre, opgaven lugter langt væk af et af Danmarks famøse IT projekter, AKA 10 milliarder over budget, 10 år forsinket, med 10% af den bestilte funktionalitet.

    Skalaen gør systemet komplekst, ja, men ikke den grundlæggende struktur. Det burde være rimeligt ligetil at bygge med en gruppe dygtige ildsjæle. Hvis I kender nogen i Folketinget / EU så sig at jeg gerne gør det for 10 milliarder, og det bliver færdigt på 2 år. Sig at jeg lover at overholde deadline; det plejer at være godt nok.

    Jeg må vist hellere stoppe nu, kan se at der forsvandt et par timer, men synes de er givet godt ud ift. at få konkretiseret et par idéer og tanker. Kan være det kan bruges til noget en dag af mig selv eller andre, eller kan sætte skub i et par tanker andetsteds☺

    . . . . . .

    † Eks. Laundry Sheets. 109,- for 60 ark = kr. 1,82/vask, 2,08 gram/vask. 480 vaske/kg.

    A+ flydende vask, 880 ml, 52,95 (Rema1000). Antager at 1L = ~1KG: kr. 3,11/vask (aktuel Rema pris, kan helt sikkert findes billigere), 51,76 gram/vask, 20 vaske/kg (efter A+ anvisninger). 2385% tungere/vask.

    • SorteKaninMA
      3·
      1 year ago

      synes det er svært at huske hvad kiloprisen på et specifikt produkt er/var, men kan være et regneark er vejen frem, omend irriterende ekstraarbejde

      Jeg har også dårlig hukommelse når det kommer til priser så nu er jeg virkelig glad for at jeg er begyndt at skrive dem ned! Det er ret nemt med et regneark på telefonen.

      Tak for al den research! Jeg er enig, det kunne være for vildt med sådan en database. Hvis det kunne gøres på EU-plan ville det også være nemmere for virksomhederne da de ikke skal registrere for hvert lands egen lille database separat. Men når det er sagt så lyder det meget ambitiøst at få sådan et system til at virke. Jeg kan allerede se en del edge cases og der er sikkert flere.

      Jeg tror det er mere realistisk at få kiloprisen til at være lige så stor som den almindelige pris på prisskiltene… :P

      • renard_roux@beehaw.orgOP
        2·
        1 year ago

        Regnearket gør bare også ondt ift. at det er noget den enkelte skal gøre, og interfacet er mindre end ideelt på mobilen, især når der begynder at komme mange poster.

        Hvis vi snakker manuel registrering (måske med både offentlige og lukkede brugergrupper? 😍) så kunne et MVP være:

        • Scan stregkode med kamera.
        • Scan pris med kamera (OCR)
        • Auto-registrér butik baseret på GPS.
        • En QuickScan knap der prompter for en kombination af nedenstående (kan tilpasses i indstillinger):
          • billede af “forside”
          • billede af ingredienser
          • billede af vægt/mængdeangivelse (OCR)
        • Backend server kan gemme historisk data, lave statistikker, som hentes frem ved scan af stregkoden (hvorefter man opfordres til at tilføje den aktuelle vares data igen)
        • Angiv favoritter; nu hvor alle priserne strømmer ind kan man blive adviseret når en kombination af rabat/max-pris og butikskæde bliver triggered.

        OK, det ser ud som om at jeg ikke ved hvad MVP betyder, men det ville være en app jeg rent faktisk gad bruge 😊

        EDIT Det er jo i virkeligheden en slags OpenStreetMap / Waze for registrering af fødevarer/dagligvarer. Community driven, open source (OSM at least, købte Google ikke Waze?), FOSS. Kunne være en fin måde at beskrive/sælge projektet på. “Frivillige ildsjæle skaber landets største åbne database over dagligvarer, priser, og allergener! Sådan kan du være en del af projektet!”

        Fuck hvor ville jeg gerne være bedre til at kode. Og have mere tid. Og råd til at trække stikket for at hellige mig et frivilligt projekt 😓

        Og ja, helt sikkert EU til mit andet forslag, og det ville helt sikkert være langt mere besværligt end jeg tror det er, sådan er det altid. Har også selv ramt et par edge-cases mens jeg skrev på “oplægget” i løbet af dagen, eks.:

        • Hvad gør man når én variant, men ikke alle, ændrer ingredienser? Er det så et nyt hovedprodukt der skal til (ja), og hvad gør man så med navnet? Skal der være krav om unikke navne til hovedprodukter?
        • Hvad forhindrer producenterne i at registrere masser af “fake” varianter som obfuskerer de triggers der skal til for at udløse et krav om “tydelig mærkning”?
        • Hvad kan producenterne ellers gøre for at game systemet?

        Men jeg tror nu godt at det kan lade sig gøre, og jeg har en mistanke om at noget der minder lidt om det allerede findes. En veninde i fødevarebranchen (bagels) fortalte mig forleden at der er en central database hvor alle fødevarer + ingredienser skal registreres. Jeg prøver lige at spørge hende i morgen om hvad den hedder. Tror ikke den er offentlig. Måske kan vi få en insider/whistleblower til at leake en kopi af dataen 😄

        Det ser også ud til at alle stregkoden i EU (i hvert fald til fødevarer) skal være G1/GTIN, og dem kan man kun købe ét sted; der må også være lidt data samlet dér, men nok ikke så meget.

        • autoexec@lemmy.blahaj.zone
          3·
          1 year ago

          Hey, vi er nogle som snakkede om det samme på Mastodon, lige nu både om en app til at skanne prisskilte og system til at læse api’er. Lige nu snakker jeg med 1 via signal og ved at der også er et par stykker som gerne vil være med på sidelinjen.

          Tænkte om vi ikke skulle finde en fælles kommunikations kanal at samle vores arbejde i, så at vi ikke ender med at hver især lave det samme projekt :)

          • renard_roux@beehaw.orgOP
            2·
            1 year ago

            Cool! I må endelig sige til når I finder et sted, jeg vil meget gerne være med til brainstorm eller hvad jeg ellers kan hjælpe med hvis I har plads til flere 👌

            Jeg er her, på Mastodon, Discord, og kan lave flere konti hvis det er. Bare det ikke ender med Facebook, Twitter, Threads eller Reddit 😅

            • autoexec@lemmy.blahaj.zone
              1·
              1 year ago

              Fedt! Nogle af dem jeg har snakket med har det blandet omkring Discord og open source arbejde, men finder lige ud af noget. Indtil videre så har jeg oprettet en GitHub her: https://github.com/Herover/heissepreise

              Hvis du vil så må du meget gerne dele din research på de 3 supermarkeder du har kigget på under issues. Jeg kiggede lidt på deres Lidl kode og det er næsten klart til .dk, URL’en skal ændres lidt og enheder er mærkelige men ellers! Tænker at smide en foreløbig server op på et sted hvor jeg har lidt andre ting kørende senere på ugen, så kan man altid flytte den til sit eget domæne senere (når vi finder et godt navn).

          • SorteKaninMA
            1·
            1 year ago

            Tænkte om vi ikke skulle finde en fælles kommunikations kanal at samle vores arbejde i, så at vi ikke ender med at hver især lave det samme projekt :)

            Det bedste ville nok være at samles om et eller andet GitHub projekt.

        • renard_roux@beehaw.orgOP
          3·
          1 year ago

          Update fra bagel-veninden: systemet hun nævnte for mig er GS1Trade Sync. GS1 er dem der udsteder alle stregkoder til fødevarer i EU, nævnte dem i en af mine tidligere kommentarer.

          Her er deres egen beskrivelse af produktet:

          Hold styr på produktstamdata - GS1Trade Sync er et system til udveksling af produktstamdata og billeder, hvor data er samlet ét sted, så det er tilgængeligt, når dine handelspartnere har brug for det.

          Systemet er opbygget af valideringsregler og datamodeller, der sikrer, at lovpligtige og relevante data altid er angivet for det enkelte produkt.

          GS1Trade Sync er en del af *GDSN netværket

          Så den store database som alle bruger til udveksling af varedata (ikke kun fødevarer) og billeder, og som sandsynligvis indeholder 100% af det jeg beskrev, er et lukket økosystem med et meget stort prisskilt, drevet af en stor, ond, multinational… NGO? 😳

          Det ser desuden ud til at der er en hel underskov af Certificerede Partnere, som eks. FoodInfo.dk, som vist ikke helt er en NGO.

          Tættere på vores ende af spektret har jeg fundet OpenFoodFacts.org:

          Open Food Facts er en fødevareproduktdatabase udarbejdet af alle, for alle. Du kan benytte den til at foretage bedre fødevarevalg, og da det er åbne data, kan alle genbruge disse til ethvert formål.

          De får data ind ved at frivillige scanner fødevarer hjemme eller i butikken med deres iPhone eller Android apps.

          Afhængig af hvor Åbne deres data er, er det nok et af de bedste steder at starte. Hvis man var vildt heldig er deres apps FOSS med kode på GitHub, og man kunne tilpasse dem til et nyt system med samme datasæt, med tilføjelsen af de “manglende” data (pris, dimensioner?).

          BINGO. Al data er frit tilgængelig, ligeledes koden til begge apps!

          Og hvis vi var rigtig heldige kunne man få lavet skrav af de tre danske supermarkeder vi har fundet online med Marios kode/system, og dermed få et baseline sæt af varer; mit gæt er at det vil give omkring 25K, måske lidt mere. Med dem i databasen, og måske supplerende scrapes løbende med nye priser, ville vi have et fint grundlag til sammenligning, og man kunne bygge en “manuel” indsamling ovenpå, for at få data fra alle de danske butikker der ikke er online.

          Jeg har ikke fået skrevet til Mario endnu; som tingene ser ud lige nu tror jeg at det vil kræve én bare nogenlunde kyndig koder til at tilpasse de ting jeg ikke selv kan grokke, og så har vi de tre første datasæt + dataen fra OFF. Det kan ikke være specielt svært at mappe OFF dataen til HeisePreisse skabelonen, eller omvendt.

          Før man begynder at bygge helt nye apps kunne vi starte med de lavthængende frugter 😊

          @autoexec@lemmy.blahaj.zone @sortekanin@feddit.dk

    • Rook@pawb.social
      1·
      1 year ago

      Sig at jeg lover at overholde deadline; det plejer at være godt nok.

      Det er så sandt at det gør ondt…