some parties recently compared the output structure of the two geocoder APIs we offer within PTV Developer:
From a generic perspective let's distinguish between
- a postal address
- a business object address (a company, administration ...)
- PTV Developer Geocoding & Places (Here)
- Locations based on coordinates, structured address fields, formatted address and various quality fields
- Places based on one mutual structure for all categories. Based on coordinates, address data, name, category IDs and quality
- PTV Developer Geocoding & Places (OSM, based on NOMINATIM)
- One shared structure for locations and places. Compareably sparse details when it comes to detail level and quality, no structured addresss fields at all
The anser is simply because the underlying engines don't share the same concept of the data modell and also not the same data pool.
- What is the purpose of a geocoder? - To give you a coordinate that is as close as possible to the context of the users story. For postal delivery preferably based on house number level - for international distance calculation less detailed levels such as street / district or city are sufficient. By the way: it is NOT the purpose of a geocoder to verify whether an address is valid (exists) or not.
- How do users benefit from the output of the geocoder
- Dialogue - in an interactive user context a single formatted address is usually sufficient for the user to pick his preferred result (and coordinate). The user's intelligence decides about validity of a result.
- Batch - in this context all decisions about is there a result that a process can use for the next step have to be described on rules based on quality criteria such as score, detail level, ... within PTVs own engine we return as many details as possible. But with the Nominatim engine used within OSM we do not have that many details.
- Need structured address output from OSM engine
- Need quality criteria for each result for an automated check
