Jag har under de senaste veckorna suttit och fnulat på en större import av hastighetsgränser i Sverige.
Först gjorde jag arbetet manuellt och har gradvis optimerat och optimerat till den punkt att jag nu sitter på ett script som skulle möjliggöra en större import av alla saknade hastighetsgränser från Trafikverket.
Notera: saknade! (inga ändringar av befintliga hastigheter)
Eftersom det handlar om ett större projekt så vill jag rådfråga communityn lite först. Jag beskriver först vad scriptet gör.
Scriptet jämför geometrin från OSM med den från Trafikverket med avseende på längd och geografiskt centrum och försöker avgöra om linjerna/way är identiska. Om så är fallet adderar den saknad hastighetsgräns till sträckan i OSM.
Detta kommer alltså bara att fungera på:
ways som redan är mappade väldigt snarlikt NVDB
på sträckor där det endast är en hastighet som råder. På ways som skulle behöva delas i flera hastighetssegment behövs det fortfarande göras manuellt.
Det handlar dock fortfarande om tusentals vägar som skulle kunna få hastighetsgränser rätt omgående.
Jag har gjort några lovande tester i Skåne. Scriptet tar inte miste på några geometrier. Dock kan felaktigheter förekomma, främst från NVDB självt (de räknar med en korrekthetsgrad på ca 95-96%)
Jag skulle isf tagga varje changeset med mechanical=yes och möjligtvis någon identifierbar tag?
Jag och några till, håller på med att manuellt importera NVDB till osm. Kommun för kommun. Genom att så mycket behöver uppdateras, tar det mycket tid. Att bara lägga till hastighetsgränser, för att slippa uppdatera allt, känns för mig meningslöst. Även om hastighetsgränser blir uppdaterade, så kommer mycket ändå vara fel och saknas i osm för de svenska vägnätet.
Föreslaget innebär en automatisk skriptimport till osm. En sådan import kräver att osm-regler för import är uppfyllda. Dessa regler finns dokumenterade på osm-wiki. Om man inte följer dessa regler finns stor risk för att alla ändringar tar bort!
Om någon vill göra en sådan här import, vilket jag personligen tycker är av ringa värde, så var så god. Jag hoppas bara att inte mitt och andras arbete med NVDB-merge inte blir förstört eller påverkad negativt på annat sätt.
Att bara lägga till maxhastighet där det saknas är väl inte fel (om det blir rätt!).
Men jag kan tänka mig att det finns del “utmaningar” (problem) att lösa.
Exempelvis där nuvarande vägsegment inte sammanfaller med hastighetsgränser, och att vägens uppdelning behöver ändras för att matcha dessa. Vilket i sin tur kan medföra problem med väg/rutt-relationer som är beroende av den befintliga uppdelningen.
Sedan tillkommer att de flesta vägarna som inte har uppdaterats från NVDB, har positionsfel. Ytterligare en “utmaning”. Speciellt om en sådan väg först måste delas upp i olika hastighetsdelar.
Som jag nämnde har mitt script begränsningar, men i vissa fall är de också självvalda.
Exempelvis vill jag inte ändra något där “maxspeed” redan finns utan endast addera taggen där det saknas. Att hitta felaktigheter skulle vara ett senare script-projekt.
Det enda mitt script gör är att lägga till taggen “maxspeed=x” till en way som scriptet identifierat som identiskt. Och nej, som jag skrev i ursprungsposten kommer det inte läggas till några maxspeed-taggar på sträckor som NVDB anser bör vara uppdelade. Det kommer att behöva göras manuellt.
Jag delar inte din åsikt att det är onödigt med maxspeed eftersom vägarna inte stämmer ändå.
Att förlita sig på default maxspeed har definitiva begränsningar, speciellt nu när stora ändringar sker 70-vägar blir både 60 och 80. 30 blir 40. 50 blir 40 osv. Det går åt båda hållen. Explicit är alltid bättre än implicit.
Att få hastighetsgränserna på plats skulle förbättra routing ordentligt.
Säkerhet. Som förälder ogillar jag personligen att sitta och köra på en 30 väg och min navigeringsapp står det att jag får köra 50. Ibland sneglar folk på appen för att minnas vad det är för hastighet. Då bör det vara så korrekt som möjligt.
Mitt script skulle plocka all lågt hängande frukt i Sverige vilket är tusentals vägar, men ja, det skulle återstå arbete med vissa stäckor. Dessa skulle dock vara betydligt lättare att identifiera om övriga sträckor var taggade så gott det går.
Jag vill bara försäkra mig om att det inte finns något projekt i konflikt. Exempelvis där man tar bort hastigheter eller vägar och gör allt från scratch igen?
Jag delar inte din åsikt att det är onödigt med maxspeed eftersom vägarna inte stämmer ändå.
Jag håller med dig @moaxed. Även om en väg inte är 100% tipptopp (som de blir efter @Msiipola’s NVDB-merge), så är ändå en operfekt väg MED hastighetsgränser bättre än en operfekt väg UTAN hastighetsgränser.
“Stor förbättring” är förstås bättre än “liten förbättring”, men “liten förbättring” är trots allt oändligt mycket bättre än “ingen förbättring”.
Allt som tillför nåt, tillför nåt. Jag röstar på kör
Kul!
Jag tror att jag inleder med att hålla nere storlek på changesets och fortsätter att manuellt kontrollera resultaten ett tag. Håller mig även fortsatt i Skåne som jag känner hyfsat till.
Jag lägger även till taggen #SweFixMaxspeed för er som vill följa/kontrollera resultat.
Som jag nämnde tidigare måste import göras enligt det mycket specifika regler som finns. Strunta inte i det!
Annars kan man räkna att det blir revert på allt!
Det vore intressant att få höra problemet med olika hastighet på olika segment ska lösas. I de fall väg inte är uppdelad enligt hastighetssegment som finns i nvdb.
Ska skriptet dela upp vägen enligt nvdb:s hastighetssegment?
Om ja, hur löses problemet med att en relation för väg/rutt då kan bli ogiltigt?
Om nej, så finns risk för att fel hastighet placeras på en del av ett segment. Jämfört om vägen hade delats upp i segment enligt nvdb.
Vet ej ännu. Mitt script befattar sig inte med de sträckorna utan ignorerar dessa. Jag tror att såväl dessa sträckor som segment med olika hastighet i olika riktningar fortsatt kommer att behöva editeras manuellt.
Dock tror jag att det manuella arbetet kan underlättas mycket om man vet var man ska söka.
Ponera att mitt script lyckas fånga 70-80% (har ingen aning om så är fallet. enbart hypotetiskt) av vägsträckorna där geometrin är god och enhetlig hastighet råder. Det kommer att vara betydligt tydligare efteråt var det faktiskt krävs manuellt arbete. De mänskliga resurserna är begränsade så varför inte frigöra tid åt det som faktiskt kräver precisionsarbete och noggrannhet.
Du har förmodligen redan noterat att hastighetgräns finns färdigt inlagd - nära nog fullständigt - på vägarna (ner till tertiary) i Hallands och Västra Götalands län samt delar av Östergötlands län (overpass turbo)(OBS utsökningen tar lite tid, men risk för timeout är obefintlig). Allt per manuell hantering, där hastighetsgränsen lagts in på respektive vägavsnitt (där den hör hemma), med puts efteråt på de diverse rutter som har skadats genom uppdelningen av vägsträckorna. Har tagit systematiskt vägarna i kommun för kommun (förutom i Östergötland, där annan kartritare har arbetat (jag vill minnans via import).
För mig är det obegripligt hur du kan placera rätt hastighetsgräns på respektive vägavsnitt utan manuell hanteing, dvs utan uppdelning av vägsträckan och lagning av rutterna. Låter som forna tiders alkemism.
Det låter som skriptet behöver vara lite mer avancerat. Skriptet vi använder för att konvertera NVDB-databasen i NVDB-projektet en del av oss jobbar med är ca 7000 rader python-kod, och all uppdatering/sammanfogning därefter sker manuellt, så rent formellt är det “assisted manual mapping” snarare än automatiserad import. På sikt är det tänkt att göra ännu ett skript som är tänkt att hitta skillnader som gör det lättare att underhålla en kommun som redan har en bra grundstatus. Problemet är att många kommuner är i ganska dåligt skick, då det är bara delar av Sverige som har aktiva kartläggare. Medan man i t ex i Göteborg har hunnit så långt att man är nere och kartlägger enskilda träd och parkeringsplatser hittar jag här i norra Sverige vägar och huskroppar som ligger 40 meter fel, ett stort antal saknade vägar och gamla taggar.
Därför har vi gjort bedömningen i detta tidiga skede av projektet att man måste gå igenom hela kommunen manuellt så att man är säker att lägstanivån är hög. Detta med att bara uppdatera lite här och där slumpmässigt leder till en karta som inte går lita på för man vet inte var det är bra och var det är dåligt. När Sverigekartan håller en hög lägstanivå är det enklare att göra skript som automatiskt söker upp ställen som behöver uppdateras.
Att sammanfoga manuellt innebär inte att man behöver skriva in taggarna manuellt varenda gång, de finns i NVDB-geometrin. Det manuella rör matchandet av geometrin, justera annan geometri som inte hör till vägarna men ligger uppenbart fel (hus mm), och bedöma när det blir konflikter med taggar. Det blir ganska ofta konflikter med maxspeed för det som ligger inne i ouppdaterade kommuner är ofta hastighetsgränser från förr, t ex 90 där det nu är 80, och man har ofta hoppat över hastighetsförändringarna som sker genom byar.
Paradoxalt innebär det mer arbete för oss som sammanfogar om någon har lagt in data som inte är exakt rätt, tex om hastighetsbyte ligger på fel ställe, då är det bättre att man inte lägger in nåt alls.
Det är också värt att nämna att vi valt att inte ta med hastighetsgränser som inte är skyltade. NVDB har mycket hög kvalitet på datat, men det finns problem inom vissa enskilda områden, och ett av dem är hastighetsgränser på enskilda vägar, “implicit maxspeed”. De verkar har nån slags area-modell, och de där areorna verkar vara sådär… helt plötsligt kan det dyka upp ett 50-segment mitt inne i skogen fast det naturligtvis inte är så i verkligheten. På alla allmänna vägar där hastighetsgränserna är skyltade är det däremot väldigt hög kvalitet, det är i stort sett bara NVDB inte hunnit uppdateras efter nybyggnationer det är felaktigheter. I nåt enstaka fall har det varit olika hastigheter i olika riktningar vilket jag tyckt sett konstigt ut så jag har gått in och kollat på vägfoton från streetview/mapillary och sett att det faktiskt varit rätt.
NVDB saknar information om när hastighetsgränser är skyltade och när de är implicita tyvärr, men det går i regel räkna ut från typ av väg. Mitt förslag är att inte ta med implicita gränser, och gör man det bör man nog ha implicit-taggar för det.
Jag är försiktigt positiv till initiativet, men skulle hellre se att det sker som en del av NVDB-importprojektet. Du bör också se till att dokumentera din importprocess med vilka verktyg/skript du använder, hur du har tänkt att genomföra den, m.m. på wikin innan du sätter i gång i större skala, och också rådfrågar gemenskapen igen när en sådan sida finns.
Mitt svar ovan kanske låter lite negativt, men överlag är jag positiv till att folk lägger ned tid för att förbättra kartan på det sätt de finner lämpligt och kul. OSM är “kaotiskt” i sin natur, man kan inte räkna med att alla gör på det sätt man själv tycker är bäst, man får samsas med olika metoder och ideal. Det OSM allra främst behöver är ju folk som uppdaterar kartan. Alla sätt är bra, utom de dåliga, som man brukar säga. Nu finns det redan ett NVDB-importprojekt som tar ett helhetsgrepp och inte bara hastighetsgränser, och jag ser förstås hellre att man lägger ned tid att hjälpa till där än att skapa ett partiellt importprojekt som gör samma sak fast en delmängd, men om det är det man brinner för, så visst kör på.
Jag håller dock fast vid att skriptet behöver se till att hastighetsgränser hamnar på rätt ställe, och det kommer kräva att man ändrar geometrin, delar upp segment så ändring av 50 till 70 osv hamnar där skylten står.
Det har redan nämnts, men i det pågående import-projektet har man avsiktligt låtit bli att lägga in de bashastigheter som finns i Sverige (50/70/110) (Bashastighet). Detta är avsiktligt och beslutades efter diskussion med community. Det är inte ok att lägga till alla dessa, utan att ta hänsyn till de diskussioner och beslut som togs. Om det ska ändras, måste community åter diskutera för- och nackdelar med att lägga in bashastigheter i osm. Och införande av dessa får inte ske bara för att någon personligen tycker det är bra.
Bashastighet är ju också närmast ett icke-begrepp i Sverige, hastigheten är nästan alltid skyltad på allmän väg. De två bashastigheter som finns är 50 km/h (inom tättbebyggt område) respektive 70 km/h (utanför tättbebyggt område). På motorväg gäller 70 km/h om inget annat skyltas. Det finns väldigt liten mening med att försöka ange dem på något annat sätt än maxspeed=50 / maxspeed=70, eller göra antaganden om vilken hastighet som gäller på en särskilt väg enbart baserat på dess placering. Man måste se till den data som finns i NVDB/STFS för att ta reda på om en väg har annan hastighet än bashastigheten.
För mig är det inte i närheten av fullständigt om unclassified och residential inte är mappat? Och ja, jag har ägnat de senaste veckorna åt att kika igenom hela trunk/primary/secondary-nätverket i Sverige som hade enorma brister. När jag skulle ge mig i kast med tertiary insåg jag att det behövdes effektivisering - därav scriptet, särskilt senare för residential.
Beror helt på vilka krav på noggrannhet du har? Du skulle kunna säga åt ett script att distribuera noder (enligt önskad toleransnivå) längs en befintlig väg och sedan genom NVDBs angivelser räkna ut vid vilken nod det är lämpligast att dela vägen - addera hastighetsgränserna - och sedan rensa upp bland noderna? Inte alkemi. Mest matte.
Om man vill göra en komplett import, ja. Definitivt. Min önskan är att kunna plocka den lågt hängande frukten för att sedan ägna sig åt det som verkligen kräver manuellt arbete eller ett mer krävande script. Mitt script passar exempelvis för sträckor som redan överensstämmer med NVDB, har enhetlig hastighet och förerträdesvis kortare sträckor (exempelvis korta residentials, längre redan välplacerade sträckor med enklare geometri).
Jag tycker att Sweden Import projektet är imponerande och har kikat igenom de färdigställda kommunerna. De ser fantastiska ut! Men: Av progressidan har 40 kommuner färdigställts på cirka 2 år och då flera mindre kommuner, de stora kommunerna kommer sannolikt ta ännu längre tid? Vi pratar alltså om ett projekt på ytterligare minst 13 år för att färdigställa Sverige i nuvarande takt. Jag är inte beredd att ge mig in i ett sådant projekt. OSM är en hobby för mig och jag vill att den hobbyn ska förbli rolig, men samtidigt utmananade. Jag kan bidra på de områden jag behärskar och roas av. Exempelvis scripting, automatisering, felkontroll osv. Detaljredigering gör jag gärna på de områden som jag har väldigt god lokalkännedom kring.
Det här är ju väldigt hårda ord. “Införande av dessa får inte ske?”
Då skulle jag verkligen vilja ta del av argumentationen om communityt anser det så problematiskt i Sverige? Vad jag förstår har andra lokala communities motsatt uppfattning. Att man inte tycker om “implicit speed”. Varför ska just Sverige använda sig av implicit? Jag tycker att förlitande på default/implicit speed är ett jätteproblem. Långa sträckor inom tätbebyggt område är 30-vägar som nu visas som 50. Samma sak vanligt med 50-segment på 70 vägar som nu defaultas som 70 rakt av. Det ger systematiska fel i routing och driver trafik in på gator som inte är lämpligast för genomfart osv. Jag tycker också att explicit alltid är bättre eftersom det möjliggör bättre arbetsflöden/filtrering osv.
Jag är inte beredd att vänta åratal på att få till hastighetsgränser i Sverige, men vill inte stöta mig med en hel community. Inleder med att mappa de områden som känner till så att det blir mer att betrakta som assisted mapping. Slutligen en bild på ungefär vilken typ av sträckor som scriptet kan addera taggar på:
Röda ringar: scriptet kommer ignorera dessa pga antingen multipla hastigheter eller komplicerad geometri.
Blå ringar: scriptet kommer att tagga dessa med rätt hastighet från Trafikverket pga enkel geometri och sammanhängande hastighet (den overlay) som syns på bilden)
Kommer befintliga vägar att delas upp för att passa väg/hastighetssegment enligt nvdb för motsvarande väg, i de fall dessa segments start- och slutnod inte överensstämmer exakt i både osm och nvdb? (“exakt” definieras)
Om ja, hur hanteras relationer för sträckan som delas upp?
Om nej, kommer hastighet ändå att sättas för en sträcka så att start/stop är ungefär rätt? Alternativt att vägar där hastighetssegment inte överensstämmer mellan osm och nvdb inte ändras/uppdateras alls?
Kommer bashastigheter att adderas trotts detta inte gjorts tidigare?
