Talk:Collaboration with other projects

Die Idee, die Daten von Gyokov Solutions zu importieren, ist echt super und genial!

Wass jedoch beim Verschmelzen der Daten von Gyokov Solutions und opencellid.de beachtet werden sollte:

Die Cellids von Gyokov Solution sind bei UMTS grundsätzlich im kurzen CID-Format (5-stellig), bei opencellid.de im LCID-Format (8-stellig)! Dadurch kommt es jetzt zu massenhaft doppelten Einträgen, wobei die Zelle bei UMTS von opencellid im langen Zellformat (RNC+Cellid) existiert und von Gyokov im kurzen Cellid-Format. Ich würde hier lieber einen einheitlichen Standard bevorzugen, um doppelte Einträge mit unterschiedlichen Zellformaten zu verhindern.

Vielleicht kann man die API, measurements.csv und cell_towers.csv mit folgenden Werten erweitern:

- RNC = RadioNetwork Controller (entspricht bei Gyokov dem Wert Node)

- Short+Long-Cellid-Format (5-stellig und 8-stellig)

Format Messungen: mcc,mnc,lac,lcellid,rnc,cellid,lon,lat,signal,measured_at,created_at,rating,speed,direction

Wird der RNC (Node) nicht verwendet (bei GSM) so sollte hier ein Standardwert z.B. -1 verwendet werden. Vielleicht könnte man auch noch zusätzlich die verwendete Technologie mit integrieren wie 2G, 3G und 4G, bzw. GSM, UMTS oder LTE

Format Zellen: mcc,mnc,lac,lcellid,rnc,cellid,lon,lat,samples,changeable,create_at,update_at,averageSignal

Wird der RNC (Node) nicht verwendet (bei GSM) so sollte hier ein Standardwert z.B. -1 verwendet werden. Vielleicht könnte man auch noch zusätzlich die verwendete Technologie mit integrieren wie 2G, 3G und 4G, bzw. GSM, UMTS oder LTE

Die Suche/Hochladen bei der API sollte dann nach dem kurzen und langen Zellformat möglich sein. Durch beide Formate gleichzeitig in den Messungen und cell_towers.csv wird sich die Datenbank z.B. bei den UMTS-Zellen nicht unnötig mit beiden Formaten aufblähen (Somit die Gesamtzahl der Zellen nicht der wirklich einmalig vorhandenen Cellids und täuscht langfristig ein falsches Ergebnis vor).

Wenn man die beide Zellformate (LCID, CID) und RNC sowie verwendete Technologie in den csv abbildet, so wäre dies echt genial. Vielleicht wird es irgendwann möglich sein auch die Daten von Mozilla Location Service zu importieren (wenn die Rohdaten irgendwann verfügbar sind) und diese sind im LCID-Format. Dadurch lassen sich jederzeit das kurze Cellid-Format und der RNC berechnen.

Die Daten von UMTS-Zellen sind bei opencellid im Long-Cellidformat, womit sich direkt RNC und Cellidformat (short) erzeugen lassen. Vielleicht kann der Programmierer von Gnet-Track das Long-Cellidformat noch in seine Logfiles einfügen, welche er in seiner App erzeugt.

Hierzu verweise ich auch auf http://wiki.opencellid.org/wiki/Talk:API

RNC: http://en.wikipedia.org/wiki/Radio_Network_Controller

Beispiel Logdatei der App GMON: LCID;CID;LAC;NET;PSC;RNC;RXL;QUAL;RSRP;RSRQ;ECIO;TYPE;LAT;LON;SPEED;ALT;DATE;TIME;N1CID;N1LAC;N1RXL;N2CID;N2LAC;N2RXL;N3CID;N3LAC;N3RXL;N4CID;N4LAC;N4RXL;N5CID;N5LAC;N5RXL;N6CID;N6LAC;N6RXL Hier ist die LCID, CID und der RNC enthalten.

Angaben Speed in km/h oder m/s?

Dieser Datensatz scheint von Gyokov zu sein, da eine UMTS-LAC und Short-Cellid. Hier ist zu erkennen, dass die Speed in km/h angegeben wird wie in den Logfiles von Gnet-Track. Die anderen Programme wie Tower Collector oder Keypad-Mapper scheinen aber die Geschwindigkeit schon seit ewigen Zeiten in m/s anzugeben.

Hier sollte ein einheitliches Format (am besten m/s) definiert werden! Das Format müsste dann von Gyokov von km/h nach m/s umgerechnet werden.

In der API fehlt hierzu noch jede Angabe und sollte noch ergänzt werden.

262,7,51906,44233,9.15776,49.01372,-89,1382597091000,1390505872000,3,75,0

262,7,51906,44233,9.15789,49.01355,-81,1382597091000,1390505872000,3,75,0

Sollte 75 gleich m/s entsprechen, dann wären ca. 270 km/h gefahren worden (Wert daher in km/h).