Нет нет к сожалению.
Почему вы можете спросить
Потому что разные нации и страны имеют совершенно разные форматы и требования к хранению адресов.
Здесь, в Великобритании, например, определение почтового индекса имеет довольно сложный набор правил, тогда как почтовые индексы в США представляют собой 4-значный числовой префикс с простым 2-буквенным кодом штата.
Затем вы должны рассмотреть вопрос что именно представляет собой адрес? опять же, это различия не только от страны к стране, но иногда и резко в пределах одной и той же территории.
например: (Здесь, в Великобритании)
Smith and Sons Butchers
10 High street
Some town
Mr smith
10 High street
Some town
The Occupier
10 High Street
Some Town
Smith and Sons Butchers
High Street
Some Town
Все действительные адреса в Великобритании, и во всех случаях почта будет доставлена в правильный пункт назначения, однако с GPS могут возникнуть проблемы.
База данных GPS может быть настроена таким образом, что каждое здание представляет собой квадратный элемент геометрии, а идентификатор представляет собой номер дома.
Это дало бы нам возможность точно сказать, где находится число 10, а это означает, что последний поиск немедленно завершится ошибкой.
Сюжеты могут быть проиндексированы по названию бизнеса, опять же, это нормально, пока вы не начнете использовать имена людей или общие названия.
Существует так много вариаций, что просто невозможно создать один унифицированный формат, который мог бы охватить все возможные правила, необходимые для того, чтобы любое приложение на планете могло правильно форматировать любой геокодированный адрес.
Итак, как мы решим проблему?
Просто, сужая область.
- Работайте ТОЛЬКО с определенным набором определенных сущностей, с которыми вам нужно работать.
- Держите только ту информацию, которая вам нужна для описания того, что вам нужно описать (Всегда помните YAGNI * здесь)
- Используйте стандартные форматы передачи данных, такие как JSON, XML и CSV, это повысит ваши шансы на то, что вам придется выполнять меньше работы с кодом, который вы не контролируете, чтобы он мог читать ваши выходные данные.
(* YAGNI = Вам это не понадобится)
А теперь копнем глубже:
Когда дело доходит до фактических данных ГИС, существует множество файлов стандартных форматов, 3 наиболее распространенных:
- Шейп-файлы Esri (*.shp)
- Язык разметки Keyhole (*.kml)
- Значения, разделенные запятыми (*.csv)
Все основные бесплатные и платные пакеты ГИС могут работать с любым из этих 3 типов файлов и многими другими.
Шейп-файлы, безусловно, являются наиболее распространенными, с которыми вы столкнетесь, почти каждый бит геопространственных данных, с которыми я сталкивался за годы работы в ИТ, был в шейп-файле, однако я бы НЕ рекомендовал хранить ваши данные в них для обработки, они представляют собой довольно сложный формат, часто медленный и последовательный для доступа.
Однако, если ваши файлы геометрии будут использоваться в других системах, вы не ошибетесь с ними.
У них также есть дополнительный бонус, заключающийся в том, что вы можете прикреплять атрибуты к каждому элементу данных, например, сведения об адресе, имена и т. д.
Проблема в том, что не существует стандарта в отношении того, что вы должны называть столбцами атрибутов или что вы будете включать, и, возможно, более радикально, имена столбцов ограничены ПРОПИСНЫМИ буквами и ограничены длиной 32 символа.
Файлы Kml являются еще одним общепризнанным, и поскольку они основаны на XML и используются Google, вы можете включать в них много дополнительных данных, которые технически являются самоописываемыми для машины, читающей их.
К сожалению, размеры файлов могут быть невероятно громоздкими даже для нескольких простых геометрий, однако этот компромисс означает, что с ними довольно легко работать практически на любом языке программирования на планете.
и это подводит нас к скромному CSV.
Основное место передачи данных (не только геопространственных) с незапамятных времен.
Если вы можете поместить свои данные в таблицу базы данных или электронную таблицу, вы можете поместить их в файл CSV.
Опять же, нет никаких стандартов, кроме того, как столбцы могут или не могут быть указаны в кавычках и каковы точки разделения, но читатели должны заранее знать, что представляет каждый столбец.
Также нет «готового» элемента географического хранения (фактически вообще нет типов данных), поэтому вашему приложению для чтения также необходимо заранее знать, какие типы данных столбца предназначены для того, чтобы оно могло анализировать их соответствующим образом.
С положительной стороны, однако, ВСЕ могут их прочитать, могут ли они понять их — это другая история.
person
shawty
schedule
16.07.2014
