Спасибо всем за их ответы, их ответы были полезны, но не касались всего, что мне было нужно. В конце концов я нашел подход, который взял на себя все мои дела. Этот подход является модифицированной версией того, что я предложил в вопросе.

Основной Подход

Здесь я буду ссылаться на что-то под названием "узел", это объект класса, который будет содержать геоинформацию, такую как широта, долгота, возможно, измерение объекта и его полный адрес.

Если адрес объекта - "101 C, Pearl Street, New York, USA", то это означает, что наша структура данных будет иметь по крайней мере четыре узла для - "101 C", "Pearl Street", "New York" и "USA". Каждый узел будет иметь name и одну address часть. Для "101 C" name будет "101 C", а адрес будет "Pearl Street, New York, USA".

Основная идея состоит в том, чтобы иметь дерево поиска этих узлов, где узел name будет использоваться в качестве ключа для поиска. Мы можем получить несколько совпадений, поэтому позже нам нужно будет ранжировать результаты о том, насколько хорошо узел address совпадает с запрошенным.

                                    EARTH
                                      |
                ---------------------------------------------
                |                                           |
               USA                                        INDIA
                |                                           |
        ---------------------------                     WEST BENGAL
        |                         |                         |
     NEW YORK                 CALIFORNIA                 KOLKATA
        |                         |                         |
   ---------------            PEARL STREET              BARA BAZAR
   |             |                                          |
PEARL STREET   TIME SQUARE                                 101 C
   |             |
  101 C         101 C

Предположим, что у нас есть географические данные, как указано выше. Таким образом, поиск "101 с, Нью-Йорк" вернет не только узлы "101 С" в "Нью-Йорке", но и в "Индии". Это происходит потому, что algo будет использовать только name, то есть '101 C' здесь, для поиска узлов. Позже мы можем оценить качество результата, измерив разницу address узла от запрошенного адреса. Мы не используем точное совпадение так как пользователю разрешается указывать неполный адрес, как и в данном случае.

Сортировка Результатов Поиска

Для оценки качества результата мы можем использоватьсамую длинную общую подпоследовательность . Случаи "упущения" и "избытка" хорошо рассматриваются в этом algo.

Лучше всего, если я позволю коду говорить. Ниже приведена реализация Python, специально разработанная для этой цели.

def _lcs_diff_cent(s1, s2):
    """
    Calculates Longest Common Subsequence Count Difference in percentage between two strings or lists.

    LCS reference: http://en.wikipedia.org/wiki/Longest_common_subsequence_problem.
    Returns an integer from 0-100. 0 means that `s1` and `s2` have 0% difference, i.e. they are same.
    """
    m = len(s1)
    n = len(s2)

    if s1 == s2:
        return 0
    if m == 0: # When user given query is empty then that is like '*'' (match all)
        return 0
    if n == 0:
        return 100

    matrix = [[0] * (n + 1)] * (m + 1)
    for i in range(1, m+1):
        for j in range(1, n+1):
            if s1[i-1] == s2[j-1]:
                matrix[i][j] = matrix[i-1][j-1] + 1
            else:
                matrix[i][j] = max(matrix[i][j-1], matrix[i-1][j])

    return int( ( 1 - float(matrix[m][n]) / m ) * 100 )

Оптимизированный Подход

Я отказался от вышеупомянутого (базового) подхода, так как это вынужденная избыточность, и это не могло сократить рычаги тот факт, что если пользователь предоставил " США "в своем запросе, то нам не нужно искать узлы в "Индии".

Этот оптимизированный подход в значительной степени решает обе вышеперечисленные проблемы. Решение состоит в том, чтобы не иметь одного большого дерева поиска. Мы можем разделить пространство поиска, скажем, на " США " и "Индию". Позже мы можем дополнительно перераспределить эти пространства поиска по состоянию. Это то, что я называю "нарезкой".

На приведенной ниже диаграмме - SearchSlice представляет собой "срез", а SearchPool - дерево поиска.

                            SearchSlice()
                                  |
            ---------------------------------------------
            |                                           |
        SearchSlice(USA)                           SearchSlice(INDIA)
            |                                           |
    ---------------------------                  SearchPool(WEST BENGAL)
    |                         |                   |
 SearchPool(NEW YORK)     SearchPool(CALIFORNIA)  |- KOLKATA
    |                         |                   |- BARA BAZAR, KOLKATA
    |- PEARL STREET           |- PEARL STREET     |- 101 C, BARA BAZAR, KOLKATA
    |- TIME SQUARE
    |- 101 C, PEARL STREET
    |- 101 C, TIME SQUARE

Несколько ключевых моментов, которые следует отметить выше...

Каждый срез имеет только один уровень глубины. Ну это не совсем очевидно выше.
• имя срезанного уровня не появляется в адресе его потомков. Например, SearchSlice(USA) поддерживает срез Штатов в "США". Таким образом, узлы под "Нью-Йорком" не включают название "Нью-Йорк" или " США " в их address. То же самое касается и других регионов. Отношение иерархии неявно определяет полный адрес.
• '101 C' address также включает в себя родительские name, поскольку они не разрезаны.

Возможности Масштабирования

Там, где есть ведро (пул), существует неявная возможность масштабирования. Мы (скажем) разделяем географические данные для " США " на две группы. И то и другое может быть в разных системах. Таким образом, совершенно нормально, если пул "Нью-Йорк" находится в системе а, а пул "Калифорния" - в системе в, поскольку они не обмениваются никакими данными, кроме родителей курс.

Вот предостережение. Нам нужно дублировать родителей, которые всегда будут кусочком. Поскольку срезы должны быть ограничены в количестве, чтобы иерархия не была слишком глубокой, поэтому дублирование их не должно быть слишком избыточным.

Рабочий Код

Пожалуйста, обратитесь к моему GitHub длярабочего демонстрационного кода Python .