Создание REST API для геопространственных запросов

#django #rest #geospatial #geodjango #django-piston

#django #rest #геопространственный #geodjango #django-поршень

Вопрос:

Я пытаюсь создать приложение для iOS, которое определяет местоположение пользователя, а затем запрашивает серверную часть для других пользователей рядом с ним / ней через REST api.Я немного погуглил, и мой выбор (учитывая мой опыт), похоже, таков.

  • Django — поршень с geodjango.Возможно, хостинг на webfaction.
  • Движок приложений Google.

Я больше склоняюсь к первому выбору, поскольку Google App Engine кажется не таким открытым и вначале имеет крутую кривую обучения.

Теперь выполнение запросов о местоположении в базе данных mysql кажется немного пугающим.Я нутром чувствую, что должно быть что-то получше.В конце концов, я не хочу изобретать велосипед!!

Кто-нибудь, пожалуйста, может пролить свет на

  • как именно я собираюсь выполнять запросы местоположения? .. ограничивающие изменения или что-то лучше?
  • какую базу данных мне следует использовать? … нереляционную или относительную?
  • Если реляционные … должны ли базы данных индексироваться по местоположению?
  • Должны ли данные о местоположении храниться в отдельной таблице или в той же таблице, что и другие пользовательские данные?
  • Должен ли я использовать временные метки для аннулирования старых обновлений местоположения или есть какой-либо лучший способ для этого?(например, база данных может сама периодически удалять обновления местоположения).

До сих пор я был в основном разработчиком iOS и имею минимальный опыт в создании веб-приложений.Любое предложение было бы высоко оценено.

Если подобный вопрос задавался ранее, не стесняйтесь указать на него.

Заранее спасибо. — samyzee!

Ответ №1:

Боюсь, вы задаете слишком много общих вопросов, чтобы получить полезный ответ. Я попытаюсь:

Если вы хотите выполнять очень простые геопространственные действия, попробуйте придерживаться работы с ограничивающими рамками. стоит изучить простейшую технологию, которая подходит для решения проблемы. Однако, вы, вероятно, скоро узнаете, что вам нужно больше…

Если вы хотите использовать geodjango, используйте базу данных PostGIS и забудьте о нереляционных. Вы будете разрабатывать серверную часть, и у нее крутая кривая обучения для программиста, не работающего в webapp. Начните с руководств по geodjango и постепенно разрабатывайте технологический стек, с которым вам удобно (сервисы REST будут достаточно простыми с geodjango).

Причина выбора нереляционной базы данных либо очень специфична для конкретного варианта использования (вы хотите хранить документы, график или вам не нужна предопределенная схема), либо требуется для целей масштабирования (одновременное чтение и запись большого количества данных и, следовательно, использование нескольких узлов и т.д.). Если вы не являетесь программистом веб-приложений, наймите человека с опытом (который может выполнять некоторую «архитектуру программного обеспечения»), чтобы помочь вам на этом пути.

  • Должны ли данные о местоположении храниться в отдельной таблице или в той же таблице, что и другие пользовательские данные?
  • Должен ли я использовать временные метки для аннулирования старых обновлений местоположения или есть какой-либо лучший способ для этого?(например, база данных может сама периодически удалять обновления местоположения).

Попросите кого-нибудь, кто занимался каким-либо дизайном базы данных, помочь вам. С описанием проблемы до сих пор вы могли бы работать с двумя таблицами: User(id, name) table и UserLocation(id, timestamp, user_id, xCoordinate, yCoordinate) table. Чем добавлять UserLocation строку для каждого образца, который вы получаете для пользователя. Позже вы можете разработать (и изменить) правила интерпретации таблицы userLocation, например:

  • Последнее местоположение пользователя является допустимым
  • Если временная метка старше 4 часов, она непригодна для использования
  • и т. д

Судя по вашему ответу на вопросы, кажется, что вы немного не в своей лиге. Однако, если вы сможете придерживаться простой технологии и работать прагматично, вы сможете заставить свой сервис работать. Почему бы не начать с mysql php и ограничивающих запросов? И поменять его на что-то другое, как только у вас заработает все остальное?