Когда я разговариваю с клиентами, у меня всегда возникает поворотный момент, когда их запрос превращается из «Google Map» в «приложение для веб-картографирования». Обычно там, где данные фильтруются, обновляются или когда упоминаются «пользователи». Это ключевой момент, когда проект становится интереснее, сложнее и, вероятно, дороже для клиента. в этом посте я расскажу о том, как на самом деле выглядит приложение веб-картографии, и обрисую некоторые соображения по поводу приложений высокого уровня.
«Мне нужна карта Google, показывающая некоторые точки данных поля, это легко, правда?»
"Конечно"
«И я хочу, чтобы мои ребята могли их обновить, вы знаете, как из электронной таблицы?»
«О, хорошо…»
В этот момент «простая» карта Google превращается в картографическое приложение. Веб-карта - это обычно то, что вы могли бы назвать «сделкой с одним выстрелом», она содержит отдельный набор данных, который отображается в основном все сразу, за исключением некоторой чистой магической стороны. Приложение начинает появляться, когда на карту просят показать больше и разнести данные, возможно, квалифицированным пользователям. Кроме того, может быть возможность добавить данные в приложение или отредактировать его. Хотя данные по-прежнему являются одним из основных компонентов приложения, в общих чертах происходит «больше».
Каркасы
я использую Джанго где это возможно, но я не буду вступать в религиозную войну на благо Джанго против рельсы против CodeIgniter против <>. Дело в том, что если вы не хотите писать действительно большой объем дополнительного кода для поддержки пользователей, авторизации, форм, проверки, администрирования и т. Д. С использованием инфраструктуры имеет смысл. Помните, что значение вашего ключа, вероятно, означает, что вы можете создать карту, а не то, что вы можете написать потрясающую технологию проверки форм на стороне сервера. Использование надежных современных рамок несколько облегчит вашу боль. если ваше приложение становится ужасно популярным, вполне вероятно, что вы захотите поработать с фреймворком, чтобы добиться большей производительности, но, честно говоря; это не проблема, пока это не проблема.
Я использую Django отчасти потому, что GeoDjango запекается, но тем более, что питон подходит моему довольно упрощенному мозгу лучше, чем рельсы. Так что это очень личный выбор. По вашему выбору убедитесь, что за пространственными объектами хорошо следят, в идеале ваша инфраструктура будет подключена прямо к PostGIS или другому надежному решению для хранения пространственных данных.
История
Независимо от того, предназначено ли это приложение для сбора полевых данных пожарных гидрантов или для обмена историей движения белого медведя, есть история. Карта станет частью этой истории. Возможно, это важная часть, возможно, второстепенная роль персонажа, в любом случае карта является ключевым элементом визуального повествования и должна быть переплетена с остальной частью сайта таким образом, чтобы поддерживать мотив сайта. С точки зрения дизайна приложения всегда сначала рассматривайте историю и мотив этой истории. Как картограф, веб-дизайнер, веб-разработчик или даже бэкэнд-инженер, ваша цель - написать историю, понятную вашим пользователям.
Выбор карты
Чтобы добавить данные в ваше приложение, вполне вероятно, что у пользователя должна быть учетная запись. Вполне вероятно, что им придется войти в систему. Этот, казалось бы, общий акт поднимает проблему. Если только несколько человек могут войти в систему (то есть, если это корпоративное решение, или если пользователь платит за учетную запись) и если этому пользователю необходимо взаимодействовать с картой во время входа в систему способом, недоступным для не вошедшего в систему пользователя. Пользователь может (вероятно), что вы будете нарушать неявные лицензионные соглашения. Это означает, что вы, как разработчик, должны платить за корпоративную лицензию, иметь дело с несколькими API-решениями для сопоставления / базовыми картами или использовать решение для сопоставления с открытым исходным кодом с самого начала. Это сложный бизнес, потому что вполне вероятно, что ваш клиент запросил «Google Map», а не просто карту, поэтому у него есть определенные ожидания относительно картографии и интерактивности. Хорошее будущее администратора geoDjango заключается в том, что OpenLayers а также OpenStreetMap в админ по умолчанию, тем самым облегчая большую часть этой проблемы.
С точки зрения картографии базовой карты, мы теперь избалованы выбором, и хотя я бы сказал, что Google Maps имеет самый надежный и хорошо документированный набор вариантов функциональности, с точки зрения выбора чистой картографии сейчас очень необходимо обсудить.
Проверьте эти примеры со всего города Маммот Лейкс в Калифорнии:
Mapbox Terrain
Google Maps Terrain
Тычинка рельеф
Между каждым примером есть некоторые различия, но очевидно, что качество картографической онлайн-картографии значительно возросло, и потребитель стал крупнейшим победителем.
Сначала подумай о мобильном
Казалось бы, простое действие по добавлению концепции пользователей на веб-карту может разрушить всю привлекательность любой карты. Но ключевая идея, которую нужно помнить, заключается в том, что ценность здесь определяется картой как платформой визуализации. Имея это в виду, пользовательские функции должны быть удалены как можно дальше от пользовательского интерфейса. С акцентом на карту, если мы пойдем к исходному примеру, это всего лишь краткий умственный шаг, чтобы мыслить мобильно. Со всеми преимуществами, которые могут обеспечить геолокация и мобильный сбор данных, отсутствие у клиента или работодателя предложения о том, что какое-либо веб-картографическое приложение должно быть построено с учетом местоположения, которое внутренне рассматривается в рабочем процессе, почти безответственно.
Резюме
Я надеюсь, что эта статья помогла выделить некоторые из моих мыслей о разработке веб-картографического приложения в качестве расширения идеи простой веб-карты.
Ключевые моменты:
- Вы должны рассмотреть рамки веб-приложений ( Джанго , рельсы так далее)
- вы всегда должны помнить свою историю на протяжении всего пользовательского интерфейса
- у вас есть некоторые решения, связанные с отображением API (особенно с точки зрения защищенных частей корпоративного сайта)
- вы должны рассматривать любое приложение как мобильное
