Location
Description
A generalized physical location, less strict than an :Address.
General location for a Festival or Fair. Using the LOCATED_IN relationship this location could indicate where an :EventInstance is taking place. For example, an event instance for "Coachella 2025" could have a location of "Indio, CA" as its base.
Label
:Location
Properties
| Property | Type | Description / example |
|---|---|---|
| id | String | Unique identifier for this base, a uuid |
| country | String | The three-letter ISO 3166-1 alpha-3 country code |
| locality | string | The locality, usually the city, in which the street address is, and which is in the region. For example, Nashville. |
| region | string | The region in which the locality is, and which is in the country. For example, California or Ontario or another appropriate first-level Administrative division. |
| regionAbbreviation | string | CA, ON, etc |
| geoPoint | Point | Point(longitude=-116.238964, latitude=33.682525). For our use cases, a 6-decimal place precision is enough. |
| createdBy | string | the person or process that created the node |
| createdDate | dateTime | |
| modifiedBy | string | the person or process who last modified the node |
| modifiedDate | dateTime |
INFO
Neo4j offers some level of geocoding support natively within the product, defaulting to OpenStreetMap (OSM); please refer to the spatial functions in the Neo4j documentation.
WHY NOT MAKE BASE A CATEGORICAL VARIABLE RATHER THAN PARTY DATA?
Just a judgement call. If we were to establish unique base nodes for every possible locality globally, it could be done, but it isn't truly necessary. Using this structure, we can do pretty fast geo-spatial queries over all the :Base nodes to find, for example, all the active clients with a home base that is within 100 miles of Los Angeles.
For some sample queries of distance searching using Neo4j spatial functions, see "Spatial Search Functionality with Neo4j"
Key
id
Relationships
The LOCATED_IN relationship connects various data nodes to locations, and uses the standard relationship properties.
Address verification requirements
While no address should be allowed into UTA systems that does not run through the address verification, normalization, and geocoding gate, the base need only resolve to the state, province, country level, with generic latitudes and longitudes that typically center on the region.
Examples