henca

[henca]

När du skrev att du kunde konvertera en koordinat utan problem trodde jag att du menade att du hade programkod och formel för konvertering av en koordinat. Då menade jag att det skulle vara trivialt att modifiera programkoden till att loopa över flera koordinater. Att någon tredje part implementerat detta till en tjänst där vem som helst kan konvertera en koordinat hjälper oss inte så mycket, utan tillgång till källkod och formel kan vi inte modifiera eller skriva om koden till att köra batch-job.

m v h Henrik

[henca]

Ja, men även att jämföra koordinaterna mellan trafikverkets alla kameror och våra kameror kommer kräva en hel del manuellt arbete. Beakta t ex positione för den här fartkameran som vi fick in häromdagen:
https://www.google.com/maps/place/62%C2%B027’18.0%22N+17%C2%B009’45.4%22E/@62.455,17.1604213,17z/data=!3m1!4b1!4m5!3m4!1s0x0:0x0!8m2!3d62.455!4d17.16261

Genom att bara studera kartan skulle jag gissa att precisionen på den positionsinmätningen har ett fel som i meter överstiger hur många meter bred vägen är. Men även om positionen skulle vara 10, 20 eller rentav 50 meter fel duger den mer än väl till att låta våra GPSer varna för dess position.

Låt oss anta att trafikverkets positioner är mer exakta och att vi efter koordinattransformationer får ett fel på bara några enstaka meter. Hur långt avstånd skall vi då tillåta mellan fartkamerapositioner för att anse att två positioner från olika källor skall vara samma fartkamera? Å ena sidan bör detta avstånd vara större än felet på våra inmätta kameror, å andra sidan bör avståndet vara mindre än minsta avståndet mellan två kameror. Så hur litet avstånd kan det vara mellan två kameror? Jag skulle tro att det avståndet är något större än bredden på den smalaste väg som har två kameror på varsin sida om vägen som mäter motsatt riktning.

Däri består problemet att automatiskt identifiera nya kameror, precisionen på våra positioner är nog sämre än minsta möjliga avstånd mellan två kameror.

m v h Henrik

[henca]

Jag tror mig kunna fixa batch-konvertering. Då det är mera avancerade beräkningar som skall göras duger det nog inte med enkla script i bash och awk. Sannolikt kommer jag i stället förlita mig på php eller i värsta fall C. Men hur stor nytta har vi av konverterade koordinater när övriga data saknas? Framför allt hastigheten vill vi ju ha till varje punkt. Även vägnamn vill vi helst ha för att kunna fortsätta med samma namnkonvention.

m v h Henrik

[henca]

Ja, man kan ju tycka att det borde räcka med en 3×3-matris för att konvertera mellan olika koordinatsystem, men matten blir ofta mer avancerad än så. Då kart-länkarna till hitta.se byggde på RT90 var jag tvungen att konvertera WGS84-koordinaterna i databasen till RT90 för att stödja kartlänkar till hitta.se. Den delen av phpoi blev såhär:

<?php

/******************************************************************
    Copyright 2008 Henrik Carlqvist

    This file is part of phpoi.

    Phpoi is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    Phpoi is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with phpoi.  If not, see <http://www.gnu.org/licenses/>.
******************************************************************/

function RT90($lat, $long)
{
   $sin_lat = sin(deg2rad($lat));
   $cos_lat = cos(deg2rad($lat));
   $sin_lon = sin(deg2rad($long));
   $cos_lon = cos(deg2rad($long));
   $a_wgs = 6378137.0;
   $e2p_wgs = 0.00669437999013;
   
   $Bessel_Ellipsoid_a   = 6377397.1542;
   $Bessel_Ellipsoid_e2p = 0.006674372232;

   $Gd_dR0 = 424.3;
   $Gd_dR1 = -80.5;
   $Gd_dR2 = 613.1;
   $Gd_dC0 = 0.000021315;
   $Gd_dC1 = -0.0000096313;
   $Gd_dC2 = 0.000025136;

  /* Transform WGS84 Lat/Long/H to geo-centric coordinates */
   $N_wgs = $a_wgs/sqrt( 1.0 - $e2p_wgs * $sin_lat*$sin_lat );
   $X_wgs = $N_wgs*$cos_lat*$cos_lon;
   $Y_wgs = $N_wgs*$cos_lat*$sin_lon;
   $Z_wgs = $N_wgs*(1.0 - $e2p_wgs)*$sin_lat;

   /* Bursa-Wolf transformation */
   $X_gd = ( $X_wgs-$Gd_dC2*$Y_wgs+$Gd_dC1*$Z_wgs ) - $Gd_dR0;
   $Y_gd = ( $Y_wgs+$Gd_dC2*$X_wgs-$Gd_dC0*$Z_wgs ) - $Gd_dR1;
   $Z_gd = ( $Z_wgs-$Gd_dC1*$X_wgs+$Gd_dC0*$Y_wgs ) - $Gd_dR2;
  
   /* Transform geo-centric coordinates to Lat/Long/H in Generic Datum */
   $P = hypot($X_gd, $Y_gd);
   $Q = sqrt(1.0 - $Bessel_Ellipsoid_e2p);
   $R = $Bessel_Ellipsoid_a*$Bessel_Ellipsoid_e2p;
   $Eta = atan( $Z_gd/($P*$Q) );
   $lat_gd = atan( ($Z_gd + $R*pow(sin($Eta),3.0)/$Q) /
                   ($P - $R*pow(cos($Eta),3.0) ) );
   $long_gd = atan2( $Y_gd, $X_gd );
   $N_gd = $Bessel_Ellipsoid_a /
       sqrt( 1.0 - $Bessel_Ellipsoid_e2p*pow(sin($lat_gd), 2));
   $h_gd = $P/cos($lat_gd) - $N_gd;

   $a1 = 6.674372206E-3;        /* Series expansion coefficients */
   $a2 = 3.7073149E-5;
   $a3 = 2.569374E-7;
   $a4 = 1.9482E-9;
   $b1 = 8.3522527E-4;
   $b2 = 7.56302E-7;
   $b3 = 1.193E-9;
   $Y0 = 1500000.0;              /* Mean Meridian Y Coordinate */
   $RTH_L0 = 0.2759064963;       /* Mean Meridian in RT90 (rad) */
   $EarthRadius = 6366742.5194;  /* [m]      Mean Earth Radius */

   $sin_lat = sin($lat_gd);
   $sin2_lat = pow($sin_lat, 2);

   $Lat_gc = $lat_gd -
       $sin_lat*cos($lat_gd) *
       ($a1+$sin2_lat*($a2+$sin2_lat*($a3+$sin2_lat*$a4)));
   $Xsi = atan(tan($Lat_gc) / cos($long_gd-$RTH_L0));
   $Eta = atanh(cos($Lat_gc) * sin($long_gd-$RTH_L0));
   
   $res["X"] = $EarthRadius*($Xsi+$b1*sin(2.0*$Xsi)*cosh(2.0*$Eta) +
                             $b2*sin(4.0*$Xsi)*cosh(4.0*$Eta) +
                             $b3*sin(6.0*$Xsi)*cosh(6.0*$Eta));
   $res["Y"] = $Y0 + $EarthRadius*($Eta+$b1*cos(2.0*$Xsi)*sinh(2.0*$Eta) +
                                   $b2*cos(4.0*$Xsi) * sinh(4.0*$Eta) +
                                   $b3*cos(6.0*$Xsi) * sinh(6.0*$Eta));
   return $res;
} /* RT90 */

?>

Det går säkert åt någonting med motsvarande komplexitetsnivå för att konvertera från Sweref99 till WGS84.

m v h Henrik

[henca]

[quote quote=213]Till Henca ok laddade ner detta program 1.0.4. Här måste jag erkänna att min kunskap brister *.tar.gz är ju ett format som jag kopplar ihop med androider och programvara.

Misstänker att man måste ha något mer, men frågan är om jag ska ge mig in i detta [/quote]

Programmet är ingenting för “vanliga” GPS-användare. Programmet är bara för dem som vill sätta upp en egen web-server där man kan tanka hem GPS-filer.

m v h Henrik

[henca]

[quote quote=212]Om vi utgår från att vägverkets positionsbestämmelser är mest rätt. Gör en programsnutt som jämför koordinaterna matcha och hämta därefter all data som är kopplat till denna position och gör en ny fil…[/quote]

Problemet med att skapa en ny fil är att vägverkets fil inte innehåller alla data som vi vill ha i den nya filen. Att koordinaterna är på fel format är ett mindre problem. Större problem är de data som saknas, det saknas vägnamn och framförallt saknas hastighet.

m v h Henrik

[henca]

[quote quote=201]har lite idéer om hur det eventuellt skulle kunna gå till att få dit vägnamnet och gällande hastighet.
Återkommer när jag har haft tid o leka lite.[/quote]

Om du lyckas lösa detta så vore det en höjdare! Då skulle man kunna jämföra med de kameror som vi redan har och lägga till de kameror som saknas. Tyvärr kommer det ändock nog krävas en del manuellt arbete då många kameror mätts in manuellt och inte matats in med exakt samma koordinater. På något vis gäller det att identifiera vilka kameror som är nya och vilka som bara skiljer lite i position.

m v h Henrik

[henca]

[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

[henca]

Tack! De är nu inlagda som K86W01, K86N02, K86N03, K86S04 och K86S05.

m v h Henrik

[henca]

Tack!

De är nu inlagda som K263E08, K263E09 och K263N10.

m v h Henrik

[henca]

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

• Det här svaret redigerades för 7 år, 8 månader sedan av henca.

[henca]

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

• Det här svaret redigerades för 7 år, 8 månader sedan av henca.

[henca]

[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

[henca]

[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 bli

Formel: (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

[henca]

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/Karta

Men 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

[Författare]

Inlägg