Implement "articles nearby" feature (geolocation of articles) about kiwix-js HOT 6 CLOSED

For the device geolocation : https://hacks.mozilla.org/2013/10/who-moved-my-geolocation/

from kiwix-js.

That feature won't be easy to implement.

I suppose I should create a rectangle around the device location (with a configurable size) and implement the same algorithm as in https://github.com/evopedia/evopedia_qt/blob/master/src/localarchive.cpp (getTitlesInCoords)
I will need a javascript rectangle implementation to replace the Qt one (http://harmattan-dev.nokia.com/docs/library/html/qt4/qrectf.html) with methods contains(point), intersects(rectangle) and normalize()
https://github.com/DavidDurman/joint/blob/master/src/geometry.js seems a good starting point

The storage is based on Quadtrees https://en.wikipedia.org/wiki/Quadtree
There are several javascript implementations, but I don't think it should be necessary to use them (https://github.com/silflow/quadtree-javascript/blob/master/quadtree.js and https://github.com/timohausmann/quadtree-js/blob/master/quadtree.js)

from kiwix-js.

Here is the explanation of Christian Reitwießner about the way coordinate files are structured :

The different files are all the same, they only contain different coordinates that should be visible at different zoom levels, i.e. coordinates_01.idx contains the most important coordinates (think of countries) and coordinates_17.idx contains the least important coordinates, but this is not always correct.

The files itself encode quadtrees in the following way:

The file encodes a single node (which can in turn contain other nodes).
Each node is either an inner node (it contains other nodes) or a leaf node (it directly contains links to the title file).

Each node starts with a 16-bit unsigned int, the "selector". If it is smaller than 0xffff, then the node is a leaf, otherwise it is an inner node. They are composed as follows (all numbers are little-endian):

NODE = INNERNODE | LEAFNODE

INNERNODE = 0xffff, COORDINATE center, uint32 len_sw, uint32 len_se, uint32 len_nw, NODE sw, NODE se, NODE nw, NODE ne

LEAFNODE = uint16 n, n * TITLE
TITLE = COORDINATE, uint32 titlepos
COORDINATE = latitude, longitude
(both in "little endian, single precision IEEE 754 encoding")

where titlepos is a byte-offset in titles.idx

Each node represents a rectangular region (in WGS84, of course it is not really rectangular). The region corresponding to the node "sw", for example stretches from the south-west corner of its parent node to theccenter of its parent node. len_sw is the byte-length of the sw-node, and so forth, so we can compute where "se" starts in the file.

from kiwix-js.

In order to test my implementation :
with a target rectangle (40,50,-10,10) on the "small" archive, it should find :
Danube - 48.106945, 8.282500
Paris - 48.856667, 2.350833
Alps - 45.833611, 6.865000

from kiwix-js.

The algorithm is now implemented and working.
What still needs to be done :

• move the maximum distance in an option (with a default value) AND/OR (if it's not too complicated) create an algorithm that makes this maximum distance vary, based on the number of results found. Example :
  • start with a very small distance
  • if there are 0 (or less than some value) titles found, search with a bigger distance
  • and so on, until a significant number of titles is found
• Simplify the home page, so that it is still readable on a device (even with keyboard on)

from kiwix-js.

Another approach would be to keep the algorithm as it is now, with a default distance. But, based on the number of results, suggest to reduce or enlarge this distance. The user might do so by clicking on a link : it would launch the search again, with a smaller/higher maxDistance.
So, instead of complexifying the algorithm, we let the user decide if he wants more or less results

from kiwix-js.