This is actually a question that I have wondered at for a while, and it’s coming to me again as I work on a project.
If we are defining a one-to-many relationship between location and address, shouldn’t we then move
longitude to the address table? If I should happen to have multiple addresses with different lat/long, then those should be stored with their respective addresses, and I shouldn’t have to choose which one I store at the location level.
What am I missing?
I think lat/long is on location because a single address can have multiple locations such as a mall, shopping complex etc.
That sort of makes sense, but what we’re actually modeling in HSDS is that one location can have many addresses. From the perspective of a given service-at-location, I presume that what we care about is where physical locations (ie, physical addresses) for those services are at. If I’m allowed to have multiple physical addresses, then it seems like I should be allowed to have multiple lat/long coordinate pairs that match them. And if, as with most locations, there is only one physical address, then the lat/long are still accessible in that data.
Looking at it another way, is there a use case where we definitely don’t want lat/long stored in the address table?
Are lat/long used for geospatial search? Would that impact answer? I’m not hands on with the data at this stage so wondering how location and address interact. Does location imply a broader geography?
We don’t tie to address, because we sometimes generate based off intersection or manual pins, and we tie it to whatever data was used to generate the lat/long data. We also have different privacy settings on our lat/long and address data. Generalized lat/long data (often based on major instersection) is used to provide proximity search results when detailed address data is private, particularly where the organization’s administrative address is a private residence, or in the case of domestic violence shelters.
Those are interesting points @klambacher. We handle confidential address differently, but that’s a clever use case.
@HowardAskew in our system, the lat/long are used for geospatial search.
I’m hearing that, purity of relationships aside, there isn’t a really strong use case for moving lat/long to to the address table, whereas it might mess up existing databases.
In practice, I haven’t found location data that actually has more than one physical/street address tied to it. We have one street address per location, and we connect multiple locations to services via the service_at_location table.
So, perhaps we just shelve this topic?