Forumsvar skapade
-
Inlägg
-
[quote quote=200]Vad är PHPOI, Är det något program ?[/quote]
Ja, det kan man säga: http://phpoi.sourceforge.net/
Det är det system med databas som gps-filerna bygger på. Alla data ligger i en sql-databas och zip-filen till vald gps-modell genereras dynamiskt från databasens innehåll i samma ögonblick som man tankar ned en GPS-fil.
När phpoi får stöd för fler GPS-format kan fartkameraforum.se uppdatera sin installation av phpoi och även tillhandahålla de nya gps-formaten direkt från sql-databasen.
m v h Henrik
Som jag tolkar tidigare beskrivningar av igo8-formatet i denna tråd så saknar igo8-filerna såväl namn som kommentarer för varje punkt. Även min Garmin-GPS varnar för att man kör för fort om man kör på en väg med högre hastighet men närmar sig en punkt med lägre gällande hastighet. Det kan naturligtvis vara lite irriterande om punkten bara ligger på en närliggande eller korsande väg, men i de fall då hastigheten sänks längre fram på den väg som man kör och det dessutom finns en fartkamera där så tycker jag bara att varningen är bra. Men jag får ju inte min varning redan en hel kilometer innan punkten.
Om du lyckas få till en automatiserad metod för att generera filer för igo8 kanske ibasto kan lägga dem i någon katalog för bonus-filer att tanka hem. Då skulle de separata filerna kunna fungera tills jag fått till stöd för igo8 i phpoi. Men tills vidare tycker jag filen ligger ganska bra i denna forum-tråd.
m v h Henrik
För funktionalitetens roll spelar det ingen roll vad punkterna heter, de skulle inte ens behöva ha unika namn. Men jag ser ändå en skönhet i den namnkonvention som nu valts. Nuvarande namnkonvention berättar på vilken väg kameran befinner sig och i vilken riktning kameran tittar. Om vi skulle frångå den namnkonventionen för nya kameror skulle listan se inkonsekvent ut och en del information skulle gå förlorad.
Nuvarande namnkonvention bygger på vägnamn, riktning och löpnummer. Riktningen kan man få från excel-filen, det skulle vara enkelt att konvertera vinkeln i grader till ett väderstreck. Löpnummer är bara att räkna upp, men det är olika löpnummerserie för varje väg. Därför behövs vägnamnet för att kunna fortsätta med nuvarande namnkonvention. Det skulle naturligtvis gå att ta reda på vägnamnet för varje punkt genom att studera google maps eller liknande, men det skulle bli väldigt mycket manuellt arbete.
I princip innehåller filen från vägverket bara hälften av den information som vi har i våra filer. De tillhandahåller koordinater (som måste räknas om) och riktning men saknar vägnamn och hastighet.
m v h Henrik
[quote quote=180]Jag skrev fel sökväg till vart trafikverkets fil hittas, skall vara 4.Produktpaket-Sverigepaketet-ATK_Trafiksakerhetskameror.zip den filen är inte så stor bara 100 kB zippad.[/quote]
Den filen var ju lite mer hanterbar! Jag kunde öppna dbf-filen i OpenOffice. Tyvärr anger de inte koordinaterna i WGS84 utan det verkar som om de anges i Sweref 99. Det står inte heller namnet på vägen där fartkameran står. Att plocka data från dessa filer skulle nog innebära ganska mycket manuellt arbete, då känns det enklare att åka ut och mäta in några nya fartkameror själv och förlita sig på att flera vill hjälpa till att mäta in fartkameror.
m v h Henrik
[quote quote=178]Vad beträffande riktningen gäller att med den formeln jag kör med nu så stämmer vissa men andra är upp till 30° fel. (Håller vi oss inom 90° så torde det ju inte påverka, kan vara ett mätfel utan betydelse)
Konstanter N=0;E=90;S=180;W=270
Om vi utgår ifrån min exempelposition enligt tidigare K100W01@50 så skulle en Igo8 översättning bliFormel: (1/50*90)+W = 271,8°
[/quote]Namn-konventionen för varje fartkamera är något som ärvts från gamla speedcams. När jag lagt in nya punkter har jag försökt följa samma namnkonvention. Egentligen ”vet” jag inte hur namnkonventionen fungerar, det här är bara min gissning:
Namnet på varje kamera börjar med ett ”K” som i Kamera.
Därefter följer namnet på vägen.
Därefter följer en bokstav för väderstreck, detta innebär att riktningen kan få ett fel på + – 45 grader.
Efter väderstrecket följer ett tvåsiffrigt löpnummer med syfte att varje kamera skall få ett eget unikt namn.I Garmins csv-filer kan man knyta en hastighet till en punkt genom att lägga till @xx på namnet där xx är hastigheten.
Precis som du skriver så är inte citat-tecknen så viktiga i fartkamerafilen som inte har så mycket kommentarer och denna typ av namn. Fördelen med citat-tecken i en komma-separerad fil är att du kan ha kommatecken även i ett namn eller en kommentar utan att riskera att någon tolkar din komma-separerade fil snett.
m v h Henrik
Det kanske som standard skulle funka att sätta TYPE till nr 23, POI? Eller kan man vara så fräck att man helt utelämnar type och lämnar tomt mellan dessa ,-tecken?
Jo, jag vet att man kan få positionerna från trafikverket. Man kan även se dem på en karta här:
http://trafikinfo.trafikverket.se/LIT/#url=Vagtrafiken/KartaMen det är som sagt bara positionerna, det som vi behöver för varje punkt är koordinater och gällande hastighet. Jag har inte excel, men de där dbf-filerna verkar ju närmast löjliga. ISA_ramp.dbf är nästan 2 Gig stor, hur mycket plats skall man egentligen behöva till några koordinater med tillhörande data?
Redan som packade zip-filer är det hundratals megabyte som skall tankas hem från trafikverkets server och deras server verkar inte helt stabil, det tar lång tid att tanka och tankandet avbryts ibland.
m v h Henrik
Unapproved låter bra tills vidare. Jag lägger till kommentarer om att de togs bort idag efter rapporter om ombyggd väg.
m v h HenrikJag ser ingen bild, glömde du bifoga filen?
Om du har glädje av kml-filer så har phpoi även stöd för att generera sådana. T ex
http://poi.fartkameraforum.se/www/kml.php?selected_database=fartkamerorFörr kunde man använda dessa kml-filer till att på google maps se alla punkter i en tabell.
m v h Henrik
Tack för exempelfilen! Varje rad slutar på DOS-vis med både CR och LF.
Då exemplet är en fartkamerafil är TYPE satt till 1 vilket är helt korrekt för en fartkamerafil. Men hur stor roll spelar egentlige TYPE? Skulle det vara OK att sätta TYPE till 1 även för alla andra filer som t ex filen med vägbulor och filen med kontrollplatser?
När det gäller vinkel för fartkameran är det ingenting som finns med i databasen. Å andra sidan stod det ovan att DIRECTION är optional.
Närmaste veckorna är fullbokade för mig både vardagar och helger, men i oktober har jag en planerad semester, då hinner jag kanske kika på att implementera IGO i PHPOI.
m v h Henrik
Hur funkar IGO med övriga POI-filer, d v s sådana som inte har någon hastighet knuten till sig. T ex en fil med positioner för ett antal butiker? Vad skall då TYPE ha för värde? Finns det ingen möjlighet att i IGO-filen ange namn för punkten?
Vad är det för tecken som anger radslut i IGO? CR (ascii 13) eller LF (ascii 10) eller båda?
Om jag skulle få tid att försöka implementera IGO, skulle du ha möjlighet att testa om jag skickar några test-filer på IGO-format till dig?
m v h Henrik
Den där kryssrutan efter posten, skulle den gå att ändra så att den inte default är ikryssad? När man svarar på ett inlägg (som t ex när jag skriver detta) syns inte den kryssrutan och går därmed inte kryssa ur, men ändå får man ett mail hem med en länk att klicka på för att registrera sig på listan.
m v h Henrik
PHPOI är som sagt förberett för att relativt enkelt kunna lägga till stöd för ytterligare GPS-format. Stöd för något nytt format kräver tre förutsättningar:
1) En specifikation för hur formatet fungerar. Om man har tur och formatet bygger på läsbar text kan det gå att läsa från en befintlig fil. När det gäller csv-formaten för Garmin och Navman är det exempel på enkla text-filer. Däremot TomToms ov2-format är binärt och hade inte gått att implementera utan en ordentligt skriven specifikation.
2) Någon som vill, kan och har tid att implementera det nya formatet. Den personen måste då förutom format-specifikationen även ha lite kunskap om php-programmering. Det brukar vara jag som lägger till stöd för nya format, men PHPOI är opensource och jag tar gärna emot patchar med ny funktionalitet också.
3) Någon som har möjlighet att testa den nya funktionaliteten.
Då det sällan blir rätt vid första försöket brukar punkt 2 och punkt 3 ovan bli en iterativ process med flera försök till implementation som sedan måste testas. Snabbast går det då att få fram ett nytt format om personen som implementerar formatet har tid att lägga på detta arbete under samma dagar/veckor som personen som testar formatet. Allra enklast blir det om personen som implementerar formatet själv har möjlighet att testa.
m v h Henrik
