Oznaczanie nadajników GSM

Communities Polska (Poland)
21

Mnie również nie chodziło o mapę zasięgu. To zdecydowanie zbyt skomplikowana i dynamiczna kwestia. Często jednak sprawdzam w przeróżnych bazach, czy w danym miejscu znajduje się nadajnik HSPA, czy jakikolwiek inny. I pomagało mi to o wiele bardziej, niż mapy zasięgu operatorów. Zwłaszcza wtedy, gdy naniesione były budynki i zalesienie. Ktoś również wspomniał o wieżach jako punktach nawigacyjnych. I tylko o to chodzi.

Oczywiście.

Można dogadać się co do importu bazy danych i dać możliwość wprowadzania nadajników, które w jej skład nie weszły - ręcznie. Moje pytanie dotyczyło otagowania i nie miało na celu rozpoczęcia technicznej wrzawy o tym co można a czego nie można. Słyszałem już o akcji dodawania ławek. Jeszcze nigdy nie zdarzyło mi się szukać ich z nawigacją, a tym bardziej drukować mapy po to, aby je odnaleźć. Inaczej było w przypadku BTS’ów z HSPA, czy chociaż zwykłym UMTS bez tego rozszerzenia. Coby się z EDGE nie męczyć… Mapa zasięgu jest przekłamana jak cholera, a znając pozycję nadajnika, szukam miejsca w którym będzie on widoczny i mam czego potrzebuję.

22

Ja uważam że temat jest ciekawy i że same wieże powinny być zmapowane i to z podstawowymi danymi technicznymi jakie pozwalają na określenie teoretycznego zasięgu telefonu - choćby w przybliżony sposób (czyli prosta funkcja - bez współczynników - wysokość*moc/odległość) to już sporo.
Nie rozumiem też powodu aby te dane były poufne :slight_smile: ciężko taki nadajnik ukryć, każdy jest doskonale widoczny z daleka :smiley: a dopuszczalna moc jest podana w informacjach publicznych w UKE. Pytanie na ile znajdzie się wśród nas grono osób które zechcą tą pracę wykonać i później konserwować. Jeśli uzyskamy zgodę z btsearch na importy to można wiele rzeczy zesynchronizować czy nawet zrobić procedury dynamicznej synchronizacji i sporo rzeczy zautomatyzować. Wiele nodów jest już pewnie w bazie OSM (kominy, pojedyncze wieże), te trzeba przypisać, znaleźć, połączyć. Wiele pewnie ma rozjechane współrzędne itd. i to jest kilka tysięcy baz - jest co robić :slight_smile: Na szczęście btsy mają unikatowe dane po których łatwo będzie to ‘pożenić’.

23

Jesli to ma byc robione to trzeba miec jako pierwsze proposal z sensownym opisem. Przede wszystkim:
po co to wszystko tak, by ludzie zrozumieli sens, po drugie: Jak rozpoznac w terenie (kilka zdjec).
No i ktos musi zmapowac jakis teren.
dobrze by bylo miec oczywiscie zaplanowana warstwe, na której to mozna zobaczyc…

24

Nie lubię proposal’i. OSM to żywy organizm, który przeżywa naturalną ewolucję. Proposal za bardzo z polityką mi się kojarzy. Ale to moje zdanie.

25

No, ale chyba chodzi o ustalenie jakiegoś sposobu tagowania? Jak to inaczej zrobić? Sposobem “ilościowym”? Załóżmy, że każdy z nas zacznie tagować nadajniki wg własnego widzimisie i wygra sposób tej osoby, która wprowadzi najwięcej danych?

26

Ja tez nie lubie proposali… pisac.
Sa jednak takie rzeczy jak np. hydranty.
Jeden fachowiec przysiadl, dal sensowna propozycje i reszta to robi.
Gdzie tu polityka?
Jak ktos chce proposal ulepszyc to dopisuje nowe rzeczy lub daje na tej samej stronie propozycje.
Ja np. nie chce sie wglebiac w mozliwe szczególy takiego opisu. Bede wdzieczny jesli ktos, kto cos o tym wie, da jakas spójna propozycje opisu.

27

W przypadku tagowania poszczególnych BTS (lokalizacje i zasięgi też się zmieniają - operatorzy non stop wprowadzają zmiany) dużym problemem będzie również to, że z jednego obiektu (czasem nawet toru radiowego) może korzystać kilku operatorów - wtedy np. zrobimy w OSM punkt oznaczający BTS i w tym jednym punkcie za pomocą tagów trzeba opisać 4 operatorów, 16 różnych sektorów radiowych, każdy z innym cell-id, itp. Nie wiem czy dobrą praktyką jest robienie tagów typu:

operator1:name=PlusGSM
operator1:MNC=01
operator1:sector1=5020
operator2:sector2_5021

operator2:name=Orange
operator2:MNC: cośtam

i tak dalej.

Myślę, ze propozycja skyraster jest najsensowniejsza - zamiast mozolnie ślęczeć nad obiektami GSM można użyć “chmury” użytkowników i robionych przez nich pomiarów. Raz, że takie dane są bardziej użyteczne - bo z powodu odbić od budynków całkiem niezły zasięg może być w miejscu w którym teoretycznie nie powinno go być.

Dwa, że w ramach ogólnego szablonu upchniemy ładnie w OSM i dane o smogu elektromagnetycznym i dane np. o sieciach wifi - co daje większą dokładność przy nawigacji poza-GPS-owej ;).

W przypadku pomiaru smogu ja bym dał dane o zakresie fal radiowych wg. przyjętej konwencji - np. HF, VHF, UHF + klasyfikacja pasm mikrofalowych (nie pamiętam). Nadajniki stacji radiowych czy telewizyjnych też mocno sieją - weźmy taki Raszyn czy Solec Kujawski. O Pałacu Kultury nie wspomnę :wink:

W przypadku pomiarów gsm-range trzeba również dodać pasmo (900, 1800, 2100 - chyba UMTS tu jest) a także parametr cell-id - bez którego te dane będą bezużyteczne - i kod MNC operatora - taki Plus zmieni nazwę na Vodafone i potem masz babo placek ;).

W przypadku wifi-range tak samo.

Moja propozycja wygląda tak:


measure=yes
measure:type=gsm-range
measure:band=GSM900
operator:name=.... (nazwa operatora)
operator:mnc=....(kod MNC operatora)
operator:cell_id=....(numer cell-id)
measure:unit="%"
value="80"
measure:datetime="yyyy-mm-dd hh:nn:ss"
measure:device="..." (nazwa/model smartfona)



measure=yes
measure:type=wifi
measure:band=2.4GHz
operator:name=.... (nazwa sieci wifi)
operator:bssid=....(adres MAC urządzenia wifi)

measure:unit="%"
value="80"
measure:datetime="yyyy-mm-dd hh:nn:ss"
measure:device="..." (nazwa/model smartfona)

raz jeszcze zaznaczam, że cell-id czy bssid są najważniejszymi bo unikalnymi identyfikatorami danego “obiektu” - takich sieci wifi o nazwie “linksys” są dziesiątki tysięcy ;).

Pojawia się tylko problem zagregowania wielu pomiarów w jednym punkcie - stojąc na skrzyżowaniu możemy łapać 10 różnych sektorów GSM i 20 sieci wifi - bez sensu byłoby robić dla każdego pomiaru osobny punkt.

//edit: zamiast measure:unit=% dałbym obowiązkowy parametr dBm - każde urządzenie to wspiera i przynajmniej jest to jakoś osadzone w prawach fizyki.

28

Opisz to na jakiejs stronce z przykladami. Jesli piszezs o pomiarach robionych przez uzytkowniow, musisz chyba tez opisac, jak taki pomiar dokonac.
Przydala by sie wersja tagowania minimum dla osób chodzacych jedynie z walkingpapers oraz dla mapowiczów bardziej zaangazowanych w temat.

29

A gdzie masz tę “chmurę”? Osobiście wolę zbierać POI niż mierzyć zasięgi :stuck_out_tongue:
Poza tym mieliśmy ustalić sposób tagowania nadajników, a nie miejsc dokonywania pomiarów…

30

Marek:
na razie poczekałbym aż inni się wypowiedzą w temacie ;). Zwłaszcza, że największym nierozwiązanym problemem jest agregowanie wielu pomiarów w jednym punkcie.

IMHO zbieranie takich pomiarów musi robić automat - np. oprogramowanie w telefonie. Raz, że jest do tego masa gotowych rozwiązań - dwa że tak jak pisałem “zasięg” czy siła sygnału są parametrami mocno zmiennymi w zależności od otoczenia. Można stanąć metr obok i mieć zupełnie inny odczyt bo np. fala inaczej się odbija od elewacji budynku. Oprogramowanie może to jakoś uśredniać np. w zadanych promieniach - a trudno oczekiwać od użytkownika z walkingpapers żeby zdejmował co 2 metry pomiar jednocześnie dla 10 BTS i go uśredniał ;).

Jak dla mnie w miarę sensownym rozwiązaniem jest dogadanie się z jakimś serwisem zbierającym dane o BTS i jakimś zbierającym dane o WiFi. Wtedy można użytkowników OSM zachęcać do jednoczesnego udziału w tych projektach - ze świadomością że te dane trafią do OSM. Nie ma co wyważać otwartych drzwi.

//edit:

Zbigniew: czy to tagując pomiary, czy POI - dla nadajników problemy do rozwiązania są te same - wielu operatorów i wiele sektorów radiowych na jednym obiekcie.

31

Sorki, ale pomysł z mapowaniem miejsc pomiaru do mnie nie trafia. I jest to IMO zbyt nienamacalne, by znalazło większy odzew w społeczności.

32

Hmm…11 letni projekt z dziesiątkami tysięcy użytkowników - ponad 1,5 miliona BTS i 70 milionów sieci wifi w bazie. Trudno to nazwać małym odzewem społeczności :wink:

http://wigle.net/images/rigled-images/europe.png

http://wigle.net/gps/gps/main/screenshots/

http://wigle.net/gps/gps/main/stats/

Oczywiście pomijam fakt jak to ma się do OSM i jego założeń. Inna sprawa jak takie dane wykorzystać do ustalania lokalizacji w urządzeniach mobilnych - to już inna bajka.

33

Mówiłem o społeczności OSM i jej odzewie.

34

dlatego twierdzę, że jedynym sensownym sposobem jest dogadanie się i importy :stuck_out_tongue:

35

Że niby te dane miałyby trafić do OSM? Może się nie znam, ale ja jestem przeciwny. Nadajniki, jako obiekty fizyczne tak, pomiary - nie.

36

Masowe importy moga byc zrodlem klopotów jesli dokladnosc polozenia nadajników bedzie znacznie odbiegac od dokladnosci danych OSM:
Bylo tak sweo czasu z bankomatami: Informacja generalnie bardzo pozyteczna, jednak roznice polozenia odbiegaly o kilkanascie do niekiedy kilkudziesieciu ( tak na oko) metrów.
Jesli koledzy z projektu który sie tym zajmuje sa na tyle dobryz by np. na jekims obszarze sprawdzic precyzje swoich danych w porównaniu z OSM tak, zebysmy mogli wykluczyc zamieszanie w naszych danych, to czemu nie. Praktyczie obawiam sie, ze bylby to raczej “import” kawalek po kawalku i w obszarach zabudowanych kontrola w porównaiu z bing.
Na obszarach niezabudowanych jest to oczywiscie mniej klopotliwe.

37

Można dogadać się w kwestii importu baz danych tych nadajników. Pomiarów również bym nie wprowadzał.

38

Jestem przeciwny pomiarom. Te dane łatwo mogą się zaktualizować i nie będzie osób do naprawy tego. Inna sprawa. Czy jest sens dublować dane? Myślę, że można to połączyć lecz niekoniecznie w jednej bazie danych.

39

Ja mam dane z pomiarów :slight_smile:
Co prawda niewiele tego mam raportowane, pewnie będzie ze 100 czy 200 pojazdów i to raport jedynie 0-5 - siła sygnału co 20% więc niewiele z tego raczej pożytku. I ogólnie też jestem przeciwny nanoszenia takich mało ‘widocznych’ danych. Ale za BTS-ami + ich technicznych parametrów - jestem za - w wielu projektach mogą się przydać. Np wspomniany już indor navigation.

40

Dlatego też napisałem w drugim poście, że do pomiarów najlepszy byłby osobny serwer do tego celu (czyli osobna baza danych), choć spokojnie może być oparta o analogiczny protokół wymiany danych jak w OSM. Obecna postać OSM - jako mapa typowo statyczna raczej słabo się nadaje do przechowywania takich (lotnych) danych, i które najprawdopodobniej trzeba by później dodatkowo weryfikować (czy ktoś nie dodał fikcyjnych pomiarów). Dane z pomiarów z reguły nie powinny być widoczne, ale wykorzystywane pośrednio do wykonania podkładu graficznego rodzaju warstwic. Ale faktycznie skoro maperów nie jest zbyt dużo, to tego typu projekty pozostają jeszcze pieśnią przyszłości.

Nie kwestionuję potrzeb mapowania nadajników BTS. To dobry pomysł, zważywszy na możliwość identyfikacji w terenie jako punktu nawigacyjnego. Choć mając na uwadze pomysły z mapowaniem kierunkowości anten/sektorów i użycia ich do symulacji zasięgu BTSu… lepszym pomysłem do tego jest wykorzystanie pomiarów, wyniki opracowane na ich podstawie mogą być dokładniejsze niż symulacja z położenia i parametrów BTS (bazująca na modelu z ograniczoną ilością parametrów). Trzeba pamiętać, że tracki GPS wgrywane do OSM również są pomiarami (choć zdecydowanie bardziej statycznymi niż odczyty siły sygnału), które nie są bezpośrednio wyświetlane na mapie docelowej (ale służą pośrednio przy mapowaniu).

Zakładam, że OSM wciąż się rozwijając, znajdzie się w sytuacji w której zajdzie potrzeba rozdzielenia danych na dane statyczne oraz dynamiczne (chociażby informacje o natężeniu ruchu “live-traffic” ). Po prostu trudno wyobrazić sobie, aby projekt, który jest już projektem globalnym nie posiadał w przyszłości opcji wspomagających dynamicznie wyświetlane warstwy.