+for id in $(seq 1 874) ; do
+ search="{
+ lokasjon: {
+ bbox: \"10.34425,59.96386,10.34458,59.96409\",
+ srid: \"WGS84\"
+ },
+ objektTyper: [{
+ id: $id, antall: 10
+ }]
+}"
+
+ query=/sok?kriterie=$(echo $search | urlmap)
+ if lookup "$query" |
+ grep -q '<totaltAntallReturnert>0<'
+ then
+ :
+ else
+ echo $id
+ lookup "/datakatalog/objekttyper/$id" |grep '^ <navn>'
+ fi
+done
+
+exit 0
+</pre></blockquote>
+
+Aktuelt ID-område 1-874 var riktig i datakatalogen da jeg laget
+scriptet. Det vil endre seg over tid. Skriptet listet så opp
+aktuelle typer i og rundt skibrua:
+
+<blockquote><pre>
+5
+ &lt;navn>Rekkverk&lt;/navn>
+14
+ &lt;navn>Rekkverksende&lt;/navn>
+47
+ &lt;navn>Trafikklomme&lt;/navn>
+49
+ &lt;navn>Trafikkøy&lt;/navn>
+60
+ &lt;navn>Bru&lt;/navn>
+79
+ &lt;navn>Stikkrenne/Kulvert&lt;/navn>
+80
+ &lt;navn>Grøft, åpen&lt;/navn>
+86
+ &lt;navn>Belysningsstrekning&lt;/navn>
+95
+ &lt;navn>Skiltpunkt&lt;/navn>
+96
+ &lt;navn>Skiltplate&lt;/navn>
+98
+ &lt;navn>Referansestolpe&lt;/navn>
+99
+ &lt;navn>Vegoppmerking, langsgående&lt;/navn>
+105
+ &lt;navn>Fartsgrense&lt;/navn>
+106
+ &lt;navn>Vinterdriftsstrategi&lt;/navn>
+172
+ &lt;navn>Trafikkdeler&lt;/navn>
+241
+ &lt;navn>Vegdekke&lt;/navn>
+293
+ &lt;navn>Breddemåling&lt;/navn>
+301
+ &lt;navn>Kantklippareal&lt;/navn>
+318
+ &lt;navn>Snø-/isrydding&lt;/navn>
+445
+ &lt;navn>Skred&lt;/navn>
+446
+ &lt;navn>Dokumentasjon&lt;/navn>
+452
+ &lt;navn>Undergang&lt;/navn>
+528
+ &lt;navn>Tverrprofil&lt;/navn>
+532
+ &lt;navn>Vegreferanse&lt;/navn>
+534
+ &lt;navn>Region&lt;/navn>
+535
+ &lt;navn>Fylke&lt;/navn>
+536
+ &lt;navn>Kommune&lt;/navn>
+538
+ &lt;navn>Gate&lt;/navn>
+539
+ &lt;navn>Transportlenke&lt;/navn>
+540
+ &lt;navn>Trafikkmengde&lt;/navn>
+570
+ &lt;navn>Trafikkulykke&lt;/navn>
+571
+ &lt;navn>Ulykkesinvolvert enhet&lt;/navn>
+572
+ &lt;navn>Ulykkesinvolvert person&lt;/navn>
+579
+ &lt;navn>Politidistrikt&lt;/navn>
+583
+ &lt;navn>Vegbredde&lt;/navn>
+591
+ &lt;navn>Høydebegrensning&lt;/navn>
+592
+ &lt;navn>Nedbøyningsmåling&lt;/navn>
+597
+ &lt;navn>Støy-luft, Strekningsdata&lt;/navn>
+601
+ &lt;navn>Oppgravingsdata&lt;/navn>
+602
+ &lt;navn>Oppgravingslag&lt;/navn>
+603
+ &lt;navn>PMS-parsell&lt;/navn>
+604
+ &lt;navn>Vegnormalstrekning&lt;/navn>
+605
+ &lt;navn>Værrelatert strekning&lt;/navn>
+616
+ &lt;navn>Feltstrekning&lt;/navn>
+617
+ &lt;navn>Adressepunkt&lt;/navn>
+626
+ &lt;navn>Friksjonsmåleserie&lt;/navn>
+629
+ &lt;navn>Vegdekke, flatelapping&lt;/navn>
+639
+ &lt;navn>Kurvatur, horisontalelement&lt;/navn>
+640
+ &lt;navn>Kurvatur, vertikalelement&lt;/navn>
+642
+ &lt;navn>Kurvatur, vertikalpunkt&lt;/navn>
+643
+ &lt;navn>Statistikk, trafikkmengde&lt;/navn>
+647
+ &lt;navn>Statistikk, vegbredde&lt;/navn>
+774
+ &lt;navn>Nedbøyningsmåleserie&lt;/navn>
+775
+ &lt;navn>ATK, influensstrekning&lt;/navn>
+794
+ &lt;navn>Systemobjekt&lt;/navn>
+810
+ &lt;navn>Vinterdriftsklasse&lt;/navn>
+821
+ &lt;navn>Funksjonell vegklasse&lt;/navn>
+825
+ &lt;navn>Kurvatur, stigning&lt;/navn>
+838
+ &lt;navn>Vegbredde, beregnet&lt;/navn>
+862
+ &lt;navn>Reisetidsregistreringspunkt&lt;/navn>
+871
+ &lt;navn>Bruksklasse&lt;/navn>
+</pre></blockquote>
+
+<p>Av disse ser ID 775 og 862 mest relevant ut. ID 775 antar jeg
+refererer til fotoboksen som står like ved brua, mens
+«Reisetidsregistreringspunkt» kanskje kan være boksen som henger der.
+Hvordan finner jeg så ut hva dette kan være for noe. En titt på
+<a href="http://labs.vegdata.no/nvdb-datakatalog/862-Reisetidsregistreringspunkt/">datakatalogsiden
+for ID 862/Reisetidsregistreringspunkt</a> viser at det er finnes 53
+slike målere i Norge, og hvor de er plassert, men gir ellers få
+detaljer. Det er plassert 40 på østlandet og 13 i Trondheimsregionen.
+Men siden nevner «AutoPASS», og hvis en slår opp oppføringen på
+Sollihøgda nevner den «Ciber AS» som ID for eksternt system. (Kan det
+være snakk om
+<a href="http://www.proff.no/selskap/ciber-norge-as/oslo/internettdesign-og-programmering/Z0I3KMF4/">Ciber
+Norge AS</a>, et selskap eid av Ciber Europe Bv?) Et nettsøk på
+ «Ciber AS autopass» fører meg til en artikkel fra NRK Trøndelag i
+ 2013 med tittel
+«<a href="http://www.nrk.no/trondelag/sjekk-dette-hvis-du-vil-unnga-ko-1.11327947">Sjekk
+dette hvis du vil unngå kø</a>». Artikkelen henviser til vegvesenets
+nettside
+<a href="http://www.reisetider.no/reisetid/forside.html">reisetider.no</a>
+som har en
+<a href="http://www.reisetider.no/reisetid/omrade.html?omrade=5">kartside
+for Østlandet</a> som viser at det måles mellom Sandvika og Sollihøgda.
+Det kan dermed se ut til at jeg har funnet ut hva boksene gjør.</p>
+
+<p>Hvis det stemmer, så er dette bokser som leser av AutoPASS-ID-en
+til alle passerende biler med AutoPASS-brikke, og dermed gjør det mulig
+for de som kontrollerer boksene å holde rede på hvor en gitt bil er
+når den passerte et slikt målepunkt. NRK-artikkelen forteller at
+denne informasjonen i dag kun brukes til å koble to
+AutoPASS-brikkepasseringer passeringer sammen for å beregne
+reisetiden, og at bruken er godkjent av Datatilsynet. Det er desverre
+ikke mulig for en sjåfør som passerer under en slik boks å kontrollere
+at AutoPASS-ID-en kun brukes til dette i dag og i fremtiden.</p>
+
+<p>I tillegg til denne type AutoPASS-sniffere vet jeg at det også
+finnes mange automatiske stasjoner som tar betalt pr. passering (aka
+bomstasjoner), og der lagres informasjon om tid, sted og bilnummer i
+10 år. Finnes det andre slike sniffere plassert ut på veiene?</p>
+
+<p>Personlig har jeg valgt å ikke bruke AutoPASS-brikke, for å gjøre
+det vanskeligere og mer kostbart for de som vil invadere privatsfæren
+og holde rede på hvor bilen min beveger seg til enhver tid. Jeg håper
+flere vil gjøre det samme, selv om det gir litt høyere private
+utgifter (dyrere bompassering). Vern om privatsfæren koster i disse
+dager.</p>
+
+<p>Takk til Jan Kristian Jensen i Statens Vegvesen for tips om
+dokumentasjon på vegvesenets REST-API.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Speeding up the Debian installer using eatmydata and dpkg-divert</title>
+ <link>http://people.skolelinux.org/pere/blog/Speeding_up_the_Debian_installer_using_eatmydata_and_dpkg_divert.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Speeding_up_the_Debian_installer_using_eatmydata_and_dpkg_divert.html</guid>
+ <pubDate>Tue, 16 Sep 2014 14:00:00 +0200</pubDate>
+ <description><p>The <a href="https://www.debian.org/">Debian</a> installer could be
+a lot quicker. When we install more than 2000 packages in
+<a href="http://www.skolelinux.org/">Skolelinux / Debian Edu</a> using
+tasksel in the installer, unpacking the binary packages take forever.
+A part of the slow I/O issue was discussed in
+<a href="https://bugs.debian.org/613428">bug #613428</a> about too
+much file system sync-ing done by dpkg, which is the package
+responsible for unpacking the binary packages. Other parts (like code
+executed by postinst scripts) might also sync to disk during
+installation. All this sync-ing to disk do not really make sense to
+me. If the machine crash half-way through, I start over, I do not try
+to salvage the half installed system. So the failure sync-ing is
+supposed to protect against, hardware or system crash, is not really
+relevant while the installer is running.</p>
+
+<p>A few days ago, I thought of a way to get rid of all the file
+system sync()-ing in a fairly non-intrusive way, without the need to
+change the code in several packages. The idea is not new, but I have
+not heard anyone propose the approach using dpkg-divert before. It
+depend on the small and clever package
+<a href="https://packages.qa.debian.org/eatmydata">eatmydata</a>, which
+uses LD_PRELOAD to replace the system functions for syncing data to
+disk with functions doing nothing, thus allowing programs to live
+dangerous while speeding up disk I/O significantly. Instead of
+modifying the implementation of dpkg, apt and tasksel (which are the
+packages responsible for selecting, fetching and installing packages),
+it occurred to me that we could just divert the programs away, replace
+them with a simple shell wrapper calling
+"eatmydata&nbsp;$program&nbsp;$@", to get the same effect.
+Two days ago I decided to test the idea, and wrapped up a simple
+implementation for the Debian Edu udeb.</p>
+
+<p>The effect was stunning. In my first test it reduced the running
+time of the pkgsel step (installing tasks) from 64 to less than 44
+minutes (20 minutes shaved off the installation) on an old Dell
+Latitude D505 machine. I am not quite sure what the optimised time
+would have been, as I messed up the testing a bit, causing the debconf
+priority to get low enough for two questions to pop up during
+installation. As soon as I saw the questions I moved the installation
+along, but do not know how long the question were holding up the
+installation. I did some more measurements using Debian Edu Jessie,
+and got these results. The time measured is the time stamp in
+/var/log/syslog between the "pkgsel: starting tasksel" and the
+"pkgsel: finishing up" lines, if you want to do the same measurement
+yourself. In Debian Edu, the tasksel dialog do not show up, and the
+timing thus do not depend on how quickly the user handle the tasksel
+dialog.</p>
projects / homepage.git / blobdiff