Diffo - TMF Service and Resource Management with a difference
LocationPoint - the lat/long where a service is delivered.
The point is the anchor: it is always present and is what service qualification runs against (which CSA's bounds contain it). A postal GeographicAddress is a separate, optional concern — non-premise NBN locations (a street cabinet that needs comms but has no postal address) legitimately have only a point.
A TMF675 GeographicLocation (a location point), in the NBN domain so it
can carry consumer-specific richness later.
A LocationPoint — the lat/long where a service is delivered
Summary
Types
@type t() :: %DiffoExample.Nbn.LocationPoint{ __lateral_join_source__: term(), __meta__: term(), __metadata__: term(), __order__: term(), accuracy: term(), aggregates: term(), bounds: term(), calculations: term(), created_at: term(), href: term(), id: term(), location: term(), name: term(), place_refs: term(), referred_type: term(), type: term(), updated_at: term() }
Functions
Validates that the keys in the provided input are valid for at least one action on the resource.
Raises a KeyError error at compile time if not. This exists because generally a struct should only ever
be created by Ash as a result of a successful action. You should not be creating records manually in code,
e.g %MyResource{value: 1, value: 2}. Generally that is fine, but often with embedded resources it is nice
to be able to validate the keys that are being provided, e.g
Resource
|> Ash.Changeset.for_create(:create, %{embedded: EmbeddedResource.input(foo: 1, bar: 2)})
|> Ash.create()
Same as input/1, except restricts the keys to values accepted by the action provided.