model Location, Csa and Poi places

[matt-beanland]

NTD are at Location
NNIGroup are at a Poi
CVC serve a CSA (a hinterland)
CSA and POI are 1:1

A LOC has a CSA (connectivity serving area) based on a technology (or technology plan). Need to think about this more.

We won't model geospatial yet.

There may be another geographic thing we need, let's call it a TSA (technology serving area).

TSA's are contained solely within a CSA, and represent an area served by the same technology. (NBN had FSA, Fibre Serving Area) early on.
We'll allow TSA to have a single technology only, and overlap.

A LOC can be in multiple TSA, but policy will provide a technology preference, and a migration strategy (none, customer, RSP, provider).

We typically will have 1000's of LOC in a TSA, and 100's of TSA in a CSA.

We can connect LOC - TSA - CSA - POI

An access node is typically in a single TSA, although we could sectorize fixed wireless.

[matt-beanland]

This would be impacted (made easier) by diffo-dev/diffo#101

[matt-beanland]

LOC to TSA is pretty dense, we may prefer the relationship is indirect.

[matt-beanland]

Yarning about this with the diffo 0.4.0 Place DSL in hand — the heavy lifting is already there.

What the DSL already gives us (permit/deny):

For Place kinds, places do role :foo, OtherPlace end declares which place-to-place relationships are permitted. The hierarchy from the body becomes:

• Location: places do role :located_in, TSA end
• TSA: instances do role :covers, Location end ; places do role :within, CSA end
• CSA: places do role :anchors, POI end ; instances do role :served_by, CVC end
• POI: instances do role :hosts, NNIGroup end

All four resources use BasePlace as a fragment, declare these role permissions, and the DSL enforces what relationships can exist. Technology/preference data lives on Location (or on a join — TBD) as attributes.

What's missing — action-level wiring:

The DSL says "Location may be located_in TSA"; what we still need is the runtime action that actually creates the PlaceRef edge between a specific Location and a specific TSA. Today Diffo.Provider.Instance.Relationship.relate_instance/2 handles instance → instance edges (the path of our Relate change module), and Diffo.Provider.Instance.Place.relate_instance/2 handles instance → place — but there doesn't seem to be a clean Place.relate_place/2 equivalent for place → place.

That's the place to dig and, if a gap is real, yarn with diffo using the #125 format.

TSA semantics: the body's "TSA contained solely within a CSA, single technology, overlap allowed, LOC can be in multiple TSAs with policy-driven preference" all stays valid. The TSA-overlap-with-LOC bit may suggest places :located_in, TSA, constraints: [min: 1] (plural) on Location rather than singular — worth deciding.

Migration strategy (none / customer / RSP / provider) and technology preference are policy concerns — likely live on a separate resource or as attributes on the Location-TSA relationship if Diffo's place-to-place supports edge attributes.

I think the right shape is: declare the roles, prototype the place-relate actions, then if we hit a Place.relate_place gap, raise a #125-style issue on diffo for symmetric place→place wiring.