¿Cómo almacenar las líneas y polígonos en documentos JSON?

Question

Viendo la creciente NoSQL movimiento y teniendo en cuenta que las bases de datos como MongoDB ofrece una nueva perspectiva en almacenamiento de datos flexible para GIS. ¿Cuál es la mejor manera de almacenar las líneas y polígonos en documentos JSON para tomar ventaja de los índices 2d y funciones espaciales?

Answer 1

GeoJSON aquí están las Especificaciones.

Aquí está un ejemplo de una línea y un polígono:

{ "type": "FeatureCollection",
  "features": [
    { "type": "Feature",
      "geometry": {"type": "Point", "coordinates": [102.0, 0.5]},
      "properties": {"prop0": "value0"}
      },
    { "type": "Feature",
      "geometry": {
        "type": "LineString",
        "coordinates": [
          [102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]
          ]
        },
      "properties": {
        "prop0": "value0",
        "prop1": 0.0
        }
      },
    { "type": "Feature",
       "geometry": {
         "type": "Polygon",
         "coordinates": [
           [ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0],
             [100.0, 1.0], [100.0, 0.0] ]
           ]
       },
       "properties": {
         "prop0": "value0",
         "prop1": {"this": "that"}
         }
       }
     ]
   }

Answer 2

Una cosa a tener en cuenta es que MongoDB del soporte para tipos de datos espaciales es horriblemente malo para cualquier grave espacial de búsqueda, y esto se aplica a través de la junta con NoSQL última vez que lo comprobé. No me gusta GeoCouch un poco menos, pero también todavía tiene un camino que recorrer.

GeoJSON es un fantástico formato, pero para tomar ventaja de la limitada (PUNTO) índices espaciales en Mongo que había necesidad de un espacio indexado de la colección de la celebración de nada sino un registro para cada uno de los polígonos de puntos con un valor adicional para el ID de registro de su espaciales registro que viven en otra colección, a continuación, utilizar un cuadro delimitador de consulta para obtener los Id de registros de uno y seleccione una de las otras, de manera efectiva, emulando una combinación.

Usted podría ir chapucero y no con las esquinas de la caja de contorno de puntos para sus registros, pero, a continuación, cuadro delimitador de búsquedas puede fallar y todo ello obliga a algunos bastante ineficiente patrones de diseño y de forma inapropiada empuja a todos los tipos de responsabilidades para el desarrollador.

Como una implementación de referencia, usted puede querer referirse a este código, que fue presentado en la Cumbre de Desarrolladores de Esri este año.

No he sido feliz con la distribución espacial de apoyo en las diversas bases de datos NoSQL. Ellos sólo van lo suficientemente lejos como para tontos nube de puntos de búsqueda, lo cual tiene sentido considerando que la mayoría de las aplicaciones que utilizan este sólo están cayendo marcadores en un mapa de Google en un navegador en algún lugar. PostGIS es todavía va a ser la mejor fuente abierta caballo de batalla para la gestión de información espacial para el futuro previsible.

Answer 3

Esto simplemente no es cierto,

"para tomar ventaja de los índices espaciales en Mongo, que había necesidad de un espacio indexado de la colección de la celebración de nada sino un registro para cada uno de los polígonos de puntos, con un valor adicional para el ID de registro de su espaciales registro que viven en otra colección, a continuación, utilizar un cuadro delimitador de consulta para obtener los Id de registros de una [colección] y seleccione [registro de datos] en el [colección], de manera efectiva, emulando una combinación."

He USGS punto de datos se almacenan en un único Mongo colección de registros que se parecen a esto:

> db.names.find({FEATURE_NAME: 'Mount Saint Helens', STATE_ALPHA: 'WA'})       
{ "_id" : ObjectId("4e262106d7a99b7db41a4919"), 
"_ID" : 1525360, 
"FEATURE_NAME" : "Mount Saint Helens", 
"FEATURE_CLASS" : "Summit", 
"STATE_ALPHA" : "WA", 
"STATE_FIPS" : 53, 
"COUNTY_NAME" : "Skamania", 
"COUNTY_FIPS" : "059", 
"COORDS" : [ -122.1944, 46.1912 ], 
"ELEV_IN_FT" : "8356" }

Yo soy capaz de hacer cuadro delimitador consultas sobre este dato que devolverá la totalidad del registro (sin la necesidad de otra colección) bien.

Consulta:

> box = [[-126.562500,45.089036], [-123.750000,47.040182]]
[ [ -126.5625, 45.089036 ], [ -123.75, 47.040182 ] ]
> db.names.find({"COORDS" : {"$within" : {"$box" : box}}, FEATURE_CLASS: "Summit"}, {FEATURE_NAME: true, COUNTY_NAME: true, STATE_ALPHA: true, ELEV_IN_FEET: true}).limit(5);

Respuesta:

{ "_id" : ObjectId("4e2620f8d7a99b7db4146cec"), "FEATURE_NAME" : "Harlocker Hill", "STATE_ALPHA" : "OR", "COUNTY_NAME" : "Coos" }
{ "_id" : ObjectId("4e2620f8d7a99b7db414a349"), "FEATURE_NAME" : "Neskowin Crest", "STATE_ALPHA" : "OR", "COUNTY_NAME" : "Tillamook" }
{ "_id" : ObjectId("4e2620f8d7a99b7db414a105"), "FEATURE_NAME" : "Miles Mountain", "STATE_ALPHA" : "OR", "COUNTY_NAME" : "Tillamook" }
{ "_id" : ObjectId("4e2620f8d7a99b7db414934a"), "FEATURE_NAME" : "Mount Gauldy", "STATE_ALPHA" : "OR", "COUNTY_NAME" : "Tillamook" }
{ "_id" : ObjectId("4e2620f8d7a99b7db4149d06"), "FEATURE_NAME" : "Little Hebo", "STATE_ALPHA" : "OR", "COUNTY_NAME" : "Yamhill" }

Mongo también proporciona la capacidad de hacer del vecino más cercano búsquedas, así como el punto en el polígono de las búsquedas. Esto está bien documentado en mongodb.org