Google Maps e lunghezza LINESTRING SQL Server incoerente

Question

Google Maps e MSSQL sembrano essere d'accordo sul modo di calcolare la distanza/lunghezza di una polilinea/linee che usando SRID 4326.

MSSQL:

SELECT geography::STGeomFromText('LINESTRING(-98.78 39.63,2.98 27.52)', 4326).STLength() 

Risultato: 9030715.95721209

allora Google Maps:

http://jsbin.com/niratiyojo/1/

Risultato: 9022896.239500616

In un primo momento ho pensato che fosse solo un diverso raggio di misura terra, così ho suonato in giro con questo e si è rivelato essere più.

Ho bisogno della mia interfaccia JavaScript per abbinare ciò che MSSQL segnalerebbe per rimanere coerente e preciso. Dove o come posso trovare come MSSQL calcola il loro STLength() e può essere replicato in JavaScript?

Aggiornamento:

ho capito se faccio

SELECT GEOGRAPHY::STGeomFromText('LINESTRING(-98.78 39.63,2.98 27.52)', 104001).STLength() * 6378137 

Poi MSSQL restituisce 9022896.23950062

La nuova SRID in MSSQL:

Nuovo “Unità Sphere” Spatial Reference ID Il riferimento spaziale predefinito ID (SRID) in SQL Server 2012 è 432 6, che utilizza il sistema metrico come unità di misura. Questo SRID rappresenta anche la vera forma a sfera ellissoidale della terra . Sebbene questa rappresentazione sia la più accurata, è anche più complessa calcolare la matematica ellissoidale . SQL Server 2012 offre un compromesso in termini di velocità e precisione , aggiungendo un nuovo riferimento spaziale id (SRID), 104001, che utilizza una sfera di raggio 1 per rappresentare una terra perfettamente rotonda.

Quindi il problema è che Google Maps non utilizza una vera sfera ellissoidale nei calcoli. Sto cercando una funzione javascript che ottenga 9030715.95721209 come testimoniato.

ho cercato formula diretta Vincenty qui: http://jsbin.com/noveqoqepa/1/edit?html,js,console e mentre è più vicino non riesco ancora a corrispondere MSSQL

Edit 2:

sono stato in grado di trovare le misure che usa:

SridList._sridList.Add(4326, new SridInfo(4326, "EPSG", 4326, "GEOGCS[\"WGS 84\", DATUM[\"World Geodetic System 1984\", ELLIPSOID[\"WGS 84\", 6378137, 298.257223563]], PRIMEM[\"Greenwich\", 0], UNIT[\"Degree\", 0.0174532925199433]]", "metre", 1.0, 6378137.0, 
6356752.314)); 

ma collegare apparentemente quelli in Vincenty non porta fortuna.

Answer 1

L'unico modo per accertarsi è quello di ottenere il programmatore Microsoft al telefono, disassemblare il codice o semplicemente inviare una query a un database di SQL Server e accettarne i risultati.

Questo può essere di aiuto a voi: Using SQL Spatial Types in a .NET Application

Se si vuole provare a smontare, credo che il metodo è nel file Microsoft.SqlServer.Types.dll.

Answer 2

Ti rendi conto che Google Maps utilizza Web Mercator, alias EPSG: 3857 e non WGS EPSG: 4326? Il Web Mercator article e i suoi riferimenti possono aiutare a spiegare le differenze.

Provare l'implementazione JavaScript di GeographicLib e/o Proj4js. Come indicato da this question/answer on gis.stackexchange, le implementazioni sottostanti delle conversioni di dati spaziali possono essere sottilmente diverse. Hai almeno bisogno di qualcosa di meglio di Vincenty diretto.

Answer 3

Dopo aver esaminato tutte le diverse opzioni, l'opzione migliore sembra essere quella di utilizzare la stessa funzione letterale sia sul server che sul client. Ciò può essere ottenuto in due modi:

Approccio 1: Utilizzare la funzione SQL sul client

In questo caso si potrebbe innescare una query AJAX sul client al server, che a sua volta interroga il database per il calcolo specifico desiderato e restituirlo al cliente.

Approccio 2: Utilizzare la funzione JavaScript in SQL

Questo potrebbe sembrare impossibile, ma usando xp_cmdshell è possibile execute command line commands from sql, ed è possibile eseguire JavaScript dal terminale usando qualcosa come node.js, quindi tutto ciò che si' Resta a sinistra con l'implementazione della funzione Vincenty per essere called from the command line.

La grande domanda qui è come sarà la performance. L'avvio e l'arresto di una istanza di node ogni pochi secondi sembra una cattiva idea, quindi sarebbe molto più ottimale codificare un servizio nel nodo per fare questo lavoro, tuttavia non saprei quale sarebbe il modo migliore per interagire con sql un tale servizio. L'approccio più semplice sarebbe probabilmente per averlo fare una richiesta HTTP a qualcosa di simile localhost:8888/?lat1=&lng1=&etc., ma che sta cominciando ad essere quasi così complesso come approccio 1.

Conclusione

Approccio 1 sembra essere ancora la più ragionevole, anche se l'approccio 2 ti dà molta più flessibilità per fare esattamente quello che vuoi. Per un progetto privato o un progetto perfezionista penso che andrei con l'approccio 2, per un 'dobbiamo finire questo e non abbiamo tempo per sorprese o ottimizzazioni' - un progetto di tipo penso che consiglierei l'approccio numero 1.