Create NAICS/ Business Licensing Code/ Planning Code Mapping Logic

[lovehandle]

Create mapping logic in the backend in order to create relationships between NAICS codes, Business Licensing Codes, and Planning Codes. Should we expose an endpoint for this as well?

I think using PostgreSQL to create some kind of relationship mapping would suit this task best.

[louh]

I'd like to think this through a little more and write out some clear steps to have in mind for what this looks like.

Right now these are three fairly static data sets:

• NAICS codes. These can draw from NAICS-API or make a copy of the NAICS data.
• Business licensing categories. These do change from time to time. For the moment, I've scraped them in placed them in a flat file JSON so the front end has something to read, but it's already outdated. In the future, are codes manually entered by an administrator user when they are changed? Would there (or should there) be a way to automatically refresh the list of categories from a city source, e.g. a Hansen endpoint?
• Planning zones. Again, this was "scraped" into a flat file JSON for now, but will also change from time to time when the code itself is updated. Zone changes are less rare, but do happen. Same question, though. How are changes picked up?

Between each of these, something needs to determine the relationship between the two. Are mappings manually created by an administrator user? Or is there a way to use secondary data sets to create a "lookup table"?

In my mind, one way to use data and keep the manual data interaction as small as possible is to look at what's currently existing and using it to draw some conclusions. We have a fairly recent data set somewhere (I'll have to find it again) which can actually tell us that most NAICS codes 519210's are classified as an A25 business category (or something like this). I have to think through this a little bit more but I'd like to know what you think of this idea.

[lovehandle]

@louh

1. I think we need to persist all business classification codes into the database (NAICS included). It'll make doing relationship queries between alternative classification codes considerably easier IMO.
2. While storing all classification codes in the database gives us the advantage of managing relationships easier, it makes the process of updating the codes programmatically a little cumbersome. This, in my opinion, isn't the end of the world (for right now), but it's an important consideration for a future version.
3. ^^

Unless the mappings are currently in a machine-readable format, they'll have to be created manually and managed through an admin interface. My understanding is that there's no mapping for planning codes -> NAICS codes. If that's the case, we should figure out a sustainable way for non-technical users within the city to manage the mapping relationships between classification codes.

Regardless, I think you're right - for Vegas, at least, I think we can automate much of the information entry process. For now, though, I think the sanest implementation strategy is to save these classification codes into the database.