addresses

vet portal

Need in vet portal for 2 pieces of functionality

1. Allow user to enter in a ‘primary location’ - their house/home/apartment.
2. “Verify” this address - is it an address that is found in a mapping service?

I think there may be a need to have a vet (or others) have more than one address, eventually, but unsure if that should be baked in today or just go for a ‘one to one’ approach right now.

The “verification” part - can use mapbox or similar service to see if the address is found. If it’s not found, we can still allow the address to be stored, but we’d not mark it as ‘verified’ - the ‘verified’ would primarily be a flag indicating it passed geocoding and we have lat/lon for the address. I could see allowing someone to find their place on a map, and get lat/lon from that, (then maybe reverse geocode as well?)

address repo and service

AddressRepository has 2 subclasses - basic UserAddress and VetAddress and SiteAddress

Passing a vet user to VetAddressRepo will allow data access to be limited to the vet in question, and it will check that the user has a vet role.

The AddressService takes an address repository, and provides a way to do some user/address management - early stage dev on this - more ideas are welcomed.

usage

// get the primary address for a site
$siteAddressRepo = new SiteAddressRepository($site);
$address = $siteAddressRepo->getPrimaryAddress();

types

Address can be one of 3 types. ‘mailing’, ‘driving’, ‘physical’.

Address::TYPE_MAILING; // etc

for the mapping/distance process, the system will look first for an address of type ‘driving’. if that is not found, it will look for ‘physical’. if that is not found, a ‘mailing’ address type will be used. An initial address for a site will be added with type ‘mailing’.

Initial address added will have ‘primary’ flag added as well, which can be used as a default indicator in instances where multiple addresses may exist for a user.

use cases

Site/hospital may potentially have multiple addresses, each with potentially different type (‘driving’ address for mapping, and ‘mailing’ address for deliveries/mail). The ‘type’ attribute will be of more specific use for this sites.

Site hospital will have ‘primary’ address be attached as key on site record - one-to-one relation to address table. On need for multiple address support, either more explicit one-to-one can be added, or the one-to-many support with the in the SiteAddressRepository can be used.

Individual doctor users may have multiple addresses, and will, by default, all be considered ‘driving’ addresses to start, as map/distance calculations are the primary use case to start. The ‘primary’ flag will be used as the default address to show when multiple addresses are present for choosing.

geocoder

Looking to base off https://github.com/geocoder-php/Geocoder and https://github.com/geocoder-php/GeocoderLaravel

Calling direct from browser can expose keys.

composer require toin0u/geocoder-laravel geocoder-php/mapbox-provider php-http/guzzle6-adapter

Token is in config/geocode.php, and is mapbox_token, overrideable in env() as MAPBOX_TOKEN.

mapbox

Marker/map styling info/playground here https://staticmapmaker.com/mapbox/

converting existing addresses

docker-compose exec app artisan core:address --action=convert

This command will run a one-time conversion of addresses in the ‘site’ table to an external address entry in the ‘addresses’ table.

This will use the methods on the AddressService with a SiteAddressRepositor to create the entry and relate the address as a ‘primary address’ as a one-to-one via a primary_address_id on the site.

The admin sites ui screen has an extra field added to show a map icon when the primary_address is present on the site.

The distance calculation jobs use the site’s primary address during calculations. A site without a primary address for some reason should be skipped during calculation processing.

docker-compose exec app artisan core:address --action=list > output.txt

This provides output of site addresses - including converted and previous states - to allow for quickly seeing which addresses may not have converted at all, or any which may look wrong. TSV output suitable for quick review in spreadsheet.

address forms & input fields conventions

Input forms should use the following named fields for consistency. Refer to the Addresses table for additional fields.

• address1
• address2
• city
• state
• postal_code
• country

lat/lon to timezone

Oct 2021

Addresses validated through mapbox have ‘lat/lon’ attributes. There is also a need to determine the timezone of an address, and mapbox does not provide this. In the immediate future, we’ll be using geocodio.com API to get a timezone from lat/lon. The return value is an address and local time and separate identifier. The identifier will be a value like “CST” or “EDT”, and includes a flag indicating “observes_dst”.

AddressService::getTimezoneKeysFromLatLon will return a ‘resolvedName’ and ‘detectedName’. The ‘resolvedName’ will be a constant from Timezones class - “Eastern” or “Central” or similar. The ‘detectedName’ will be a full identifier, like “America/Boise”, “America/Phoenix”, etc.

The resolvedName is used for display purposes. Detected name is stored, but isn’t currently used. When determining a ‘full’ timezone to use for calculation purposes, the Timezones class is referenced to get “America/New_York” from “Eastern” (for example).

AddressService::convertGeneralTZToFullTZ and AddressService::convertFullTZToGeneralTZ can handle converting back and forth, and existing references to manual conversion will be modified.