GeoJSON i MongoDB: Czy warto przechowywać punkty jako GeoJSON.Point?

Question

Po wprowadzeniu 2.3 > MongoDB stał się jeszcze bardziej przydatny w obsłudze danych lokalizacyjnych i zapytaniach. MongoDB przechowuje dokumenty jako BSON, więc każdy dokument ma wszystkie pola dokumentu, co potencjalnie prowadzi do większych baz danych niż nasze konwencjonalne RMDBS.

Użyłem do przechowywania polilinii i wielokątów jako serii indeksowanych punktów, z dodatkowym polem reprezentującym kolejność każdej linii (robiłem to, aby zapewnić spójność, ponieważ używam JavaScript, więc punkty nie były zawsze przechowywane w ich prawidłowa kolejność). To było coś takiego:

polyline: { 
    [ 
    point: [0,0], 
    order: 0 
    ], 
    [ 
    point: [0,1], 
    order: 1 
    ] 
} 

Podczas gdy obecnie używam:

polyline: { 
    type: 'LineString', 
    coordinates: [ 
    [0,0], 
    [1,0] 
    ] 
} 

widziałem poprawę w wielkości dokumentów, jak niektóre polilinie może mieć maksymalnie 500 punktów.

Zastanawiam się jednak, jakie byłyby korzyści z przechowywania wszystkich moich Point danych jako GeoJSON. Jestem zniechęcony przez zwiększenie rozmiaru dokumentu, jak na przykład:

loc: [1,0] 

jest lepsze niż

loc: { 
    type: 'Point', 
    coordinates: [0,1] 
} 

iw ten sposób będzie łatwiej pracować.

Moje pytanie brzmi:

Czy lepiej/zalecany do punktów sklepowych jak GeoJSON obiektów w przeciwieństwie do tablicy 2 pkt?

Co mam uważany jest następujące:

• ograniczenia rozmiaru: mogę mieć potencjalnie miliony dokumentów z lokalizacją, które mogą wpłynąć na wielkość zbiorów i potencjalnie kieszeni.
• Spójność: Lepiej byłoby radzić sobie z każdym zestawem współrzędnych w formacie lng, lat, zamiast trzymać się punktów lat, lng, a dla wszystkich innych moich funkcji lokalizacji.
• Wygoda: jeśli zdobędę punkt i użyję z nim $geoWithin lub $geoIntersects, nie będę musiał najpierw przekonwertować go na GeoJSON przed użyciem go jako parametru query.

Co Jestem pewny jest:

• czy zostaną usunięte wsparcie dla loc: [x,y] w przyszłości na MongoDB
• żadnych korzyści indeksujące z 2dsphere w przeciwieństwie do 2d
• Niezależnie od wszelkich planowanych GeoJSON dodanie do MongoDB może spowodować konieczność zachowania spójności opisanej powyżej.

Wolałbym przenieść się do GeoJSON, podczas gdy moje dane są nadal w zarządzaniu, niż zmienić w przyszłości przy dużym obciążeniu.

Proszę uprzejmie poprosić o gruntownie przemyślaną (nawet jeśli lekko) odpowiedź. Nie wybiorę poprawnej odpowiedzi wkrótce, więc mogę ocenić każdą odpowiedź.

Nie jestem również pewien, czy SO jest właściwym miejscem do postawienia pytania, więc jeśli DBA jest bardziej odpowiednim miejscem, poruszę to pytanie. Wybrałem SO, ponieważ istnieje wiele związanych z MongoDB działań tutaj.

Answer 1

Polecam używanie nowego formatu GeoJSON. Chociaż nie uważam, że zapadły jakiekolwiek oświadczenia o zrzekaniu się wsparcia dla starego formatu, fakt, że odnoszą się one do niego jako dziedzictwa, powinien stanowić o ich opinii.

Istnieje kilka korzyści indeksowania do korzystania z 2dsphere zamiast 2d.

• Po pierwsze w rzeczywistości oblicza zapytania oparte na kuli ziemskiej. Jedną z wad indeksu 2d jest to, że nie uwzględnia to znaczenia, że ​​sam będziesz musiał obsługiwać konwersję, jeśli interesujesz się rzeczywistym obszarem objętym zapytaniem, a nie podstawowymi latami/lng.
• Możliwość korzystania z indeksów złożonych, jeśli chcesz zrobić coś w rodzaju "uzyskaj 100 wyników z tego obszaru jako pierwszego", a następnie 2dsphere to Twój jedyny wybór.
• Możliwość korzystania z zapytań geoIntersects.
• Zapytania geometrii GeoWithin wymagają użycia formatu geoJSON.

Jeszcze jedną ważną rzeczą jest to, że musisz mieć pewność, że zapytanie, którego używasz, jest obsługiwane przez indeks, którego używasz. Jeśli używasz 2dsphere na przykład nie możesz użyć zapytania $ box, ponieważ nie będzie ono indeksowane - jednak mongo nie ostrzeże Cię - wynik po prostu wykona skanowanie tabeli i będzie bardzo wolny!

Mongo provide a compatibility chart of which queries can be used with which index

Answer 2

Tak, myślę, że warto. Z moich doświadczeń z GeoSpatial Information System najlepiej byłoby przechowywać dane o lokalizacji w użytecznym i możliwym do przeniesienia standardzie. GeoJSON w MongoDB obsługuje standard odniesienia WGS84.

W MongoDB operator $near może wyszukiwać na starszych współrzędnych 2D i współrzędnych GeoJSON. W poprzedniej kolekcji współrzędnych 2d wartość $ blisko zwraca najbliższą pierwszą posortowaną kolekcję. $geoNear zwraca najbliższą pierwszą posortowaną kolekcję z odległością od wyszukanych meta danych punktu.

Inną zaletą jest możliwość korzystania z innych geoprzestrzennych zapytań (czyli $ geoWithin i $ geoIntersect) zwłaszcza jeśli przechowywania rodzajów innych GeoJSON (polilinia, Polygon)

Wreszcie While basic queries using spherical distance are supported by the 2d index, consider moving to a 2dsphere index if your data is primarily longitude and latitude.

mam nadzieję te informacje dają pewne punkty myślowe, co zrobić z danymi o lokalizacji.

Answer 3

Jeśli tylko geometrie punktowe Zapisywanie w swojej bazie danych, ale chcą wspierać wiele różnych GeoJSON odpytuje na tych danych, a następnie zwrócić uwagę, że jest możliwe, aby zapisać punkty w spuściźnie współrzędnych formatu pary i użyj indeksu 2dsphere.

release notes do pomocy GeoJSON MONGOOSE'S (MongoDB> = 2,4) uzyskując następujący przykład:

2dsphere indeks Legacy par współrzędnych:

new Schema({ 
    loc: { type: [Number], index: '2dsphere'} 
}); 

GeoJSON zapytanie na dziedzictwie współrzędnych parami, używając indeksu 2dsphere:

var geojsonPoly = { 
    type: 'Polygon', 
    coordinates: [[[-5,-5], ['-5',5], [5,5], [5,-5],[-5,'-5']]] 
}; 

Model.find({ loc: { $within: { $geometry: geojsonPoly }}});