Re: Three different databases for gsm celltower locations
Hi, Thomas Landspurg wrote: The good news is that we are communicating and discussing while progressing slowly. With Sebastian of CellHunter, we basically agree that Cell Hunter would upload is cells to OpenCellID while maintaining their own database for the purpose of the game. With Onen one of the idea (in my view, but Onen to confirm ) is that to enable a the GPS Logger to be connected to OpenCellID to upload cell informations directly. For sure this is a possibility, either direct upload to OpenCellID, or as CellHunter plans to do, regular upload of new data (but for the moment I may like less the second, because it would mean we would still have many databases ;-), I still hope to see some merging). Now, the main part remains the positionning of OpenBMap. The main difference (in my view) between OpenBMap and OpenCellID is that OpenBMap is more focused on getting accuracy for cells , while we (OpenCellID) are more concerned about having the biggest and complete coverage. This is absolutely correct. I have the exact same opinion. That is the reason behind keeping more details about measures. This allows to gather a lot of data, but with time, we can trash the low quality ones, because we have got high quality ones since. This brings three questions: 1. if you have big HPV-Dops, your position is not very precise. If you add to this that you have a high speed, then when you take your measure, the GPS position is very inaccurate. And the time you get notified that the GSM connection has changed, this adds to inaccuracy. My question is: do people think this argument makes sense? 2. Do OpenCellID or CellHunter think this could be possible to add these extra fields to their database, and measures? This would allow to use inaccurate data, until when we have better ones. Then we could filter the low quality measures. I think we are still all learning a lot, and this would imply that extra fields could be added in the future. So this is probably not only a one shot change. 3. The database should also keep track of the software (id and version) which has logged the data: this allows to ignore/remove data which has been submitted by a buggy software, even if the bug is discovered much later. That is also the idea behind keeping the GSM chip model + Firmware version + GPS chip, etc... It there was a way to export cells informations, I would be happy to import them to the main OpenCellID database, I can suggest to OpenBMap for instance to use OpenCellID interface for non existing cells in their database? The idea behind the license of the data is exactly to allow this. I think that once we have clarified the situation, we can automate this. Lastly some update of OpenCellID: we are now more than 210 000 cells ( http://www.opencellid.org/cell/stats ) and 19 000 000 of mesures which is already great, so having support of the FSO would definitively gives the final boost to the project. So thanks for the support for evrybody. Yes we have followed the growth of your database. That's very good! Do not forget CellHunter which has grew over 2 000 000 measures! Congratulations to both of you! Another point is the other signals than GSM. Our initial vision was to build a database of communicating objects, WiFi, Bluetooth, etc... Thomas do you intend to keep strictly GSM data in OpenCellID? Sebastian same question with CellHunter? May be good to add Jan to the thread, as he has started work on the databases? Onen ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Three different databases for gsm celltower locations
Hi, Sebastian Hammerl wrote: At this time I do note have the time to submit the data because I have to finish my master thesis until mid of may. But after that I promise to upload new cellhunter cells periodically. At this momemt there are about 4 cells with over 200 measures. At least germany is covered very well. Congratulations, that's very good! We are over 1 cells, without logging neighbours, so direct comparison is biased ;-) There is much work which is duplicated between OCI, CH and OBM: * KML, etc... map on the website * the website by itself * the promotion we do to get new users * the server code * the client code I will talk from my part the client code. I know you have little time right now for a collaborating project. But I think we have much better to do than duplicating this aspect. If you would agree on coding on the same soft, we would save a lot of time. I am thinking about internationalisation of the code, etc... From my side, I think the only thing I need to be sure, is would you accept code which reduce the amount of data, in preference of quality (no log in a call, no log when too high speed, etc...). The time saved could allow to start other platforms support (Thomas there is no Android client, right?). My motivation here is only the will to prevent duplicating effort. Let me know what's your opinion. A FSO approach for getting cell information should query opencellid. Perhaps Thomas should think about to transfer the db to a faster server I have some troubles sometimes to reach the site. Perhaps we should set up a mirror at the openmoko servers or something else. But these should be problems for the future. I disagree here. The database should definitely be located on the phone itself. Which does not diminish the interest of a Web API (for mashups of all sorts). Advantages: * privacy: you get your location without involving third party * efficient: no problem of server scalability, lag, etc... * no need of a data connection * update can be done from time to time while connected to WiFi/USB etc... Onen ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Three different databases for gsm celltower locations
Hi, Stefan Schmidt wrote: I can see some technical problems you may face here. Cellhunter needs some db fields for the group management and ranking. OpenBmap likes to have more fields for quality informations about GPS and GSM. Different layouts of the databases, etc. What should work easily is that the fields of the cellhunter db that are not relevant to the group management get synced to opencellid and openbmap. Then these both have to figure out a way how to sync with the different ideas of stored data for position quality. That one is of course harder. Best would still be to join forces and go for one central collection point. I don't see this happen tho. So please, step back and think about how you are able to sync for efforts at least. At first glance I see: * OCI supports the extra fields of OBM, we can store our data there. (I see a difficulty here, is that we may discover with time additional interesting information to collect, and maybe Thomas is not very keen on the idea of modifying too often his database...?) * CH and OBM merge. CH collects already extra fields for the game. So we would add the extra fields for OBM. * another approach I still have to find out ;-) I need some thinking about it to be innovative... Freesmartphone, which will hopefully a big consumer of this in the future, also would like to see a effort to collect the position of wifis and use them in combination with GSM for better accuracy outdoor and also in buildings where no GPS is possible at all. We could also imagine Bluetooth. This is the initial vision of openBmap (all the communicating objects). I'm working on the networking part of FSO to give the logging clients an easy interface for the wifis around you. That's cool :-) And please, before answering here. Step back and think about it. I don't want flames but constructive work here. :) As said before, I will keep trying to find other ways which would bring everybody to an agreement... Onen ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
[PATCH] Add Display interface to cornucopia
Hi all,
Attaching a couple of patches,
1.) Adding Display abstract interface to libfsoframework
2.) Adding kernel26_display plugin to fsodevice
--
Regards
Sudharshan S
Blog : http://www.sudharsh.wordpress.com
IRC : Sup3rkiddo @ Freenode, Gimpnet
From b8acb2a5492d1a43dc38641d07adab1ac5b769f0 Mon Sep 17 00:00:00 2001
From: Sudharshan 'Sup3rkiddo' S sudha...@gmail.com
Date: Sat, 4 Apr 2009 19:25:21 +0530
Subject: [PATCH] Add Display Interface to libfsoframework
Signed-off-by: Sudharshan 'Sup3rkiddo' S sudha...@gmail.com
---
libfsoframework/fsoframework/fsoframework-2.0.vapi | 13 +
libfsoframework/fsoframework/interfaces.vala | 16 +++-
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/libfsoframework/fsoframework/fsoframework-2.0.vapi b/libfsoframework/fsoframework/fsoframework-2.0.vapi
index b9a20d5..01b8ced 100644
--- a/libfsoframework/fsoframework/fsoframework-2.0.vapi
+++ b/libfsoframework/fsoframework/fsoframework-2.0.vapi
@@ -5,6 +5,15 @@ namespace FsoFramework {
[CCode (cprefix = FsoFrameworkDevice, lower_case_cprefix = fso_framework_device_)]
namespace Device {
[CCode (cheader_filename = fsoframework/interfaces.h)]
+ [DBus (name = org.freesmartphone.Device.Display)]
+ public interface Display : GLib.Object {
+ public abstract bool GetBacklightPower ();
+ public abstract int GetBrightness ();
+ public abstract GLib.HashTablestring,GLib.Value? GetInfo ();
+ public abstract void SetBacklightPower (bool power);
+ public abstract void SetBrightness (int brightness);
+ }
+ [CCode (cheader_filename = fsoframework/interfaces.h)]
[DBus (name = org.freesmartphone.Device.LED)]
public interface LED : GLib.Object {
public abstract string GetName ();
@@ -13,6 +22,10 @@ namespace FsoFramework {
public abstract void SetNetworking (string iface, string mode) throws DBus.Error;
}
[CCode (cheader_filename = fsoframework/interfaces.h)]
+ public const string DisplayServiceFace;
+ [CCode (cheader_filename = fsoframework/interfaces.h)]
+ public const string DisplayServicePath;
+ [CCode (cheader_filename = fsoframework/interfaces.h)]
public const string LedServiceFace;
[CCode (cheader_filename = fsoframework/interfaces.h)]
public const string LedServicePath;
diff --git a/libfsoframework/fsoframework/interfaces.vala b/libfsoframework/fsoframework/interfaces.vala
index 5dd12ad..1214dd3 100644
--- a/libfsoframework/fsoframework/interfaces.vala
+++ b/libfsoframework/fsoframework/interfaces.vala
@@ -32,7 +32,11 @@ namespace FsoFramework
public const string LedServiceFace = ServiceFacePrefix + .LED;
public const string LedServicePath = ServicePathPrefix + /LED;
-
+
+ public const string DisplayServiceFace = ServiceFacePrefix + .Display;
+ public const string DisplayServicePath = ServicePathPrefix + /Display;
+
+
[DBus (name = org.freesmartphone.Device.LED)]
public abstract interface LED : GLib.Object
{
@@ -41,5 +45,15 @@ namespace FsoFramework
public abstract void SetBlinking( int delay_on, int delay_off ) throws DBus.Error;
public abstract void SetNetworking( string iface, string mode ) throws DBus.Error;
}
+
+ [DBus (name = org.freesmartphone.Device.Display)]
+ public abstract interface Display : GLib.Object
+ {
+ public abstract void SetBrightness(int brightness);
+ public abstract int GetBrightness();
+ public abstract bool GetBacklightPower();
+ public abstract void SetBacklightPower(bool power);
+ public abstract HashTablestring, Value? GetInfo();
+ }
}
}
--
1.6.0.6
From bfac604756e4e81c4f4d16b57f380d03a0ae1a8d Mon Sep 17 00:00:00 2001
From: Sudharshan 'Sup3rkiddo' S sudha...@gmail.com
Date: Sat, 4 Apr 2009 19:27:22 +0530
Subject: [PATCH] add kernel26_display plugin
Signed-off-by: Sudharshan 'Sup3rkiddo' S sudha...@gmail.com
---
fsodeviced/configure.ac|1 +
fsodeviced/src/plugins/Makefile.am |1 +
.../src/plugins/kernel26_display/Makefile.am | 45 ++
.../src/plugins/kernel26_display/display-helpers.c | 38 +
.../plugins/kernel26_display/display-helpers.vapi |4 +
.../src/plugins/kernel26_display/plugin.vala | 164
6 files changed, 253 insertions(+), 0 deletions(-)
create mode 100644 fsodeviced/src/plugins/kernel26_display/Makefile.am
create mode 100644 fsodeviced/src/plugins/kernel26_display/display-helpers.c
create mode 100644 fsodeviced/src/plugins/kernel26_display/display-helpers.vapi
create mode 100644 fsodeviced/src/plugins/kernel26_display/plugin.vala
diff --git a/fsodeviced/configure.ac b/fsodeviced/configure.ac
index 9308b70..538a359 100644
--- a/fsodeviced/configure.ac
+++ b/fsodeviced/configure.ac
@@ -53,6 +53,7 @@ AC_CONFIG_FILES([
src/bin/Makefile
src/plugins/Makefile
src/plugins/kernel26_leds/Makefile
+ src/plugins/kernel26_display/Makefile
tests/Makefile
])
diff --git
Re: [PATCH] Fix compiler errors, and a little cleanup in cornucopia
Applied (with style changes), thanks! :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
