ArcGIS REST Services Directory Login
Home > services > Street_Labels_for_Aerial_Imagery (MapServer) > Street Label for Aerial Imagery Help | API Reference
JSON

Layer: Street Label for Aerial Imagery (ID: 1)

Name: Street Label for Aerial Imagery

Display Field: STREET_NAME

Type: Feature Layer

Geometry Type: esriGeometryPolyline

Description: <DIV STYLE="text-align:Left;"><DIV><DIV><P><SPAN>Data Type: Dynamic. Vintage: Current. Editing of street features within ASP is ad-hoc. Such generally occurs on a daily to weekly basis.</SPAN></P><P><SPAN>This street data is maintained in the Address Street Political (ASP) production database by the Business Innovation &amp; Technology Division via the ASP Tools. Source data is the BaseLine feature class, an atomic-level linear dataset which includes street, unnamed road and political line features. Column BL_TYPE has a domain of 'S' (street), 'U' (unnamed road and 'N' (non-street political line) and is used by the ASP DERIVATIVE processing, through tabular selection, to pull the street and unnamed road subsets to distinct features classes whenever geometric or attribute editing occurs. These linear derivatives are then pushed to the spatial data warehouse (SDEWHP) by the ASP To Warehouse (ASP2WH) processing. Here, BLTYPE is obviously 'S' for all features.</SPAN></P><P><SPAN>Original street feature digitization in the early 1990s occurred using 1:4,800 scale ortho-rectified imagery and remnants of that digitation effort remain, where road geometry will appear quite jagged and rough when zoomed to larger scales. Between 2003 and 2011, using the Address Geocode Environment (AGE) toolset, street digitization generally occurred at higher resolutions, where1:1,000 was the desired scale. Since 2012, when ASP and the ASP Tools went live, efforts have been made to consistently digitize new street features, and fix old, at a 1:500 scale. Due to the offset in the 2022 ortho-imagery relevant the 2020 through 2012 image data, streets seen in 2020 or prior imagery will generally match to that data, where only streets new to the 2022 imagery will be aligned to such. </SPAN></P><P><SPAN>Column BLUID (BaseLine Unique Identifier) is the unique BaseLine feature key maintained by the ASP Tools, which is independant and not-to-be confused with Esri's OBJECTID. Column BLUID is used in all ASP bridge tables where many-to-many street-related correspondences are managed.</SPAN></P><P><SPAN>Columns BL_LBPUID (Left BPUID) and BL_RBPUID (Right BPUID) refer to the associated coincident BasePoly polgonal feature associated with the respective side of the street. Cul-de-sacs and dead-end roads, where one endpoint of the road has no connectivity to another BaseLine feature, will obviously carry the same value for BL_LBPUID and BL_RBPUID. Note BasePoly features carry political or jurisdictional attributes, and the relation of an adddress to the side of a street to which it matches and the political polygon associated with that side of the street feature is how all political attributes are tied to address point features- with the exception of special districts (tax authorities). The latter are the only political component attached to addresses via point-in-poly spatial overlay.</SPAN></P><P><SPAN>Columns STREET_LLO (left low), STREET_LHI (left high), STREET_RLO (right low) and STREET_RHI (right high) refer to the left- and right-side address range attributes attached to a street feature. Addressible street features carry non-zero values in these columns. </SPAN><SPAN STYLE="font-style:italic;">Note feature directionality always corresponds with address-range attribution: </SPAN><SPAN>low values are associated with the feature's from-node and high values with the to-node.</SPAN></P><P><SPAN>Columns STREET_LADDRESSABLE and STREET_RADDRESSABLE are flags indicating whether the side of the street is addressable, where the domain is 'Y' (yes) or null (no).</SPAN></P><P><SPAN>Columns STREET_LZIP and STREET_RZIP refer to the left- and right zip codes associated with the street feature. </SPAN></P><P><SPAN>Columns STREET_DIRECTION_PREFIX (street direction prefix), STREET_NAME (street name), STREET_TYPE (street type) and STREET_DIRECTION_SUFFIX (street direction suffix) form the individual components of the full street name (column STREET_NAME_FULL). Note column STREET_NAME may not be null whereas the other individual components may. Columns STREET_DIRECTION_PREFIX, STREET_TYPE and STREET_DIRECTION_SUFFIX all utilize appropriate domain tables for data entry. Table "StreetNameFull" carries the domain of all distinct (unique) street name full combinations, while table "StreetName" carries the domain of all distinct column STREET_NAME values. Both of these tables are available in SDEWHP.</SPAN></P><P><SPAN>Column STREET_ALIAS (street alias) is a "flag" which is 'Y' where the street feature is an aliased street and null otherwise. By aliased, we mean multiple street names are attached to the feature where the primary name (generally what is signed) is shown in column STREET_NAME_FULL. The many-to-many correspondence of street features to street names is managed through the "StreetAndName" bridge table, which contains all street feature (BLUID) and street name full unique identifier (SNFUID) combinations. Table StreetAndName column STRNAMPRIORITY is used to manage which street name is primary, where a '1' indicates the signed street name and '2' the secondary name. Note the "StreetToStreetName" and "StreetNameToStreet" relationship classes (RCs) exist in SDEWHP so that when the "Street" feature class is added to an MXD, identify operations will return the multiple street names when such exist. To find all aliased streets through a tabular join, use the syntax per the following SQL:</SPAN></P><P STYLE="text-indent:20;"><SPAN>SELECT bluid, c.street_name_full, strnampriority FROM street a, streetandname b, streetnamefull c WHERE a.bluid = b.bluid AND b.snfuid = c.snfuid AND street_alias = 'Y' ORDER BY c.street_name_full, bluid, strnampriority</SPAN></P><P><SPAN>Column STREET_GRID_NAME contains a code for how the street was named and addressed. For most street features, the code will be either 'DMAG' (Denver Metropolitan Addressing Grid) or 'JCAG' (Jefferson County Addressing Grid), where the latter is the County's extention to DMAG. The City of Golden (GOLDEN) is an exceptiopn, where most city streets were named and addressed based on Golden's grid. However, there are three areas within the City of Golden's municipal extents where no grid (GOLDNG) was employed. Another prominent exception is the Ken caryl Ranch Plains (KCRP) subdivision, which was granted an exemption from County addressing standards. Column STREET_GRID_KEY contains the numeric JAGUID key from the feature class JefffersonCountyAddressingGrid where such are associated with features from the Denver (DMAG) standards.</SPAN></P><P><SPAN>Coulmns STREET_BUILT (street built) and STREET_PAVED (street paved) are "flags" which are 'Y' where true and null otherwise.</SPAN></P><P><SPAN>Column STREET_CLASS (street classification) is a three-digit code with this domain: '010' (freeway), '020' (parkway), '030' (principal arterial), '040' (minor arterial), '050' (principal collector), '060' (collector), '070' (local residential street). ASP street classifications are periodically reviewed relative the County's Major Thoroughfare Plan (per Highways &amp; Transportation).</SPAN></P><P><SPAN>Column STREET_SPEED_CAD contains a two-to-three digit value associated with street classification (STREET_CLASS) and maintained solely for Sheriff Computer Aided Dispatch (CAD) purposes. Column STREET_SPEED_LIMIT contain a two digit value representing the posted speed limit. The default value for a feature derived from the STREET_SPEED_LIMIT associated with the street classification (STREET_CLASS) but may be adjusted up-or-down in 5 mile-per-hour increments to reflect actual posted speed limits. </SPAN><SPAN STYLE="font-style:italic;">Note column STREET_SPEED_LIMIT was initially assogned based on defaults for street classificaitons; no effort has been made to correct. Over time, these values will be adjusted using both Cartegraph road maintenance information and actual observation. </SPAN></P><P><SPAN>Column STREET_TRAVEL_DIRECTION is a two-character code for how travel occurs on a street segment. </SPAN><SPAN STYLE="font-style:italic;">Note travel directionality, on one-way segments, often differs from feature directionality (orientation of a feature in terms of from- and to-nodes) where feature directionality is always based on addressing and the associated addressing grid. </SPAN><SPAN>Column STREET_TRAVEL_DIRECTION contains this domain: 'BI' (bi-directional, two-way travel), 'FT' (one way travel, from feature from-node to to-node), 'TF' (one way travel, from to-node to from node), and 'NT' (no travel allowed).</SPAN></P><P><SPAN>Columns STREET_ZLEVEL_FROM and STREET_ZLEVEL_TO are one-digit codes used to manage feature connectivity in the database relative real-world road connectivity. As an example, in the database the street features for I-70 and WARD RD show connectivity whereas in the real world Ward Road is at ground level and I-70 is an overpass- one may not directly turn left- or right from one to the other. The domain of values are '0' (underpass), '1' (ground level) and '2' and '3' for overpass conditions, where '1' is the norm for the from- and to-nodes (endpoints) of most street features. These columns consequently help manage where turns may or may not occur and are of great value in general routing operations and in dispatch. </SPAN></P><P><SPAN>Columns LCOUNTYCODE, LCOUNTYNAME and RCOUNTYCODE, RCOUNTYNAME refer to the respective left- and right three digit Colorado county code and its associated county name. These columns do not exist in the source 'BaseLine' feature class in ASP but are appended and populated by the nightly ASP DERIVATIVE processing whenever editing has occurred. The county code is populated on the basis of left- or right- BPUID for the street segment. Given some street features on the county boundary, or extending out-of-county, have no associated BasePoly feature then LBPUID or RBPUID must be null. Consequently, in these cases, the LCOUNTYCODE or RCOUNTYCODE is null, and the associated LCOUNTYNAME or RCOUNTYNAME is designated as 'OUT OF COUNTY' rather than carrying the actual county name.</SPAN></P><P><SPAN>This data may be filtered using definition queries:</SPAN></P><P STYLE="text-indent:20;"><SPAN>Jefferson County streets: LCOUNTYNAME = 'JEFFERSON' or RCOUNTYNAME = 'JEFFERSON'</SPAN></P><P STYLE="text-indent:20;"><SPAN>Out of County streets: LCOUNTYNAME &lt;&gt; 'JEFFERSON' and RCOUNTYNAME &lt;&gt; 'JEFFERSON'</SPAN></P><P><SPAN>Additional information concerning ASP street data is available on Sheet 2 of the ASP schema (here via Livelink): </SPAN><A href="file://admin.co.jeffco.us/admin/Share/GIS/MetaData/ASP/AddressStreetPolitical_GDB_Schema_Phase4_Visio2002_20170201.pdf"><SPAN STYLE="font-weight:bold;">Address, Street and Political (ASP)- Physical Geodatabase (GDB) Schema</SPAN></A><SPAN /><SPAN STYLE="font-style:italic;">(Six 44"x34" pages, 676 Kb, PDF)</SPAN></P><P><SPAN>Where known, gates, check points, bollards or other structures which constrict traffic on a street exist as point features in the RoadGate feature class, where such 'snap' to, or are coincident with, a vertex on the associated street. </SPAN></P><P><SPAN><SPAN>Data is in State Plane Grid Coordinates, Colorado Central Zone, NAD83 (US feet). </SPAN></SPAN></P><P><SPAN /></P></DIV></DIV></DIV>

Service Item Id: a98e7ede144b427a9c75c504fda0e096

Copyright Text: Credit the GIS Team in Jefferson County's Business Innovation & Technology Division in any use of this data.

Default Visibility: true

MaxRecordCount: 2000

Supported Query Formats: JSON, geoJSON, PBF

Min Scale: 0.0

Max Scale: 0.0

Supports Advanced Queries: true

Supports Statistics: true

Has Labels: true

Can Modify Layer: true

Can Scale Symbols: false

Use Standardized Queries: true

Extent:
Drawing Info: Advanced Query Capabilities:
HasZ: false

HasM: false

Has Attachments: false

HTML Popup Type: esriServerHTMLPopupTypeAsHTMLText

Type ID Field: null

Fields:
Supported Operations:   Generate Renderer   Return Updates

  Iteminfo   Thumbnail   Metadata