X,Y naar Lat,Long

[Martin]

Hoi,

Omdat de NS niet weet waar alle stations liggen (via api) wil ik de gegevens uit de iff gaan gebruiken die 9292 aanlevert. deze heeft deze informatie wel :)

Echter staat in de iff bestanden een X en een Y as inplaats latitude en longitude. Hoe moet ik dit omrekenen? Ik heb even zitten snuffelen op internet en je hebt dan een begin punt enzo nodig begrijp ik maar deze kan ik nergens vinden in de documentatie. Weet misschien iemand hier iets meer over?  :)

[Stefan de Konink]

On Tue, 23 Oct 2012, Martin wrote:

> Omdat de NS niet weet waar alle stations liggen (via api) wil ik de gegevens
> uit de iff gaan gebruiken die 9292 aanlevert. deze heeft deze informatie wel
> :)

Ik denk dat je het beste de GTFS van Thomas kan pakken.

Om X/Y om te zetten moet je RD omzetten naar WGS84. Dat gaat het snelste
met PostGIS.

ST_Transform(st_setsrid(st_makepoint(locationx_ew, locationy_ns), 28992),
4326)

Stefan

[Koch]

Martin gebruikt MySQL afaik.
Dat NS hiervoor RD gebruikt is overigens een faal. De stations in het buitenland zijn ernstig misplaatst of hebben geen locatie de befaamde (0,0)
Op https://github.com/StichtingOpenGeo/Koppelvlakken/tree/master/iff

Heb ik in het GTFS een output naar WGS84.
Ook staat daar een lijst met locatie van stations+perrons, die gecrowdsourced is.
Op woensdag 24 oktober 2012 10:03:22 UTC+2 schreef Stefan de Konink het volgende:

[Martin]

Ok dan kan ik beter die gaan gebruiken idd. Dat staat in de stops_positioned.txt?

En omdat ik heb gezien dat kv6 van 9292opendata ook de x,y doorgeeft heb ik er even een php scriptje bijgezocht.

Wel raar dat er een apart gebruikt wordt idd. Vooral omdat je ook stations in buitenland bedient. 

function rd2wgs ($x, $y)

{

    // Calculate WGS84 coördinates

    $dX = ($x - 155000) * pow(10, - 5);

    $dY = ($y - 463000) * pow(10, - 5);

    $SomN = (3235.65389 * $dY) + (- 32.58297 * pow($dX, 2)) + (- 0.2475 *

         pow($dY, 2)) + (- 0.84978 * pow($dX, 2) *

         $dY) + (- 0.0655 * pow($dY, 3)) + (- 0.01709 *

         pow($dX, 2) * pow($dY, 2)) + (- 0.00738 *

         $dX) + (0.0053 * pow($dX, 4)) + (- 0.00039 *

         pow($dX, 2) * pow($dY, 3)) + (0.00033 * pow(

            $dX, 4) * $dY) + (- 0.00012 *

         $dX * $dY);

    $SomE = (5260.52916 * $dX) + (105.94684 * $dX * $dY) + (2.45656 *

         $dX * pow($dY, 2)) + (- 0.81885 * pow(

            $dX, 3)) + (0.05594 *

         $dX * pow($dY, 3)) + (- 0.05607 * pow(

            $dX, 3) * $dY) + (0.01199 *

         $dY) + (- 0.00256 * pow($dX, 3) * pow(

            $dY, 2)) + (0.00128 *

         $dX * pow($dY, 4)) + (0.00022 * pow($dY,

            2)) + (- 0.00022 * pow(

            $dX, 2)) + (0.00026 *

         pow($dX, 5));

 

    $Latitude = 52.15517 + ($SomN / 3600);

    $Longitude = 5.387206 + ($SomE / 3600);

 

    return array(

        'latitude' => $Latitude ,

        'longitude' => $Longitude);

[Koch]

Ik weet niet hoe nauwkeurig die methode gaat zijn, ik zou zelf kiezen
voor proj4 waar vast wel een PHP binding voor is.

> > Ophttps://github.com/StichtingOpenGeo/Koppelvlakken/tree/master/iff

[Martin]

Ah zoiets als http://sourceforge.net/projects/proj4php/ bedoel je? ga ik naar kijken :)

eerst maar even mijn momentele project afmaken. daar heb ik het nog niet bij nodig dankzij dat andere bestand met locaties. Ook handig trouwens dat de gps locaties van alle sporen erin staan. Heb ik misschien ook wel nodig. :)

[FrankM]

Op woensdag 24 oktober 2012 11:43:59 UTC+2 schreef Koch het volgende:

Dat NS hiervoor RD gebruikt is overigens een faal.

Dat is een beetje misplaatst. Om te beginnen heeft de OP het over een bestand dat 9292 aanlevert, dus als er iemand zou falen dan is het 9292 want die levert het zaakje aan.

Dat RD gebruikt wordt is verder niet vreemd. Uiteindelijk zijn het allemaal overheidsbedrijven (geweest) en de overheid gebruikt het Rijksdriehoeksstelsel. Dat wordt actief beheerd en onderhouden door het Kadaster en het is, ook al ben je er misschien niet gelukkig mee, gewoon een standaard.

Als je WGS of ETRS coordinaten wilt dan kan je die simpel omrekenen.

 

De stations in het buitenland zijn ernstig misplaatst of hebben geen locatie de befaamde (0,0)

 

Ja... het RD stelsel is ook niet bedoeld voor locaties buiten Nederland. Dus als je het over falen hebt...heb je daar een punt.

Gr/F

NB: voor wie het echt wil: de officiele omrekenfunctie van het Kadaster: http://www.kadaster.nl/rijksdriehoeksmeting/docs/RDNAPTRANS2008.zip

[Koch]

On 25 okt, 12:55, FrankM <maas.fr...@gmail.com> wrote:
> Op woensdag 24 oktober 2012 11:43:59 UTC+2 schreef Koch het volgende:
>
>
>
> > Dat NS hiervoor RD gebruikt is overigens een faal.
>
> Dat is een beetje misplaatst. Om te beginnen heeft de OP het over een
> bestand dat 9292 aanlevert, dus als er iemand zou falen dan is het 9292
> want die levert het zaakje aan.

9292 levert (als het goed is) direct door. HP ism. met NS maakt deze data.

>
> Dat RD gebruikt wordt is verder niet vreemd. Uiteindelijk zijn het allemaal
> overheidsbedrijven (geweest) en de overheid gebruikt het
> Rijksdriehoeksstelsel. Dat wordt actief beheerd en onderhouden door het
> Kadaster en het is, ook al ben je er misschien niet gelukkig mee, gewoon
> een standaard.

Voor KV6 & KV1 en andere OV toepassingen binnen Nederland is Rijksdriehoek inderdaad zeer geschikt. Voor de NS IFF is het een heel ander verhaal, hier zitten stations in tot in Polen. 158 van de 597 stations is buiten Nederland.

Mijn issue met de keuze voor RD in IFF data is daarnaast dat ze gewoon de stations die niet binnen hun systeem pasten op 0,0 hebben gezet. Ook zijn er nieuwe stations ingemeten op een locatie van soms 200 meter verder.
Ander puntje is dat ze in de documentatie niet hebben gespecificeerd wat het projectiesysteem überhaupt is.

>
> Als je WGS of ETRS coordinaten wilt dan kan je die simpel omrekenen.
>
> > De stations in het buitenland zijn ernstig misplaatst of hebben geen
> > locatie de befaamde (0,0)
>
> Ja... het RD stelsel is ook niet bedoeld voor locaties buiten Nederland.
> Dus als je het over falen hebt...heb je daar een punt.

Yep ;)

>
> Gr/F
>
> NB: voor wie het echt wil: de officiele omrekenfunctie van het
> Kadaster:http://www.kadaster.nl/rijksdriehoeksmeting/docs/RDNAPTRANS2008.zip

Wat makkelijker werkt toch de PROJ4 library. Ik gebruik altijd de verbeterde projectiestring op http://blog.openstreetmap.nl/index.php/2012/01/21/rd/

[FrankM]

Op donderdag 25 oktober 2012 15:42:01 UTC+2 schreef Koch het volgende:

9292 levert (als het goed is) direct door. HP ism. met NS maakt deze data.

En precies daarom noem ik het eerder een falen door 9292. NS maakt de data voor "intern gebruik". Als 9292 dat verder verspreid mogen ze er ook wel wat voor doen om het bruikbaar te maken...

 

Voor KV6 & KV1 en andere OV toepassingen binnen Nederland is Rijksdriehoek inderdaad zeer geschikt. Voor de NS IFF is het een heel ander verhaal, hier zitten stations in tot in Polen. 158 van de 597 stations is buiten Nederland.

Mijn issue met de keuze voor RD in IFF data is daarnaast dat ze gewoon de stations die niet binnen hun systeem pasten op 0,0 hebben gezet. Ook zijn er nieuwe stations ingemeten op een locatie van soms 200 meter verder.
Ander puntje is dat ze in de documentatie niet hebben gespecificeerd wat het projectiesysteem überhaupt is.

Hier geef ik je helemaal gelijk. Ik snap ook niet dat ze dat zelf doen, want RD en buitenland is geen gunstige combinatie. Maar ik verwacht dat ze intern alleen maar RD-georienteerde systemen hebben en dat dit min of meer de enige mogelijkheid is om buitenlandse stations uberhaupt te visualiseren. Waarom nieuwe stations "verkeerd" zijn ingemeten is ook wat ongewis, hoewel ik vrees dat ze dan door een WGS/ETRS gebruiker zijn ingemeten en (verkeerd) worden geconverteerd naar RD.

 

> NB: voor wie het echt wil: de officiele omrekenfunctie van het
> Kadaster:http://www.kadaster.nl/rijksdriehoeksmeting/docs/RDNAPTRANS2008.zip

Wat makkelijker werkt toch de PROJ4 library. Ik gebruik altijd de verbeterde projectiestring op http://blog.openstreetmap.nl/index.php/2012/01/21/rd/

Zeker, maar een referentie naar "de officiele" richtlijn vond ik wel op zijn plek. ;-)

Gr/F

[Stefan de Konink]

On Fri, 26 Oct 2012, FrankM wrote:

> En precies daarom noem ik het eerder een falen door 9292. NS maakt de data
> voor "intern gebruik". Als 9292 dat verder verspreid mogen ze er ook wel wat
> voor doen om het bruikbaar te maken...

Een NDOV-loket moet niet meer doen dan doorleveren wat ze binnen krijgen.
De bronhouder moet data van kwaliteit leveren. Al het gehack van 9292 in
die bestanden moet dus ophouden, de data moet vanaf het begin goed zijn.

> Hier geef ik je helemaal gelijk. Ik snap ook niet dat ze dat zelf doen, want
> RD en buitenland is geen gunstige combinatie. Maar ik verwacht dat ze intern
> alleen maar RD-georienteerde systemen hebben en dat dit min of meer de enige
> mogelijkheid is om buitenlandse stations uberhaupt te visualiseren. Waarom
> nieuwe stations "verkeerd" zijn ingemeten is ook wat ongewis, hoewel ik
> vrees dat ze dan door een WGS/ETRS gebruiker zijn ingemeten en (verkeerd)
> worden geconverteerd naar RD.

Je kunt ook zeggen: intern doen ze niets met coordinaten. (Bijvoorbeeld
geen onderdeel van A* heuristiek.)


Stefan

[Koch]

NS verspreidt deze data (stationslocaties) ook zelf via de NS-API.

Op vrijdag 26 oktober 2012 13:03:05 UTC+2 schreef FrankM het volgende:

[Martin]

Ja idd, en dat was op begin een puinhoop (lagen enkele stations in de noordzee enzo). Maar nog steeds niet allemaal correct. Zelfs binnen nederland zijn stations met coordinaten 0,0. Volgens mij zijn dat alleen nieuwe maar waarom is dit nog niet correct ingevoerd? 

[FrankM]

Op vrijdag 26 oktober 2012 13:11:19 UTC+2 schreef Stefan de Konink het volgende:

On Fri, 26 Oct 2012, FrankM wrote:

> En precies daarom noem ik het eerder een falen door 9292. NS maakt de data
> voor "intern gebruik". Als 9292 dat verder verspreid mogen ze er ook wel wat
> voor doen om het bruikbaar te maken...

Een NDOV-loket moet niet meer doen dan doorleveren wat ze binnen krijgen.
De bronhouder moet data van kwaliteit leveren. Al het gehack van 9292 in
die bestanden moet dus ophouden, de data moet vanaf het begin goed zijn.

 

Dat eerste ben ik niet met je eens. Er wordt (ook op dit moment) heel veel geld verspild omdat "bronhouders" data moeten converteren voor ze het bij een ND* afleveren. En niet alleen die geldverspilling is mij een doorn in het oog, maar ook het feit dat die conversie wordt belegd bij partijen die er de ballen verstand van hebben.

Je kunt als ND* veel beter de data native inzamelen en converteren naar een voor jouw publiek bruikbare interface. De kennis daarover vent je vervolgens ook richting de bronhouders uit die daar hun voordeel mee kunnen doen. Maar belangrijker is dat je als ND* kunt investeren in die kennis en je daardoor kunt omringen met partijen die het (a) kunnen en (b) voor een normale prijs aanbieden. Dat is iets dat de bronhouders, ieder afzonderlijk, helaas nooit (meer) gaat lukken.

Waar je je niet in moet vergissen is dat er geen "een-waarheid" is als het gaat om "goede data". Wie met een RD-georienteerd systeem werkt kan, de inmeetfouten waar Koch het over had even daargelaten, gewoon werken met de brondata. Dat het, in een wereld die nogal GPS/WGS84 georienteerd is, onhandig is, maakt het nog niet 'fout'.

Gr/F

[Thomas Koch]

Ik ben het niet met je eens

Op zaterdag 27 oktober 2012 16:31:41 UTC+2 schreef FrankM het volgende:

Op vrijdag 26 oktober 2012 13:11:19 UTC+2 schreef Stefan de Konink het volgende:

On Fri, 26 Oct 2012, FrankM wrote:

> En precies daarom noem ik het eerder een falen door 9292. NS maakt de data
> voor "intern gebruik". Als 9292 dat verder verspreid mogen ze er ook wel wat
> voor doen om het bruikbaar te maken...

Een NDOV-loket moet niet meer doen dan doorleveren wat ze binnen krijgen.
De bronhouder moet data van kwaliteit leveren. Al het gehack van 9292 in
die bestanden moet dus ophouden, de data moet vanaf het begin goed zijn.

 

Dat eerste ben ik niet met je eens. Er wordt (ook op dit moment) heel veel geld verspild omdat "bronhouders" data moeten converteren voor ze het bij een ND* afleveren. En niet alleen die geldverspilling is mij een doorn in het oog, maar ook het feit dat die conversie wordt belegd bij partijen die er de ballen verstand van hebben.

Bronhouders hoeven data niet te converteren voor het NDOV. Er is ze gevraagd waarmee ze nu communiceren met andere partijen en dat is het formaat wat nu in het publicatiedocument staat. RET levert bijvoorbeeld uit in hun PAS.
Tevens is er in Nederland door BISON (http://bison.connekt.nl/home/) een uniforme uitwisselingsstandaard opgesteld voor zowel dynamische en statische data. Elke stad/streekvervoerder in Nederland op de RET na kan nu hun statische dienstregeling (en ook al geruime tijd) in het BISON formaat Koppelvlak1 exporteren, Arriva doet dit zelfs voor hun spoor en waterboten netwerk. Dezelfde vervoerders genereren ook al BISON KV6, actuele voertuig posities en punctualiteit.
 

Je kunt als ND* veel beter de data native inzamelen en converteren naar een voor jouw publiek bruikbare interface. De kennis daarover vent je vervolgens ook richting de bronhouders uit die daar hun voordeel mee kunnen doen. Maar belangrijker is dat je als ND* kunt investeren in die kennis en je daardoor kunt omringen met partijen die het (a) kunnen en (b) voor een normale prijs aanbieden. Dat is iets dat de bronhouders, ieder afzonderlijk, helaas nooit (meer) gaat lukken.

 

En welke publiek bruikbare interface denk je dan?

Jouw model heet 9292 en heeft volkomen gefaald. 9292 detecteert de meest basale fouten nog niet, laat staan terugleveren. In plaats van te werken aan de BISON koppelvlakken worden de planningen nog steeds aangeleverd in een allergaartje aan vage formaten en ongedocumenteerde hacks.
Vervoerders moeten zowiezo gaan werken aan het verbeteren van data, want dat is ook in hun eigen voordeel.
Denk aan de OV-chipkaart. Ongepubliceerde omleidingen tot foutieve checkin/checkuits waardoor je als reiziger te veel/te weinig betaald. Een halte die niet precies is ingemeten? Halte wordt niet gezien door boordcomputer en dus gaat het mis. Er is echt een ton aan dit soort voorbeelden waarbij slechte data in het nadeel zijn van de vervoerder.

Waar je je niet in moet vergissen is dat er geen "een-waarheid" is als het gaat om "goede data". Wie met een RD-georienteerd systeem werkt kan, de inmeetfouten waar Koch het over had even daargelaten, gewoon werken met de brondata. Dat het, in een wereld die nogal GPS/WGS84 georienteerd is, onhandig is, maakt het nog niet 'fout'.

Bison KV1/6 doet ook rijksdriehoek. Wie afwijkt is Syntus in zijn VDV452 welke locaties opslaat als  WGS84 microdegrees
 

Gr/F

[Stefan de Konink]

On Sat, 27 Oct 2012, FrankM wrote:

> Dat eerste ben ik niet met je eens.

Helaas draag ik alleen het standpunt van het Ministerie van Infrastructuur
& Milieu uit ;) En 9292 kennende zullen ze exact hetzelfde doen ;)

> Er wordt (ook op dit moment) heel veel
> geld verspild omdat "bronhouders" data moeten converteren voor ze het bij
> een ND* afleveren.

Er wordt juist gezegd dat brondocumenten _niet_ geconverteerd moeten
worden maar dat ze volgens een consessie aan een standaard moeten voldoen.
Als de bronhouder z'n zaakjes niet op orde heeft, is het aan de overige
inschrijvers op een concessie dat aan te tonen.

> En niet alleen die geldverspilling is mij een doorn in
> het oog, maar ook het feit dat die conversie wordt belegd bij partijen die
> er de ballen verstand van hebben.

Ik zou dat niet te hard zeggen, want gezien de veiligheid op het spoor is
het van heel groot belang dat iedereen z'n zaakjes op orde heeft. Voor
hij/zij er met treintjes op gaat rijden. We willen immers geen ongelukken.

> Waar je je niet in moet vergissen is dat er geen "een-waarheid" is als het
> gaat om "goede data". Wie met een RD-georienteerd systeem werkt kan, de
> inmeetfouten waar Koch het over had even daargelaten, gewoon werken met de
> brondata. Dat het, in een wereld die nogal GPS/WGS84 georienteerd is,
> onhandig is, maakt het nog niet 'fout'.

Zolang de brondata niet in EuroDisney ligt ;) En dat doet het wel.


Stefan

[FrankM]

Aangezien het al lang niet meer over X/Y gaat stel ik voor de discussie te besluiten. Laten we maar zien hoe het loopt. Mijn ervaring uit het verleden maakt mij niet hoopvol.

Gr/F