Feature Request: Only show seen by me on map

[pejacoby]

I also have a run with a bunch of 0.0,0.0 coordinates, example below. One section of this file has 5 points in a row with zero coords, so my GPS must have dropped (though I recall you guys saying you cache the GPS location in case of brief drops).
I also noticed the time on all of these points is fubar.... 1969?

<Placemark>
<name>digitalally2</name>
<open>1</open>
<description>Network ID: 2A:A4:3C:4F:15:66
Encryption: WPA2
Time: 1969-12-31T18:00:00.000-08:00
Signal: -93.0
Accuracy: 3.0
</description>
<Point>
<coordinates>0.0,0.0</coordinates>
</Point>
</Placemark>

When you load one of these files into Google Earth it defaults the rotation to that shown in the attached image.

Attachments

Screen Shot 2017-02-12 at 5.05.44 PM.jpg (50.25 KiB) Viewed 39229 times

[arkasha]

I'll start fixing the GPS signal issues on the client - that's a real bummer. In the meantime, I've implemented and deployed a date filter that should discard invalid points; if you find any other 0,0 points after this fix, let me know. I *have* seen some low-accuracy, still-kinda-valid points in my own traces. I've left those in because those are real observations, even if skewed, and are useful in understanding what data is in the individual run. Knowing what noise gets discarded during the trilateration process seems like a legitimate use of these traces.

[pejacoby]

Looking good -- no more oceanic destinations on the files where I was seeing the 0,0 coords.

-kw, check you files for the date-stamp on the 0,0 coordinates, I'm curious if you see the 1969 dates too. I'm running a Galaxy Core Prime, which is a good performer but I am usually in and out of downtown buildings on at least a portion of each days tour, so chances of dropping signal (or not synching until I'm outside) are pretty high.

[-kw]

@pejacoby I rechecked the old kml export and can confirm that all gps points at 0/0 have the date 1970-01-01T01:00:00.000-08:00 (not 1969, guess it depends on the timezone - Germany here). The network I am talking about was captured by the WiGLE app. I did not check any network that was discovered by kismet in netxml. I could check it after my next run, but I think this is caused by signal loss as well.

@arkasha I did not find any "invalid" points at 0/0 after the fix. Thank you! Are the 0/0 observations included in the triangulation of the wigle map or are they not considered? And one more question: Could you explain the "alt" and the "accuracy" values to me, please?

[arkasha]

Accuracy is the meters-accuracy estimate from the device.
Alt is the altitude-above-sea-level estimate from the device.

(0,0) measurements, poor accuracy (high numbers), are excluded in our cluster-detection algorithm, although if you browse around our world maps, you can see spots where the clustering algorithm still isn't sophisticated enough to prevent "blurs."

[-kw]

Thank you

[arkasha]

Two items:

1. a deployment mistake was resulting in null timestamps getting converted to the UNIX epoch. I've set up the database driver to set these to null instead of sometimes failing, sometimes setting them to 1969 - however this means that items with really lousy GPS fixes (whatever accuracy in meters your device might assign to them) will get dropped from the KML export. Is this a net win or loss? Specifically, preserving these un-timestamped "bad points" will require a conscious work-around, we should figure out how we handle them. On my phone, these are accuracy 1046 meters, but even that doesn't look reliable (I'm seeing these "lines" extending more than 1k away from any possible point of measurement)

2. I've added color coding to indicate placemark accuracy. These correspond to a round scale based on my sample data - 5.x meters looks reliable, 12.5 meters is still quite useful, within 50 meters is lousy but still useful and beyond that, it's probably junk :

• Green for points with accuracy under 6 meters
• Yellow for points with accuracy under 12.51 meters
• Red for points with accuracy under 50.01 meters
• White for everything else.

Let me know what you think on both fronts!

[-kw]

Hi arkasha,

thanks for keeping work on this!

1. I think its ok to exclude such points with very weak accuracy from export. Would accept this without any contradiction

2. Looks nice! It is a good idea Meter-values are ok for me. Are these accuracies taken from the exported file or the database of WiGLE (average value)?

[arkasha]

the point location shown is the best accuracy value in that "run" available in the individual stumble file.

[pejacoby]

The export just keeps getting better and better!

1. Sounds like the right approach -- I had seen a few of those 1KM "arms" emanating out of my downtown runs, now I'm guessing they came from indoor points with bad GPS.

2. I'm happy to see most of my runs are bright green, nice accurate GPS coords

[hdmn]

Check out the link behind the Transaction ID on your "Uploads" page, see what you think?

THIS IS HUGE!! Thank you very much, arkasha!
-hdmn

[arkasha]

glad folks like it - keep the suggestions and improvements coming.

[-kw]

Since this feature is running for a couple of weeks fine now I have a suggestion:

Could you implement another export please? Just like the current kml export, but containing only the points which were new to the database by the upload?
That would be very nice! =)

[-kw]

I noticed that some kml exports fail. Can I PM someone the transaction ID for further action?

[arkasha]

sure, send them along. I've noticed those, but assumed they were files without viable locations.