Tree Services Database Updated: 13,238 Selected U.S. Locations

The Tree Services Database has a new release. Build #163, version 2.0.0, contains 13,238 selected U.S. tree-service business places across all 50 states. The packages share a locations table keyed by location_id. Publication adds published business contacts, while Master adds source traceability and a small, labeled historical reference layer.

What is in the October 13 release

The base locations table contains 13,238 selected business-place rows, with released names, addresses, coordinates, categories, and status fields. These are records in this product, not a count of every tree-service business in the United States. Coverage of all 50 states does not certify that every business is represented or still operates at its recorded address.

The contacts table contains 23,420 published phone and website rows associated with the selected places. A place can have more than one contact row, so that count is not a second count of businesses. A published phone number or website may be useful for research and matching, but it does not establish that the contact still works or grants permission for marketing outreach.

Master adds source_lineage, with 13,238 rows, and historical_facts, with four labeled reference rows in this build. Older Oddity information appears only where it could be confidently matched to the selected current population. It remains historical context, not a claim of fresh verification. Unmatched older listings were kept out of the customer release.

Choose the package that fits the work

Usage: Tree Service Locations

Usage contains the base locations table. It is a practical starting point for a directory, map, territory analysis, or comparison against an existing place list. Names and addresses can change, so retain the supplied identifier when matching places or joining later fields. Review the public sample and field descriptions before treating a category or status value as a current business claim.

Publication: Tree Service Contacts

Publication includes locations and the published business-contact table. Join contacts.location_id to locations.location_id to display available phone and website entries beside a selected place. Preserve the one-to-many relationship: flattening the contact rows without care can duplicate a location in a count or search result. Give users a way to understand that a published contact can become stale.

Master: Complete Tree Service Directory

Master includes the lower-tier tables plus source traceability and labeled historical context. source_lineage helps an internal workflow inspect the source path of a released place. The four historical_facts rows should retain their historical label if they are displayed in an application. This tier fits projects that need to inspect how a selected place relates to source and prior-release evidence.

Working with the joined data

Start with one row in locations and use location_id to retrieve associated rows available in your tier. A directory detail page can show a place name and mapped address, followed by published contact entries. A data-review view can add source lineage. Keep these layers distinguishable: a selected place, a published contact, and a historical reference have different meanings and freshness.

For a regional planning project, filter locations to a state, plot the released coordinates, and compare them with your service territory. Add Publication's contacts if the project needs published business details. Add Master's files if it needs source tracing or matched older context. Count distinct locations when reporting business places, not the joined contact rows.

A coordinate identifies the position supplied in this release, not a guarantee of an active storefront or service area. Tree-service companies may work across multiple communities from one recorded place. Conversely, one business can have more than one place. Recheck any fact that must be current before using it for routing, eligibility, or direct contact.

Scope and responsible use

This is a dated selection built from documented current-source evidence and matched Oddity-owned legacy context. It is not a live census or certification of every arborist and tree-care company. Categories, addresses, phones, websites, and operational status can change after the source snapshot. Published contact data is not proof of consent for email, calls, or other outreach; a contact workflow needs its own current verification, permissions, preferences, and suppression checks.

The release provides CSV, JSON, and SQLite formats with schemas, samples, statistics, and documentation. Inspect the public sample and field dictionary for exact column names and value treatment before choosing a package or building a production import. The product page shows current tier details, prices, and the applicable license.

Reading the fields before you publish

A useful directory makes the source fields understandable without overstating them. Put a business-place name beside its address and map position, and label any published contact as a contact supplied by the released source. If a record has multiple phone or website entries, show them as separate entries or apply a documented selection rule. Do not silently choose one and imply that it is the only current contact. When a field is blank, display that as unavailable information instead of turning the absence into a negative claim about the business.

It also helps to distinguish a place from the company operating it. The release is organized around selected business places, so two rows can describe different locations associated with one wider business. A user who wants a count of distinct companies would need a separate matching method and should state its assumptions. The 13,238 headline is the number of selected location rows in build #163. The 23,420 figure is the number of published contact rows, not the number of independently verified phone numbers or websites.

Sample workflow for an application

Consider a service-area research tool. Import the Usage table, keep location_id as an identifier, and index the state and coordinate fields used for map and filter views. A user can browse the selected places in a target state and open a detail record. If the product later adds Publication, join contact rows by location ID and display them in a separate contact area. If the project adds Master, put source lineage and historical references behind a clearly labeled context view. This progression keeps the base result stable while making added detail visible.

Before presenting a filtered count, decide whether it represents locations, contact rows, or locations with at least one published contact. Those are three different measures. A query that joins contacts and then counts all rows will overstate the number of places whenever a place has multiple contacts. Count distinct location_id values for the location measure, and explain the filter and date used. For a public map, add a note that a point represents a released business-place position rather than a guaranteed operating address or the full service territory of a company.

Keeping the release usable over time

Store the version and build number alongside any imported copy so a later update can be compared accurately. Keep source fields and local edits separate. For example, if a team verifies a new phone number after import, retain that verification date and provenance in its own operational record instead of silently rewriting what build #163 supplied. The same applies to an address correction or a note that a place has closed. That separation makes future refreshes and customer support easier.

Use the samples to test actual joins and field parsing before importing the full files. CSV and JSON can differ in how an application treats blanks, identifiers, and numeric-looking strings, so inspect the schema and the resulting types. SQLite can provide a quick way to run a representative join and check whether counts match expectations. If a project needs more current verification, a narrower geography, or a different category definition, treat that as a separate research requirement rather than assuming the release answers it automatically.

This announcement describes the October 13, 2026 release. Specific records and real-world conditions may change after that date.