bktruss / qnetaddressbook

Automatically exported from code.google.com/p/qnetaddressbook
GNU General Public License v2.0
0 stars 0 forks source link

XML import #11

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Implement import from xml instead of csv one. 

Original issue reported on code.google.com by lorenx...@gmail.com on 25 Oct 2008 at 8:31

GoogleCodeExporter commented 9 years ago
It'd be better if you could also implement XML export - then you could easily 
share
your xml data with other people, not by just switching between your DB and your
friend's DB, for example. Though, it'll require you to solve some problems - 
it's
naturally that two people will never mark one WAN with the same coordinates. So,
there should be some mechanism that would ask wether to morege two WANs with 
the same
ESSID if they are located closely (which also means dealing with "close" as in 
real
life, not as "close" on 1:500000 map).

Original comment by Krapl...@gmail.com on 27 Oct 2008 at 3:19

GoogleCodeExporter commented 9 years ago
We will implement the xml export. 
The program distinguish two networks by bssid (which is unique), not essid. 
For now the program simply skip the import of a network if its bssid is already 
in the db.
How can we implement the import of a duplicate network with different 
coordinates? 
Maybe making the average of the coordinates?

Original comment by lorenx...@gmail.com on 1 Nov 2008 at 3:05

GoogleCodeExporter commented 9 years ago
XML import implemented using DOM.

Original comment by lorenx...@gmail.com on 1 Nov 2008 at 2:38

GoogleCodeExporter commented 9 years ago
Well it's not only approximation - one should admit that for more accurate 
results
the triangulation should be used - the same way it's done when calculating your
coordinates by the level of signal from 3 GSM antennas at some cell operators. 
But
it's more of a separate issue, then. And not many people would agree to get 
triple data.

Original comment by Krapl...@gmail.com on 1 Nov 2008 at 4:24

GoogleCodeExporter commented 9 years ago
Kismet automatically stores in the csv log some values (bestlat and bestlon) 
which are the coordinates where 
best signal was registered. Obviuslly it isn't the real location of the ap, but 
it is the point of those registered 
where you can find the best signal. 
To do this with the xml log, we have to parse the .gps one too. 
However, ther isn't a way of find the real location of an ap without a 
directional antenna, and making the 
triangulation. 
Isn't it?
So, what do you suggest?

Original comment by lorenx...@gmail.com on 1 Nov 2008 at 9:44

GoogleCodeExporter commented 9 years ago
Follow issue #13.

Original comment by lorenx...@gmail.com on 28 Nov 2008 at 10:07