Forumsvar skapade
-
Inlägg
-
Förlåt, jag blandade ihop inlägg #786 med inlägg #758 som du tidigare hänvisat till.
Det bästa är nog om du laddar upp dina filer i någon egen tråd under rubriken ”övriga format”, https://fartkameraforum.se/forums/forum/ovriga-format/ ungefär som att vi har trådar för igo8-formatet som inte stöds av phpoi under
Det är Ibasto som är den store administratören av sidorna, jag bara skriver lite på forumet och gör mitt bästa för att underhålla databasen. Rent tekniskt inser jag dock att det inte skulle vara trivialt att lägga filerna i samma tabell som övriga ”filer” på https://fartkameraforum.se/poi-filer/ då ”filerna” där inte ”finns” utan skapas dynamiskt från vår databas då de laddas ned.
Av de filer som du erbjuder skulle jag tro att den för igo8 är mest efterfrågad. Den skulle ju helt klart platsa under igo8-rubriken på forumet. Det är nu några månader sedan ludde28 var aktiv på forumet och laddade upp en igo8, fil, så ingen skulle nog vara ledsen om den hamnade där.
m v h Henrik
Jag har full förståelse för att det krävs en massa arbete med något som kräver manuell handpåläggning. Jag är också smärtsamt medveten om att det krävs en faktor mera med arbete för att automatisera något sådant. När väl arbetet med automatiseringen är klar man man dock spara mycket arbete för många under lång tid framöver.
Du har vid ett par tillfällen hänvisat till inlägg #786. Den hänvisningen säger mig dock ingenting. Jag förstår att det hänvisar till inlägget med just nummer 786 och vid varje inlägg ser man vad de har för nummer. Jag vet dock inget sätt att leta upp ett inlägg med ett visst nummer. Om du vill att jag skall läsa #786 får du posta en länk till det inlägget.
Jag har inget emot konkurrerande datakällor med andra data och stöd för andra format. För några år sedan efterfrågades det stöd för igo och jag brände någon semestervecka på att försöka implementera det vilket dokumenterades i https://fartkameraforum.se/forums/topic/igo-8/page/7/#post-352
Jag har dock själv inte någon igo och kunde därför inte sjäv testa, med beroende på andra personers engagemang som av förståeliga skäl var svalt då de inte hade semester samtidigt som mig rann det arbetet ut i sanden. Dock skulle det ju även med stöd för igo från vår databas saknas vinklar då vår databas saknar vinklar.
m v h Henrik
Tack för varningen för de 9! Vi har redan valt att ha den lägre hastigheten som varning i vår databas. Nu fick jag dock ändå tillfälle att uppdatera ett par positioner med ortsnamn:
KE4N10 Ljusvattnet
K50S16 TegellökaI våra ortsnamn/kommentarer brukar det för dessa positioner också stå något i stil med S80 V60 när hastigheten varierar. Dock saknar vi sådan text för:
K31S19 Boskvarnasjö (vet du om det är sommar 90, vinter 70?)
K140N04 Tofta södra (vet du om det är sommar 80, vinter 60?)
K140W05 Tofta strand (vet du om det är(t sommar 80, vinter 60?)m v h Henrik
Jag menade att metoden med våra manuellt inmätta fundament innebär fördelen att vi kan få in positionerna ett par år tidigare i vår databas.
När jag skrev ”å andra sidan” menade jag, precis som du, att det är en nackdel att dubletter kan finnas länge i vår databas.
Vad var och en vill ha i sin GPS får var och en naturligtvis tycka vad man vill om. Själv har jag hellre en komplett databas som larmar på några positioner för mycket än en inaktuell databas som saknar positioner.
Jag skrev 4 gånger per år därför att du bara erbjöd dig 4 gånger per år. Man skall inte säkert räkna med att andra, som t ex Benke är villiga att komplettera uppdateringen av databasen oftare. Man skall nog inte underskatta arbetet med att plocka fram data på ett format som blir användbart.
Om du nu tycker att data från NVDB räcker, varför matar du då inte in NVDB i din GPS-navigator? Vår databas enda syfte är att vara underlag till utdata i form av ett begränsat antal GPS-format, det är denna anpassning som ger oss ett existensberättigande.
Du får gärna visa på en arbetsmetod som utan automatik producerar användbara GPS-filer från NVDB med en rimlig arbetsmängd. Vår databas bygger på phpoi som är ett opensource-system från https://phpoi.sourceforge.io/ som du kan leka fritt med. Där finns rutinerna för att konvertera från data i en SQL-databas till tre olika filformat för tre olika typer av GPSer.
Idag matas varje position in manuellt i ett web-formular med fem fält för lattitud, longitud, namn, hastighet och kommentar/ortsnamn. Det arbetet är görligt när det kommer små delta-uppdateringar, men det skulle inte hålla att arbeta så om någon kommer med en stor datamängd och säger ”kasta allt det gamla och ta detta i stället”.
Vår databas innehåller inte något attribut för väderstreck, främst för att de format som vi stödjer inte har med det attributet. Det skulle vara onödigt att mata in data som inte används. Dock stödjer inte phpoi igo, och de fristående konverteringar till igo-format som görs av eldsjälar på forumet nyttjar väderstrecks-delen i namnen för att återskapa ett vinkelattribut.
Det vore en välgärning om du kunde få till GPS-filer som matchar NVDB, men ett sådant arbete kräver mer än kunskap om GIS och databaser, det kräver också kunskap om hur GPS-formaten fungerar. Den kunskapen går att läsa sig till från en del officiella specifikationer, men i praktiken behöver ens implementation också sedan testas på varje typ av GPS som man har för avsikt att stödja.
m v h Henrik
Man kan vara imponerad av att NVDB har med fartkameror ett halvår innan de aktiveras, men icke desto mindre har våra manuella inrapporteringar ofta haft betydligt mer marginal än så. Exempel:
13e augusti, 2018 rapporterades K292E02 som ett manuellt inmätt fundament:
14e maj 2021 rapporterades K292E26 från NVDB:
9e oktober 2024 rapporterades att dessa två positioner var dubletter:
Så vårt manuella arbete innebär å ena sidan att några positioer rapporteras nästan 3 år tidigare än de kommer från NVDB men å andra sidan innebär de också att vi har dubletter under drygt 3 år.
Ändock är jag inte helt främmande för tanken på en automatisk uppdatering från NVDB. Det känns dock lite skrämmande att 4 gånger om året kasta hela vår databas för att skapa om den från scratch. Man måste tänka sig för hur man skall göra t ex med namn på positionerna. Idag har vi konsekventa unika namn som anger vilken väg och väderstreck en kamera har, det befarar jag skulle gå förlorat med din automatiska rutin för uppdatering?
Vi måste också komma överens om ett format för sådana automatiska uppdateringar. Office-format som Word och Excel innebär manuellt arbete vilket funkar när en begränsad mängd kameror skall uppdateras. En automatisk uppdatering skulle i princip kräva SQL-data.
m v h Henrik
Kul anekdot om kamerapositionen som ”inte” fanns med i NVDB!
Jag ser fortfarande en vits med att mata in manuellt rapporterade fundament i vår databas. Detta eftersom dessa positioner kan hinna få en aktiv kamera innan vår genomsnittlige användare har hunnit uppdatera kamerapositionerna i sin navigator, handen på hjärtat, hur ofta brukar ni själva uppdatera era GPS-navigatorer? Själv brukar jag bara uppdatera en eller högst två gånger om året.
Ja, det där med hastigheter som ändras är ett elände. En del västräckor har till och med så att de byter hastighet med årstiderna. Min ambition med vår databas är att den åtminstone inte skall lura någon att köra för fort, så vid minsta tveksamhet låter jag en lägre hastighet stå kvar. Men det finns säkert några positioner som ändå har kvar en inaktuell numera för hög hastighet.
Benke som brukar skicka uppdateringar från NVDB gav mig en excel-fil som tydligt visar kommentaren för de positioner som vi har som saknar kommentar/ortsnamn. Jag tänkte börja kika på det framöver, det rör sig om ca 900 positioner. I samma fil fanns hela listan med positioner som vi har med i vår databas men som saknas i NVDB. Där tänkte jag manuellt kika på varje position i google streetview för att se om positionen skall tas bort. Detta arbete kommer dock ta många helger…
m v h Henrik
Tack för filen! Den är ju åtminstone någon månad färskare än när vi senast fick någon uppdatering från NVDB. I en perfekt värld skulle jag nu kunna plocka data från den filen och mata in i vår databas.
Dock lever vi i allt annat än en perfekt värld… Då jag jämför med de data som vi har så har koordinaterna olika antal decimaler och ofta (kanske vid manuella inmätningar) skiljer de ganska mycket. Därmed är det inte så enkelt som att automatiskt jämföra positioner.
Kanske skulle man kunna ta alla kameror från ett visst datum i kolumnen FRAN_DATUM? Men då jag kikar på de kameror som vi senast matat in i NVDB så har de datum som kan skilja sig månader eller år från datumen i den kolumnen.
Återstår då att titta på kolumnen ”namn”. Den kolumnen kommer skilja för manuellt inmätta fundament (men det problemet har vi alltid haft när vi fått uppdateringar från NVDB och det har då ofta gett oss dubletter), värre är dock att vi har 935 kamera-positioner i vår databas som inte har något namn alls.
Jag vet helt enkelt inte hur jag skall få in dessa data i vår databas med någon rimlig arbetsmängd.
Exempel på en lite förvirrande position från din fil:
14.17687
61.13329
Oxberg norrgående
20017010
70
135
20241104
90Dess koordinater kan jämföras med vår K70W52@90 som har koordinater
14.176417
61.133533Datumet antyder att positionen är nyare än vår senaste uppdatering från NVDB, men den positionen justerade vi i vår databas i maj år 2022: https://fartkameraforum.se/forums/topic/hojd-hastighet-8-positioner-vag-70/
Jag vill inte underskatta det jobb som forum-medlemmar tidigare gjort som gett oss data från NVDB, men jag gissar att det jobbet underlättades lite av att de mellan varje leverans av data kunde se vilka positioner som tillkommit sen förra leveransen.
m v h Henrik
Det var nu länge sedan det kom några uppdateringar med NVDB som datakälla… Har det möjligen att göra med att NVDB-sidorna verkar vara omgjorda? Går det inte längre att prenumerera på data på samma vis som tidigare?
m v h Henrik
Nej, det hjälpte inte, problemet är kanske att jag länkar till en bild på FaceBook. När jag laddar hem bilden till min egen dator är den ca 800 kB stor, men jag kan inte ladda upp den till forumet, bara ange en URL. FaceBook kan nog vara knepiga med sånt.
m v h Henrik
Nehej, det där med bilderna funkade inte ens för mig själv som är inloggad på facebook. Då blev inte det här inlägget mycket till instruktion.
m v h Henrik
Då jag kikar på den som hette K70S34 ser jag att vägen där lokalt går mer i östlig riktning än sydlig riktning, så jag döper om den till K70E34. En bit innan kameran går vägen mer i sydlig riktning, men övriga kameror brukar vi döpa efter den lokala riktningsvinkeln.
Jag tror att den positionen är ett arv från gamla speedcams, i vårt forum hittar jag inte när den blivit tillagd, bara ett par inlägg om att positionen fått ny hastighet.
m v h Henrik
Jag har nu korrigerat dessa två positioner i tunneln med koordinater från excel-filen som du skickade via mail. Jag har också uppdaterat positionerna för K218N01 och K218S04.
Dessutom har jag enligt ditt mail korrigerat positionerna för KE6W07, KE6N08, KE6N11 och KE6S12.
Skillnaden mot tidigare positioner blir som sagt något 10-tal meter, men som jag ser det spelar det inte någon jättestor roll. När man kör på dessa vägar rör man sig med ca 20 meter per sekund. (25 m/s = 90 km/h, 19.44 m/s = 70 km/h).
m v h Henrik
Jag inser nu att 1 grad inte kan motsvara ca 100 m, kanske är det i stället så att 1 grad motsvarar ca 10 km skillnad. I så fall är positionerna något 10-tal meter fel.
m v h Henrik
De två positionerna rapporterades in av dig 2021:
Koordinaterna är inte exakt lika, men ändå ganska lika, kan du kanske ha använt olika metoder för att konvertera till WGS84 från NVDB?
WGS84 anger koordinaterna i grader, 1 grads skillnad innebär ca 100 m skillnad. Här skiljer koordinaterna ca några tiotusendels grader, d v s några centimeter om jag räknar rätt.
m v h Henrik
