Карта для Android

[rajid]

Приветствую всех! Не подскажете какое программное обеспечение можно и нужно использовать для создание приложения для Android? В магистерской работе надо создать карту и реализовать ее на Android платформе. В Qgis есть конвертировать карту в формат для Android ?

[gimran]

QGIS + модуль Qtiles + Ваша карта.
Генерируете тайловый кеш (папка или zip архив).
Скачиваете Nextgis Mobile для андроида и кеш кладете на карту памяти в определенную папку.
ссылки по теме:
http://gis-lab.info/qa/qtiles.html
http://nextgis.ru/nextgis-mobile/

[paleogis]

Можно воспользоваться Androzic

[gimran]

Топик-стартер хотел создать карту, не указано, что у него что-то есть. Androzic требует наличия карты, а предложенное мною — можно данные ОЗИ всять + любые свои и соединить.

[Дмитрий Барышников]

Для создания своего приложения необходимо выбрать картографическую библиотеку - выбор библиотеки будет диктовать формат данных. Обратное тоже справедливо.
Из распространенных:
1) Google Maps Android API (https://developers.google.com/maps/docu ... n/android/)
2) Mapforge (https://code.google.com/p/mapsforge/)
3) OSMDroid (https://code.google.com/p/osmdroid/)

[ericsson]

Можно создать веб-приложение, а не нативное, оно будет работать не только на Андроиде, но и много где еще, но в browser-е.
Понадобиться leaflet.js, немного знания javascript/html и любой софт, который умеет резать карту на тайлы в TMS. Вектор можно отображать из формата KML.

[Дмитрий Барышников]

Странно, что ни Гугл, ни Яндекс, Apple, Microsoft не сделали веб картографических приложений для мобильных - у всех нативные. Интересно - почему?
Я думаю, что веб хорошо кушает батарею и не работает без коннекта.

[ericsson]

Э... веб-приложения прекрасно работают с локальными данными, не кушая при этом батарею дополнительно ни через wifi, ни через 3G и прочее. Минусы есть, но они не в этом.
http://geospatialscott.blogspot.com/201 ... fline.html навскидку, рабочий пример.
Кивать на грандов индустрии - это крутой аргумент, но неплохо бы делать это несколько менее голословно (и уж точно без грубых ошибочных предположений о том, что не работает в оффлайне).
У них-то еще куча требований к приложениям была, а не только "карту показывать".

[Дмитрий Барышников]

2ericsson вы запутались с веб и не веб.
1. Утверждение не голословное. Я же русским языком написал: "Я думаю"
2. Предложенная вами ссылка не веб - да это веб образный интерфейс. Но тайлы режуться и кладутся на устройство (The main idea is to download the .mbtiles to the device). А то, что автор в качестве контейнера использует браузер, так в барузере и картинки (фотографии) можно смотреть. Это не делает его ни программой типа "галерея" ни веб сервисом типа Instagram. Так что все, что вы предложили ничем от нативного не отличается.
3. Да, есть технология Гугла для работы веб приложений (повторяю ВЕБ) в режиме онлайн. Это сделано например в документах Гугл. Если Гугл меняет что-то в коде документов, то эти изменения получают все пользователи. Да, и тем не менее, под Android (ВНЕЗАПНО) у Гугла нативное приложение для документов.

[ericsson]

Веб-приложение - не обязательно то, что лазает через IP по http на сервер.
Это, прежде всего, приложение, которое использует browser или его движок, запускаемый в каком-то wrapper-е, как среду для запуска клиентской части. Вот от непонимания вами этого и происходит половина спора в этой теме.

Страница с кодом на js, способная самостоятельно что-то показывать пользователю (например, сортировать и делать выборку в альбоме фотографий, который хранится локально) - уже веб-приложение, хотя и примитивное. Вы же называете веб-приложением нечто с клиент-серверной архитектурой, что тоже вполне может быть веб-приложением, однако это уже нечто большее.
То, что я предложил, отличается от нативного кода тем, что запустить это можно будет на любом устройстве, от телефона до десктопа. У меня есть аналогичное приложение для своих нужд, так что, по-вашему выходит, что если у меня там в конфиге URL начинаются с file:/ или там фигурирует localhost - то это не web-приложение, а если http:/ - то веб? А если я локальный http-сервер подниму? А если между клиентом и сервисом локальный кэширующий proxy? Все это архитектурное многообразие не важно. Важна технология, как я уже сказал выше.

Повторюсь - мне все равно, почему в Гугле решили сделать нативное приложение - может быть потому, что не хотели расхлебывать проблемы, которые связаны с падучестью и кривизной работы с CSS некоторых browser-ов (а при показе документов это важно). Но коль скоро речь таки зашла о том, как html+js жрет батарею - ну так вот я могу точно сказать, что жрет не больше, чем это делает browser.