Из-за ограничений движка GQL было высказано предположение, что люди, желающие выполнить поиск по близости, должны найти что-то вокруг этих ограничений, используя предложенную геомодель. Это может быть не очень изящное или быстрое решение, но есть ли что-нибудь, чтобы остановить любого, кто использует алгоритм отсюда:
SELECT id, ( 3959 * acos( cos( radians(lat_t) ) * cos( radians( lat ) ) * cos( radians( lng ) - radians(lng_t) )
+ sin( radians(lat_t) ) * sin( radians( lat ) ) ) ) AS distance
FROM Stores HAVING distance < 25
ORDER BY distance
как простой способ вычисления расстояния. То есть мы просто вычисляем расстояние вручную для каждой пары (lat, lng) и (lat_t, lng_t) путем прокрутки каждой записи в нашем хранилище данных и, таким образом, получения идентификатора таким образом всех записей, которые находятся на нашем целевом расстоянии без прибегнуть к использованию команды HAVING? Итак, чтобы подвести итог, мы сделаем простой поиск GQL, чтобы получить все записи и пропустить все пары lng/lat и сравнить с нашими целевыми значениями.
Очевидно, что этот фрагмент является некотором ароматом SQL и несовместим с Datastore гораздо более простым индексированием.
Если вы хотите просто получить ВСЕ ваши сущности и выполнить вычисления расстояния в памяти с помощью python; то это, безусловно, возможно, но вы будете ограничены тем, что делаете это на относительно небольшом наборе сущностей или делаете это партиями, используя Задачи.
Взгляните на GeoModel, который предназначен для этого очень практичного случая.