How to handle data errors?

This forum deals with questions about special content. Let us know what kind of content you wish to see within our services...
Post Reply
User avatar
Bernd Welter
Site Admin
Posts: 2695
Joined: Mon Apr 14, 2014 10:28 am
Contact:

How to handle data errors?

Post by Bernd Welter »

Hi there,

every once in a while users mention an error in the data:
  • a geocoding didn't find the required address
  • a geocoding returns wrong coordinates for a proper address
  • a street is missing
  • a street's attributes are wrong, e.g.a truck attribute is missing (usually reported by drivers who weren't allowed to drive over there)
  • a poi wasn't found
  • ...
This motivates me to provide some details about how to react on such a condition if you face something similar. For a proper understanding we need to explain the process:
If you encounter some missing data and even adapting the business logic can't help you are supposed to forward the missing data issue to
who will then take care for the internal forwarding process to data department. The colleagues will create an internal task for the incidenct and decide how to proceed.,

Please provide the following mandatory info:
  • API / software you use, e.g. PTV xServer Internet 2, PTV Developer (also with specific service URLs)
  • Map version (incl. provider, e.g. HERE, subversion e.g. "2024.2H"...)
  • Coordinates of the "object in charge"
  • Result you expect
Optional
  • Requests / responses
  • Result you get
  • External source of info: why do you think it is wrong? (image taken by driver, google streetview pics, official announcement , ...)
workflow schema in case of "user report". Also describes the complexity of a solution. The further left a solution is, the lower are the efforts and the time to fix the issue.
workflow schema in case of "user report". Also describes the complexity of a solution. The further left a solution is, the lower are the efforts and the time to fix the issue.
Le's distinguish different roles:
  • The user. Sometimes not aware of the backend infastructure in use. He is the patient zero who reports the issue to his application provider, e.g. his own IT department or the PTV partner who integrated the software.
  • The application provider: the party that implemented the business logic which accesses the xServer interface via on premise or cloud access.
  • The PTV "face to the customer" (consulting/forum or support): we try to find out whether there's a quick solution (adapt business pogic) or not (data really missing)
  • The PTV data department: those colleagues evaluate whether the missing data was part of the binary maps or not. If not they get back to the...
  • providers (HERE, TOMTOM, ...) who delivered the raw data to PTV which created the binaries afterwards. A data provider cycle could last up to one year. In extreme situations even two!
  • There's also another stage which isn't part of the schema: administration. Sometimes the data in real life has been updated, e.g. when the administration re-assings postcode areas. If providers aren't aware of such a major change it could even take more than a year to reflect the new circumstances.
Best regards,
Bernd
Last edited by Bernd Welter on Thu Jan 28, 2021 2:50 pm, edited 4 times in total.
Bernd Welter
Technical Partner Manager Developer Components
PTV Logistics - Germany

Bernd at... The Forum,LinkedIn, Youtube, StackOverflow
I like the smell of PTV Developer in the morning... :twisted:
Post Reply