How to geocode

deals with geocoding and reverse geocoding

How to geocode

Postby Bernd Welter » Tue Feb 20, 2018 4:21 pm

Hi there,

here's an article of my fellow Thorsten Frerk. It deals with geocoding strategies - not on a technical level but some of you might find valuable ideas.

https://www.linkedin.com/pulse/instruct ... ten-frerk/

Thanks Thorsten - wow, that was impressive.
Feedback from the crowd is welcome!

Bernd

Unlock the power of location – in major companies – a worldwide approach!

The use cases geocoding, mapping and routing are more and more requested from the businesses and markets e.g. in large FMCG and other global acting companies.

Especially if it is about sales and/or service organizations or DSD’s who use any standard crm or sfa or individual app solution in the fields and the different markets around the world.

All major companies expect a global approach for these three use cases, since SAP/Salesforce.com/maihiro/assecco/Portatour/Stay in Front etc. – plus all major end customers - are also mostly acting globally.

Generally spoken: mapping & routing are not the real problems. PTV AG provides cloud solutions for every continent and country globally, just like almost every other supplier does – except e.g. North-Korea...but on request...

One major challenge is always and everywhere the geocoding issue (finding right coordinates based on any address input), which is one major precondition for enhanced routing functionalities in general. The establishment of a proper routing functionality additionally to the balanced territory optimization is the second major premise for routing in general. This topic will be explained separately.

Instruction on how to geocode any address data globally – within a major FMCG company:

In general, this issue appears initially as a bulk problem (big first load) because there is usually a lot of historically grown data already existing in the company’s databases without proper coordinates.

There is additionally an ongoing (smaller) problem for any occurring changes or any new data that comes up permanently.

To solve the initial problem, it seems to be the best approach to enhance the customer master data with coordinates from any GIS-suppliers db’s such as e.g. google maps, but unfortunately there is no legal way to license this use case with google maps with the legal right to store them (coordinates) in SAP c4c crm or elsewhere more than 30 days. So beside privacy concerns google maps is no reliable option.

There are few major suppliers that cover this coordinate issue globally and with lifetime licenses, such as TomTom, Here, Pitney Bowes, but none of them has yet achieved a full coverage. (Bing maps is based on Here, OSM is not yet suitable)

Plus, there are local third party specialists who focus – case-by-case - on a dedicated region. TomTom & Here together cover Europe and the Americas plus Australia quiet well.

If it comes to other continents, it is always an individual question and often different suppliers must be combined for geocoding purposes.

PTV’S proposal includes the service to offer this combining job as a service - based on PTV xLocate cloud services plus individually chosen local services - as a general and reliable global GIS supplier. Project- and marketwise – not in standard! – PTV AG can attach third party suppliers for dedicated countries e.g. if input data comes with country code = JP (Japan), a different third-party web service will be consumed (instead of only TomTom or Here etc.) initially and also for the ongoing process and always at additional cost.

Additionally, it is the old „shit in - shit out” thing

The quality and semantic of the input data plus the quantity structure of the data is – per customer/project/market - always very different, but very relevant.

If there are zip codes available, there are detailed specialties to take into account. For example in the USA: 5 digit plus only sometimes 4 digits = 9 digits, in Japan = every prefecture is different...

Town/City and district information’s are often mixed up, street names with abbreviations and historically grown changes can be totally different etc.

Is there a need for additional polygons and additional shape-layers (zip-code or administrative boundaries etc.), to represent and take into account e.g. sales territories etc.?

To measure the scale of the disaster per market it is mandatory for the projects to provide sufficient sample data and detailed requirements from the (mostly emerging) markets to PTV and allow some time for research and setup purposes.

To avoid such a sketchy approach for the ongoing process we strongly recommend establishing an additional mobile process in the first entry of any address data – the pure doctrine:

Gather the GPS-coordinate of the POI, once a field-rep is in front of its door via the mobile device and GPS and directly store it back to the customer master data (e.g. in c4c crm directly…).

This is the most accurate, license free and easiest way to solve this geocoding requirement/use case at long sight and globally.

DB based solutions/enhancements as an additional option for the ongoing process are recommended.

If new map-updates are released, maintaining a measure of the geocoding quality per map-release and data-set is also always recommended.

&

Please don’t hesitate to get back directly for any further questions.

Best

Thorsten Frerk
Bernd Welter
Manager Technical Consulting & Requirement Engineering
Senior Technical Consultant Developer Components
PTV GROUP - Germany

Bernd at Youtube
User avatar
Bernd Welter
Site Admin
 
Posts: 1098
Joined: Mon Apr 14, 2014 10:28 am

Return to PTV xLocateServer

cron