Mappoint - приоритет почтового индекса над названием улицы в FindAddressResults()

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

Таким образом, когда мы используем MapPoint для добавления путевых точек и оптимизации работы по почтовому индексу и названию улицы / номеру дома.

Проблема в том, что если вы вызываете функцию MapPoints FindAddressResults() с неправильным названием улицы, но действительным почтовым индексом, она игнорирует почтовый индекс и пытается найти название улицы в другом месте, часто в случайном городе за сотни миль.

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

Мой вопрос: при вызове FindAddressResults() есть ли способ заставить его отдавать приоритет почтовому индексу над названием улицы, в отличие от его поведения по умолчанию, при котором приоритет отдается названию улицы над почтовым индексом?

Пример использования (это написано на VB6 (не спрашивайте) - но любой пример/информация поможет):

'#### GeoCode using postcode & streetname
Set oResults = oMap.FindAddressResults(rsRequest("Request_Address"), , , , rsRequest("Request_Postalcode"))
If oResults.Count = 0 Then
    '#### Nothing was found, GeoCode using postcode only
    Set oResults = oMap.FindAddressResults(, , , , rsRequest("Request_Postalcode"))
End If

Единственное, что я могу придумать, это установить переменную «Максимальное расстояние», если 1-й элемент (наилучшее совпадение) в oResults [] превышает этот порог, по умолчанию используется поиск только по почтовому индексу, но это было бы в лучшем случае провалом.

РЕДАКТИРОВАТЬ 1. Только что придумал это, кажется, работает нормально:

Set oResults = oMap.FindAddressResults(rsRequest("Request_Address"), , , , rsRequest("Request_Postalcode"))
If oResults.ResultsQuality <> geoFirstResultGood Then
    echo (rsRequest("Request_Address") & " + " & rsRequest("Request_Postalcode") & " had poor results (" & CStr(oResults.ResultsQuality) & "), using postcode only instead...")
    Set oResults = oMap.FindAddressResults(, , , , rsRequest("Request_Postalcode"))
End If

geocoding mappoint
person HeavenCore    schedule 12.07.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Да, вы пришли к результату, который я бы предложил:

  1. Выполнить запрос с уличным адресом
  2. Проверьте ResultsQuality, если оно неоднозначное/плохое, то...
  3. ...выполните второй запрос только с почтовым индексом

Еще один способ улучшить качество FindAddressResults с британскими адресами — попробовать несколько разных вызовов FindAddressResults, пока не найдете тот, который дает результат «хорошего» качества. Каждый вызов будет иметь несколько разные варианты параметров. Британские адреса довольно гибки, например, название дома может быть в строке 1 (что делает строку 2 улицей); и может быть более одного места («города» на языке США) - например. деревня и город/поселок. в адрес.

Сначала запустите некоторые тестовые данные; и найти комбинации, которые работают лучше всего. Затем ваша последовательность вызовов будет начинаться с лучшей комбинации, второй лучшей и т. д., пока не будет найден «хороший» результат. Наконец, если результатов нет, вы можете попробовать позвонить только по почтовому индексу, как указано выше.

person winwaed    schedule 12.07.2012
comment
Ура, на данный момент это однопоточное приложение (устаревшее приложение VB6), оно не отстает от спроса, выполняя 1 вызов FindAddressResults(), однако я буду переписывать это как многопоточное приложение в течение следующих нескольких месяцев - и в этот момент я рассмотрю рекурсивное использование FindAddressResults() - +1 и еще раз спасибо. - person HeavenCore; 12.07.2012
comment
Извините, я не имел в виду использование многопоточности. Мой код был однопоточным и последовательно вызывал FindAddressResults. Если первый не работает, попробуйте следующий. Вы выбираете порядок в соответствии с вероятностью успеха в ваших тестовых данных, так что он, скорее всего, будет успешным в первом вызове, а не в последнем - это очень помогает со скоростью. - person winwaed; 12.07.2012