2017-01-05 6 views
1

Я работаю над проектом, где мне нужно хранить и выполнять вычисления на дорожках и точках SVG (желательно в MySQL). Мне нужно иметь возможность быстро запросить, находится ли точка внутри пути. Похоже, что геопространственные функции MySQL поддерживают этот вид запроса с помощью функции ST_Within.Должен ли я использовать типы геопространственных данных MySQL для векторной графики

Однако я нашел 2 противоположных утверждения относительно того, учитывает ли геопространственная функциональность MySQL «кривизна земли». "I understand spatial will factor in the curvature of the earth" и "all calculations are performed assuming Euclidean (planar) geometry as opposed to the geocentric system (coordinates on the Earth's surface)". Итак, мой вопрос заключается в том, какая из претензий истинна, и как это влияет на меня?

Также приветствуются любые общие рекомендации относительно того, должен ли я использовать этот подход для хранения объектов SVG в виде геопространственных типов данных MySQL.

+1

use postgis, где вы находитесь в полном соответствии с тем, чтобы использовать кривизну или нет. Он имеет геометрию и геометрию двух типов: – e4c5

+0

, а также postgresql имеет ST_DWithin, которого не хватает в mysql, и это настоящий mccoy. – e4c5

+0

@ e4c5 Спасибо за совет. Можете ли вы описать, как поддержка ST_DWithin будет проблемой в моем случае использования? [ST_Within] (https://dev.mysql.com/doc/refman/5.6/en/spatial-relation-functions-object-shapes.html#function_st-within) кажется достаточным для моего использования. Или, не так ли? –

ответ

2

При дальнейших исследованиях кажется, что второе утверждение верно. То есть все вычисления в MySQL выполняются без учета кривизны земли и просто предполагают плоскую плоскость. Ссылки:

Общие рекомендации относительно того, следует ли мне принимать этот подход хранения объектов SVG, как MySQL гео-пространственных типов данных по-прежнему очень приветствуется.