Mapkit. Получение близлежащих мест с сервера и, возможно, их кеширование (например, для использования в автономном режиме)

@Stanislaw - Мы реализовали описанные вами функции в приложении под названием PreventConnect для одного из наших клиентов. У клиента уже были некоторые данные, хранящиеся в таблице Google Fusion. Мы расширили существующее решение, добавив еще одну таблицу Google Fusion, в которой хранятся геокоординаты для ряда местоположений. Все это сказано, чтобы ответить на ваши вопросы ...

1) Сама часть карты довольно нестандартная, плитки и тому подобное, но вам нужно будет немного кодировать, чтобы получить степень масштабирования, падение булавки, аннотации и тому подобное, работающие так, как вы ожидаете, что они будут работать .

2) Мы нашли решение Google Fusion достаточно эффективным. Если вы не хотите использовать Google Fusion, есть другие поставщики облачных баз данных, такие как StackMob, database.com и многие другие. Google бесплатный, и у них есть SDK для iOS, который упрощает взаимодействие с Google Fusion.

3) Совершенно верно! Мы кэшируем большую часть данных в хранилище Core Data локально на устройстве. Это значительно улучшает производительность и скорость отклика.

Пора написать твердый ответ на этот мой вопрос (я мог написать его год назад, но почему-то я забыл об этом).

Имеется ли в MapKit функция тайлов (способ Google Maps) из коробки, и нужно ли мне дополнительно работать над ней, если нет?

Ответ положительный: в MapKit он есть. Ключевые слова здесь overlays (MKOverlay, MKOverlayView and others). См. еще один мой ответ.

Смотрите также:

Сессия WWDC 2010: настройка карт с наложениями,

Apple-WWDC10-TileMap.

Как лучше всего получать информацию о местах (положение маркеров и аннотации) с сервера?

Собственно с тех пор я мало что узнал о «лучших практиках» - к сожалению, мне о них никто не сказал :( - поэтому я опишу «свои практики».

Прежде всего, есть две стратегии заполнения карты MapKit местами:

Первая стратегия заключается в заполнении вашей карты местами по запросу: представьте, что вы хотите отобразить и увидеть все места поблизости (например, на расстоянии не более 1 км от текущего местоположения пользователя) - этот подход предполагает, что вы спрашивайте у вашего сервера только места для интересующей вас коробки. Это означает что-то вроде: «если я нахожусь в Берлине (а я ожидаю 200 мест в Берлине), зачем мне когда-либо искать места из России, Японии, .. . (10000+ мест) ».

Этот подход приводит к тому, что полагается на функциональность «плиток», которая задает адрес N1: карты Google и карты Apple обычно рисуются с использованием «плиток», поэтому для вашей части карты «Берлин» вы полагаетесь на соответствующие плитки «Берлин», которые рисуются с помощью MKMapView - вы используете их размеры, чтобы запрашивать у своего сервера только места в поле «Берлин» (см. мой связанный ответ и демонстрационное приложение там).

Изначально я использовал именно такой подход, и моя реализация работала отлично, но позже меня подтолкнули к использованию второго подхода (см. Ниже), поскольку возникла проблема кластеризации.

Вторая стратегия - получить все места сразу (да, все эти 10000+ или больше) и использовать Core Data для получения мест, необходимых для видимых частей карты, которые вам интересны.

Второй подход означает, что во время первого запуска вы отправляете своему серверу запрос на выборку всех мест (у меня в приложении около 2000). Важно здесь то, что вы ограничиваете поля, которые вы выбираете, только географическими, которые вам действительно нужны для вашей карты: id, latitude, longitude.

Эта выборка "fetch-all" оказывает значительное влияние на время первого запуска моего приложения (на "самом старом" iPhone 4 у меня есть около 700 мс на весь Fetch + Parse-JSON-into-Core-Data процесс, и обширные тесты показывают мне, что это Core Data и его вставки - узкое место), но тогда у вас будет вся необходимая геоинформация о ваших местах на вашем устройстве.

Обратите внимание, что какую бы стратегию вы ни использовали, вы должны эффективно получать эти географические точки:

Представьте себе объект Core Data Place, который имеет следующую структуру полей (код preudo-Objective-C):

// Unique identificator
NSNumber *id,

// Geo info
NSNumber *latitude,
NSNumber *longitude,

// The rest "heavy" info  
NSString *name,
NSString *shortDescription,
NSString *detailedDescription, etc

Эффективная выборка мест означает, что вы запрашиваете только ваше место, записывающее геоданные с вашего сервера, чтобы сделать процесс этого зеркального отображения как можно быстрее.

См. Также эту горячую тему: Улучшить процесс зеркального отображения базы данных сервера в базу данных клиента через JSON?.

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

Соответствующие ссылки по кластеризации:

Сессия WWDC 2011: географическая визуализация информации с помощью MapKit,

Как эффективно отображать большие объемы данных на iOS Карты,

kingpin - решение для кластеризации с открытым исходным кодом: производительное и простое в использовании.

Можно ли кэшировать эту информацию, чтобы пользователь мог видеть близлежащие места «своего города» в автономном режиме?

Да, обе стратегии делают это: первая кэширует места, которые вы видите на своей карте - если вы наблюдали часть карты Берлина, у вас будет кешированная часть Берлина ...

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