Coordinaten koppijn

[renevanh]

Voor een klant ben ik een bestaande (.Net dacht ik) stand alone app aan het ombouwen naar een webapplicatie. Helaas heb ik geen toegang tot de broncode maar uiteraard wel (na wat moeite met conversie) de SQLlite database naar MySQL kunnen omzetten.

De database is in feite een gigantische lijst gebouwen met allerlei eigenschappen, waaronder de coordinaten.
Die moeten bij het aanklikken van een gebouw direct naar een Bing mapje geschoten worden waarbij direct ingezoomd wordt op (de locatie van) het gebouw. Dat lukt allemaal qua functionaliteit, behalve dat ik met de coordinaten vastloop.

Volgens de kolom 'coordsystem' in de database gaat het om WGS84 coordinaten. Fijn dat er zo'n kolom is overigens.
Echter, ze lijken er niet echt op en zien er als volgt uit:

code:

x = 595002.01011843
y= 6806132.9670098
z = 0

Na ongeveer een halve dag pielen, converters en diverse scripts proberen, Google'n en veel over coordinatensystemen lezen kom ik er nog niet uit. Ik krijg er geen werkbare lat/long uit die ik in Bing kan invoeren en me dan op de juiste plek brengt. Ik kom in de buurt (halverwege het kanaal) maar dat is niet waar ik moet zijn.

Ter info: de lat/long van bovengenoemde coordinaten zouden (give or take een paar meter) moeten zijn:

code:

Lat: 52.033211
Long: 5.344767

Wie weet hier meer over? Is er iemand die het gebruikte systeem herkent en me de goede richting op kan sturen? Uiteindelijk ben ik niet bepaald een geografisch expert...

[Croga]

Na even kort zoekwerk:

Ten eerste is er niet zoiets als "WGS84 coordinaten". WGS84 is een methode die coordinaten op verschillende manieren kan registreren. Je zult dus eerst moeten uitzoeken welke manier gebruikt is, welke notatie.
Ten tweede geeft Wikipedia aan dat het WGS84 systeem een afwijking heeft van grofweg 100 meter. Als je daar voor kunt compenseren kom je er wellicht wel.

Aan de nauwkeurigheid zou het in ieder geval niet mogen liggen; die is in WGS beter dan in GPS.

[ Voor 198% gewijzigd door Croga op 19-02-2015 23:22 ]

[ajakkes]

In eerste instantie zou ik zeggen dat het coord. in decimale graden zijn vermenigvuldigd met 10.000 voor x en 1000.000 voor y. Maar dan nog kom je niet in de buurt van 52 en 5. Het in Nederland veelgebruikte Rijksdriehoek kan het ook niet zijn. Het lijkt een ander stelsel te zijn maar welke weet ik nog niet.

Succes

Edit:
Dit zou het wel eens kunnen zijn:
http://tsusiatsoftware.ne...nateSystemCalculator.html

Oftewel BC Albers coordinaten systeem ipv WGS84.

[ Voor 20% gewijzigd door ajakkes op 19-02-2015 23:42 . Reden: even zoeken ]

[Rikkiz0r]

Weet je zeker dat Z = 0 correct is in je sample data? Heb je misschien meer data?

[defiant]

Gebruikt de App die je moet reverse engineeren zelf een online kaart ? Je zou kunnen kijken met een HTTP sniffing tool welke request hij daadwerkelijk verstuurd naar de kaartserver, dat kan je een inzicht geven of de geodata intern misschien getransformeerd wordt.

Verder is dit een handige tool: Coordinates transformation on-line, maar die had je waarschijnlijk al gevonden.
Edit: of de tool van ajakkes

[ Voor 3% gewijzigd door defiant op 19-02-2015 23:50 ]

[Douweegbertje]

Je data is 'shapefile' soort format wat wel gebruikt wordt met de meeste GIS data/software.
Best bet is om het in CSV te dumpen en vervolgens te converteren naar iets wat jij wel kan gebruiken.

CSV als ;

x, y
595002.01011843, 6806132.9670098


'epsg:4326' is nog een term waar je op zou kunnen zoeken

Rikkiz0r schreef op donderdag 19 februari 2015 @ 23:39:
Weet je zeker dat Z = 0 correct is in je sample data? Heb je misschien meer data?

Want? Met x en y kun je z uitrekenen. Overigens totaal niet relevant voor bepaalde data, daarom dus.

[ Voor 33% gewijzigd door Douweegbertje op 20-02-2015 00:01 ]

[Rikkiz0r]

Ik zat zelf aan een formaat te denken waarbij het wel relevant is, van daar mijn vraag

[ajakkes]

Ben wel benieuwd hoe je z uitrekend met x en y?

En epsg:4326 is nog steeds WGS84 wat een bereik heeft van -180 tot 180 en -90 tot 90. Dat komt niet in de buurt van 6 miljoen.

Een shapefile is een manier van opslaan. Hier kan elk coordinatenstelsel in opgeslagen worden. Maar TS geeft aan dat zijn coordinaten in sqllite zaten en inmiddels in mysql zitten. Lijkt me vrij zinloos om er dan csv van te maken.

Het is volgens mij mogelijk dat z een invloed heeft op de x y weergave van een punt doordat de hoogte van de twee stelsels verschillen. Maar dat is marginaal. Z is dus niet de oorzaak van de afwijking. Maar het is vrij lastig rekenen als je niet weet van welk stelsel je naar WGS84 moet gaan rekenen.

[MSalters]

Heb je meer bekende punten? Dan is het een kwestie van de puntenparen Y/Lat en X/Long in Excel gooien, 2 grafiekjes ervan maken, trendlijn fitten, klaar.

[Verwijderd]

Heb je al geprobeerd om met een tool als dotPeek de source van de .NET applicatie te achterhalen?

[Umbrah]

Met 6mln is het niet eens EPSG:28992; zelfs niet met verschoven decimaal want dan zou je één coordinaat onder de 300k verwachten.

Weet je 100% zeker dat het een as-is SQLite omgeving was en niet een systeem met een extensie zoals spatialite? Wat spatialite doet is in feite heel simpel een extra datatype toevoegen: "geometrie". Een hele hoop geometrieformaten zijn omschreven als onderdeel van de SFS standaard die weer onder de OGC noemer valt, wat de instantie is die eigenlijk "alles geo" min of meer standaardiseert:

http://www.opengeospatial.org/standards/sfs

Nogmaals: zit je niet zonder extensie nu iets uit een SQLite database te halen waar je idealiter een extensie voor hebt? Met dotpeek iig even kijken naar spatialite zal niet verkeerd zijn!

[DonJunior]

Is 'Z' sowieso niet gewoon de 'altitude'?

[Umbrah]

Niet elk coordinatenstelsel heeft faciliteit voor hoogte, vandaar dat we in Nederland onder meer ook van het rijksdriehoekstelsel afstappen naar ETRS89

[AlphaRomeo]

Verwijderd schreef op vrijdag 20 februari 2015 @ 07:04:
Heb je al geprobeerd om met een tool als dotPeek de source van de .NET applicatie te achterhalen?

Dikke kans dat je door dat überhaupt te doen al een of andere license schendt.
Edit: bovendien is er natuurlijk een kans dat het ge-obfuscate is.

Is er niet gewoon een kans dat als je een mailtje stuurt naar de auteurs van het originele programma dat ze je even wat snelle insight geven over het gebruikte formaat? Nee heb je... ja kun je krijgen.

[ Voor 7% gewijzigd door AlphaRomeo op 20-02-2015 10:04 ]

[jackaubrey]

https://code.google.com/p/geoconvertor/

java api om coordinaten te converteren, weet alleen niet of het geschikt is voor jouw coordinaten

[pedorus]

MSalters schreef op vrijdag 20 februari 2015 @ 01:25:
Heb je meer bekende punten? Dan is het een kwestie van de puntenparen Y/Lat en X/Long in Excel gooien, 2 grafiekjes ervan maken, trendlijn fitten, klaar.

Dit. Ik denk ook dat 1 punt geen punt is... En wat voor systeem het ook is, een polynoom fitten zou altijd een zeer goede benadering moeten geven.

Het lijkt een beetje op UTM WGS84 (zone 31), maar dan valt het punt niet meer in Nederland.

[The N Man]

Volgens mij zijn deze coördinaten gewoon in Web Mercator / EPSG:3857. Een transform lijkt dat te bevestigen.

[mngm]

Ziet er uit als lambert 2008: Wikipedia: Lambertcoördinaten

[ProfPi]

The N Man is right:

Lon = 180*x/20037508,34
Lat = 180/PI() * (2 * ATAN(EXP( y / 20037508,34 * PI())) - PI() / 2)

Dan kom je op
Lon = 5,344993998
Lat = 52,03321271

[ Voor 7% gewijzigd door ProfPi op 20-02-2015 13:03 ]

[renevanh]

Top! Dank voor alle tips, meedenken, ideeen en zelfs de oplossing!