Ho studiato questo problema da un po 'di tempo poiché ho sviluppato un'applicazione che consente all'utente di generare un rettangolo di area di interesse tramite un'azione DragBox o tracciando punti di estensione immessi dall'utente. Quando ho iniziato questa avventura, ero completamente nuovo su OpenLayers. Il problema con i punti di estensione immessi manualmente era che se AOI avesse coperto la linea dati internazionale il rettangolo disegnato sarebbe stato disegnato nel modo sbagliato in tutto il mondo. Numerosi utenti StackExchange hanno chiesto di questo problema solo per essere detto da un risponditore di OpenLayers che (e sto parafrasando qui) "OpenLayers non ha modo di conoscere l'intento direzionale dei punti da tracciare, quindi per impostazione predefinita ...". Uh, devo alzare la bandiera BS su quella risposta dato che ora ho imparato abbastanza su OpenLayers per essere pericoloso e questo problema mi sta succedendo. Il problema che ho con la loro risposta è che carico le coordinate in una misura che, per definizione, specifica la longitudine e la latitudine in alto a destra, nonché la longitudine e la latitudine in basso a sinistra. Se la longitudine in alto a destra si trova sul lato occidentale dell'IDL e la longitudine in basso a sinistra si trova sul lato orientale dell'IDL, è abbastanza ovvio in che modo l'utente vuole tracciare il poligono e tuttavia OpenLayers insiste sullo scambio dei valori longitudinali e sul disegno il poligono nel modo sbagliato nel mondo. Di seguito è riportato un esempio della dichiarazione di estensione e della chiamata problematica del metodo OpenLayers. Se la longitudine in alto a destra si trova sul lato occidentale dell'IDL e la longitudine in basso a sinistra si trova sul lato orientale dell'IDL, è abbastanza ovvio in che modo l'utente vuole tracciare il poligono e tuttavia OpenLayers insiste sullo scambio dei valori longitudinali e sul disegno il poligono nel modo sbagliato nel mondo. Di seguito è riportato un esempio della dichiarazione di estensione e della chiamata problematica del metodo OpenLayers. Se la longitudine in alto a destra si trova sul lato occidentale dell'IDL e la longitudine in basso a sinistra si trova sul lato orientale dell'IDL, è abbastanza ovvio in che modo l'utente vuole tracciare il poligono e tuttavia OpenLayers insiste sullo scambio dei valori longitudinali e sul disegno il poligono nel modo sbagliato nel mondo. Di seguito è riportato un esempio della dichiarazione di estensione e della chiamata problematica del metodo OpenLayers.
// I would start out with the following entered values as an example
lonLL = 175.781; // minX
latLL = 13.992; // minY
lonUR = -165.937;// maxX
latUR = 25.945; // maxY
// I would then make the following call
var manCoordEntryExtent = ol.extent.boundingExtent([[lonLL,latLL], [lonUR, latUR]]);
// Looking at the resulting structure in the debugger I get:
0: -165.937 // minX
1: 13.992 // minY
2: 175.781 // maxX
3: 25.945 // maxY
length: 4
__proto__: []
Come puoi vedere, le coordinate longitudinali vengono invertite e quindi dopo aver creato l'intera struttura delle coordinate, un poligono. un poligono Funzionalità e quindi applicare quella funzione a un vettore e infine tracciarlo solo per scoprire che il poligono va nella direzione sbagliata in tutto il mondo.
Avevo bisogno di capire perché questo stesse accadendo, così ho scavato in questo metodo ol.extent.boundingExtent nella libreria OpenLayers 4.
/**
* Build an extent that includes all given coordinates.
*
* @param {Array.<ol.Coordinate>} coordinates Coordinates.
* @return {ol.Extent} Bounding extent.
* @api
*/
ol.extent.boundingExtent = function(coordinates) {
var extent = ol.extent.createEmpty();
for (var i = 0, ii = coordinates.length; i < ii; ++i) {
ol.extent.extendCoordinate(extent, coordinates[i]);
}
return extent;
};
It first calls ol.extent.createEmpty to initially create an extent structure
/**
* Create an empty extent.
* @return {ol.Extent} Empty extent.
* @api
*/
ol.extent.createEmpty = function() {
return [Infinity, Infinity, -Infinity, -Infinity];
};
// It then iterates thru the number of coordinates and fills in the extent structure values, however...
// Here is where the problem is. Notice the complete lack of any explanation as to what the hell this
// method is doing. Why is it doing what it does? All I know is that it cannot handle plots across
// the IDL and it corrupts your extent structure if you try.
/**
* @param {ol.Extent} extent Extent.
* @param {ol.Coordinate} coordinate Coordinate.
*/
ol.extent.extendCoordinate = function(extent, coordinate) {
if (coordinate[0] < extent[0]) {
extent[0] = coordinate[0];
}
if (coordinate[0] > extent[2]) {
extent[2] = coordinate[0];
}
if (coordinate[1] < extent[1]) {
extent[1] = coordinate[1];
}
if (coordinate[1] > extent[3]) {
extent[3] = coordinate[1];
}
};
// The solution was for me to test for IDL myself and if found then create an empty extent and populate it myself manually.
// Using the same extent coordinates as before
lonLL = 175.781; // minX
latLL = 13.992; // minY
lonUR = -165.937;// maxX
latUR = 25.945; // maxY
// I test for Dateline instance (Dont have to worry about the potential of there being a polygon covering both Meridian
// and Anti-meridian as a valid polygon is limited to a maximum size of just over 12 million square kilometers.)
if ((lonLL > 0.0) && (lonUR < 0.0)) {
// Manually build the coordinates for the Area calculation as the boundingExtent
// codepath corrupts an extent to be plotted across the Dateline
var manCoordEntryExtent = ol.extent.createEmpty();
manCoordEntryExtent[0] = lonLL;
manCoordEntryExtent[1] = latLL;
manCoordEntryExtent[2] = lonUR + 360.0;
manCoordEntryExtent[3] = latUR;
} else {
var manCoordEntryExtent = ol.extent.boundingExtent([[lonLL,latLL], [lonUR, latUR]]);
}
// Looking at the resulting structure in the debugger I get:
0: 175.781 // minX
1: 13.992 // minY
2: 194.063 // maxX
3: 25.945 // maxY
length: 4
__proto__: []
Il mio codice calcola l'area in modo dinamico in modo da poter determinare se l'utente ha creato un poligono AOI di dimensioni valide. Quando sto elaborando una selezione generata da DragBox, sto richiedendo le coordinate dalla struttura della geometria risultante e per una proiezione EPSG: 4326 quando restituisce coordinate da un mondo avvolto, le coordinate oltre i primi 180,0 gradi continuano ad aumentare quindi la ragione del calcolo del 360,0 - 165,937 = 194,063. Il mio codepath per il calcolo dell'area utilizza il seguente test IDL e per utilizzare lo stesso codepath per le coordinate immesse manualmente avevo bisogno di simulare il valore delle coordinate come se fosse stato restituito dalla chiamata getGeometry di DragBox. Sto effettivamente testando una struttura poligonale GEOJSON che è un array tridimensionale con la prima dimensione che è il numero dell'anello,
function getArea(coords, extent) {
// Test for Western side of Dateline instance
if (((coords[0][0][0] <= -180.0) && (coords[0][2][0] > -180.0)) ||
// Test for Eastern side of Dateline instance
((coords[0][0][0] < 180.0) && (coords[0][2][0] >= 180.0))) {
.
.
.
Se questi test superano a questo punto il codice utilizza l'algoritmo che ho sviluppato per calcolare l'area sopra l'IDL, altrimenti la calcola normalmente come ovunque.
Quindi uso questa estensione per creare un poligono, quindi una funzione poligono, quindi applico quella funzione a un vettore e infine la tracciamo e questa volta è stata stampata correttamente. Quindi la correzione che mi è venuta per risolvere il problema di calcolo dell'area che avevo risolto anche il problema di stampa.
Forse questa soluzione aiuterà qualcun altro o li farà pensare in una direzione diversa. La soluzione mi è venuta quando sono finalmente riuscita a dividere il problema dell'IDL in due problemi. Il calcolo effettivo dell'area era un problema con l'altro era la stampa del poligono sull'IDL.
