#mlocs

10 textured, braided, and locked male hairstyles

1. johnnysims - amir hair 2. johnnysims - travis hair 3. thatonegreenleaf - trace hair 4. axa - isaiah hair 5. greenllamas - andre hair 6. simandy - jericho hair 7. qrsims - hair 31 moonstone 8. joshseoh - tegan hair 9. crazy hazy sims - cool as fuck hair 10. birksche - lock my dreads hair

This whole model revolves around the maiden-location for any given lat-lon-tuple. For those of you who haven't been using HAM radio, and/or not familiar with the Maiden Head Locator System, here's a small recap.

The world is divided into 324 chunks (at level 1) 

These can be made (usefully) up to level 5. Here's a picture of the Eiffel Tower at level 4. The blue locator pin is the exact location we're tracking (48.858278, 2.294254). The red locator pins (A,B,D and D) are showing the bounding box for all lat-lon-tuples sharing this locations mloc at level 4.

Here's the same picture, then for Level 3.

Then we can zoom out further to Level 2.

Or even Level 1.

Wondering what the Level 5 looks like?

And now you wonder why Level 6 is not sane?

Now that we've visualised the various MaidenHead Locations ranging from Level 1 to Level 5 it's about time to reveal how we can exploit this.

Suppose we want to store 'locations' in such a manner we can easily find 'nearby' locations given any location. There are multiple ways of doing this. By using the MaidenLoc system, where we effectively hash locations to a mloc we can store locations in multiple bloc hashes.

So we have hashes (representing different mloc-levels) like this :

>>> eiffel_tower = [48.858278, 2.294254] >>> toMaiden(eiffel_tower,1) 'JN' >>> toMaiden(eiffel_tower,4) 'JN18DU55' 

However, suppose you've just parked your car somewhere in Paris (like at 48.858318,2.295332).

>>> user_location = [48.85551,2.291838] >>> toMaiden(user_location, 4) 'JN18DU55'

Now that's amazing, they both share the same mloc-4 :) Is this true on level 5?

>>> toMaiden(user_location, 5) 'JN18DU55AH' >>> toMaiden(eiffel_tower, 5) 'JN18DU55HX'

With this hashing algorithm in place, it's fairly easy to store any 'POI' with it's 'MLOC-key'. This will result in easy (and efficient) queries to our 'backend'.

We can take the users GeoLocation (via browser, or device) and calculate (on the user device) the various mlocs representing this location. Now a simple "select ... from ... where mloc=mloc" will return all locations within the same mloc. There is no need for distance calculations in de backend/database/query as sharing an mloc IMPLIES being at a certain distance within the other locations. In our basic setup we assume the following : MLOC-1 : < .... km. MLOC-2 : < ..... km. MLOC-3 : < .. km. MLOC-4 : < ...m

In order to reduce the effort to find nearby locations, we can simply query for our own MLOC-4. We have one situation where we might be on 'the edge' of our MLOC-4 square, therefor 'missing' the nearby locations in an adjacent MLOC-4 square.

To amend for this we're also required to query the 8 surrounding MLOC-4's. We can determine these 8 additional MLOC-4's via a straightforward algorithm.

The net-result being we can get all stored-locations nearby the user location with a very simple query. (pseudo-codish looking like : select locs from database where mloc4 in mloc4list) 

The python package is stored at pypi (https://pypi.python.org/pypi/mlocs) currently at version 1.0.1 ;)