Forumsvar skapade
-
Inlägg
-
Härligt jobbat! Det är denna typ av rapporter som vi har störst behov av för att få vår databas korrekt. Då hastigheten sänkts på en massa vägar den senaste tiden behöver vi få veta vilka kamerapositioner som behöver uppdateras.
m v h Henrik
Tack för filen! Detta är ju början till ett försök att synka ihop data från vår databas med data från NVDB. Men till vilken nytta? Om nu målsättningen är att per automatik få ut alla data som behövs från NVDB finns det väl inte längre något behov av att manuellt synkronisera data från de två databaserna? Den dag vi får en sådan metod kommer jag gladeligen med jämna mellanrum kasta bort alla data från vår databas för att sedan tanka in nya färska data från NVDB.
m v h Henrik
Tack för ikonen! Nu kan man välja när man laddar hem filen vilken ikon man vill ha, din ikon är satt som default-val.
m v h Henrik
Tack för access-filen via PM (även om jag inte kan läsa den). Om jag förstått ditt senaste inlägg rätt menar du att NVDBs ID-nr skall in i ett nytt fält i vår databas i stället för att ersätta något befintligt fält?
Forumets fartkamerafiler bygger på phpoi som är ett väldigt generellt system för att hantera positioner. Till positioner kan man knyta alla möjliga data som telefonnr, web-adresser eller ikoner. Dock finns det inte något fält direkt anpassat för NVDBs ID-nr… Men visst, adress eller tel-nr kanske man skulle kunna aktivera på vår sida och lägga in ID-numret där. Men om vi gör det innebär det att den kolumnen kommer presenteras med rubriken ”Adress” ellet ”Tel-nr” och den kolumnen kommer finnas för samtliga filer för denna sida, även t ex vägbulor och lasermätplatser.
Sen måste ju på något vis ID-numret fyllas på för alla våra punkter i databasen. Kommer vi få till en automatisk metod för det eller kommer det krävas manuellt arbete?
Innan vi ger oss på detta måste vi också fråga oss hur stor nytta vi egentligen har av ID-numret. Om vi skulle lyckas med en automatisk metod att hämta alla data vi behöver från NVDB så ser inte jag något behov av att lagra ID-numret i vår databas. Då skulle vi bara kunna ta och med mer eller mindre jämna mellanrum automatiskt uppdatera vår databas från NVDB.
m v h Henrik
Jag menar att om vi ersätter dagens beskrivande namn typ:
KE4N05
med ett namn som består av ID-nummer typ:
12345
…så förlorar vi information om vägnamn och riktning i våra filer.
Att vägverket kommer hitta på något nytt den 14e är inte någon garanti för att de sedan därefter i all evighet kommer fortsätta leverera data på samma vis. Därför är det lite synd att göra sig helt beroende av NVDB.
Du behöver inte ödsla tid på att skicka någon access-fil till mig, jag har inte access. Dock är jag ändå ganska väl insatt i såväl SQL-databaser som filformat för GPSer, så vi kan nog hålla diskussionen om dessa här.
m v h Henrik
Men en fråga till, Shas: Om vi nu skulle lyckas finna en metod för att automatiskt hämta alla data som vi behöver från NVDB, varför skulle du då se ett behov av att få NVDBs kamera-ID i våra filer?
Även om vi förlorar data om vägnamn skulle vi fortfarande kunna räkna fram färdriktningen för varje kameraposition och behålla åtminstone den informationen i kameranamnet.
m v h Henrik
Jag vill att så fort något ändras eller läggs till så ska man med en enkel körning få forumets fil uppdaterad.
Fint! Lyckas vi lösa det så är åtminstone jag villig att offra nuvarande namnkonvention. Då förlorar vi visserligen all information om vägnamn och riktning i våra filer men vi får å andra sidan kompletta och förhoppningsvis också mer korrekta data än vi har idag.
Att kameror står lite fel (ofta placerade mitt i vägen) i NVDB ser jag inte som något stort problem, precisionen är tillräcklig för den funktion som vi är ute efter. Koordinat-transformationer går också att lösa även om det handlar om ganska jobbiga formler.
Det stora problemet med att hämta data från NVDB är avsaknaden av automatisk metod att knyta hastighet till kameraposition.
Men det finns också risker med att helt förlita sig på NVDB som datakälla, då vet vi aldrig när mattan rycks undan fötterna för oss. Nu står det följande på trafikverkets web:
Information från förvaltningen
OBS! En ny version av NVDB på webb kommer att driftsättas 2016-12-14 med start ca 9.15 Under en kortare tid kommer systemet inte att vara åtkomligt!
Uppgiften uppdaterad
2016-12-06Med ett system som tillåter manuella inmätningar är vi inte helt beroende av NVDB.
Varje kamera har ett unikt ID-nummer i NVDB, men detta ID-nummer är inget som någon kan räkna ut på egen hand. Man måste leta upp kameran i NVDB för att hitta ID-numret. När Nisse Hult i Kramfors mäter in en ny position så kanske det rentav bara rör sig om ett fundament där kameran ännu inte blivit monterad. Då vet inte Nisse Hult kamerans ID-nummer och varken Nisse eller någon annan kan slå upp det i NVDB förren den dag kameran kommit med där.
m v h Henrik
Stort tack igen till Erik! Idag fick jag en ny fil, NVDB har nu 1474 kameror, dock saknas det riktningsvinkel för några av dem. Den aktuella länken (som är en återanvänd gammal karta) är nu: https://drive.google.com/open?id=1P3xpP-MBLwINMGiQLXXFCOSk5Bs&usp=sharing
m v h Henrik
Tack!
K19S04 är nu korrigerad. Mailen går till Ibasto, vi får se om han korrigerar de andra eller om han skickar mailet vidare till mig eller via forumet.
m v h Henrik
För oss IGO8 användare skulle detta innebära att vi skulle kunna göra en fråga med ”oförstörda” data. I ”vår” databas har vi ju ”konstruerat” väderstrecken utifrån en matematisk korrelation. (I detta exempel finns ett underliggande villkor, finns det data i korr använd den annars hämta data från grader)
Jag befarar att du och jag söker lösningar på två helt olika problem. Det problem som jag skulle vilja se lösningen på är en automatisk metod att få in alla data som vi behöver i vår databas från NVDB. Avsaknaden av sådan metod ger dig behov av att kunna lösa ett annat problem:
Hur skall du knyta ihop data från var databas med data från NVDB? Svaret på den frågan är inte ID-numret från NVDB. Skälet till att ID-numret inte funkar är att när Nisse Hult från Kramfors åker ut till närmaste lokala fartkamera och mäter in dess position med sin GPS så har varken han eller vi någon aning om vad NVDB valt för ID-nummer till den. Därmed kan inte vi mata in NVDBs ID-nummer till alla rapporterade kamerapositioner som vi får in.
m v h Henrik
Nuvarande namnkonvention i vår databas är ett arv från tidigare eldsjälar som underhöll liknande web-sidor. Jag vet inte om de liksom vi använde sig av någon SQL-databas i botten eller om de kanske bara underhöll ett antal filformat och samarbetade om data till sina filer.
Det som vi skulle tappa om vi övergav nuvarande namnkonvention är namnet på vägen där fartkameran sitter samt den grova färdriktningen. Dock tycker jag personligen att det skulle vara värt att offra den informationen i fall det kunde leda till en automatisk uppdatering med data från NVDB. Idag kommer inte alla våra kamerapositioner från NVDB, många av våra positioner är också manuellt inmätta.
Om vi kunde komma till ett system där vi automatiskt uppdaterar vår databas med alla kamerapositioner från NVDB skulle det bespara oss väldigt mycket arbete. Vi skulle nog också få mindre fel i vår databas. Därmed inte sagt att data från NVDB är felfria, vi skulle inte kunna korrigera felaktiga data i vår egen databas utan i stället hänvisa felanmälningar vidare till NVDB.
Största hindret som jag sett till att automatiskt uppdatera kamerapositioner från NVDB är att det verkar svårt att automatiskt få ut vilken hastighet som hör till varje kamera från NVDB. Lyckas någon lösa det problemet offrar jag gladeligen vår namnkonvention med vägnamn och färdriktning och övergår till NVDBs IDnr.
m v h Henrik
Eftersom 90 grader är rakt österut ser jag även 89 grader som en ganska östlig riktning. Därför strävar jag efter att mata in följande väderstreck i databasen beroende på färdriktning:
315° – 45° => N
45° – 135° => E
135° – 225° => S
225° – 315° => WSedan kommer då de bokstäver som anger väderstreck kunna tolkas som kompassriktning i grader:
N = 0°
E = 90°
S = 180°
W = 270°I princip borde precisionen på dessa framräknade vinklar kunna ha ett fel på max +-45°, men enstaka kameror har lite större fel än så. I NVDB kan det t ex finnas en fartkamera som tittar i riktningen 130° vilket motsvarar färdriktning 310° vilket borde vara en ganska så västlig riktning. Men vägen kanske till största delen sträcker sig i nord-sydlig riktning och i kommentaren till kameran kanske det står ”ortsnamn norrgående”. I dessa fall har jag inte varit helt konsekvent, ibland har jag skrivit riktning W efter kameravinkeln, ibland har jag skrivit riktning N efter kommentaren. Så jag skulle nog inte våga lova någon precision bättre än kanske +- 60°.
m v h Henrik
Tack! Nu är dessa 4 kameror korrigerade.
Just när vi i vår databas har för hög hastighet tycker jag har allra högst prioritet att korrigera. Det vore ju förargligt om vi skulle lura någon att köra för fort, dessutom mitt för en fartkamera!
Om vi skulle prioritera de rapporter vi vill ha in skulle jag nog prioritera på detta vis:
1) Befintliga fartkameror där vi felaktigt påstår att hastigheten är för hög
2) Borttagna fartkameror där vi felaktigt påstår att hastigheten är för hög
3) Saknade fartkameror
4) Befintliga eller borttagna fartkameror där vi felaktigt påstår att hastigheten är för låg.
5) Borttagna fartkameror som vi har kvar med korrekt hastighetMen denna prioritering är inte särskilt viktig för mig, hittils har vi haft kapacitet att ta emot alla rapporter som kommer in. Vi vill ha alla tips vi kan få data som saknas eller är felaktiga i vår databas!
m v h Henrik
Nja det verkar konstigt.
Var och en får naturligtvis tro som man själv vill, men jag som bara senaste månaden matat in drygt 50 fartkameror i vår databas borde väl ändå ha lite koll på vilken namnkonvention jag använder för de kameror som jag matar in?
Varför finns det då endast numrering upp till 100 och flertalet har samma..
Löpnumret i slutet av kameranamnet är per väg. Normalt sett är dessa löpnummer 2-siffriga, d v s första (eller äldsta) kameran på en väg får nummer 01. Därefter räknas det uppåt. Sen finns det säkert fall där det har blivit fel, även om ambitionen är att alla kameranamn skall vara unika kanske det har fumlats så att det blivit dubletter. Någon gång när jag var ganska ny på det här med att mata in kameror råkade jag ta samma löpnummer för olika väderstreck, sen såg jag att löpnumren för övriga kameror verkade vara unika per väg. Jag brydde mig inte om att korrigera den väg där det fanns dubletter av löpnumren, huvudsaken är att varje kameranamn är unikt.
Vad får dig att tro att numreringen bara går upp till 100? Även om numreringen oftast bara är tvåsiffrig finns det åtminstone en väg med med kameror som har högre löpnummer och det är E4:
KE4N121 Granberget norrgående
Jag vill nog mena att väderstrecken bestämmer vilken sektor vi befinner oss inom.
Det som talar för min teori är att det faktiskt stämmer
Ett gott råd är att kontrollera hur noggranna vinklar du faktiskt får med din teori och dina formler. Om du inte vill att slumpen skall kunna spela dig ett spratt bör du naturligtvis kontrollera flera kamerapunkter. Jämför t ex med vägens riktning på google maps. Tycker du att det verkar stämma på en grad när?
Eller så gör du det enkelt för dig själv och litar på mig när jag säger att siffrorna i slutet på fartkameranamnet bara är ett löpnummer som inte har någonting alls att göra med kompassriktningen.
m v h Henrik
