Veriplace was WaveMarket’s approach to making carrier location infrastructure accessible through a common application interface. Its historical significance lies in the separation between the application asking for a location and the network helping supply it. That separation offers a useful way to examine location services: identify the permission, the source and the meaning of the returned information.
This case study describes historical announcements and an evaluation method. Its dated sources establish the historical model; verify current service availability separately. Apply the method to documented services and devices you are authorized to evaluate.
Place the platform in its period
In its March 2010 announcement, WaveMarket described T-Mobile USA joining its Veriplace initiative, alongside existing carrier connections. The company presented a single API for applications using location information from multiple networks, including support for feature phones and smartphones. These are dated provider claims about the platform’s design and reach.
The period also saw efforts to package information as cloud services. Microsoft’s November 2009 description of codename Dallas presented a marketplace and catalogue for public and commercial data. A catalogue entry, a carrier agreement and a successful application request represent different parts of such an ecosystem. Each needs its own evidence when reconstructing a historical integration.
Follow a location request through its dependencies
A useful conceptual chain is: an authorized application requests a permitted device location; a provider obtains an estimate from its available infrastructure; the application receives information it must interpret and handle appropriately. Use this as an evaluation model; exact response fields require the service’s own documentation.
| Question | Evidence needed | Why it matters |
|---|---|---|
| Who permitted the request? | Documented authorization, purpose and withdrawal behavior | Connects access to the intended person and use. |
| What device and source? | Device association and documented location method, when available | Defines what the estimate refers to. |
| When was it observed? | Observation time, response time and time zone | Separates freshness from delivery speed. |
| How uncertain is it? | Uncertainty field, units and provider’s definition | Prevents a map pin from implying unjustified precision. |
| What happens afterward? | Access controls, retention and deletion behavior | Shows how the application handles the returned data. |
Record unavailable fields as unknown. A successful request can still be unsuitable for a decision if its observation time or uncertainty is missing. A provider’s claim of indoor coverage needs test conditions and results before it becomes evidence about a particular building or device.
Read time as carefully as position
Invented example: an application receives a response at 14:05:00 UTC containing an observation stamped 14:02:30 UTC. The estimate is 150 seconds old at receipt. Observation age and API response speed measure different things. Show the observation time and assess whether its age fits the task.
If a person or vehicle could have moved during that interval, the old point represents an earlier observation. Preserve the supplied uncertainty definition instead of inventing a confidence radius. For repeated reports, assess gaps and changes in source as well as the shape drawn on a map. See interpreting vehicle location reports for a related application.
Compare interfaces without assuming equivalence
A clearly documented contemporary comparison is the W3C Geolocation specification. Its interface concerns the device hosting the implementation and exposes position information, a timestamp and permission-dependent behavior. It is a different access model from a historical carrier aggregation service. Use it to understand the questions an interface should answer, while checking each system’s own documentation.
For an authorized evaluation, include refusal and withdrawal cases in the test plan. Explain what the application shows when a location is unavailable, how a user stops sharing, and which stored records remain. Verify those behaviors through documentation and observation.
The location-service evaluation record keeps historical claims, current documentation and actual observations separate. Use it to write a narrow conclusion: which request worked, under what conditions, with what information and what unresolved dependency. The location messaging guide extends this reasoning to useful alerts.