how does importing/merging emitters exactly work?

[DJCrashdummy]

first of all i have to say thank you @Helium314 for this backend! a few relatives and i use it for more than a year now, and it simply just works. 👏

---

for some months now i thought about importing the latest available MLS database and merging it with my local database, as i read that it can be downloaded somewhere. ...but until now i hadn't the time do it.
but now i have a different situation (some relatives visit my city for the first time since using Local NLP Backend - and i thought about giving them a kick-start by importing my database into their phone), which results in similar tasks and raise the same questions: i'm not 100% sure how the 3 import options work and would appreciate if someone could confirm my assumptions resp. elaborate them a little bit more.

1. replace local emitters: as the local database could be purged as a whole by resetting the app, i guess only single emitters which are present in both databases will get discarded in the local database (and all other - from both databases - remain untouched).
2. keep local emitters unchanged: i guess the same but the other way around.
3. merge emitters: that's where i have no clue what happens... which criteria are used to decide which emitter should remain? is this done for every single emitter?

[Helium314]

first of all i have to say thank you @Helium314 for this backend! a few relatives and i use it for more than a year now, and it simply just works. 👏

Thanks, I'm surprised there are still users of this backend now that MicroG has removed support for external location backends.

These options only affect conflict handling. So if you import an emitter that already exists in local database:

• replace: overwrites the existing emitter in the databas with the emitter to import
• keep: discards / does not import the emitter
• merge: expands the area covered by the emitter, so that local and imported area are both contained

[DJCrashdummy]

I'm surprised there are still users of this backend now that MicroG has removed support for external location backends.

are you kidding? even the "microG flavor of LineageOS 21" (using Android 14 as a base) still ships with microG 0.2.27 (thank god!). i guess because it is still considered the latest stable release even by microG.

---

thanks for taking your time and elaborating the functions a little bit more.
unfortunately i have still a hard time understanding what happens when using merge: ok... so the merge is done for every emitter one by one, but how does it exactly work?

IIRC for every emitter a position (lat & long) and a radius is saved....

• what makes sense to me is, that if one device found the network from farer away, the radius is expanded because the emitter might have a bigger coverage as the other device "assumed".
• but what is done if the position is not exactly the same? how is determined which position to use/keep?
• ...and (how) is then the radius adjusted accordingly if the position is altered?
• BTW: what is the difference between the 2 radius columns?

---

is my hasty conclusion correct, that merging databases from 2 or even more different devices which are used in the same area might not be the smartest idea, since the accuracy might even go down because the radius gets further and further expanded, which might not even make sense for the current device because it might simply have a not that strong radio dongle?
or to put it short: with imports the accuracy usually does not get better but rather worse (especially when merging emitters is used), and should mainly be used to expand coverage.

[Helium314]

but how does it exactly work?

The two radii (east-west and north-south) and a center position give you a rectangle (approximately, as we're on a sphere) which corresponds to a bounding box (with north & south latitude and east & west longitude).
When merging two emitters, the resulting bounding box is expanded to fully contain both previous bounding boxes. New center is center of the new bounding box.

See merge and BoundingBox.update.

the accuracy might even go down because the radius gets further and further expanded, which might not even make sense for the current device because it might simply have a not that strong radio dongle?

It's possible, but I would expect this to be really bad only in extreme cases (merging very sensitive and very insensitive devices).

or to put it short: with imports the accuracy usually does not get better but rather worse (especially when merging emitters is used), and should mainly be used to expand coverage.

Yes, you will never get a better accuracy on the merged positions, but it's less likely that you are actually outside the accuracy circle of the resulting location. Decreased accuracy also means that this emitter's weight will be reduced when averaging positions coming from multiple emitters.

[DJCrashdummy]

thank you very much @Helium314 for the insights into this topic.
beside occasionally contribution to OSM, i never had much to do with mapping, positioning and the like. so this is pretty interesting to me.

---

ok... with your description, the merging is crystal clear and even doesn't seem that complicated. 👍
what partly lead me the wrong way was the radius thing and dumb me in the first place not connecting "ns"/"ew" with north-south/east-west. 🤦
if someone wants to nitpick, it's not really a radius but rather something like a bidirectional extent/stretch, but the approach makes perfect sense.

yes... concerning decreased accuracy a few exceptions - especially when multiple (known) emitters are reachable - came into my mind at the time of writing, but i didn't want to text even more and stayed with the theoretical approach.

one last question:
as it seems that there is no date, import flag or any other option to quantify the quality of an emitters data, is my assumption correct that once an emitter is in the database it stays as it is forever (unless it is discarded or altered manually)? or is there a way resp. "active mode" to check if the data of already known emitters are still correct resp. refresh them? or is this additionally done in every "active mode" beside the task which triggered the active mode?

[Helium314]

if someone wants to nitpick, it's not really a radius but rather something like a bidirectional extent/stretch, but the approach makes perfect sense.

It used to be a radius initially, but was changed to the ew/ns style at some point in original DejaVu backend. I considered switching the DB to bounding boxes, but found that the current style give more readable information when just looking into the database.

one last question: [...]

The emitter stays forever. There used to be a check whether supposedly nearby (but not detected) emitters are still existing, but I found that it used too much CPU with a large database, and often it incorrectly removed actually existing emitters (e.g. WiFi that you can't find through a thick wall or floor).
There also used to be a check that would move emitters if they were found far away, e.g. WiFi several km away from where it was detected previously). But this caused a lot of trouble and incorrect location reports with mobile hotspots, so now those "moving" emitters are simply blacklisted instead.