Абсолютно согласен.
Проект только начал работу, так что результата ждать пока рано. Скорее всего у них есть задержка между получением сырых данных от пользователей и обновлением базы, используемой для геолокации.
Update: вот что пишут про это представители Мозиллы: https://groups.google.com/d/msg/mozilla.dev.geolocation/Ud5xI9-AjM8/WRCnK625_fYJ
Я пока так и не понял вообще определяет ли он что-то 
Весь город почти изъездил, покрытие есть, но без результатов пока. Жду что скоро сделают. Сайт регулярно попадает от хабра-эффект, наверное в вычислительные мощности действительно страдают от притока народу))
Ну программного средства так и не нашёл - рисую по Bing+MapBox
C man_made=antenna принципиально не согласен - тк мы рисуем именно вышки, а одна вышка сотовой связи как правило содержит от 4х (направленных секторных) антенн
У них нет базы для скачивания - а мне бы скачать , отфитровать по региону и залить на устройство. Как бы 50Мб на регион это не страшно
OpenWLANMap@Android
Пробить положение соты сразу по нескольким сервисам можно на xinit.ru. Там yandex, google, opencellid, MLS. Разные серсисы для одной соты выдают разные координаты, причем, иногда они отличаются достаточно сильно.
В целом, opencellid - вполне подходящее место для хранения примерно вычесленных координат БС и измерений. Если вносить в OSM, то только точные координаты и достоверную инфу.
Я начал еще собирать собственную базу по региону. В качестве клиента - модифицированный mozstumbler - клиент, используемый в mozilla location service. Много моих изменений было принято в апстрим. Плюс своя вебка (если кто захочет поиграться, url) .
Из наблюдений: в umts координаты вышки достаточно хорошо можно определить по PSC - он обычно один у нескольких секторов БС. Этим почему-то этим не пользуется ни один из сервисов.
С устройствами на android все достаточно сложно. Некоторые не отдают neighbour’ов, некторые - PSC текущий соты. Timing advance доступен только в LTE. ECIO, RSRQ, CQI, и проч. через стандартные API недоступны вообще, только иногда есть в field test. Авторы G-NetTrack даже собирают базу по возможностям различных устройств.
Зачем распаляться? Если сейчас каждый начнет собирать собственные базы, со своими особенностями, в каждой из которых будет малюсенькая часть всех данных, то ничего хорошего из этого не выйдет - объединить их потом будет очень сложно, а собирать данные со всех сразу - еще сложнее. И так этих сервисов уже несметное количество.
Куда эффективнее всем наполнять какую-то одну базу. И, по-моему, идеальный сервис для этого - OpenCellId.org, т.к. только они позволяют не только использовать API, но и скачать полную базу, как с отдельными измерениями, так и с вычисленными координатами секторов.
Для создания карт покрытия, ИМХО, вполне достаточно данных из базы OpenCellID. А вот смысла наносить координаты конкретных базовых станций не вижу - уж слишком быстро меняется и разрастается их сеть.
Хотелось бы услышать комментарий по u-blox AT командам
AT+CGED(=6), AT+COPS=5, AT+UCELLINFO, AT+UCELLOCK, AT+UCD, AT+UTEST
Это не для общего пользования. Чтобы лучше понять, что там происходит, не зависеть от качества чужих данных и от CC-BY-SA. Плюс всегда можно экспортировать данные хоть во все существующие сервисы. В той же базе opencellids нет типа сети, точности координат, высоты, PSC. Практически никогда нет уровня сигнала, а когда есть - непонятно в каких он единицах. Короче, существующие сервисы меня не устроили вообще. Да и решаемая задача - не создать карту покрытия, а определить принадлежность наблюдаемой вышки оператору.
На уровне AT команд вся нужная инфа есть. Но на андроиде получить доступ к этому уровню очень сложно, даже на рутованном девайсе (не сломав при этом функции телефона). А внешние USB модемы стоят денег, неудобны и очень прожорливы. Иногда для их работы не хватает выдаваемой на USB силы тока.
Мои мысли относятся к этому ардуиносовместимому устройству
https://mbed.org/users/ublox/notebook/u-blox-C027-Getting-Started
у которого есть и GPS и глонасс и CAN и GSM и UMTS.
Нужно только краткое описание, какие именно GSM/UMTS/LTE
параметры имеет смысл протоколировать.
Если очень кратко:
GSM: MCC, MNC, LAC, CID
UMTS: MCC, MNC, LAC, SAC (дополнительно, но вовсе не обязательно, можно сохранять PSC)
LTE: MCC, MNC, TAC, ECI (дополнительно, но вовсе не обязательно, можно сохранять PCI)
Если более подробно, то здесь, уж не сочтите за рекламу.
Вот у меня вопрос. А есть ли более-менее доступный радиомодуль, который бы умел работать сразу в GSM, UMTS и LTE? Чтобы можно было автоматически фиксировать базовые станции всех стандартов.
Текст отличный, но ИМХО недостаточный, так как
(a) нет никакой информации о BSIC, ARFCN и TA для GSM, и UARFCN+PSC для UMTS;
а также CSQ и подобных
(b) непонятно, что конкретно будет “мапиться” и визуализироваться:
координаты текущего измерения (как в opencellid) + аттрибуты или же базовые станции + аттрибуты.
Я не знаю таких даже для UMTS+LTE.
Спасибо, текст доработаю.
Что ж, буду мучать ZTE MF 823. Пока что, это наиболее доступное средство для экспериментов.
Unfortunately I don´t speak Russian, sorry for that.
My name is Markus, I´m the maintainer of OpenCellID.
The question was raised in this thread what the difference is between opencellid.org and opencellids.org
Today there is no difference, the two databases have been merged into one.
Historically this were two competing projects, but then it was agreed early 2013 that I take care for both projects in the future.
OpenCellID collects the cell-id data outside OpenStreetMap because the collection process is different from OSM:
in OSM visible things are mapped; in OpenCellID invisible things are mapped.
wiki.opencellid.org is the wiki page for OpenCellID.
Send me an email if you like to contribute to that wiki.
I´ll then setup an account for you. This cumbersome process has been setup for avoiding spam on the wiki.
Currently there are discussions how to further improve OpenCellID:
- more data for GSM cell towers
- WiFi data
- iBeacon data
- bluetooth data
- magnetic field data
- fingerprints
- etc.
I appreciate your feedback in this regards as well as any other feedback regarding OpenCellID.
Keypad-Mapper 3 combines collecting housenumbers for OSM and cellid data for OpenCellID.
Hi Markus, the current opencellid API design may be appropriate for a $random clueless smartphone owner,
but it misses a lot of important and useful technical information that can be gathered
for the network cells.
- For GSM you do not collect Timing Advance (TA) which is a much more useful parameter
for pure positional purposes than signal quality - There is no API specification for signal quality physical units
- There is no way to provide UMTS and LTE information (PSC et al.)
- For the base stations you do not collect BSIC, antenna directions, ARFCN and other BS physical properties.
I can’t imagine why do you need UMTS and LTE information other than already collected by service. For positioning purposes it’s necessary and enough to have MCC, MNC and one of these:
for GSM: LAC, CID
for UMTS: LAC, SAC
for LTE: TAC, ECI
In the list above LAC corresponds to TAC, CID corresponds to SAC and ECI. Important is that collecting those parameters makes positioning in all generation networks fully compatible - you need 4 parameters with almost the same (in terms of service API) meaning. Thats why you don’t need TA but strongly need signal quality (one reason, another is - TA has gradations about half a kilometer, it is too much in the city). The same applies to different physical BS properties.
As for antenna directions, a phone can’t guess it, nobody can except provider engineers. How do you suggest to collect it?
And there is one more but fundamental problem. I believe that Android SDK don’t have capabilities to collect a lot of parameters you are asking for. Just look at existing Netmonitor software, most powerful can collect about half of parameters you are talking about.