sparkfish / orbitron Goto Github PK

Test

Add support for ipstack.com's geocoding services so that a user can request records near an IP address input.

/nearest/{count}/{sourceType}/to/{location}[/within/{distance}/{units}]

Note that we will have to discern the data type of the location parameter as being either an IP address or Lat/Long or Postal Code.

Alternate IP-lookup services could be added later: https://resolve.rs/ip/geolocation.html (We can take requests or look at google search popularity or SEO link popularity checkers to assess top services to support)

It would be helpful to consumers if the data returned by Orbitron includes a distance measure. Since every query requires a given data point (whether it be a specific lat/long or zip centroid), then we should be able to calculate a distance between the input and each row of the output.

At some point, we may need to respond with varying units (miles vs km), or provide code for helper functions that convert between units, or allow parameters to be passed that dictate units to include in the response. However, the current project only supports miles at the moment. For this issue, perhaps we just add the units to the response, like _distance: "1.5 mi"? (The underscore is added here to avoid clashing with the source's data model.)

To get the initial set of 100 pharmacies, we could use the following request:

/nearest/100/pharmacies/to/75001  (1st page)

For this issue, we could add support for getting the next 100 with the following:

/nearest/100/pharmacies/to/75001/skipping/100  (2nd page)
/nearest/100/pharmacies/to/75001/skipping/200  (3rd page)

APIs today often offer continuation tokens that consider changes in the underlying data. As it is now, the underlying data is expected to remain reasonably static. So the benefits of a more complicated approach are not yet warranted and remains to be something that can be added at a later time when needed.

As the REST API gets more elaborate, we may want to handle all parsing of the query path ourselves instead of relying on FastAPI routes.

Currently, we can query for N records within X miles of a postalCode.

However, it would be helpful to request matches nearest a lat/long so that a browser's location API can be used to source the end-users location center.

Using a Lat/Long Center

/nearest/{count}/{sourceType}/to/{latitude}/{longitude}/within/{miles}
or
/nearest/{count}/{sourceType}/to/{latitude_longitude}/within/{miles}

The format of the lat/long could either be as separate parameters or perhaps it needs to be in a single parameter formatted like (32.947560, -96.839760) if the route parser can't disambiguate between other route paths.

It'd be nice to have a container definition to build and deploy.

We need a basic admin UI to minimally see an activity log and very basic dashboard of metrics.

Allow USPS addresses to be used as input to the API via the location parameter:

/nearest/{count}/{sourceType}/to/{location}[/within/{distance}/{units}]

This will require live support for Geocodio's API. Other Address-to-LL APIs worth looking at are PositionStack and Geocodeapi.

https://www.geocod.io/pricing/
https://positionstack.com/product
https://geocodeapi.com/#pricingSection

The data import script could feasibly be updated to include geocoding using the same service.