Difference between revisions of "Public:Future OpenCellID database content cellid"

From OpenCellID wiki
Jump to: navigation, search
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Public:Future_OpenCellID_database_content_cellid Future cell-id data structure]]
 
[[Public:Future_OpenCellID_database_content_wifi Future WiFi data structure]]
 
[[Public:Future_OpenCellID_database_content_gps Future GPS position data structure]]
 
  
 
{|width=998
 
{|width=998
|This page is intended for compiling all ideas on how to improve the information stored for each measurement / cell in the main OpenCellID database.
+
|This page is intended for compiling all ideas on how to improve the information stored for each cellid measurement.
  
 
Please use the "Discussion" page for discussing the various ideas and concerns on this subject.
 
Please use the "Discussion" page for discussing the various ideas and concerns on this subject.
 
The plan is to keep this discussion going for a few weeks and decide what to implement when it becomes obvious that no additional new information is contributed regarding this topic.<br>
 
In cases where there are different opinions regarding a feature, a vote similar to the votes in OpenStreetMap, which is a proven mechanism, will be initiated.
 
 
Due to the current work load of the developer, it is unlikely to start with the implementation of the enhanced database scheme before summer 2014; therefore, there is enough time in that perspective to discuss the OpenCellID database evolution briefly.
 
  
 
The following table contains the list of potential additional fields of the database according to the current status of the discussion.<br>
 
The following table contains the list of potential additional fields of the database according to the current status of the discussion.<br>
Line 44: Line 36:
 
| title="Affected components" | measurements_.csv&nbsp;/ cell_towers.csv
 
| title="Affected components" | measurements_.csv&nbsp;/ cell_towers.csv
 
| title="Technology" | UMTS
 
| title="Technology" | UMTS
| title="Comment" |  
+
| title="Comment" | One RNC can handle multiple LACs. RNC ID does not necessarily have a connection to LAC ID - it depends how the network is planned. For example you can find in the same RNC (12) LACs 33, 21 and 78 - no connection between them. No relative connection of RNC IDs and LAC. This is based on how to plan the network. LAC depends on paging. RNC ID is same as Site IDs. It only serves as identification.
 
|-
 
|-
 
| title="Field name" | RGPS
 
| title="Field name" | RGPS
Line 84: Line 76:
 
| title="Field name" | manufacturer
 
| title="Field name" | manufacturer
 
| title="Data type" | string
 
| title="Data type" | string
| title="Description" | the manufacturer from the mobile phone (LGE, Samsung, Apple)  
+
| title="Description" | the manufacturer of the mobile phone (LGE, Samsung, Apple)  
 
| title="Filter criteria" |  
 
| title="Filter criteria" |  
 
| title="Formula (if computed)" |  
 
| title="Formula (if computed)" |  
 
| title="Affected components" | measurements_.csv
 
| title="Affected components" | measurements_.csv
 
| title="Technology" | all
 
| title="Technology" | all
| title="Comment" |
+
| title="Comment" | allows to estimate market share per manufacturer
 
|-
 
|-
 
| title="Field name" | model
 
| title="Field name" | model
 
| title="Data type" | string
 
| title="Data type" | string
| title="Description" | the model from the mobile phone (Nexus 4)  
+
| title="Description" | the model of the mobile phone (Nexus 4)  
 
| title="Filter criteria" |  
 
| title="Filter criteria" |  
 
| title="Formula (if computed)" |  
 
| title="Formula (if computed)" |  
 
| title="Affected components" | measurements_.csv
 
| title="Affected components" | measurements_.csv
 
| title="Technology" | all
 
| title="Technology" | all
| title="Comment" |
+
| title="Comment" | allows to correct erratic data of certain models like signal strength offset per model
 
|-
 
|-
 
| title="Field name" | version
 
| title="Field name" | version
Line 160: Line 152:
 
| title="Formula (if computed)" |  
 
| title="Formula (if computed)" |  
 
| title="Affected components" | cell_towers.csv
 
| title="Affected components" | cell_towers.csv
| title="Technology" | all
 
| title="Comment" |
 
|-
 
| title="Field name" | altitude
 
| title="Data type" | string
 
| title="Description" | GPS altitude
 
| title="Filter criteria" |
 
| title="Formula (if computed)" |
 
| title="Affected components" | measurements_.csv
 
 
| title="Technology" | all
 
| title="Technology" | all
 
| title="Comment" |
 
| title="Comment" |
Line 180: Line 163:
 
| title="Technology" | all
 
| title="Technology" | all
 
| title="Comment" | how to enter this data?
 
| title="Comment" | how to enter this data?
 +
|-
 +
| title="Field name" | GPS height
 +
| title="Data type" | long integer
 +
| title="Description" | height above sea level reported by GPS
 +
| title="Filter criteria" |
 +
| title="Formula (if computed)" |
 +
| title="Affected components" | measurements_.csv
 +
| title="Technology" | all
 +
| title="Comment" | WGS84 format
 +
|-
 +
| title="Field name" | timestamp of measurement creation
 +
| title="Data type" | timestamp
 +
| title="Description" | timestamp of the moment when the measurement was created
 +
| title="Filter criteria" |
 +
| title="Formula (if computed)" |
 +
| title="Affected components" | measurements_.csv
 +
| title="Technology" | all
 +
| title="Comment" | allows to predict on which weekday how many people must be expected close to this tower at which time
 
|-
 
|-
 
| title="Field name" | technology
 
| title="Field name" | technology
Line 199: Line 200:
 
| title="Comment" |
 
| title="Comment" |
 
|-
 
|-
| title="Field name" | speed
+
| title="Field name" | RNC, POS-RAT, RFU are present in DB but hidden. What is it? Ticket 14221
| title="Data type" | string
+
| title="Data type" |  
| title="Description" | Speed of the phone / tracking device when recording the measurement
+
| title="Description" |  
 
| title="Filter criteria" |  
 
| title="Filter criteria" |  
 
| title="Formula (if computed)" |  
 
| title="Formula (if computed)" |  
| title="Affected components" | measurements_.csv
+
| title="Affected components" |  
 
| title="Technology" | all
 
| title="Technology" | all
| title="Comment" | the field already exists in the database but the measurement unit is not clear (m/s or km/h or mph)
+
| title="Comment" ||-
|-
+
| title="Field name" | gps_quality
+
| title="Data type" | string
+
| title="Description" | GPS quality of the phone / tracking device when recording the measurement
+
| title="Filter criteria" |
+
| title="Formula (if computed)" |
+
| title="Affected components" | measurements_.csv
+
| title="Technology" | all
+
| title="Comment" | there might be issues with the values provided by the different devices; maybe storing the device type is required
+
 
|}
 
|}
 +
 +
==Data filters==
 +
tbd

Latest revision as of 13:03, 3 May 2014

This page is intended for compiling all ideas on how to improve the information stored for each cellid measurement.

Please use the "Discussion" page for discussing the various ideas and concerns on this subject.

The following table contains the list of potential additional fields of the database according to the current status of the discussion.
Please update it each time you introduce a discussion about a new database field.

Field name Data type Description Filter criteria Formula (if computed) Affected components Technology Comment
LCID string concatenation of RNC and CID
https://stackoverflow.com/questions/7240038/utran-cell-identity-returned-by-getcid
measurements_.csv / cell_towers.csv UMTS
RNC string Radio Network Controller measurements_.csv / cell_towers.csv UMTS One RNC can handle multiple LACs. RNC ID does not necessarily have a connection to LAC ID - it depends how the network is planned. For example you can find in the same RNC (12) LACs 33, 21 and 78 - no connection between them. No relative connection of RNC IDs and LAC. This is based on how to plan the network. LAC depends on paging. RNC ID is same as Site IDs. It only serves as identification.
RGPS string Real GPS position (changeable=0) cell_towers.csv all Currently, EITHER the real GPS position OR the computed GPS position is provided in cell_towers.csv depending on if the fix GPS position is available or not. The intention of this field is to provide the calculated GPS position as well as the fix GPS position in case the fix GPS position exists.
SGPS string GPS position of measurement with best signal The closer the signal is to ASU=31 or -51 dBm the better it is cell_towers.csv all
CGPS string GPS position computed from all measurements of all cells being a sector of the same base station Average of all GPS positons of all measurements of all cells being a sector of the same base station cell_towers.csv all
cell_range  ??? cell_towers.csv all
manufacturer string the manufacturer of the mobile phone (LGE, Samsung, Apple) measurements_.csv all allows to estimate market share per manufacturer
model string the model of the mobile phone (Nexus 4) measurements_.csv all allows to correct erratic data of certain models like signal strength offset per model
version string the version (firmware) from the mobile phone (4.1.2 for Android 4.1.2) measurements_.csv all
asu signalstrength as value asu  ??? measurements_.csv all At the moment there is value signal a mix between asu and value in dBm
zip_code cell_towers.csv all
city string cell_towers.csv all
street_name string cell_towers.csv all
housenumber string cell_towers.csv all
other_address_information string cell_towers.csv all
tower_height integer height of the tower/building above ground cell_towers.csv all how to enter this data?
GPS height long integer height above sea level reported by GPS measurements_.csv all WGS84 format
timestamp of measurement creation timestamp timestamp of the moment when the measurement was created measurements_.csv all allows to predict on which weekday how many people must be expected close to this tower at which time
technology string GSM/UMTS/LTE ??? measurements_.csv / cell_towers.csv all
bcch string Der Broadcast Control Channel ist ein Downlink-Kanal in GSM, der dem Endgerät Informationen über die aussendende Zelle liefert. Dies sind z. B. die PLMN-Kennung des Netzes, Cell-ID, Location Area, Kanalstruktur, Zugriffsbeschränkungen, Verfügbarkeit von Datendiensten und Frequenzen der Nachbarzellen. measurements_.csv / cell_towers.csv all
RNC, POS-RAT, RFU are present in DB but hidden. What is it? Ticket 14221 all title="Comment" -

Data filters

tbd