For hele Lemvig Kommune
Metode og transparens
Her beskrives både den letforståelige idé og den tekniske implementering. Målet er, at antagelser, usikkerheder, datakilder og afhængigheder kan efterprøves.
1. Formål og afgrænsning
Kortet viser, hvilke byer og hvor mange arbejdspladser man anslået kan nå fra et selvvalgt sted i Lemvig Kommune inden for en valgt køretid. Intet sted er valgt på forhånd.
Ved 90 minutter beregnes bylisten fem minutter længere ud. Dermed kan kortet også afgøre korrekt, hvilke byer der ligger i den viste kategori “nær zonen”. De ekstra byer bliver ikke automatisk mulige udgangspunkter.
Klienten er skrevet i PHP, HTML, CSS og JavaScript. Kortvisningen anvender Leaflet 1.9.4, geoberegninger Turf 7.2.0 og baggrundskort fra OpenStreetMap. Beregninger startes først, når brugeren vælger udgangspunkt A. Et eventuelt B-scenarie beregnes separat med samme metode og parametre.
Udgangspunkterne og de vedligeholdte kontrolbyer ligger fortsat i versionsstyret konfiguration. Derudover indlæses alle officielle BY3-byområder i et bredt analyseområde omkring Lemvig Kommune og sendes gennem den samme kalibrerede rutematrix. Analyseområdet består aktuelt af 25 kommuner: Billund, Esbjerg, Varde, Vejen, Fredericia, Horsens, Kolding, Vejle, Herning, Holstebro, Lemvig, Struer, Favrskov, Randers, Silkeborg, Skanderborg, Aarhus, Ikast-Brande, Ringkøbing-Skjern, Hedensted, Morsø, Skive, Thisted, Viborg og Vesthimmerlands.
Ved standardmodellens maksimum returneres de dynamiske referencebyer kun, når deres viste, afrundede tid er højst 95 minutter. Det er 90 minutters valg plus den faste nærzone på 5 minutter. BY3-referencebyerne kan indgå i beregning og dokumentation uden at kunne vælges som startsted.
Et delt link kan indeholde ?origin=<id>&compare=<id>&minutes=<15-90>&lat=<breddegrad>&lng=<længdegrad>&zoom=<7-19>. Parametrene gemmer den valgte analyse og den aktuelle kortplacering. Det er alene visningstilstand, ikke persondata eller en permanent profil.
2. Køretidszoner og Google-kalibrering
Standardkortets zone kommer fra TravelTime. Projektets praktiske udgangspunkt er brugerens erfaring med, at kontrolture i forbrugerproduktet Google Maps stemmer godt med den faktiske kørsel. Derfor er TravelTime-modellen justeret mod mange Google Routes-kontrolruter – ikke mod enkelte håndplukkede bypar.
Kalibreringen gør modellen mere sammenlignelig med disse kontroller, men beviser ikke, at den er rigtig overalt, og garanterer ikke samme svar som Google Maps.
Standardzoner hentes fra TravelTime API v4 på https://api.traveltimeapp.com/v4/time-map/fast. Rutematricen bruger https://api.traveltimeapp.com/v4/time-filter/fast. TravelTime beskriver standardtrafikken som typiske, historisk forudsagte forhold; den er ikke live-trafik. Alle analysedestinationer sendes som én one_to_many-søgning, hvilket ligger langt under Fast-endpointets dokumenterede lokationsgrænse og samtidig undgår kontoens lave request-rate. Midlertidige HTTP 429- og 5xx-svar prøves kortvarigt igen.
Kalibreringsversion google-routes-2026-08-13-v1 er lavet én gang med Google Routes API https://routes.googleapis.com/distanceMatrix/v2:computeRouteMatrix, DRIVE og TRAFFIC_UNAWARE. Matricen havde 27×23 = 621 mulige elementer; 602 gyldige ruter mellem 5 og 120 minutter indgik. Hvert udgangspunkt havde cirka 22–23 kontroller.
For hvert udgangspunkt estimeres en ordinær mindste-kvadraters linje:
En ønsket vist zonegrænse t sendes derfor til TravelTime som:
Den gennemsnitlige absolutte fejl på de samme træningsobservationer faldt fra 4,37 til 2,05 minutter. Dette er en in-sample-måling, ikke en uafhængig test. Der er ingen særregler for specifikke destinationer.
Rå Google-rutesvar vises ikke i standardkortet og opbevares ikke som produktdata; kun de afledte koefficienter versionsstyres. Brug af Google-tjenester er underlagt den aktuelle aftale, Google Maps Platform Policies og relevante EØS-vilkår. Operatøren skal løbende kontrollere, at den afledte kalibrering og kortkombinationen fortsat er tilladt; denne side er ikke en juridisk godkendelse.
3. Job, arbejdssteder og brancher
Der findes ikke en frit tilgængelig, komplet liste med hvert job på en præcis adresse. Derfor fordeler modellen kommunens officielle arbejdspladstal: 90 % mellem byområderne med en mild størrelsesvægt og 10 % efter hvor meget af kommunens landareal zonen dækker. Størrelsesvægten giver større byer lidt flere modeljob pr. indbygger end små, overvejende boligprægede byer.
Modellen er gjort klar til en dokumenteret korrektion, hvis en ensartet kilde senere viser, at en bestemt by har særlig høj eller lav erhvervstæthed. Der er ikke lagt håndvalgte byfordele ind. Indtil et sammenligneligt datagrundlag findes, er korrektionsfaktoren 1,00 for alle byer.
Kommunelisten viser de anslåede job for hver nået by, den øvrige del af kommunen som ligger i zonen, og – med gråt – resten af kommunens job uden for zonen. Bylisten viser for hver by kildeår og den formel eller særskilte, dokumenterede kilde, der ligger bag dens modelandel.
I standardkortet afgør den samme viste, afrundede rutetid både byens farve og om dens byandel medregnes. En vist tid på 60 minutter medregnes derfor ved et valg på 60 minutter. Byer indtil fem minutter over valget vises som “nær zonen”; ved 90 minutter kræver det rutedata til og med 95 minutter.
Små huller i en vejbaseret zone kan ligge i eksempelvis klit-, kyst- eller vådområder, selv om alle registrerede bypunkter nås. Hvis mindst 95 % af kommunen overlapper zonen, alle dens registrerede bypunkter nås, og den beregnede rest er under 100 job, medregnes denne lille restpulje. Det rå arealoverlap vises stadig i kommunedetaljerne.
En stor arbejdsplads i landzone – eksempelvis et slagteri uden for en by – placeres altså ikke præcist. Den indgår indirekte i landzonedelen. Det er en vigtig usikkerhed.
Hvert BY3-byområde i får vægten wᵢ = befolkningᵢ^1,10 × kᵢ. kᵢ er en valgfri evidensfaktor med obligatorisk kilde, årstal og beskrivelse; den er aktuelt 1,00 for alle byer. For hver kommune m er uₘ summen af vægtene for de nåede byområder divideret med summen af alle kommunens byvægte. Eksponenten 1,10 og en eventuel kᵢ er modelantagelser, ikke observerede jobtal for den enkelte by. rₘ er arealet af zonens overlap med kommunegeometrien divideret med kommunens areal. Til jobfordelingen bruges r*ₘ = 1, når uₘ = 1, rₘ ≥ 0,95 og ERHV2_jobₘ × 0,10 × (1 − rₘ) < 100; ellers er r*ₘ = rₘ.
Byernes viste heltal fordeles med største-rest-metoden inden for hver kommunes afrundede bybudget. Den viste landandel afrundes og begrænses, så byer i zonen + øvrigt område i zonen + job uden for zonen altid er lig kommunens afrundede ERHV2-total. Zonens viste jobtal er summen af kommunernes viste zonetal. Arbejdssteder og brancher beregnes med samme geografiske faktor; “Største nåede by” er en formidlingsindikator og ikke en adressebaseret optælling. Modellen kan både over- og undervurdere især industri, havne, hospitaler og andre store arbejdssteder uden for bymidter.
CVR's produktionsenheder kan stedfæstes, men den offentlige CVR-model angiver beskæftigelse i intervaller frem for et præcist jobtal pr. adresse. En fremtidig korrektion bør derfor beregnes reproducerbart for alle relevante byer ud fra samme CVR-årgang eller et mere detaljeret datasæt – ikke ud fra enkeltstående virksomheder. Den synlige byforklaring skifter da fra standardformlen til den konkrete kilde, årgang og faktor.
Lokale kontrolankre kan forskyde en hel kalibreringskurve for et udgangspunkt. De er ikke særregler for bestemte destinationer; alle destinationer fra samme udgangspunkt behandles med den samme kurve.
4. Datakilder, API-adresser og ajourføring
https://api.statbank.dk/v1/tableinfo/BY3 og https://api.statbank.dk/v1/data/BY3/CSV samt tilsvarende ERHV2-kald. Kilde: Egne beregninger baseret på tal fra Danmarks Statistik. Regler for kildeangivelse.https://api.dataforsyningen.dk/kommuner/<kode>?format=geojson og https://api.dataforsyningen.dk/steder?...&format=geojson. Datavilkår.https://api.traveltimeapp.com/v4. API-dokumentation · vilkår.Serveren cacher leverandørsvar for at sikre hastighed og begrænse API-forbrug. Cacheperioder og genbrug skal altid følge den aktuelle leverandøraftale. Årstal vises i brugerfladen, når datasættene er hentet. Kortet lover ikke realtidsdata.
5. Software, licenser og bidrag
Land og By står bag løsningen. Jonas Munkholm Jensen er angivet som udvikler. Data og software fra andre beholder deres egne rettigheder og krediteres her og i kortet.
- Leaflet 1.9.4 anvendes under projektets BSD-lignende licens.
- Turf 7.2.0 anvendes under MIT-licensen.
- OpenStreetMap-data anvendes under ODbL.
- Dataforsyningen, Danmarks Statistik, TravelTime og Google anvendes under deres respektive aktuelle vilkår.
- Selve dette repositories kildekode har p.t. ingen offentlig open source-licens. Almindelig ophavsret gælder derfor; offentlig tilgængelig kode er ikke automatisk fri at kopiere eller videreudgive.
Bidrag bør aftales med Land og By før indsendelse. Bidragyder skal have rettigheder til materialet og oplyse tredjepartsafhængigheder. Se også repository-filerne NOTICE.md og CONTRIBUTING.md.
6. Kendte usikkerheder og kontrol
- Start- og slutpunkter repræsenterer bycentre, ikke alle adresser i byen.
- Ruter, veje og leverandørmodeller ændres over tid; historiske resultater kan derfor ikke forventes at være identiske.
- Kalibreringen er lineær pr. udgangspunkt og kan ikke gengive alle lokale afvigelser i vejnettet.
- 90/10-fordelingen er en bevidst modelantagelse, ikke en officiel metode fra Danmarks Statistik.
- Små forskelle tæt ved en zonegrænse må ikke fortolkes som skarpe virkelige skel.
- Resultater bør stikprøvekontrolleres mod aktuelle, konkrete ruter og andre kilder, hvis de bruges i en vigtig beslutning.
Fejl og dokumentationsspørgsmål kan sendes til jonas@landogbyforeningen.dk.
7. Forberegnet jobheatmap
Heatmappet gør det muligt at se forskelle i joboplandet på tværs af hele Lemvig Kommune uden først at vælge en by. Farven viser det anslåede antal job, som kan nås fra et tæt net af lokale startpunkter inden for den valgte køretid.
Heatmappet er en hurtig screeningsvisning. Et klik viser tallet for det nærmeste 500-meterfelt. Den almindelige analyse for en valgt by er fortsat den mest detaljerede visning, fordi den beregner en rigtig køretidspolygon og det præcise kommuneoverlap for 10 %-landzonedelen.
Generatoren scripts/generate-job-heatmap.php placerer et 500-meter net inden for Dataforsyningens geometri for Lemvig Kommune. Punkterne sendes samlet som afgangssteder til https://api.traveltimeapp.com/v4/time-filter/fast. Resultatet forberegnes for 15–90 minutter i trin på fem minutter og gemmes som en statisk JSON-fil; normale sidebesøg foretager derfor ingen heatmap-API-kald.
90 %-bydelen repræsenteres af samtlige officielle BY3-punkter i analyseområdet med vægten befolkning^1,10. 10 %-landzonedelen repræsenteres af et ensartet 8-kilometer arealsample inden for hver kommune. Et sample, som routingmotoren ikke kan koble til vejnettet, springes dokumenteret over. For hvert 500-meterpunkt interpoleres hældning og skæring fra de fire nærmeste lokale Google Routes-kalibreringskurver med vægten 1 / afstand². Metoden undgår særregler for bestemte bypar, men både interpolationen og det grovere landzonesample giver ekstra usikkerhed.
Farveskalaen tilpasses for hvert tidsinterval mellem 5- og 95-percentilen, så lokale forskelle kan ses. Den er derfor en relativ visuel skala; popup-tallet er det relevante absolutte skøn. Den versionsstyrede fil indeholder kun koordinater og afledte heltal, ikke API-nøgler, persondata eller rå leverandørsvar.