atorger / nvdb2osm

The Unlicense
9 stars 2 forks source link

Maxhastighet saknas #53

Open marsip opened 1 year ago

marsip commented 1 year ago

Maxhastighet saknas på många vägar, trotts att den uppgiften finns i NVDB. Åtminstone finns det i NVDB-webb/hastighetsgräns.

atorger commented 1 year ago

Kan det vara 70 km/h-gränserna? Hade med dem från början, men vi valde senare att rensa bort standard-hastighetsgränserna, alltså de som troligtvis inte är skyltade. Minns inte exakt hur diskussionen gick då, men medan vi utvecklade skriptet så tog vi bort en del information som vi tyckte inte tillförde så mycket.

Jag har sett att det finns lite mer avancerade hastighetstaggar där man kan ange om det är skyltad, eller om det är en standardhastighet enligt lokal lag. Tyvärr har inte NVDB tillräckligt med information så man kan översätta dem till den typen av hastighetstaggar.

atorger commented 1 year ago

Kollade i koden, det är remove_redundant_speed_limits() i process_and_resolve.py som tar bort en del hastighetsgränser. Är det denna som är "boven", eller är det andra hastighetsgränser som saknas också? Trafikverket har ju hållit på och ändra en del i datat senaste året så det kan hända att nåt slutat fungera.

d4v1db00k commented 1 year ago

Detta är jag nyfiken på. Har själv just knåpat ihop ett script för att kunna komplettera vägar med saknad hastighet (från NVDB) och undrar om detta hamnar i konflikt med ert arbete? Det enda jag gör är att jämföra OSM-geometri med NVDB-geometri och i de fall det matchar ordentligt lägger jag till en maxspeed-tag till OSM om det saknas. Detta funkar såklart enbart på vägar där geometrin överensstämmer ordentligt (exempelvis kommer inte ways som egentligen borde delas upp flera hastighetsavsnitt taggas osv...)

För övrigt tycker jag det är bättre att alltid sätta explicit maxspeed. Default kan ändras som just nu sker i Sverige med införande av nya 40 och 60 vägar och då blir det väldigt stökigt plötsligt. Explicit är alltid bättre än implicit. Men skulle jag ge mig på att tagga 70-vägar så kommer inte ta bort dem taggarna eller ska jag förstå det som att ni raderar befintlig data?

atorger commented 1 year ago

Python-skripet generar bara en OSM-fil från NVDB-data, själva sammanfogningen görs manuellt. Befintliga taggar tas inte bort. Blir det konflikt, om det är olika hastighetsgränser, så är det upp till den som sammanfogar att bedöma vilken som är mest troligt att den är rätt. NVDB har ytterst sällan fel på stora vägar, men på kommunala och enskilda vägar har den ibland fel. Saker som att det dyker upp 50-väg mitt på en enskild väg i skogen har jag sett till exempel fast jag vet att det inte är en enda skylt där.

Så tanken var väl när skriptet utvecklades att det är bättre fokusera på de viktiga hastigheterna på de stora vägarna där datat har en hög grad av korrekthet och kan antas vara skyltade och inte lägga till taggar på skogsbilvägar och jordbruksvägar där det sannolikt inte är skyltat och dessutom verkar förekomma fel (åtminstone i norrland där jag själv kartlagt mest).

Ska man lägga till taggar där det inte är skyltat vore det nog bäst att köra med implicit-taggarna, se här: https://wiki.openstreetmap.org/wiki/Key:maxspeed#Implicit_maxspeed_values

Jag är inte påläst om implicit-taggarna själv, men man bör nog läsa på det och se hur man tänkt tidigare i OSM-världen detta med oskyltade hastighetsgränser innan man börjar tagga den automatiskt.

Hursomhelst, det blir ingen konflikt, men det blir ju förstås dubbelarbete om du gör det på någon kommun som någon gör en komplett genomgång av just efter.

Den långsiktiga planen med detta projekt är att göra ett skript som sysslar med att identifiera uppdatering senare, så det blir lite enklare att hålla saker up to date utan att gå igenom allt igen manuellt. Men vi har bedömt att det är så mycket skillnader från NVDB och gammalt data med geometri-fel mm så att man vill först göra en ordentlig manuell genomgång av en kommun innan man börjar göra uppdateringsskript som bara tittar på skillnader. Annars kommer folk skita i att göra en ordentlig basuppdatering och så fastnar OSM i status quo, dvs väldigt ojämn kvalité beroende på var i landet man är. Syftet med detta projekt är att ge sverigekartan en hög lägstanivå så att det går att lita på OSM var man än är i landet.

OSM är dock ett hobbyprojekt så folk får göra vad de tycker är roligt, så jag är inte alls emot ett separat hastighetsuppdateringsprojekt. Vi behöver emellertid fler som jobbar i detta projekt också om någon är sugen :-D