Как сохранить целостность между меняющейся уличной сетью и геокодированными точками?

12

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

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

Я однажды решил эту проблему в одноцентровой сети, используя методы линейных ссылок, геокодирования и привязки, но процесс был очень жестким и хрупким. (Подробнее см. Http://thewyvern.co/Thesis.final.pdf .)

Кто-нибудь еще сталкивался с этой проблемой? У Вас есть какие-то предложения? Можете ли вы указать на какие-либо исследования, которые могли бы помочь нам разработать надежное решение?

Для контекста: мы используем собственный алгоритм геокодирования, закодированный в ArcObjects, который опирается только частично на класс Locator ESRI. Наша система основана на ArcGIS Server 9.3.1, данные хранятся в ArcSDE 9.3.1 в Oracle. Данные Navteq доставляются в формате shapefile.

geocoding linear-referencing snapping NW1
источник
1
Можете ли вы добавить больше информации к вашему вопросу, например, какое программное обеспечение вы используете для геокодирования, форматы данных, доступное программное обеспечение и т. Д. Если вы используете ArcGIS, рассматривали ли вы вопрос об использовании геометрической сети? Если у вас есть FME, вас может заинтересовать эта презентация San Antonio Water System.
blah238
«Топологическая целостность» является очень широким термином, и я интересно, именно то , что вы подразумеваете под этим. Вы хотите, чтобы узлы, которые вы геокодировали, были частью границ улицы? Потому что использование геокодирования на уровне участка с исправлениями может легко поместить геокодированные точки в некоторую часть участков и при этом быть «топологически корректным»
Раги Язер Бурхум
@Ragi: Это топологическая проблема (я думаю) в том смысле, что точки расположены в сетевом пространстве относительно других функций. Но, возможно, этот термин здесь бесполезен.
nw1
1
Есть ли связь между атрибутами и узлами (PK / FK) между узлом и осевой линией или их можно добавить к узлам перед обновлением осевой линии? Я уверен, что NAVTEQ сохраняет полупостоянный идентификатор, который должен оставаться неизменным, даже если геометрия меняется. Достаточно ли будет идентификатора центральной линии и процента вниз по линии, чтобы правильно найти ваши узлы после обновления центральной линии?
MWrenn
1
По моему опыту, идентификатор изменяется только при разделении геометрии, обычно из-за нового пересечения с другой дорогой или геометрией пешехода, а не просто отрегулированной. Вы видите иначе? Я предполагаю, что пытаюсь определить масштаб случаев, которые должно решать это решение.
MWrenn

Ответы:

1

Я смотрю на проблему для моего агентства прямо сейчас, которая намекает на тот же сценарий или, по крайней мере, очень похожий.

То, на что я нацеливаюсь, это; все адресные точки имеют идентификатор улицы, с которой они соответствуют; а также USPS Range от AIS. Нам нужно выполнить проверку на обнаружение изменений с каждым обновлением улицы продавца, для идентификаторов сегмента улицы, которые имеют изменение, мы затем изолируем точки, которые ссылаются на этот идентификатор; Затем мы пройдемся по каждому из них, выполняя буфер, чтобы выбрать ближайший идентификатор уличного сегмента, чтобы мы могли правильно их связать.

Это будет трудоемкий процесс, но вы можете написать его довольно много (это я сейчас моделирую), и это должно произойти только при обновлении данных вашего поставщика. Мы будем получать обновления для наших адресов из ряда источников, поэтому мы возьмем точки и объединим их, а затем будем обновлять их каждый раз, когда обновляются данные наших поставщиков, я мог бы даже добавить ссылку на TIGER / Edge, но это было бы просто для будущего использования демографического моделирования.

Мы работаем над объединением адресов в диапазоне с данными на уровне участков, которые будут поддерживать источник адресации и маршрутизации по всему штату.

DEWright
источник