| A. METHODOLOGY | Manually traced using 2018 and 2017 EagleView imagery using the CCSF13 Coordinate System by CCSF Department of Technology intern Christina Peck and GIS Coordinator Brian Quinn. Split at the corners using a polygon intersection layer and ArcGIS Pro spatial tools.

| B. FREQUENCY OF UPDATES | TBD. Planning in place to incorporate changes to the curb as they pass through Public Works.

| C. OTHER CRITICAL INFO | The data were developed at DT in a specific way and as a compromise to serve as many department needs as possible.In particular, we extracted complete closed loops of curb edges, and we did that into complex line features where edge segments between two vertices are either a straight line or a circular arc.

So a rectangular block with radiused curb returns has just nine vertices, four straight edges and four circular arc edges as a loop where the start and end vertices are co-incident and snapped together at an identical location.For MTA use, Steph further developed these loop features in useful-to-MTA ways that support curb-related regulation.Depending on whether you use the DT CURB2 features (that can still be found here https://idea.sf.gov/dload/curb/curb_release_20200327.gdb.zip) or the MTA-upgraded versions, some of which have been published at DataSF, the attributes you reference may no longer be associated with the original geometry to which they were assigned.A key value of the closed-loop approach was that each closed loop defined the perimeter of a block defined by the physical curbs---not property lines or other abstractions.So we tended to refer to the lines as curb-block boundaries (CBB) and the polygons they defined as curb blocks (distinct from the parcel aggregates known as Assessor Blocks.)Thus, in the context of curb blocks, we detailed way more small things than census-sized blocks. Some of these may be known to traffic engineers by more precise names than I use or recall, so apologies in advance if I don’t sound very knowledgeable about MTA assets.curb block features were categorized asBLK = typical curb block surrounds and does not touch parcels within, and that gap is typically a sidewalk

ISL = traffic islands that are detailed with the same care, but don’t have parcels within because they’re fully in the right-of-way

NBLK = non-block features are result of CURB features enclosing areas that are neither curb blocks nor traffic islands; sometimes these are sidewalks within park areas because we have curb edges on either side of the sidewalk.I don’t recognize the NODE_LYR designator, although if you sent me the dataset I’d probably have something more to say about it. To help identify curb block polygons in a useful way, several ways of joining them to DPW street centerline network (which think of as a quasi-route, with some route characteristics that I’ve never experienced as a fully routable dataset.) Anyway, the DPW centerline node network (CNN) has street centerline edges and intersection/junction nodes.So depending on what NODE_LYR is exactly (I don’t think it’s simply the node points from DPW centerlines, but those were probably involved) you might have a version of the curb block polygons that are tagged with centerline-related features like:ENDS = the dead end of an alley centerline, for example

GRNISL = this is a traffic island that contains a planter. We evolved our workflow to *not* digitize the inside and outsize of curbs around a planter, just the same outside as digitized at all curbs. So an island-planter is a ‘green’ island and sometimes these get cut with accessibility paths, all fully detailed, that produced some of those NBLK non-block areas.NOCNN = these are curb block features that mostly are those where no street centerline crosses them. Sports field areas, the casting pond in Golden Gate Park, and lots of golf course features are like this.

NTRSCT = street intersection-related features. To help Steph get more useful CURB features, we used some heuristics to estimate intersection areas, and often these were corners of parcels/Assessor Blocks to define the intersection box. These lines helped us split the curb lines into those that could be regulated/painted as a starting point for MTA use

PEDEDG = pedestrian edge, suitable for all the many sidewalks that were digitized into curvy polygons in parks, golf courses, and other places where a paved path is not against a street. (social trails and other non-paved areas were digitized as single-line centerlines and not kept with the curb block boundaries.)PLTFRM = platform, of some type or another that could include piers, which means a lot of developed waterfront edges

STR = street, and if I saw the data I could be more certain, but I think that we’ve got a whole lot of street segments (some with island cut-outs) that run from one intersection polygon to another. It’s not like we used striping to end these, but instead typically the line from one parcel block corner to another. For MTA use, I think these were intended as our best effort to start at delineating curb lengths subject to parking regulations along each curb block boundary.

| D. ATTRIBUTES |

CBB_TYPE: Type of curb feature ('BLK','ISL','NBLK')

NODE_LYR: ('ENDS','GRNISL','NOCNN','NTRSCT','PEDEDG','PLTFRM','STR')

CBB10: