Tucson PublicMaps can route a base zone directly toward use and setback provisions while its overlay services preserve names, adoption dates, and originating cases. Treat those paths separately so an overlay’s source record is not mistaken for the base classification. It is not an approval.
Last checked: August 7, 2026.
Begin the base-zone-to-direct-UDC route at Tucson Public Zoning map service, which supplies exact base and overlay schemas. Cross-check the selected geometry through Tucson planning and zoning applications, the route used for case and agency guidance. Before copying ZONE_COT, verify gis.tucsonaz.gov official host and PublicMaps/Zoning service; those markers keep the Tucson PublicMaps tied to the intended jurisdiction and record period.
ZONE_COT is the base route; overlay layers 39-41 and 48 are separate
Tucson's service provides a chain from base zone to code and from overlay to legal history. ZONE_COT stores the City base zone, with examples such as C-1, C-2, and C-3. URL_USE and URL_SETBACKS lead to different UDC questions: allowed uses and use-specific conditions are not the same as setbacks. NAME identifies a mapped overlay or preservation zone, while DT_ADOPTED records its adoption clue and ORG_CASE preserves the originating case. DATASOURCE distinguishes ZONE_COT from ZONE_HPZ, ZONE_NPZ, or ZONE_URBAN records in an export. That provenance is essential because an overlay label must not replace the base zone. Read the base and direct code links first, then attach each named supplemental record to its source family, adoption date, and case. The resulting note remains reproducible even when several features share the same location.
| Returned local record | Record to compare | When to stop | Next decision |
|---|---|---|---|
| ZONE_COT returns C-3; C-1; C-2 | Compare with URL_USE, which links to the district use provisions | Stop the base-zone-to-direct-UDC route if URL_USE is missing, dated differently, or points to another record. | Continue through the Tucson PublicMaps: Open the exact UDC district using the field's URL. Then test whether URL_USE changes that route. |
| URL_USE returns City GIS supplies direct UDC links | Compare with URL_SETBACKS, which links to setback provisions | Stop the base-zone-to-direct-UDC route if URL_SETBACKS is missing, dated differently, or points to another record. | Continue through the Tucson PublicMaps: Reopen the current code and read definitions and use-specific standards. Then test whether URL_SETBACKS changes that route. |
| URL_SETBACKS returns City GIS supplies direct UDC links | Compare with NAME, which names an overlay or preservation zone | Stop the base-zone-to-direct-UDC route if NAME is missing, dated differently, or points to another record. | Continue through the Tucson PublicMaps: Setbacks answer a different question from permitted use. Then test whether NAME changes that route. |
| NAME returns ARMORY PARK; JEFFERSON PARK; MAIN GATE | Compare with DT_ADOPTED, which records the overlay adoption date | Stop the base-zone-to-direct-UDC route if DT_ADOPTED is missing, dated differently, or points to another record. | Continue through the Tucson PublicMaps: Use the exact name to retrieve the overlay case and standards. Then test whether DT_ADOPTED changes that route. |
| DT_ADOPTED returns 1974-12-20 for Armory Park; 2011-06-21 for Jefferson Park | Compare with ORG_CASE, which stores the originating case identifier | Stop the base-zone-to-direct-UDC route if ORG_CASE is missing, dated differently, or points to another record. | Continue through the Tucson PublicMaps: Compare it with later amendments rather than treating it as a refresh date. Then test whether ORG_CASE changes that route. |
| ORG_CASE returns C9-74-19; C9-11-01; C9-12-01 | Compare with DATASOURCE, which identifies the source layer | Stop the base-zone-to-direct-UDC route if DATASOURCE is missing, dated differently, or points to another record. | Continue through the Tucson PublicMaps: Retrieve the case details and any later modification. Then test whether DATASOURCE changes that route. |
| DATASOURCE returns ZONE_COT; ZONE_HPZ; ZONE_NPZ; ZONE_URBAN | Compare with ZONE_COT, which stores the City of Tucson base zone | Stop the base-zone-to-direct-UDC route if ZONE_COT is missing, dated differently, or points to another record. | Continue through the Tucson PublicMaps: Use it to distinguish base and overlay records in exports. Then test whether ZONE_COT changes that route. |
NAME, DT_ADOPTED, ORG_CASE, and DATASOURCE preserve overlay history
The Tucson PublicMaps table keeps each returned label beside its displayed scope and the separate legal record still waiting to be opened. Its first checkpoint is ZONE_COT, which may appear as C-3; C-1; C-2; from there, Open the exact UDC district using the field's URL. A blank in the base-zone-to-direct-UDC route stays visible so another reader can distinguish an empty official return from an unexamined field.
| Local field, layer, or record | What it does | Displayed value or scope | Next code or record check | Official page |
|---|---|---|---|---|
| ZONE_COT field | stores the City of Tucson base zone | C-3; C-1; C-2 | Open the exact UDC district using the field's URL. | Open exact record |
| URL_USE field | links to the district use provisions | City GIS supplies direct UDC links | Reopen the current code and read definitions and use-specific standards. | Open exact record |
| URL_SETBACKS field | links to setback provisions | City GIS supplies direct UDC links | Setbacks answer a different question from permitted use. | Open exact record |
| NAME overlay field | names an overlay or preservation zone | ARMORY PARK; JEFFERSON PARK; MAIN GATE | Use the exact name to retrieve the overlay case and standards. | Open exact record |
| DT_ADOPTED overlay field | records the overlay adoption date | 1974-12-20 for Armory Park; 2011-06-21 for Jefferson Park | Compare it with later amendments rather than treating it as a refresh date. | Open exact record |
| ORG_CASE overlay field | stores the originating case identifier | C9-74-19; C9-11-01; C9-12-01 | Retrieve the case details and any later modification. | Open exact record |
| DATASOURCE field | identifies the source layer | ZONE_COT; ZONE_HPZ; ZONE_NPZ; ZONE_URBAN | Use it to distinguish base and overlay records in exports. | Open exact record |
Navigate from PublicMaps layer 32 to the applicable UDC provision
- Open the Tucson PublicMaps; fix the parcel, boundary, jurisdiction, and official key before reading thematic records.
- Start the base-zone-to-direct-UDC route by copying ZONE_COT exactly as returned, including C-3; C-1; C-2.
- Keep URL_USE in a second Tucson PublicMaps worksheet field because it links to the district use provisions.
- Test URL_SETBACKS independently, then mark its value, service layer, or documented blank in the base-zone-to-direct-UDC route.
- Give NAME and every later item a separate row; never compress history, plans, and overlays into the Tucson PublicMaps result.
- Attach the Tucson PublicMaps lookup time to ZONE_COT, while preserving this separate currency clue: DT_ADOPTED is an overlay legal-history clue, while the service edit date is a data clue; preserve both and check the current UDC link.
- If ZONE_COT and URL_USE conflict, send the base-zone-to-direct-UDC route to Tucson Public Zoning map service and ask which adopted overlay adds a separate code path.
The Tucson PublicMaps worksheet is complete only when another reader can reproduce the base-zone-to-direct-UDC route from the same parcel key and official pages. Keep each source's legal role and effective date apart, then record which adopted overlay adds a separate code path as unresolved instead of selecting the most convenient output. The local currency note remains part of that audit trail: DT_ADOPTED is an overlay legal-history clue, while the service edit date is a data clue; preserve both and check the current UDC link.
An adopted overlay whose source layer is confused with base zoning
A hypothetical Tucson export pairs base-zone value C-3 with a supplemental row named ARMORY PARK, DT_ADOPTED 1974-12-20, ORG_CASE C9-74-19, and a DATASOURCE identifying the overlay family. The reviewer would keep C-3 as ZONE_COT, follow URL_USE for use provisions, and open URL_SETBACKS separately. ARMORY PARK would be logged as a named supplemental record with its displayed adoption and case clues, not rewritten as the base district or a guarantee that no later amendment exists. This is an explicitly hypothetical combination used to demonstrate the fields; it does not claim that a particular parcel carries both records or that the cited case controls today. The example shows why DATASOURCE belongs beside NAME. Without it, an export can hide whether HPZ, NPZ, urban-overlay, or base-zoning geography supplied the row.
DT_ADOPTED and the service edit date describe different events
Tucson, Arizona date check: DT_ADOPTED is an overlay legal-history clue, while the service edit date is a data clue; preserve both and check the current UDC link.
DT_ADOPTED belongs to the legal history of an overlay, whereas a service edit date belongs to data maintenance. Treating the former as the web layer's refresh date can make a decades-old adoption look like stale data; treating a recent edit as adoption can invent a new legal event. URL_USE and URL_SETBACKS also need to be reopened because the current UDC destination may evolve after the map row was created. The link from a Tucson overlay to ORG_CASE does not certify that the original case remains unamended. Save the current query date, preserve DT_ADOPTED, retrieve the originating case, and check for later modifications. Always retain DATASOURCE so a reader can distinguish base, historic-preservation, neighborhood-preservation, and urban-overlay records across different publication clocks.
Repair a broken use or setback route without guessing the standard
| Local situation | What went wrong | What to retain | How to resolve it |
|---|---|---|---|
| Scenario 1 | ZONE_OVERLAY is read without recording which source layer, such as HPZ, NPZ, or urban overlay, supplied the feature. | Preserve URL_SETBACKS, the selected geometry, and both timestamps from the Tucson PublicMaps check. | Use Tucson Public Zoning map service to settle which adopted overlay adds a separate code path; then Setbacks answer a different question from permitted use. |
| Scenario 2 | DT_ADOPTED is mistaken for the date the web service last refreshed. | Preserve NAME, the selected geometry, and both timestamps from the Tucson PublicMaps check. | Use Tucson Public Zoning map service to settle which adopted overlay adds a separate code path; then Use the exact name to retrieve the overlay case and standards. |
If a Tucson note says only 'zoning overlay' without DATASOURCE, the feature cannot be audited. Return to the export and capture NAME, DT_ADOPTED, ORG_CASE, and whether ZONE_HPZ, ZONE_NPZ, or ZONE_URBAN supplied it. Then recover ZONE_COT independently and reopen both URL_USE and URL_SETBACKS. Do not call DT_ADOPTED the service refresh date. When a case or source family is unclear, contact Planning and Development Services with the parcel and feature values. Ask: 'For this parcel, is C-3 the current base ZONE_COT, which exact supplemental source layer supplies the named record, and has originating case C9-74-19 been modified since the displayed adoption date?' This question seeks provenance and amendment history. It does not ask the agency to infer permitted use from an overlay name or a saved UDC link.
PublicMaps, Planning applications, and the UDC divide the evidence
| Official page | What to check there | Local coverage shown |
|---|---|---|
| Tucson Public Zoning map service | exact base and overlay schemas | City-owned GIS host |
| Tucson planning and zoning applications | case and agency guidance | Official city page |
| Tucson Unified Development Code | controlling code | Official codifier linked directly by City GIS fields |
How should ZONE_COT be checked in Tucson, Arizona?
Open the official ZONE_COT record and capture the value inside the Tucson PublicMaps. That record shows how ZONE_COT stores the City of Tucson base zone; one displayed form is C-3; C-1; C-2. Place the copied value in the base-zone-to-direct-UDC route, then follow its separate rule route: Open the exact UDC district using the field's URL.
How should URL_USE be checked in Tucson, Arizona?
Open the official URL_USE record and capture the value inside the Tucson PublicMaps. That record shows how URL_USE links to the district use provisions; one displayed form is City GIS supplies direct UDC links. Place the copied value in the base-zone-to-direct-UDC route, then follow its separate rule route: Reopen the current code and read definitions and use-specific standards.
How should URL_SETBACKS be checked in Tucson, Arizona?
Open the official URL_SETBACKS record and capture the value inside the Tucson PublicMaps. That record shows how URL_SETBACKS links to setback provisions; one displayed form is City GIS supplies direct UDC links. Place the copied value in the base-zone-to-direct-UDC route, then follow its separate rule route: Setbacks answer a different question from permitted use.
The question Tucson staff can answer when an overlay route breaks
- Selected parcel key, geometry, and responsible jurisdiction
- Every returned value from the local field table
- Page titles, URLs, lookup times, and update clues
- Opened code, plan, case, ordinance, or metadata records
- Unresolved blanks, boundary splits, dates, and competing outputs
- Proposed activity stated in code-relevant facts
- Agency contact, narrow question, reply date, and limits
The Tucson PublicMaps does not decide title, survey boundaries, private restrictions, vested rights, building-code compliance, utilities, licensing, or permit issuance. Request a written response when the base-zone-to-direct-UDC route leaves competing official results or when substantial reliance is planned. A useful request to Tucson Public Zoning map service identifies the parcel, quotes ZONE_COT and URL_USE, gives their source dates, and asks which adopted overlay adds a separate code path.
Use tucson zoning map by address, zoning code vs zoning map, zoning overlays special districts only where those methods clarify the base-zone-to-direct-UDC route. The Tucson PublicMaps evidence linked for ZONE_COT and URL_USE remains the local starting point.
Reviewed August 7, 2026. Recheck the Tucson PublicMaps, its cited ordinance, and the agency procedure before relying on the saved worksheet.