Typisk dansk millimeteridioti

Undervurderingen handler om, hvordan rejsekortets bagvedliggende computersystem skal håndtere de mange lokale takstsystemer og sindrige rabatordninger, såsom periodekort med rabat for antal ture eller rabat for distance, som i øjeblikket eksisterer i Danmark.

Det er så typisk tåbeligt dansk som noget kan være: Man skal naturligvis renovere takstsystemerne til et samlet let forståeligt system ved samme lejlighed.

Det minder om Dengang man skulle lære danskerne at betale for at køre på en offentlig vej. Istedet for at overveje hvordan de ville sidde og fumle med pengene i bilen, holdt man sig til en eller anden tåbelig økonomisk kalkule og satte prisen til 210 kroner.

Jeg har hørt fra flere af dem der sad i buret den første dag, at der var kommet langt flere over broen, hvis den tikrone havde været sløjfet.

Poul-Henning

Re: Typisk dansk millimeteridioti

Jeg tror ikke på, at det er et problem at udregne en prisfunktion - uanset der bruges dansk millimeteridioti. Det kræver, en mindre indsats, at analysere og finde et brugbart system, og herefter implementere.

Jeg tror, at sandheden er, at leverandøren simpelthen ikke kan lave et system som fungerer - uanset pris. Det er bare ikke opdaget før. F.eks. tages nogle gange - på samme tidspunkt af dagen - forskellig pris, for samme strækning, og samme tur. (sådan som jeg forstod en anmeldelse af systemet)

Det kommer derfor ikke til at fungere ved, at implementere et simplere system. Selvom, at alle ture, koster 10 kroner hver, tror jeg resultatet er det samme: Det vil ikke fungere. Men det er da et godt forsøg.

For at undersøge, om det fungerer, kan man opsætte to billetautomater, hvor der skal klippes begge steder. Og tjekke, at resultatet er ens. Det tror jeg ikke det bliver. Og det skyldes ikke takster.

Desuden undrer det, at leverandøren ikke har kunnet gennemskue opgavens sværhedsgrad fra starten. Der var flere udbydere - man kunne spørge, om de andre udbydere kunne, og at man reelt har givet et bedre tilbud end muligt, alene for at få ordren, og så håbe på, at kunne tage ekstra bagefter, med begrundelse i det danske prissystem.

Det lyder som et "standard trik", der er set før.

Re: Re: Typisk dansk millimeteridioti

Det er da underligt at DSBs billetautomater fint kan finde ud af alle de forskellige takster. Er der noget jeg har misset, eller burde det ikke virke på samme måde? Det er vel indkodet i kortet om ejeren er ung eller pensionist...

Så langt fra dansk idioti !

Næ, det her er en gentagelse af problemerne med den engelske kollektive trafik efter den blev solgt i salami-stykker. Prøv at spørge en englænder hvordan det var at købe en billet i midten af 90érne fra nord til syd.

Og dengang var det skræk scenariet i DSB ..... Det måtte for himlens skyld aldrig ske i Danmark !

Men desværre er det sådan hvis en passager tvinges til at købe billet i toget. DSB kan ikke sælge billetter til Ariva og vise versa.

Re: Re: Re: Typisk dansk millimeteridioti

Det er da underligt at DSBs billetautomater fint kan finde ud af alle de forskellige takster.

Hvilke billetautomater taler du om? DSB har mange forskellige slags, og de kan forskellige ting. Hvis du taler om den nyeste primært til brug for IC og regionaltog, så kan den kun noget avanceret, hvis billetten er bestilt på forhånd. Dvs. den kan stort set ikke selv noget, den printer bare hvad den får besked på.

Ny udbud?

Ses på det danske system - i forhold til et standard system leveret andre steder - så er det netop taksterne, som adskiller. Og denne del, fungerer ikke. Det mangler 3 års udvikling - med andre ord, er intet implementeret!

Måske burde opgaven deles ned i mindre dele, således prisstrukturen først løses. Vi har tidligere set, at studerende har løst skemaudlægning til skolerne - måske kunne nogle have projekter i DSB's køreplaner, og få sat system på prisen.

At løse opgaven, for landet i små dele, og herefter skulle mappe disse sammen, kan nemt vise sig at være en umulig fremgangsmåde. Dette svarer lidt til en salami metode, hvor man tror løsningen dukker op, trods man fra starten har manglende overblik. Sandheden er, at løsningen ikke dukker op. Derfor, kan man ligeså godt bide i det sure æble, og lave zoneberegningen først. På den måde, opnås optimal overblik, og opgaven løses ikke som en række delopgaver, der senere ikke vil fungere tilsammen.

Samtidigt med udvikling af algorithmen, kan producenten, rette deres software og hardware, så det er sikkert, at det fungerer.

Det undrer lidt, at man har valgt nogle "fix punkter", for priskalkulation. Skal findes det nærmeste fix punkt, svarer dette fuldstændigt til, at du opbygger landet i zoner. Og det var jo egentligt det system, man ville bort fra... I princippet, ser jeg ikke andet, end et zonekort, der udregner afstanden og prisen, udfra zoner som før, men hvor der måske udregnes udfra en zones fixpunkt koordinat.

Hvis der vælges, at stadigt gå ud fra zoner, som ovenstående tyder på - så burde hver zone kunne få et nummer, og prisen udregnes ved simpel opslag i en 2-dimmensionel zonetabel, som DSB udregner.

Kombinationszoner, der indeholder 2 zoner, gives bare et nyt nummer, og indgår i tabellen.

Når tabellen er udregnet, overleveres den formelt, som en guld eller platin DVD til Thales.

Hvis nogen kan løse opgaven, så det kan forenkles, kan tabelopslaget ændres til en formel.

Re: Ny udbud?

Ses på nuværende metode, som bruges, er landet opdelt i zoner. Prisen udregnes som:

pris = f(gennemkørte zoner,tid, rabatkortype og data)

Det er altså, en helt almindelig funktion, som blot skal fastlægges.

DSB burde kunne udregne funktionen selv, og skrive algorithmen, således Thales kun skal overføre de pågældende parametre. De kan udvikle et program, der demonstrerer prisstrukturen for Thales, så de kun skal implementere denne funktion.

Hvis DSB udregner funktionen, og kun sætter krav til, hvilke parametre de skal have til rådighed, så har DSB mulighed, for at ændre zonenumrer, priser, og funktion, som de ønsker, uden udbyderen skal programmere systemet om.

Jeg foreslår derfor, at DSB overvejer hvilke input parametre de skal have til rådighed, og returnerer med en pris. Herefter, må Thales lave et system, således DSB selv kan programmere prisfunktion, samt indkoder zoneidentifikationen for hver enkelt automat.

Re: Ny udbud?

Ses på det danske system - i forhold til et standard system leveret andre steder - så er det netop taksterne, som adskiller.

Nej, der er en anden væsentlig forskel: Danske togstationer er ikke "gated", dvs biletter checkes ikke for adgang til og fra perronerne.

Det betyder at systemet skal kunne håndtere at folk checker ind, stiger på toget, stiger ud uden at checke ud.

I de systemer der sammenlignes med slipper man ikke ud af stationen før man har stukket billet/kort i automaten.

Poul-Henning

hunden gemt andet steds?

Var der nogen som sagde Amandas tvilling?

Eller nævnte "EPJ"? (sjovt, ingen interesserer sig for hvad der er smidt efter det!)

Måske er de blot ikke dygtige nok ;-)

Re: hunden gemt andet steds?

Nej, der er en anden væsentlig forskel: Danske togstationer er ikke "gated", dvs biletter checkes ikke for adgang til og fra perronerne.

Ved rejsekortet, stemples både ud og ind - dog, betyder det intet, hvis der ikke stemples ud, og næste rejse starter inden en vis tid.

Netop udstemplingen, var en af de ting som fejlede på automaterne. Ofte trak de 50 kroner, for manglende udstempling.

Hvis der ikke stemples ud, og rejsen ikke fortsættes ved der stemples ind inden en vis tid efter sidste rejse, så vil der tages strafgebyr på 50 kroner, da der ikke vides hvor rejsen sluttes.

Reglerne er helt klare, og fuldstændigt deffinerede.

Alligevel, lykkedes det Thales, at nogle gange "ikke detektere" udstemplingen, og derfor tage 50 kroner.

Dette har jo intet med DSB's takststruktur at gøre.

Re: Re: Ny udbud?

Nej, der er en anden væsentlig forskel: Danske togstationer er ikke "gated", dvs biletter checkes ikke for adgang til og fra perronerne.

Det betyder at systemet skal kunne håndtere at folk checker ind, stiger på toget, stiger ud uden at checke ud.

I de systemer der sammenlignes med slipper man ikke ud af stationen før man har stukket billet/kort i automaten.

Poul-Henning

I Singapore er systemet faktisk både i busser og tog. I busserne er der en terminal ved ind- og udgang. Det samme burde vel være muligt i de danske tog? Det forudsætter så naturligvis at folk husker at "scanne ud" når de forlader toget.

/søren

Re: Typisk dansk millimeteridioti

Paul Henning er inde på det centrale problem: Man har ikke simplificeret takststrukturen i forbindelse med det nye billetsystem.
Det skyldes at de enkelte amtstrafikselskaber hver især ønsker at beholde hver deres eget system i stedet for at finde et fælles. Man tror det ikke, men der er virkelig store og/eller komplekse forskelle mellem de forskellige takstsystemer!
Udover amtstrafikselskaberne er der trafikselskaber der kører på tværs af amterne med deres eget takstsystem, samt busser der starter i et amt og kører ind i et andet og tredie. Oven over dem kommer DSB. Og så er der selvfølgelig problemet med hvilken vej man kommer mellem Jylland og Sjælland, tog eller færge.
På det tidspunkt du stiger på bussen ved systemet ikke hvor du er på vej hen, så du sættes i starten på lokaltakst, afh. af hvilket transportmiddel du stiger op i (Der kan være forskelle afh. af om du stiger på en lokal bus, interregional bus, regionaltog og evt. intercity tog). Hvis du stiger af bussen i et tilliggende amt (amterne eksisterer godt nok ikke længere, men de bruges stadig. Det samarbejde der er på sjælland kører stadig med 3 forskellige takstsystemer) skal der udregnes en billet ud fra de to takstsystemer. Taksten skal foriøvrigt også regnes ud for det fjerneste sted man har været på turen. Afhængig af hvilke trafikgrænser og hvilke transportmidler man benytter undervejs ryger man op på højere takstsystemer i takstsystemhierakiet, hvor DBS ligger øverst.
Hvis man havde benyttet et simpelt takstsystem så kunne man sandsynligvis have benyttet et allerede eksisterende system.
Konsortiet måtte være klar over at systemet var kompliceret, da kravene var ret specifikke, de skulle i detaillier beskrive hvordan de havde tænkt sig at løse det, da det var krævet i udbudet. At de software- og omkostningsmæssigt har undervurderet opgaven er en anden sag, men indholdsmæssigt burde de ikke have været i tvivl.

Re: Re: Re: Re: Typisk dansk millimeteridioti

Hvilke billetautomater taler du om? DSB har mange forskellige slags, og de kan forskellige ting. Hvis du taler om den nyeste primært til brug for IC og regionaltog, så kan den kun noget avanceret, hvis billetten er bestilt på forhånd. Dvs. den kan stort set ikke selv noget, den printer bare hvad den får besked på.

Hvad advanceret er det lige at den skal kunne?
Er det mig der har misset noget? Ifølge rejsekortets hjemmeside stempler man ind i sit første transportmiddel (Det kalder vi så start-stationen) og man stempler ud når man er ved sin destination. Derefter udregner dimsen så hvad rejsen koster (Dvs. pris fra start til destination fraregnet evt. rabatter) og trækker det fra ens konto.

Når jeg køber en billet ligemeget om det er i de nye med touchscreen eller de gamle der nu bliver brugt af arriva (med en talkode for stationerne) ved den selvfølgeligt hvor man starter, og den finder så en pris for en billet til destinationen.

Hvad er lige den store forskel? Begge systemer har en start og destination og skal så finde prisen... Er der noget jeg har misset, eller er det helt anderledes på sjælland?

Re: Re: Re: Re: Re: Typisk dansk millimeteridioti

Okay. Ifølge Kims indlæg virker det ret forvirrende på sjælland, men jeg er ret sikker på at både midt og nordjyllands trafikselskaber kører efter dsbs takster.

Så hvorfor ikke bare indføre rejsekortet i jylland til at starte med?

Re: Re: Re: Re: Re: Re: Typisk dansk millimeteridioti

Selvom det umiddelbart virker utrolig kompleks, er det ikke værre, end det kan beskrives som en funktion af zoner, rabatkort, og tid.

Det eneste DSB skal, er at opskrive hvilke parametre der er for prisen, og så skal systemet levere det, til en formel DSB indsætter. Det kan ikke være så svært.

Det er ikke korrekt, at det kun stemples ind ved start, og ud ved slut. I princippet, stemples ind, ved hver enkelt tog og bus, og ud ved hver enkelt tog og bus. Fortsættes rejsen, inden en vis tid, regnes automatisk som en rejseforlængelse. Det er ikke nødvendigt at stemple ud, men det sker ikke noget ved det. Udstemplingen ignoreres ganske enkelt, hvis rejsen fortsættes inden en vis tid, og derved fortsættes rejsen. Hvis der ikke stemples ud, og rejsen ikke fortsættes, så regnes et gebyr på 50 kroner.

Der har været ønske om, at i starten fortsætte med det nuværende takstsystem, som start op. Dette gør systemet en smule mere kompliceret, da det ikke er helt enkelt. Stadigt, gælder dog samme formel: Prisen udregnes udfra zoner der køres igennem, tid, og rabatkorttype. For at udregne, hvilke zoner der køres igennem, skal kendes tog eller busnummer, og dens rute, og da er zonerne bestemt af de zoner, den kører igennem - mellem der hvor der klippes ind, og hvor der klippes ud. Når rejsen forlænges, forventes udstigningszonen at være samme som hvor rejsen påbegyndes for næste tur (der kan være delte zoner). Ved månedskort, gives specielt rabat, når der køres gennem visse zoner, og ellers betales efter normal takst, eller titurs takst.

Vi har altså stadigt, at prisen er en funktion af zoner der køres igennem, tid, og pris. Zonerne, som der køres igennem, udregnes som en funktion af busnummer/tognummer og indklipningszonen, samt udklipningszonen, eller indklipningszonen ved rejseforlængelse.

Alt ialt, er det ganske simpelt. Eksempelvis kan automaterne overføre zone, og tidspunkt, til et objekt, og denne regner så prisen ud. Selvom der er flere prissystemer, er det ikke noget problem - men man skal have at vide, hvordan takstseringen skal være. Normalt er mest reelt, at vælge efter laveste pris, hvis forskellige systemer kan bruges. Systmer, skal altid regne det ud til kundens fordel, hvis det ikke er ordentligt deffineret hvordan det udregnes.

Min opfattelse er, at DSB kan deffinere hvilke parametre de har brug for, til et objekt der udregner prisen, og herefter selv indsætte funktionen. Det er ikke væsentligt sværre, end at kode en lommeregner.

Enventuelt, kan den laves så den programmeres på samme måde som en lommeregner, og fortolker koden.

Det er muligt, at DSB ikke ordentligt har deffineret takst strukturen: Derfor, lad dem kode det selv, og giv dem de parametre, som de behøver. På den måde, kan de også kode prisstrukturen om, hvis det er nødvendigt. Kan DSB ikke selv kode funktionen, kan de sikkert få Adeco til det, eller et andet konsulenthus. Takstfunktionen, hører ikke under det, der skal leveres af Thales, da den ændrer sig uafbrudt. Den hører under vedligehold (Adeco).

Re*: Typisk dansk millimeteridioti

Så længe du bevæger dig rundt på DSB's skinnenet kan du stort set slå priserne op i et array som amterne har leveret data til, men hvis du skal bevæge dig fra et vilkårligt A i Danmark til et vilkårligt B så skal priserne beregnes ud fra hvilke transportmidler der indgår og hvilke ruter du benytter mellem A og B.
Og jeg er ked af at sige det, men Århus amt hører ikke til de nemme, de gik også kun halvhjertet med i samarbejdet om det nye landsdækkende kort. Indrømmet at Storstrøms Amt havde et af de værste systemer, men de tog konsekvensen og indførte et simpelt takstsystem.
I gamle dage, før end vi fik amtstrafikselskaberne, var der stort set kun DSB som national operatør med eet takstsystem, derfor burde det kunne lade sig gøre med kun eet takstsystem igen.

Re*: Typisk dansk millimeteridioti

Hej Jens, hvis du læser dit eget indlæg, så starter det også simpelt med at man gør bare lige, men efterhånden så kommer der flere og flere undtagelser på. Specielt den med at "hvis det ikke er ordentlig defineret hvad man gør, så".
Nu bliver DSB nævnt hele tiden og det er også rigtigt at DSB har været primusmotor for at få et fælles rejsekort, men det er ikke DSB der er skyld i at takstsystemet er som det er. Det skyldes at amtstrafikselskaberne (amtspolitikerne?) ikke ville gå med i rejsekortet medmindre de fik lov til at beholde deres eget takstsystem. De skulle have nogle trafikpolitiske knapper at dreje på.
Det er egentlig ret imponerende at et af verdens mindste lande, sandsynligvis vil få verdens mest komplicerede takstsystem. Vor trafikale situation er jo ikke værre end London's.
Selv om det er verdens værste takstsystem, så er det dog ikke så slemt, at det kan retfærdiggøre en forsinkelse af den størrelsesorden, som der har været og åbenbart vil komme.

Re: Re*: Typisk dansk millimeteridioti

Selvom der er nok så mange undtagelser, kan jeg ihvertfald skrive et program for hovedstadsområdet på under en dag. Dog skal indtastes en bunke busplaner og togplaner - dette er ikke medregnet.

Det væsentlige er, at det ikke er udbyderen, men dem der står for vedligeholdelsen, som indkoder programmet. De skal have mulighed for, at ændre takststrukturen, og derfor bør de selv kunne angive programmet. Systemet skal være sikkert (f.eks. fortolket), således et "dårligt oversat program", ikke kan få systemet til at gå ned, eller forkert brug af hukommelsen. Der må ikke anvendes et sprog, som muliggør at det kan gå ned, hænge, osv. Eksempelvis kan kræves, at koden udføres på et givent antal cycles, og ellers stoppes prisudregningen, og der påstemples, at turen er gratis, grundet midlertidige tekniske problemer.

Selve hardware, skal altså fungere uden prisfunktion.
Prisfunktionen, må ikke - og bør ikke - være del af den leverede hardware løsning. Kun kald af funktionen, samt sikring af at hardwaren ikke ødelægges i form af overskrivning, eller software der går ned, er del af hardware løsningen.

En simpel måde, kan være en funktion der kaldes for hvert klip, og hvortil der leveres de sidste 100 klip som data. De pågældende klip, indeholder samme som nutidens klippekort: Indstempling/Udstempling, Tidsstempling, Zonenummer, samt bus/tog nummer (strækning). Funktionen returnerer med tidspunkt for rejsens begyndelse, samt pris. Input, er altså et array bestående af sidste 100 klip, og output er starttid og pris.

Hvis samme starttidspunkt, får ny pris, opdateres den i systemet. Således, kan startes med f.eks. 50 kroner, og opdateres for hvert klip.

Opgaven, kræver ikke en speciel dygtig programmør. De fleste, dårligere programmører, skulle kunne gøre det. Kan man ikke, mener jeg man må være totalt udueligt, og kan næppe programmere en lommeregner. Det største problem, bliver måske at overskue køreplanen.

Re**: Typisk dansk millimeteridioti

Der er specifikke krav til takststrukturen og disse løses sikrest og bedst ved at alle takstudregninger udføres gennem regel- og dataopslag. Der skal ikke sidde folk og programmere hverken dårlige eller gode programmører, alt for dyrt at teste og sætte i drift.
En anden ting er at man ønsker at simplificere takstsystemet med tiden, så behovet for ny programmering omkring takster er lille, når først systemet er oppe at køre. Jeg tror ikke der ikke findes den zonemodel der ikke er taget højde for i systemet.
Jeg er ikke så imponeret af at du vil kunne programmere HT delen, jeg havde været mere imponeret hvis du havde foreslået øresundsbilletsystemet. HT er et simpelt system og så længe du holder dig inden for et amt så tager det faktisk ikke mere end et par timer. Jeg har værert involveret i et salgssystem hvor alle de danske amtsmodeller, dsb-regional takster og øresundstakstsystemet indgik og jeg har analyseret og designet en model for rejsekortsystemet, så jeg har faktisk været der. Du kan evt se http://www.linkedin.com/in/kim...lsen .

Re: Re**: Typisk dansk millimeteridioti

Der er specifikke krav til takststrukturen og disse løses sikrest og bedst ved at alle takstudregninger udføres gennem regel- og dataopslag. Der skal ikke sidde folk og programmere hverken dårlige eller gode programmører, alt for dyrt at teste og sætte i drift.

Et program, er primært også regel og dataopslag. Det kan være svært, at indprogrammere regel og dataopslag uden "program". Du kan anvende et simpelt sprog, og det er ikke nødvendigt med advancerede C++ kommandoer og strukturer. Et simpelt basic sprog, er også rigeligt. Men, hvordan vil du indkode "regler" uden at beskrive dem som program eller funktion?

I teorien, kan du anvende kun tabelopslag, og have det som en tilstandsmaskine, således en tabel, udover opslag, også angiver næste tabel du skal bruge. Dette bliver meget uoverskueligt.

Den eneste rigtige måde, er at kunne beskrive det i et simpelt program. Om det er simpelt, eller ikke, er op til dem der fastlægger takststrukturen. Er det en advanceret takststruktur, må det naturligvis kræve et mere kompliceret program.

Thales, kan være ligeglade med takststruktur. Det de skal, er at levere de data, som udbyderen specificerer er nødvendigt for prisudregningen. Hvis Adeco står for vedligeholdelsen, kan det eventuelt specificeres af udbyderen og Adeco, hvor Adeco skal stå for software vedligeholdelse.

Når først at denne del er fast, så er hardwaren som sådan fast, og indstallationen kan begynde.

Den bedste, og nemmeste måde, er at specificere prisen i et sprog, og at gøre det ud fra de n sidste rejser, hvor de n sidste rejser fås som input, med de rette data. Det er samtidigt, en ganske simpel ting.

I princippet, kunne du have et "objekt", hvor data kunne leve mellem kaldene for hver klip - dette er dog ikke så sikkert, som en funktion, hvor intet kan overleve. Data, der overlever, er det der får moderne systemer til at fejle. Derfor virker OOP software ikke. Det skyldes tilstande. Tilstande, gør, at du ikke kan "bevise" software. Og det er også utåleligt overfor brugeren, at prisen afhænger af en skjult parameter, som de ikke må vide. Typisk, giver en sådan parameter anledning til, at prisen er forskellig fra gang til gang, fordi prisen ikke mere er en matematisk funktion af turen, og det stemplede, som ses på "klippekortet".

Hvis udbyderen, laver en simpel prisstruktur, så kan du måske indprogrammere den i et array. Men hardware, der ikke kan kodes med et program for prisen, er ikke tilstrækkeligt advanceret til, at kunne bruges. Der skal indlægges en fortolker, der fortolker et simpelt sprog, og gives tilladelse til, at udregningen af pris, tager et vist antal fortolkede indstruktioner. Er den ikke færdig inden, f.eks. på grund af løkker eller kompleksistet, må afbrydes, og turen er gratis. Indenfor hardware, sættes krav om, at opgaven udregnes inden en given tid. Dette er i praksis det eneste, der gør at prisudregningens kompleksitet ikke må være for høj. Men antages, at der må bruges 10.000 fortolkede indstruktioner på en prisudregning, kan den godt have en større kompleksitet.

Re***: Typisk dansk millimeteridioti

Der er fra rejsekort as side specificeret helt præcist hvad de ønsker omkring takstsystemet og omkrings kontrolpunkternes funktion, så den side kan faktisk ikke diskuteres. Implementationen er mere fri, omend der også her er meget klare regler for hvad der skal ligge hvor.
Der er ikke behov for at lægge kode ind dynamisk, det er faktisk forbavsende så få ændringer der er i takstsystemerne (vel, det kostede amterne en bondegård hver gang de tænkte på en ændring, så det er nok ikke så underligt;-).
Der er en regel der hedder, at jo bedre datastrukturer des mindre kode og omvendt. Det gælder absolut også her.
Nu gælder det at alle disse takstberegninger skal kunne foregå decentralt, da der ikke er konstant forbindelse til centrale servere, samt at man altid skal kunne se om der er penge nok til den tur vedkommende er igang med, dvs. pengene trækkes på kortet efterhånden som de bruges. Så alle data skal kunne sendes ud til de decentrale kontrolpunkter og det indebærer fx udsendelse af takstdata i form af takstniveau, zoner, priser, kontrolpunkter, navne, via-punkter, takstleverandører, mmm. samt regler. Alle disse data kan være beskrevet i XML el. varianter heraf. XML kan sammenlignes med et programmeringssprog, men her vil det ikke være interessant at håndkode; maskingenerering ud fra det enkelte kontrolpunkts definition vil være langt mere sikkert. Opgaven kan faktisk beskrives som en heuristisk søgning i en graf.
Jeg ved ikke hvorfor du taler om Thales og Adeco, set fra Rejsekorts side så er der en leverandør, der ud fra taksdata skal levere og drive rejsekortsystemet. Hvem der har programmeret systemet på overdragelsestidspunktet er konsortiets problem, så længe de har sandsynliggjort at det virker. Efter det er idriftsat så skal det egentlig bare virke og hvis der bliver behov for programmering, så er det enten en systemfejl fra konsortiets side eller en specifikationsfejl fra Rejsekortsside.

Re: Re***: Typisk dansk millimeteridioti

Jeg har ikke læst beskrivelsen af hvordan prisen skal udregnes udfra rejsekorts side. Hvis den er specificeret i udbudet, burde jo ikke være problem med dette. Jeg har kun læst beskrivelsen af, hvordan systemet skulle fungere overfor kunden.

Der er en regel der hedder, at jo bedre datastrukturer des mindre kode og omvendt. Det gælder absolut også her.

Korrekt - af hensyn til fleksibilitet, vil jeg selv have lavet et system, der krævede en smule kode. Hvis rejsekort, så har et system, der er kodefri, kodes algorithmen herfor så bare ind. Rejsekorts system, burde derfor kunne bygges ovenpå, hvis det altså kan specificere de priser, som der ønskes. Det er jeg sikker på, er muligt, med et system der kalder en funktion for hver klip, og som har forrige klips som parameter.

Umiddelbart er min opfattelse, at det ikke burde være advanceret at kode, men det kræver en bunke tabeller, som afhænger af prisstrukturen. Derfor, skal automaterne også have rimeligt stor hukommelse.

XML er en udmærket måde at gemme kode - men der er også ulemper. Ulempen, er f.eks. ved "søgning" - det er XML ikke egnet til. Ofte, er bedre at kode dataene til en database struktur, så der kan laves hurtige opslag. Ofte, kan man dog angive det i XML og så kompilere til en databasestruktur, hvor opslag kan laves og bliver hurtige O log(x) funktioner. Databasesøgninger, skal altid højst være O(log(n)). X*X søgninger er ulovlig, når der skal svares indenfor bestemt tid (kun haves 1000-10.000 indstruktioner totalt, incl. tegn i søgningen), som indenfor embedded processing og hardware arkitekturer. Vi må huske, at det sandsynligvis ikke er en superprocessor, der sidder i billetautomaterne - måske skal den sammenlignes med regnekraft fra en ZX 81, eller ZX spektrum. Men uanset regnekraft, gælder at intet må have større store O funkion end log(n), da det ellers ikke kan sidestilles med begrænset konstant svartid, men er deffineret til ubegrænset svartid, eller ingen svar. Datalogisk, er derfor forbudt med væsentligt større store O funkion, end O(log(n)) i systemer der skal svare indenfor en afgrænset tid.

Laves opslag efter bogen (altså optimeret store O funktion i database struktur), så er det intet problem. Laves det efter Java strukturer, og skides lort på datalogi, så vil det ikke blive færdigt i dette århundrede... (undskyld, jeg har ikke set noget java der var rimeligt udfra en datalogisk synspunkt, det kører utroligt langsomt og er ustabilt). Dette er naturligvis noget overdrevet, da der kan laves hurtige Java compilere, og for den sags skyld fortolkere - så jeg vil ikke udelukke Java kan bruges på en CPU til prisudregning, for en processor med 1 MHz klok. Normalt, kan den trods alt udføre 100.000 32bit beregninger i sekundet, eller 100.000 opslag. 32 bit (fixed), er nok til priser, og det er rigeligt til prisudregning, når data opbevares struktureret så der kan laves opslag med søgetræer (altså ikke XML).

Jeg undskylder, at jeg er en smule sur på moderne teknologi, herunder Java. Men min erfarring med Java er, at det er ubrugeligt. XML virker umiddelbart struktureret og overskueligt, men mangler fuldstændigt den underliggende struktur, der skal gøre at data kan hentes. Forestil dig, at filerne var gemt i XML på din harddisk. Du vil få søgetid uden lige. I princippet, står filerne ikke i sorteret rækkefølge, og du skal søge hele harddisken igennem for et filopslag.

Et datakatalog, med underkataloger, og underkataloger heri, er både mere struktureret, og mere hurtigt at lave opslag i, end XML.

Re****: Typisk dansk millimeteridioti

XML'en vil typisk være protokollen for overførslen, hvordan data opbevares lokalt er en helt anden sag.
Forskellige sprog er godt til forskellige ting. Der er ikke noget sprog jeg vil betragte som det universelt bedste og det er der heller ikke nogen grund til at der skal være. ADA og i en hvis grad C++ er eksempler på sprog der skulle kunne alt, men som faktisk kan gøre det til et helvede hvis de benyttes forkert. Anvendt rigtigt kan C++ gøre komplekse ting enkle, anvendt forkert kan det gøre enkle ting uoverskuelige.
Til OSer foretrækker jeg faktisk C frem for C++, fordi der er fuld kontrol over hvad der foregår. Serviceorienterede systemer som OLTP er fint pakket ind i C++, men her kan man også benytte java. Til platformsuafhængige scripts kan man fint benytte java, fx. som Google og Firefox benytter det. Objekter er godt til at programmere små genbrugelige moduler, der kan overskues af en mand. Komponenter er godt til at fremstille brugergrænseflader hurtigt, efter devisen, det er hurtigere at programmere et ny brugergrænseflade end omprogrammere en gammel, hvilket er væsentligt i disse tider, hvor brugerinterfaces har så kort en levetid som de har. Nå det var et sidespring.
Jeg hopper af her, det var hyggeligt at sludre med dig.
Mvh. Kim

Re: Re****: Typisk dansk millimeteridioti

Tror vi er helt enige.

Og opgaven, er til at løse, uden softwaren er langsom, hvis det gøres korrekt.

Re: Re: Ny udbud?

Når jeg læser denne debat, er jeg lige ved at blive kommunist, selvom jeg nu nærmer mig de fyrre år (og har let til søvnen og skal ikke tælle får.....). Det skyldes ikke de mange glimrende indlæg og forskellige vinkler på problemet, men det faktum, at det ville være ufattelig meget lettere, hvis Den store Stat drev gratis (skattebetalte) tog, busser og teletaxier landet over - det ville spare nogle ressourcer i billettering, udvikling af Rejsekort mv. Men det er ikke realistisk, næppe heller ønskeligt, så jeg forholder mig til debattens præmis: hvordan får vi et elektronisk betalingssystem, som fungerer?

Basalt/banalt skal det løse to opgaver:
1) kunden skal betale den rigtige pris for sin rejse, der automatisk udregnes med forbehold for længde, øvrig rejseaktivitet etc.
2) operatøren skal have en pose penge for at køre. Det kunne fx være et fast grundbeløb betalt over skatten plus et variabelt beløb som funktion af, hvor mange passagerer der rejser hvor langt med den givne operatør. Det vil være motiverende til at få nogle passagerer ind på sæderne.

Jeg tror det vigtigste er enkelhed! Tidligere er bl.a. foreslået:

Ses på nuværende metode, som bruges, er landet opdelt i zoner. Prisen udregnes som:
pris = f(gennemkørte zoner,tid, rabatkortype og data)

Jeg forestiller mig et landsdækkende takstsystem, hvor man helt banalt betaler for, hvor mange kilometer, man kører = afstand mellem på- og afstigning. Alternativt kunne landet deles ind i et antal zoner a fx 5 x 5 km - min pointe er blot: simpelhed og at den samme afstand koster det samme uanset om den tilbagelægges i Nordjylland, Storkøbenhavn eller på Sydfyn.

Rabat: Hvis man nøjes med tx to rabatformer, ville det være ganske enkelt at udregne såvel kundens pris, som det beløb operatøren(e) skal modtage. Rabatten udregnes på månedsbasis (som svarer ufattelig godt til det interval, bl.a. PBS opkræver med)
Det kunne fx være:
1) Pendlerrabat: Jo flere gange, man tager en tur mellem to givne steder, des billigere bliver det. Enten lineært faldende (fx 5% billigere hver gang man tager turen = 21. tur gratis) eller trinvis (5 ture til fuld pris, næste 5 til 80%, etc.).
2) Totalrabat: Beregnes ud fra det samlede antal kørte kilometer. Fx de første 500 km til fuld pris, og så trinvist faldende (5% pr. 100 km).
Når en måned er gået, begynder man forfra.
Endelig ganges prisen med en af tre mulige indkomstfaktorer (eller hvad pokker man nu skal kalde det):
1) fuld pris for os stakkels erhversaktive = 100%
2) reduceret pris for unge, studerende og pensionister = fx 50%
3) meget reduceret pris for børn = fx 25%, dog kører et barn (eller to) gratis med en betalende voksen.

Rent teknisk forestiller jeg mig, at man fører sit rejsekort forbi en automat, der registrer kortet, blinker grønt og siger "bip" samt enten lægger en påstigningskode ind på kundens rejsekort eller sender sender rejsekortets ID-til en central database. Ved rejsens slutning fører man kortet forbi næste automat, som blinker hvidt, siger "bippelip" og modtager kortets ID (og evt. påstigningskode hvis den model vælges), og sender dataene til databasen.
Herefter kan man se, hvilken strækning og hvor langt kunden har kørt, sammenholde det med månedens øvrige rejseaktivitet. Og så er resten på niveau med eller enklere end Krak.dk

Det burde kunne lade sig gøre for et par friske DTU-studerende at lave over sommerferien. Eneste minus er, at der ikke er økonomisk motivation for kunderne til at vælge de afgange, hvor der er god plads, men det kunne operatøren evt. klare vha. bonusordninge eller lignende.

Men det ville bl.a. kræve politisk mod at slå i bordet og sige. "så harmoniserer vi taksterne", så det sker næppe.

Mest utroligt at det er teknologien der skal definere takstsystemet

Uha.
Maskinerne har for svært ved at udregne priserne, så vi må sandelig ændre systemet!
At almindelige brugere der har skulle foretage rejsen indtil nu har skulle gennemgå det samme helvede, hvis de ville vide hvilken rejseform og rute var billigst har ikke givet anledning til reform, så hvorfor skulle en maskines genvordigheder gøre det?

Nå. tilbage til den tekniske diskussion. Vi er vel ingeniører.
Krav til ind- og udscanning på alle transportmidler på turen giver basalt set et radikalt anderledes system end de gamle.
Dette nye system skal så åbenbart ikke træde i stedet for de eksisterende, men de skal fungere sideløbende. Dette er en enorm dobbeltinvestering i infrastruktur da de gamle systemer jo stadig skal vedligeholdes så længe der er brugere til dem.
Kompleksiteten for brugerne bliver heller ikke mindre af at de skal opføre sig anderledes når de bruger det ene system end når de bruger det andet.
Reelt skulle man have valgt enten et system der kunne fungere efter de samme principper som det eksisterende systemer (billettering ved rejsestart med mulighed for supplering undervejs - med Århus som en undtagelse :-)) eller man skulle have reformeret hele systemet så alle skal billetere efter samme principper hvad enten de har et kort eller bare køber en enkelt tur.
Dobbeltsystemer er dømt til at blive unødigt dyre og få endnu dyrere problemer.

Gratis offentlig transport

Hvad ville en gratis offentlig transport egentlig koste, når man trækker alle udgifter til billetsystemer, kontrolsystemer og så videre fra.

Hertil kan lægges "dynamiske effekter", som at der kan spares på socialhjælp, skoletransport og lignende, samt at udbygningen af vejnettet vil blive mindre.

Er det nogensinde beregnet?

Re: Gratis offentlig transport

Hvad ville en gratis offentlig transport egentlig koste ?

Jeg tror nok erfaringen med den slags initiativer er at helt eller næsten helt gratis transport fører til tåbelige og overflødige transportmønstre.

I Moskva var det f.eks praktisk taget gratis at rejse med metroen og der er tusindvis af legender om hvordan det var billigere at levere et brev per hånd via Metro, end at sætte et frimærke på osv.

Men man kunne sagtens lave et takstsystem der ville holde ting lidt i ave, men stadig var simpelt at administrere:

Bybusser: gratis

Alt andet: X kroner for en påstigning, eller Y kroner for en dag.

Eventuelt et Z kroners tillæg for Storebælt.

Systemet kunne indføres inden august ved at lave papirklippekort til de existerende automater i tre forskellige farver.

Automaterne fra bybusser kan genbruges andre steder.

Poul-Henning

Re: Gratis offentlig transport

Teknologirådet har lavet en interessant rapport om emnet
(http://www.tekno.dk/subpage.ph...ori7)

Rapportens overordnede konklusioner er:

- at en generel gennemførelse af gratis offentlig transport på landsplan ikke er hensigtsmæssig.De økonomiske omkostninger vil være store og effekten lille for så vidt angår trængsel trafikmiljø og uheld.

- at gratis offentlig transport vil have langt større effekt i storbyerne end på landet.

- at effekten på miljø og sundhed er begrænset. Støjbelastningen og luftforureningen vil generelt ikke ændre sig mærkbart, og den formodet bedre sundhedstilstand blandt de frafaldne bilister opvejes af den tilsvarende ringere hos de frafaldne cyklister og gående.

- at mobiliteten generelt vil blive øget – især for borgere som ikke har bilrådighed. Det vil også reducere bilejerskab (anskaffelse af bil nr. 2), idet mobiliteten kan opretholdes uden.

- at en kombination af takstnedsættelse og et bedre udbud af transportmuligheder (kvalitet og
hyppighed) vil have en større effekt end indførelsen af en generel 0-takst alene.

Re: Re: Gratis offentlig transport

Jeg har ikke læst hele rapporten, men samlet set synes jeg at der er noget som tyder en del på at et system hvor man betaler entre til perron eller bus og derfra kan rejse så langt man vil for det beløb vil have mange fordele (set i lyset af rapport, og besvær med nyt system).
I øvrigt har jeg ikke været i Singapore, men i London og omegn fungerer systemet ikke. Og i London er der både automater til at lukke folk ind og ud og ansat personale til kundebetjening på perronerne, så der skal investeres massivt ud over systemet, hvis det samme skal laves i Danmark.

Det er forresten interessant at bemærk at Fyns busser slet ikke er nævnt i planen. De udgør et særligt problem som man tilsyneladende ikke har lyst til at tage stilling til lige nu.

Re: Re: Re: Gratis offentlig transport

Min opfattelse af systemet i London, som jeg jævnligt benytter, er derimod anderledes. Jeg har aldrig oplevet problemer med brugen af deres Oyster card og automaterne der skal aflæse dem, og længe tænkt over hvorfor pokker vi ikke har et så simpelt system magen til i Danmark (indrømmet - jeg er ikke den flittigste bruger af S-tog (tager cyklen når jeg kan), men zonetælling går fuldstændigt over hovedet på mig). Og når der endelig har været problemer med automaterne i Londons system skyldes det nærmere at en ombygning på stationen giver nedetid for maskinerne. Derimod er det ikke smart, at man absolut skal lukkes manuelt igennem en port, så snart man har stor bagage med eller er handikappet.

Prisudregning

Jeg troede lige, at problemerne kunne løses ved hjælp af det system, der ligger på rejseplanen.dk. Den har jo et prisberegningssystem. Men da jeg testede det på en rejse, der omfatter lidt Ariva, en del DSB og lidt busrejse på Fyn (det skulle jo ifølge noget af ovenstående være ekstra svært), fik jeg svaret: "Desværre kan Rejseplanen ikke vise prisen for netop den rejse, du har søgt, hvilket vi beklager meget.
Det skyldes, at Rejseplanen ikke har oplysninger for det område, du rejser i."

Måske er det oplysninger, Rejsekortsystemet mangler?

Re: Prisudregning

De er lidt specielle på Fyn, fx. var busserne på Fyn de sidste der indførte rygeforbud, der skulle ikke komme nogle tovlige københavnere og fortælle dem noget.
Det har bl.a. også givet sig udslag i at de ikke har et amtstrafikselskab, som i de øvrige amter, men derimod har flere selvstændige operatører. Det er også årsagen til at de ikke er nævnt i planen.
Århus købte foriøvrigt en aktie på 1000kr i rejsekort for ikke at være helt uden for, men mere ville de heller ikke give ;-)

Manuelle salgssystemer

Apropos Fyn, så var jeg for en 8-10 år siden med bus fra Nyborg til Svendborg og der brugte de det gamle mekaniske billetsystem som DSB også brugte i rigtig gamle dage. Den var ret imponerede, jeg tror ikke jeg har set et tilsvarende elektronisk system der var lige så hurtigt.