2012 ...

januari (3) februari (5) maart april (6) mei (2) juni (1) juli (2) augustus september (5) oktober (1) november (2) december

Trajectmeting E17

2012-01-02 08:29  i2999     [permalink]

Achthonderdduizend euro! Achthonderd duizend euro is al besteed aan een systeem om op twee punten langs een weg een poging te doen om je nummerplaat geautomatiseerd te lezen, en aan de hand van de tijd daartussen vast te stellen of de bestuurder zich hield aan de maximumsnelheid of niet. Eerst las ik dat er abnormaal zware voorwaarden waren gesteld om te blijven opereren in extreme condities zoals diepe vorst, maar daarna las ik dat er ernstige fouten zaten in zelfs de allerlaatste test-metingen. Het eerste is misschien storend, maar heb ik begrip voor, dat laatste is ronduit verschrikkelijk.

Ik vermoed, ook hier, dat er offertes zijn opgehaald bij precies drie bedrijven (omdat het er minimum drie moeten zijn), eentje belachelijk duur, eentje terecht duur, maar te duur in vergelijking met de derde en goedkoopste. Ik schreef bijna belachelijk goedkoop, maar achthonderdduizend blijft een bedrag dat ik wel eens graag bij de lotto zou willen winnen (minimum natuurlijk). Ik hoef u er waarschijnlijk niet bij te vertellen welke twee van de drie het beste voor-onderzoek voor hebben gedaan.

Het grappige aan dit alles is dat ik laatst op het werk een proof-of-concept opstelling heb opgesteld om met een minimum aan middelen 'barcodes in de verkeerde richting' te scannen langs een transportband. Ik gebruikte open-source-software en een webcam die we als relatiegeschenk kregen en in de kast was beland. Als ik even mijn eigen bestede tijd niet reken, dan kom ik zelfs niet met een veelvoud van mijn budget aan het totaal van de offerte die we een professionele firma lieten opstellen, want alle veelvouden van nul zijn ook nul.

Misschien is dit niet helemaal te vergelijken met juridisch geldige trajectmeting op de openbare weg, maar volg even mee. Tijdens het familiale chaufferen van het voorbije oud-en-nieuw-weekend, speelde ik met het volgende in gedachten. De grootste materiaalkost zou moeten de beeldvormende toestellen zijn. Daar kan je niet rond. Ik lees dat er voor de trajectmeting op de E17 voor infra-rood werd gekozen, maar dit ernstige invloeden ondervind van wind en weer. Dit zou beter zijn om de tekst op nummerplaten waar te nemen, maar ik geloof dit niet echt. Een nummerplaat is nog altijd bedoeld om het best met het blote oog waar te nemen. Dus gebruiken we best 'gewone' camera's die zichtbaar licht meten. Dit zal ook de kost drukken want je vind ze nagenoeg overal tegenwoordig.

In een andere dimensie, bijvoorbeeld een waar ik het voor het zeggen zou hebben, zou de inrichtende macht gewoon kunnen opleggen dat elke nummerplaat moet magnetisch of radiografisch reageren op een elektronische lus in het wegdek met een digitale code die de belettering van de nummerplaat reproduceert, maar dit ligt waarschijnlijk zowel politiek als inzake privacy best gevoelig.

Dan, eenmaal je beeld kan vastleggen, moet je op zoek naar de nummerplaat. Er bestaat waarschijnlijk wel open-source OCR software (of er zou er moeten bestaan), maar die zou ik niet zomaar loslaten op het rauwe beeldmateriaal. Meeste nummerplaten zijn van dezelfde grootte, en dus zou je moeten kunnen snel op zoek gaan in het beeld naar een rechthoek van deze verhouding. Nummerplaten hangen meestal horizontaal, da's ook handig. Zelfs als je geen nummerplaat kan waarnemen, ik denk aan bezoekers uit het buitenland of tijdelijke oplossingen achter de voorruit, dan zou ik er durven op wedden dat de specifieke verhouding van breedte en hoogte, en eventueel andere kenmerken van de omtrek, van alle auto's die tegelijk op het stuk trajectmeting aanwezig zijn, een behoorlijk hoge graad van uniciteit vertoont (een beetje zoals deze).

Deze gegevens moeten allemaal nog verwerkt worden, maar veel moet dat niet kosten. Tegenwoordig worden rekeneenheden niet alleen veel kleiner maar ook veel goedkoper. (Ken je deze?) En iets anders kiezen dan 'gewone' STP netwerkkabels zoals ze overal al liggen zou ik ook niet doen.

Dit alles zou toch veel minder moeten kosten dan wat nu al weer is verdwenen van de staatsrekeningen? Toegegeven, er kruipt nog een hoop werk in. Tegen weer en wind de dingen gaan ophangen. Uitgebreid testen, finetunen, controleren... Maar net dat zijn ze nu waarschijnlijk ook aan het doen. Al maanden lang.

→

Printer.Canvas is not threadsafe!

2012-01-26 19:46  i3003    [permalink]

What a strange discovery I made today. I was hunting down a weird exception we noticed in the logs of the live system.

It turns out that a 'global' callback procedure is being called when you use Printer.Canvas (Printer.Canvas.StretchDraw in my case) by the GDI subsystem. The default AbortProc in Printers.pas calls Application.ProcessMessages, which was causing trouble in my case.

There's a quick workaround:

function MyAbortProc(Prn: HDC; Error: Integer): Bool; stdcall;
begin
  Result := not FPrinter.Aborted;
end;

And then right after Printer.BeginDoc; call SetAbortProc(Printer.Canvas.Handle,MyAbortProc);

→

Delphi: keep the file version build number set to the current SVN revision number

2012-01-31 18:39  r1691     [permalink]

→ Delphi: keep the file version build number set to the current SVN revision number

→