NVDBs "Länsfiler" vs "Vägdata för transportplanering"

[tekeroth-snapcode]

Hej! NVDB har olika "färdiga datapaket" man kan ladda ner och jag funderar på det som de kallar för "Länsfiler" jämfört med "Vägdata för transportplanering".

NVDB säger själva om länsfiler enligt följande:

På Lastkajen ligger det länsvisa databaser med NVDB-data och dessa fungerar bra om man exempelvis ska skapa webbkartor eller då man vill hantera varje företeelsetyp, d.v.s. objekt eller egenskap, var för sig. Men om man försöker använda det för ruttning utan att bearbeta det får man snabbt problem.

Läs mer om det här: https://lastkajen.trafikverket.se/assets/Ruttning_med_NVDB.pdf

nvdb2osm fungerar dock med dessa länsfiler (man måste dela upp per kommun dock) men scriptet kör vad jag förstår.

Frågan är: Fixar/konverterar/lagar detta script det som NVDB säger saknas i datan?

Anledningen till att blir så här är att den datamodell som används i NVDB inte är tänkt för användningsområdet ruttning. Istället är syftet att skapa en databas där länkar och deras identiteter är stabila över tiden och företeelser inte behöver förändas om en ny väg ansluter till en befintlig väg. Det här betyder att exempelvis Transportstyrelsen inte behöver räkna om kopplingen till nätet för sin information om trafikolyckor vid varje nätförändring.

Det här gör att ruttning på geometrierna som kommer från en enstaka företeelsetyp från exempelvis Lastkajen inte ger förväntat resultat och det kan skapas omotiverade öar i ruttningslagret.

En sak till som försvårar ruttning baserad på NVDB-data är det faktum att varje objekt eller egenskap lagras i ett eget lager. En hastighetsgräns vet var på en utpekad länk den gäller men det finns ingen direkt koppling mellan den och en förbjuden färdriktning eller information om slitlager. En ruttningsalgoritm som direkt baserad NVDBs datamodell måste alltså för varje given position leta i en mängd lager för att beräkna vilket motstånd som gäller för länken, något som inte är görligt i de flesta programvaror.

Sedan finns då "Vägdata för transportplanering". Det är en enda stor fil för hela Sverige och beskrivs såhär:

Istället finns datapaketet ”Vägdata för transportplanering” där egenskaper viktiga för ruttning ärvts ner till väglänkarna genom en så kallad homogenisering. Detta lager kan användas som indata för olika ruttningsapplikationer efter det att man beräknat motståndet att färdas längst en länk.

(se t ex här: https://lastkajen.trafikverket.se/productpackages)

Vad jag förstår kan nvdb2osm inte hantera "Vägdata för transportplanering".

Finns det några planer på att stödja en konvertering av denna till OSM istället för de länsvisa?

Tack!

[atorger]

Homogeniserat data är bara flera lager hopslagna till en enda databas. Det är samma data. NVDB2OSM behöver inte det, det läser in lagrena separat och slår ihop allt själv till homogeniserat data, och analyserar det och genererar OSM-data som per definition är homogeniserat.

Hade det funnits bra homogeniserat data från början när NVDB2OSM-skriptet gjordes hade det antagligen använt de homogeniserade filerna direkt, eftersom att slå ihop lagrena själv är mer komplicerat än det låter då NVDB:s data är ~sådär i precision och det inte passar ihop perfekt alla gånger så skriptet måste vara "smart".

Från början var det bara separata lager som gällde, så det är så skriptet är byggt, och nu när funktionaliteten finns är det för närvarande inget värde i att byta till homogeniserat format. På sikt kan det vara det (man kan då kapa bort typ 4000 rader kod från skriptet, och körtiden blir snabbare), men Trafikverket har ändrat sina dataformat flera gånger bara de senaste två åren så det är inte lämpligt att göra något den närmsta tiden.

En fördel med att behandla lagrena separat är att man får en bättre bild av hur datat hänger ihop och datakvalitén för de olika fältena. Går man direkt på de homogeniserade filerna får man den homogenisering som trafikverket gjort utan att riktigt veta vilka avvägningar de gjort, om några, när data inte passar ihop.

[atorger]

Kan vara värt att nämna att NVDB2OSM inte använder de olika lagrena för rekommenderad färdväg för olika transporttyper. OSM är en geodatabas, och ruttningen görs inte av OSM som sådant utan av externa verktyg, och tanken är att de ska använda information om vägens förskaffenhet för att räkna ut en rutt, inte centralt bestämda rekommenderade färdvägar. Det hade nog kanske inte varit fel om ruttverktygen kunde ta in sådan information, men mig veterligen är det inget som gör det och det finns inga lämpliga OSM-taggar att använda för att speca rekommenderad färdväg. Om det finns så vore det förstås bra att använda de lagrena också.

I filerna tag_translations.py och process_and_resolve.py görs den mesta översättningen om man är intresserad av detaljer i hur det funkar nu.

[tekeroth-snapcode]

Tack för snabbt svar.

Om jag förstår det rätt föredras glt enkelt att sammanslagning och tolkning görs av scriptet då man slipper förlita sig på nvdb, samt att länsfiler duger eftersom scriptet löser problemen som annars finns där.

Finns det några planer på att hantera hela län direkt, utan att dela upp i kommuner?

[atorger]

Jag tror man kan hantera hela län direkt redan nu bara man har tillräckligt med minne i datorn. Kan möjligen behövas nån parameterjustering då det är upplagt för att lägga till läns- och kommunfilter och det är så vi alltid kör, men det är i så fall minimal kodförändring.

Anledningen att vi delar upp i kommuner är att resulterande data blir annars väldigt stort och svårhanterat, man knäcker JOSM om man laddar in en hel länsfil om man inte har en väldigt kraftfull dator. Dessutom vill man när man sammanfogar arbeta i väldefinerade avgränsade bitar, och därför har vi egna uppdelningsfiler för att dela upp större kommuner ytterligare till mer lätthanterliga bitar. Vi brukar dela en kommun i 10 - 20 bitar.

Om man vill av annan anledning har en enda stor OSM-fil (t ex för maskinell analys och behandling av något slag, att jobba med det manuellt är inte så praktiskt) så ska det vara enkelt att få till om det nu inte redan funkar.

[tekeroth-snapcode]

Jag har def intresse av att konvertera hela län; manuell bearbetning efteråt är inte något jag behöver göra, det viktiga är att ruttningen blir bra/korrekt baserat på underlaget.

Skulle du kunna peka hur man enklast moddar detta för att hantera hela län i en körning och få en fil?

Tack!

[atorger]

Borde gå fixa i startfilen nvdb2osm.py. För någon som programmerar python borde det gå hyfsat enkelt. Jag vill dock inte råka ut för att supporta något sidoprojekt så du får försöka hitta någon annan som kan hjälpa dig med kodningen :-). Skriptet är gjort specifikt för kartläggningsprojektet som beskrivs här: https://wiki.openstreetmap.org/wiki/Import/Catalogue/Sweden_highway_import/Import_guidelines och vill fokusera min egen begränsade tid bara på det som behövs för det projektet.

[tekeroth-snapcode]

Absolut, det förstår jag. Ska se om man kan dechiffrera scriptet. Tack.

[tekeroth-snapcode]

Stängde lite för tidigt. Om man försöker konvertera en hel länsfil, så får man ett antal fel, så det verkar inte fungera (men man behöver inte ange municipality_filter om man inte vill vilket är bra). Felen är ex:

2023-05-06 10:03:30,476 - nvdb2osm - INFO - No file name NVDB-Reflinjetillkomst.gpkg (or .shp) in ../input/Sodermanlands_lan_GeoPackage.zip 2023-05-06 10:03:30,477 - nvdb2osm - INFO - No file name NVDB-FunkVagklass.gpkg (or .shp) in ../input/Sodermanlands_lan_GeoPackage.zip

Det verkar som om split-scriptet delar upp lagren i olika filer, som sedan main scriptet använder, dvs main script kan inte arbeta direkt med det som laddas ner, utan det måste splittas för att det ska fungera?

[atorger]

Ja verkar så. Det kommer hursomhelst bli väldigt jobbigt om ni för ert projekt inte har någon som kan Python tillräckligt bra för att ändra skriptet till att göra det ni vill. Funktionen att läsa in hela länsfiler är inte relevant för vad skriptet finns till för (kartläggningsprojektet länkat ovan), så att det inte klarar av det rakt av är inte att anse som ett fel utifrån vårt perspektiv.

Det är förvisso troligen en smal sak att lägga till det och jag vill inte verka brysk, men jag vet av erfarenhet hur sånt här brukar sluta -- det kommer uppföljningsförfrågan efter uppföljningsförfrågan helt enkelt för att projektet behöver en programmerare men saknar en. Jag måste be er att lösa programmeringen som krävs för ert eget projekt själva.

Jag kan ta in pull requests (andras patchar) om de inte stör syftet med nvdb2osm (externa patchar har tagits in tidigare), men skriver inte dem åt andra.

[tekeroth-snapcode]

Jag förstår att vi får göra kodningen själv 👍🏻 Jag ställer frågor bara som kontroll så att jag kan bekräfta att jag förstått att det är så det fungerar idag, mest som verifiering att jag inte missat något uppenbart.