Map Viewer BTS pin colors

[E3V3A]

The BTS pin colors as shown in the Map Viewer where previously loosely defined as:

BLUE = The one currently connected BTS, GREEN = other nearby previously seen BTS's where: _Samples: >1_ RED = new or previously unknown (to OCID) BTSs or where: _Samples: 0_, or "-1".

However, this is neither logical nor according to our detection status. So we have to re-think what make more sense. In addition there may be other ways to display additional BTS information, for example, by using different size, shape or "letters" inside the pins. Perhaps the colors should be:

---

• BLUE (dot) = Your current location as determined by your GPS
• BLUE (transparent) = The radial accuracy of your GPS location
• GREEN|RED (connection) = Your currently connected BTS whose location is determined by the _DBe_import_ GPS position and the detection status. This should always be RED if not GREEN status.
• GREEN (small) = A BTS that is known to DBe_import where:
  • _rej_cause=0_ and
  • A5/x >= A5/3 and
  • Samples: >3 and
  • _isGPSexact=1_
• ORANGE (small) = A BTS that is known to DBe_import where:
  • _rej_cause=0_ and
  • A5/x >= A5/3 and
  • Samples: <4 or
  • _isGPSexact=0_
• RED (small) = A BTS that is known (or unknown) to DBe_import where:
  • _rej_cause>0_ or
  • Samples: [0,-1] or
  • A5/x < A5/3
  • or A BTS that is new or unknown to DBe_import.

---

One good source of inspiration can be found by the visually pleasing Antenna App:

Where he presents the various BTS as clearly labelled dots. (See image above.)

A red circle indicates the cell site that your mobile phone is currently using.

Yellow circles indicate other cell sites in your vicinity, that your mobile receiver is also connected to. Note that only the sites for your current network provider are visible to the application. This feature is not available on CDMA and UMTS

Smaller yellow circles indicate other cell sites in your vicinity that your mobile receiver was able to connect earlier in this session, but are now out of reach.

A blue circle indicates user location as reported by the GPS (G), the Google Network Location service (N) or as best guessed based on nearby antenna locations (A).

If you have a valid GPS location, a separate darker blue circle marked (N) indicates the "Network Location" determined by looking at nearby mobile and WiFi antennas. If you are using CDMA and WiFi is turned off, this should coincide with your active antenna location.

The numbers in the circles indicate signal strength. To calculate dBm from the number shown, use the formula dBm = -113 + 2 * strength. Values below -112 dBm are shown as 0, values over -52 dBm are shown as 31. If signal strength is unknown, a "?" is shown.

On some CDMA networks, signal strength indicators are not available. Instead the letter "A" (for Antenna) is shown.

---

References: #13, #168, #206, #228

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[SecUpwN]

Thanks for filing this, @E3V3A. I just contacted the author of Antenna and hope he'll chime in.

[E3V3A]

Already did, and he responded here so I posted his relevant Gmaps code here. But we use OSM, so...

[E3V3A]

Updated OP to reflect new pin coloring scheme. DEV's: Please discuss in locked HC room.

[E3V3A]

I'm trying to put some new map pin icons. However, I just noticed and understood that since we're using an overlay (AFAIK), the icons doesn't scale down with the map when you zoom out. Thus they remain relatively huge, when zooming out. This make them look ugly and get bloated out with each other. We need to use non-overlay icons if possible. I suppose that means drawing (mostly circles) directly on the map. I have no idea if this will effect the performance.

[SecUpwN]

@evilsocket, I know you're already working on a different Issue, but could you have a quick look at this one, please? It sounds somewhat easy to fix, but it obviously isn't. Thank you for digging into it a little.

[evilsocket]

will do asap

[SecUpwN]

@E3V3A, have you just fixed this by yourself with https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/commit/463fec0c9f1dadd86ab04209ec146ab28a75e17b? Also, did you notice that you did not respect the sizes for the map pins in their respective folders (for example: old pin is 32px and new 44px while both are in drawable-mdpi)? Not sure that this is right since the sizes are predefined values per folder.

[E3V3A]

@SecUpwN Feel free to fix, but it looks a lot better on my phone, and I have no idea what it is using in terms of the x^ndpi blah blah. I tried with different sizes, and they where just too big and ugly...so until someone can come along and do this properly...it's hopefully better than nothing. I posted for some help at the Open Street Map Forums here. And some hints here. In addition, I'd like to see a rudimentary ruler on the map.

Perhaps @ziem can help us, if we ask him very nicely?

[E3V3A]

Alternatively we could consider to use marker clustering of the BTSs unless we can keep the markers very small. I actually prefer not to have this, for simplicity...

[SecUpwN]

Feel free to fix, but it looks a lot better on my phone, and I have no idea what it is using in terms of the x^ndpi blah blah.

I actually don't get if this is really done properly, but thanks for adding this quick fix though. @evilsocket could you please have a look at https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/commit/463fec0c9f1dadd86ab04209ec146ab28a75e17b and see if we can let the new BTS pins like that? Ok can they be made generic? Having different sizes in the different drawable folders might get in our way one day.

[E3V3A]

Since about a 2-3 weeks back, the BTS points closest to "me" are not shown. I'm not sure what it causing this, but it could be a an OCID problem. Perhaps they've scrapped BTS that has been previously uploaded in my area. Only a proper working map function can fix and check this.

[E3V3A]

Thanks to Toby's mention here:

The dev site states:

Create Different Bitmaps

You should always provide bitmap resources that are properly scaled to each of the generalized density buckets: low, medium, high and extra-high density. This helps you achieve good graphical quality and performance on all screen densities.

To generate these images, you should start with your raw resource in vector format and generate the images for each density using the following size scale:

xhdpi: 2.0 hdpi: 1.5 mdpi: 1.0 (baseline) ldpi: 0.75

This means that if you generate a 200x200 image for xhdpi devices, you should generate the same resource in 150x150 for hdpi, 100x100 for mdpi, and 75x75 for ldpi devices.

So this will help make the correct sized pins.

@tobykurien The pin colors has not changed, just the shape and size. The issue is that currently no other pin colors (apart blue, and green) are shown, where in reality they should be mostly orange and red.

"DBe_import" is the new (future) name for the currently named "opencellid" table. (See comparison in #215.) The selection criteria in OP require that we add two new columns to this table: rej_cause and isGPSexact.

I don't know exactly what data from OCID is actually downloaded versus what's used to populate that table. But the isGPSexact (BOOLEAN) column corresponds to the OCID "changeable". The rej-cause column is set to 0 by default, but should be obtained from #253.

[E3V3A]

DEV NOTE:

The default droplet pins have their pointed tips (near the bottom of the icon image) on the exact location on the map. So if we are using filled colored circles, their centers will be off, unless we make this adjustment to use the center of the icon image.

This is specified for ItemizedOverlay and in MapView in the OSM source code.

But only BOTTOM_CENTER and CENTER are available for GoogleMaps API v1, OSM compatibility. There is a wrapper for others... See OverlayItem:

public enum HotspotPlace {
NONE, CENTER, BOTTOM_CENTER, TOP_CENTER, RIGHT_CENTER, LEFT_CENTER, UPPER_RIGHT_CORNER, LOWER_RIGHT_CORNER, UPPER_LEFT_CORNER, LOWER_LEFT_CORNER
}

[tobykurien]

Since we don't have those columns in the database, this issue can't be implemented. In addition, you mention A5/x >= A5/3 - no idea how to implement that!

[E3V3A]

@tobykurien Yes, I know, it is very frustrating... :scream: But they should be added. :cold_sweat: I left A5/x out since we currently don't have that detection implemented yet. But the other 3 we can do. : )

[ziem]

Hello everyone! Today I pushed basic clustering implementation which includes scale bar and compass. I also set min zoom level to 3. I used ic_map_pin_orange drawable for cluster icon. Here you can find video showing this features: https://www.dropbox.com/s/ah72msil9vkw4fr/device-2015-01-09-211533.mp4?dl=0 . It would be nice if someone can check the code and send comments.

[Ueland]

Wow, nice video! :) i have taken a quick look on the code and it looks great! Looks like it should be fine for you to create a Pull Request to get the code merged.

[ziem]

Thanks. Done.

[E3V3A]

Awesome work by @ziem. Thank you very much!

But we still need some more tweaking. Currently not all pins are shown (#280) and those pins which are shown, look like this:

[E3V3A]

I'd like to see the single BTS (green) dots smaller with ~30% diameter of the orange clustered/numbered ones. While the orange ones with a size not much bigger than the font used to number it.

[SecUpwN]

@E3V3A, we have had many changes on the map markers and also another reduction of the diameters of the map markers with https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/commit/b2034c2ddff90d43e40746a1917a39beb916c4fa. Is this Issue fixed now? I am currently re-verifying our Issues list.

[E3V3A]

NO this is not gonna get fixed until all statements have been resolved in OP. And since we don't have A5 info, nor new DB changes, I suppose this will take a while.

[SecUpwN]

NO this is not gonna get fixed until all statements have been resolved in OP.

@He3556, I don't see why this Issue has been closed either. This needs to be re-checked.