Ett sidospår, men jag vill ändå kommentera.
Ja import-projektet går mycket långsamt takt, beroende på endast några vill bidra. En mindre landsortskommun tar ca 40-50 timmar att göra. Om flera vill ta på sig en sådan uppgift skulle färdigställandet gå fortare (än 13 år).
Dessa brister är just en av de saker import-projektet åtgärdar. Men vad jag tror mig förstå så kommer det “nya” skriptet att inte rätta dessa fel. Och därför inget som är relevant för denna diskussion. Eller har jag missförstått?
Så länge korrekta hastighetsgränser läggs in så har jag inget principiellt problem med det. Bättre än inget. Och det är kul att nån är otålig och vill ha in data, hoppas entusiasmen håller i sig, det kan vara lite jobbigt att interagera med “the community”, alla har en åsikt 
Det är ju också så att vi har i NVDB-projektet ägnat rätt mycket tid åt den här utmaningen att tolka NVDB-data för OSM-användning, och att då någon gör samma sak en gång till på sitt eget vis och stöter på samma problem som vi gjort en gång till istället för att hjälpa till i existerande projekt kan verka lite onödigt. Om du vill använda det vi redan gjort kan du utgå från OSM-filen nvdb2osm-skriptet genererar istället för NVDB direkt, då kommer en del behandling med, t ex tidsbegränsade hastighetsgränser utanför skolor och sådant.
Sen är frågan hur man ska göra med implicita hastighets-taggar. Den nöten har vi inte knäckt, utan lägger helt enkelt inte in dem. Alltså detta:
https://wiki.openstreetmap.org/wiki/Key:maxspeed#Implicit_maxspeed_values
jag har sett i mitt arbete att en del har manuellt lagt in implicita maxspeed. Pga inexakthet i NVDB-data och ingen tydlighet i var det är skyltat och inte så kör vi inte på NVDB på enskilda vägar utan håller oss till där det kan förväntas ha hög kvalitet, kommunala och allmänna vägar.
Anledningen att det tar lång tid med NVDB-projektet är att det är bara ensaka personer som jobbar med det. Hade vi varit 50 aktiva istället för 1-2 aktiva åt gången som det är nu hade vi varit klara nu. Sen kommer vi nog inte gå igenom alla kommuner, en del uppdateras ju väldigt aktivt med traditionella metoder med många aktiva mappare, storstadsregionerna t ex. Jag kör mest norr- och västerbotten själv, gjort lite i västernorrland. Där har det varit stort behov av uppdatering, det går också ganska fort framåt. Jag kommer troligen själv bli klar med hela Norrbottens län under det här året. Kanske blir startpunkten för att börja fundera på ett uppdateringsskript. Hursomhelst det går ju inte fortare för att ingen ansluter 
Att det är få aktiva beror på att det är relativt hög tröskel att gå med, och de flesta vill jobba på sitt egna vis och väldigt lokalt. Utöver mitt NVDB-arbete gör jag även “mys-mappning” på mina lokala hemvister där jag går stigar med GPS och sådant, så det ena utesluter inte det andra, men det är svårt att få folk att ställa upp.
Ett litet sidospår;
Det ska sägas att det är ingen som riktigt vet vad status på Sverigekartan är, dvs var kvalitén är hög och var den är låg, för det finns inga verktyg som kan göra den typen av utvärdering. Med par månaders programmerande skulle man nog kunna göra ett skript som kan göra en visualisering så man kan få lite bättre överblick.
Då mitt eget intresseområde är främst norra Sverige har det räckt med att se att var jag än tittar har det varit ganska risig bitvis, så därav har jag inte sett något behov ännu att ta fram ett verktyg som pekar ur var behoven är som störst, utan det har känts mer relevant att helt enkelt höja kvaliteten på kartdatat där jag står.
Det börjar dock närma sig tiden då jag själv kommer börja ha ett intresse av att veta var OSM-kartan är utdaterad och behöver uppdateras.
Som jag själv skulle göra detta är att göra ett verktyg som kan ta en OSM-fil som är genererad av nvdb2osm och jämföra med datat som finns i databasen och sen generera en fil som innehåller endast skillnaderna. Detta är mycket enklare sagt än gjort, men jag har en del idéer hur man ska göra. Efter man har det verktyget kan man dels göra manuella sammanfogningar med det, samt göra en kartvisualisering som går igenom alla kommuner (åtminstone de som redan synkats en gång mot NVDB) och målar ut var skillnaderna är.
Detta ser jag som en väldigt viktig fortsättning på NVDB-projektet och kräver ganska avancerad programmering, men det finns också mycket som redan är gjort och inspireras av då flera andra europeiska länder har gått igenom liknande processer.
Många har förstås efterfrågat ett skillnadsskript att köra först så man inte behöver gå igenom hela kommunen, men jag har varit emot det av enkla anledningen att då kommer det fortfarande vara så att det är ganska oklart vilken lägstanivån på kartläggningen är. Jag tror det är mycket bättre att först göra en komplett manuell genomgång och uppfräschning av kommunen, och först därefter använda sig av skillnadsskript för att hålla sig uppdaterad med nybyggnationer och ändringar.
Och jag svarar igen. Nej.
Hastighets sätts bara om way i OSM och i NVDB överenstämmer i avseende av längd och geometri, så hastigheter sätts bara där det är möjligt att sätta på en hel way, annars uppdateras inget alls.
En fråga för communityt. Möjligheten finns om man vill. Just nu är jag restriktiv och avstår “unclassified”-vägar exempelvis. Däremot tycker jag personligen att man ska mappa 50/70, framförallt i tätort.
Tack! Det är intressant att kika på också. Jag har skummat igenom ert script och det som rör hastigheter är snarlikt det jag själv gör, men istället för att skapa ett nytt korrekt lager som sedan manuellt överförs så låter jag datorn reda ut vilka ways som redan är tillräckligt bra.
Ett sätt skulle kunna vara att först filtrera fram metadata på “längst-tid-sedan-redigering” och därfirån använda ungefär det omvända av vad mitt script gör. Leta efter snarlika, men ändå avvikande geometrier. Det kommer säkert behövas lite trial and error för att hitta rätt gränsvärden, men inte omöjligt.
FYI vi mappar 50/70 i tätorter då det är mycket hög sannolikhet att dessa är skyltade. De som filtreras bort är endast 50 och 70 på vägar som motsvarar service/unclassified/track.
Det görs av funtionen “remove_redundant_speed_limits” i filen “process_and_resolve.py” nvdb2osm om du vill kika exakt hur if-satserna ser ut. Namnet på funktionen är kanske lite olyckligt, den borde nog heta typ “remove_likely_implicit_speed_limits()”. Och “remove” är alltså endast från den fil som nvdb2osm genererar, alltså NVDB data som inte tas med i den färdiga filen som sen används för manuell sammanfogning.
Ok, då undviker även jag mappning på service/track/unclassified så hålls det enhetligt tills vidare.
Jag noterar att detta projekt har startat.
Var finns detta projekt beskrivet?
Och behövs det inget godkännande av community?
1 Like
Nja. Jag sitter och lägger in changesets manuellt. Men använder scriptet som filtrering på villka objekt som är intressanta att mappa. Att göra en import fick jag ingen känsla av att någon var särskilt intresserad av. Sedan fattar jag ärligt talat inte vad som är “projekt” och inte. Jag har inte skrivit en bot, det är inte ett “collarborative effort” och jag gör ingen import. Det jag gör är bara att ha hjälp av ett script vid filtrering?
Bland annat i denna tråd.
Men om det behövs ytterligare beskrivning av vad jag ägnar mig åt.
- Jag har skrivit ett program i Rust som tankar hem ISA-hastighetsdatasetet från Lastkajen, Trafikverket.
- Omvandlar geopackaget tll geojson för att kunna utnyttja vissa Rust-bibliotek.
- Laddar hem OSM-data genom Overpass API.
- Låter programmet matcha Linestrings i Trafikverkets data med Linestrings i OSM.
a) med avseende på längd - högst 5% avvikelse tillåtet
b) med aveende på geometriskt centrum (centroid) - kring 10 m avvikelse tillåtet ca
c) på bounding box av geometri - kring 10 m avvikelse tillåtet
Lite beroende på län kan jag stretcha toleransnivåerna. Ju bättre mappat det är från början desto tajtare kan man vara. Om det är stora avvikelser så går att fånga många sträckor ändå, men behövs lite skruvande på parametrar.
Om dessa matchar och sträckan i OSM saknar hastighetsdata så läggs sträckan med ny hastighet till i en ny fil som jag sedan öppnar i JOSM och går igenom manuellt för att se att inga outliers smugit sig in.
Jag begränsar varje körning till ca 2000 ways för att det ska vara möjligt att manuellt gå igenom. Tror dock att programmet närmat sig det som gick att hitta - dvs den lågt hängande frukten. Inte räknat ihop totalt mappade way men har gissningsvis hittat några tiotusen ways på detta sätt. Det återstår nu ca 90-95000 ways utan hastighetsangivelse i Sverige ( om vi räknar bort unclassified/service/track). Jag kanske skulle kunna hitta några tusen till med programmet, men resten kommer behöva manuell uppdelning av ways.
Ingen aning. Jag vet varken om detta kallas ett projekt eller inte och jag har ingen aning om var communityt finns?
Jag trodde att jag skrev på communitys forum nu till exempel?
Upplys mig. Hur ser beslutsgången ut?
Går det att svara på dessa frågor?
Varför ska OSM innehålla hastighetsgränser?
Vilka applikationer använder hastighetsgränser?
Varför vill man använda OSM för ruttplanering?
Tack för svar!
Kutym är att skapa en sida på wikin (exempel, du behöver inte vara lika fullt utförlig) där du sammanfattar vad ditt projekt går ut på, ungefär som du har gjort i denna tråd och dit senate inlägg. Detta för att mer permanent dokumentera det hela än en forumtråd som lätt glöms bort.
Det stämmer, och du har gjort rätt i och med att du sökt stöd för dina ändringar. Däremot så gick du vidare med att lägga in ändringarna i OSM utan att ordentligt dokumentera din import som skrivits ovan. Någon formell beslutsgång finns inte, så länge den svenska OSM-gemenskapen verkar vara positivt inställd till dina föreslagna ändringar kan du gå vidare. Däremot finns risken att om du inte har förankrat dess ändringar tillräckligt eller om du struntar i vad folk säger, så kan DWG bli inblandade och dina ändringar rullas tillbaka.
Det är observerbar fakta som enkelt går att beskriva och lagra i en geografisk databas, precis det OSM är till för. En del gillar att kartlägga vägar och dess egenskaper, andra ritar in byggnader, kraftledningar, sjöar, vindskydd, osv.
I princip alla appar som erbjuder någon form av navigation baserat på OSM-data, t.ex. OsmAnd, Organic Maps, m.fl.
Kutym är att skapa en sida på wikin (exempel, du behöver inte vara lika fullt utförlig ) där du sammanfattar vad ditt projekt går ut på
Borde inte NVDB-projektsidan finnas länkad på wiki-samlingssidan också, där “alla” projekt finns?
Nvdb-import projektet betraktas inte som en skriptad import, eftersom allt arbete görs manuellt och man använder genererade nvdb-osm-filer endast som referens/mall.
Av det skälet är inte nvdb-import dokumenterad på sida “Import/Catalogue”. Vilket också den internationella community har godkänt, vad jag vet. Exakta detaljer vad som har beslutas, vet Anders Torger bättre.
Projektet finns nu beskrivet här och har adderats till listan över projekt.
1 Like
Uppdatering:
Scriptet börjar nu slå i taket beträffande potential, lyckades dock med lite tweakande tagga ytterligare 18000 vägar.
Det återstår nu ca 72 000 vägar i Sverige som saknar hastighetsgräns. Inte räknat efter ordentligt men uppskattningsvis har scriptet lyckats tagga ca 200 000-250 000 vägar.
Återstående vägar kräver ett modifierat script och/eller manuellt arbete.
Framförallt beror det på att detta script matchar enskilda geometrier, dvs en way i OSM måste motsvara en way i NVDB.
Det finns dock en sak man skulle kunna prova, vilket jag ska göra vid tillfälle: att låta vissa NVDB vägar kopplas ihop (om de har samma hastighet) och sedan matcha kombinationer mot OSM. Krävs lite tilläggs-programmering så får bli när tid och ork ges.
1 Like
Det finns anledning till en väg är uppdelad i nvdb. Att två intilliggande delar har samma hastighet är inte tillräckligt för att koppla ihop dessa. Exempelvis att vägbredd eller maxvikt är olika.
I osm finns också vägsegment som ingår i relationer/rutter. Endast om samma relation/rutt finns på samtliga segment, får segmenten slås ihop.
Det är ju bra att vägar får maxhastighet satt, men många vägar saknar fortfarande maxhastighet. Eftersom den automatiska taggning som har gjorts, har exkluderat många av dessa.
Exempelvis i ett mindre samhälle jag jobbat med (Tumbo, Eskilstuna kommun) , har nu några korta vägar (typ servicvägar) fått maxhastighet, medans “huvudvägen” som förbinder dessa småvägar, saknar det. På vilket sätt förbättrar detta routing, vilket jag förstår, var huvudanledningen till projektet?
Ja, man kan stirra på detaljer som “varför har den här lilla vägen fått en maxspeed-tagg, det måste väl ändå vara helt värdelöst?”. Eller så kan man se det som “250000 vägar som tidigare saknade maxspeed har nu fått det, det är ju jättebra!”. Jag väljer det senare synsättet
Ja, @moaxed har väl hela tiden varit totalt öppen med att om det råder några som helst tveksamheter för en viss way, så låter hans script bli att editera taggarna där. Hur kan det komma som en överraskning att inte ALLA vägar därmed har blivit uppdaterade?
2 Likes
Nej, ingen överraskning alls. Åtminstone inte för mig. Jag redovisat mina synpunkter i tidigare inlägg. Uppdatera vägnätet i osm från nvdb, är inte enkelt. Inget som löses med ett skript man tar fram på kort tid.
Antalet vägar som uppdaterats är imponerande. Men jag antar det är “ways” som redovisas och inte vägar (väg=flera ways)? En mindre kommun har många tusen ways. Stora kommuner flera 10-tals tusen. Med 290 kommuner blir totalen gigantisk.
Mer intressant hade varit att få statistik på exempelvis:
- Hur många ways saknas i osm jämfört med nvdb?
- Hur många ways i osm saknar hastighet?
Maxspeed-projektet tog den lågt hängande frukten från NVDB, men om man ska gå vidare, så blir det mycket mer komplicerat.Vilket det pågående NVDB-vägimportprojektet försöker lösa.
Med det sagt vill jag dock upprepa, att det alltid är bättre att tillföra korrekt data i osm. Oavsett om man personligen tycker det är till nytta eller inte. Och naturligtvis inte förstör annan korrekt data.
1 Like
Ja, scriptet gör ju ingen skillnad. Det enda det betyder är att den där lilla vägen i hög grad överensstämmer med NVDB och uppenbarligen har en hastighetsgräns definierad av dem.
Angående routing. Ja, att just denna lilla väg fått en hastighetsgräns spelar kanske mindre roll, men: det känns som om arbete med maxspeed varit väldigt koncentrerat till de stora vägarna, där korrekthet har större påverkan på tiden det tar att färdas en sträcka, Tätbebyggda har varit åsidosatta, men även där spelar routing roll, kanske inte så mycket för att få korrekt tid och utan att välja rätt gator. Alla gator som inte har en maxspeed i OSM defaultas till 50 km/h i tätbebyggt område. Det gör att routing-mjukvara sällan gör skillnad på 30 och 50 vägar och därmed får jag underligga routingförslag som inte bara är sämre utan även motverkar hela syftet med hastighetsgränser. Att leda trafik till gator som är bättre lämpade för genomfart osv.
En ihopslagning skulle isf bara ske internt i scriptet för att kunna hitta fler ways, det skulle inte importeras till OSM. Och ja, relationer och rutter är en försvårande faktor.
Många poänger och jag irriterar mig faktiskt själv på att inte plockat ut mer statistik från början. Jag ser också att jag slarvat med termerna. När jag pratar om att 72000 vägar återstår, så menar jag “ways”.
Och ja: en lärdom är ju att återstående 72000 ways på ett eller annat sätt avviker från NVDB, antingen i termer av geometri, uppdelning eller konvention: ex. rondeller med tillhörande påfart/avfart mappas väldigt olika i NVDB och OSM och är svårt att får rätt. Själva cirkeln kan hittas, men påfart/avfart är oftast mappade med två eller flera ways i OSM och endast en i NVDB.
Men för mig blir trots allt tydligare var man ska lägga sitt framtida arbete. Om jag skulle ge några tips för fortsatt arbete så är det detta:
- Det är enklare att hitta korta sträckor automatiserat - fel ackumuleras snabbt med längd. Så är man sugen på att mappa maxspeed manuellet skulle jag filtrera på längd och ta längsta sträckor först - har även bäst effekt på routing.
- Att kika igenom alla junction=roundabout kommer behöva göras manuellt.
Jag ska vid tillfälle försöka plocka ut mer statistik av det återstående arbete och delge här.
1 Like