CENTERLINES DOCUMENTATION

Transcription

1 CENTERLINES DOCUMENTATION (Updated: 1/11/2005) Q:\Documentation\Centerlines\Centerlines_Documentation.doc

2 TABLE OF CONTENTS PAGE SOURCES 4 BACKGROUND Known GDT data source issues 4 Phase 1 (Consultant Improvements) 5 Phase 2 (GIS Team Improvements) 6 When should a street be included in centerlines model? 7-8 FEATURE DEFINITIONS Traveled Way - Road feature 9 Road Bed - Carriageway feature 10 ROAD & CARRIAGEWAY ILLUSTRATIONS LEGEND 11 ROAD & CARRIAGEWAY RELATIONSHIP ROADID 12 INTERIOR CARRIAGEWAYS CARRIAGEWAYID 16 STREET INTERSECTION STANDARDS Single Carriageway crosses Single Carriageway 17 Double Carriageway crosses Double Carriageway 18 Double Carriageway crosses Single Carriageway 19 Single Carriageway meets/terminates at Double Carriageway 20 Single Carriageway meets/terminates at Divided Double Carriageway 21 Double Carriageway meets/terminates at Double Carriageway 22 Double Carriage way crosses Single Carriageway and becomes a Single Carriageway 23 Double Carriage way crosses Double Carriageway and becomes a Single Carriageway 24 Double Carriageway becomes a Single Carriageway w/out Street intersection 25 Complicated Intersections (& samples) Overpasses/Underpasses 29 CUL-DE-SACS 30 2

3 ADDRESSING Introduction 31 Real Address Ranges 32 Theoretical Address Ranges 33 Padded Address Ranges 34 Segmentation of Address Ranges 35 UNETRANS MODEL ATTRIBUTE FIELDS TBD TBD 3

4 SOURCE(s): The following data sources were used in the compilation of the City of Richmond s Centerlines model, and subsequently in support of the development of our UNETRANS GIS Transportation Model. Geographic Data Technology - GDT Centerlines Central Address GIS Parcels GIS Orthophotography (1999 & VGIN source) GIS Base mapping BACKGROUND: (2001) City of Richmond did not have a centerlines product suitable for geocoding requirements of the 911 Center s MapStar application. At the time, our centerlines layer had been compiled by the consultant, but it was more for cartographic representation, as addressing of centerlines was not performed. Prior to the MapStar project, any geocoding analysis was done with the use of Bureau of the Census TIGER files. TIGER files have suspect quality in terms of both street naming/addressing and spatial accuracies; we required something more accurate. Alternative centerlines were sought. (Note: Coincidentally, the Automated Traffic Ordinance and Regulations System also required a better GIS centerlines source. The GDT product was used by DIT for this project as well. A unique ID field was created and assigned to each segments to support the ATORS project. Dealing with this unique ID field would be problematic for future centerlines improvements.) The City of Richmond s next centerlines product was obtained from Tele Atlas (formerly known as Geographic Data Technology (GDT)) in the Fall of 2002, as part of the Community Update Partner Agreement. This agreement essentially stipulated that GDT provided their Richmond metro area centerlines data set to the city free of charge, and that we would subsequently provide back to GDT any improvements we made to the centerlines. GDT had a higher quality product than did the Bureau of the Census and it met the specifications of Plant Equipment, Inc., the maker of MapStar. This did not mean, however, that the GIS Team was satisfied with either the naming/addressing, or spatial accuracy of these centerlines, particularly given the anticipated requirements of future projects such as the development of a GIS Transportation Model and Work Order Management System. The GIS Team contracted to have these original GDT centerlines improved. 4

5 Known GDT Centerlines Issues: Street Naming Addressing (ranges & odd-even sides of the street) Topological errors (improperly or inconsistently split, un-split, unconnected, connected are segments) Non-standardized from-to arc directionality Lack of alleys Inconsistently modeled single-double lined roads PHASE I ( ): The Louis Berger Group, Inc., as part of the City s Staff Augmentation Contract, was contracted from the Winter of 2003 until the Spring of 2004 to make the following improvements to GDT source centerlines: (Note: The City did not contract Berger to deal with addressing issues, other than conflating existing ranges from existing GDT arcs to newly created arcs; address ranges were saved to be corrected by in-house staff following Berger s work.) Using the City s GIS data sources and orthophotography, including the use of available Virginia Geographic Information Network (VGIN) 2002 orthophotography, all arcs were adjusted to be spatially accurate with our base mapping. Arcs which were unnecessarily split, such as between two intersections, were combined into a new single arc. Arcs which required a split due to another arc s intersecting it was corrected by splitting such arcs. Addresses were conflated from the original arc segments and reassigned to the new single arc for merges, or addressing was divided as a percentage of the arc length and reassigned to new segments resulting from a split. ATORS IDs were tracked and recorded based upon the type of correction that Berger made to the arc segments, for the purpose of being able to update and change those unique assignments in the ATORS system. ATORS IDs could be eliminated via arc merging, or new ones created via splits, or model changes as described below. (Note: There is another document which describes the ATORS methodology in more detail) Arc segments that were not connected, were topologically fixed to have proper connectivity. Intersection designs were standardized per GIS Team definitions. Arc segment from-to directionality was standardized according to methods prescribed by both the Virginia Department of Transportation (VDOT) and the UNETRANS model. South to North, West to East from-to directionality was created as our standard. The existing City GIS Centerlines, which were interpreted from the orthophotography during the original implementation phase of developing our base mapping included alleys. Berger inserted alleys into the updated centerlines. Alleys were snapped to the main road arcs to ensure connectivity, but a break/node was not made and a complex edge was maintained for roadways. (Note: Because of the complex nature 5

6 of our planned transportation model, the task of splitting these roads, reconnecting alleys, and fixing address ranges was reserved for the GIS Team to do in-house) GDT centerlines were modeled with a mix of single line and double line representations. The supposed method was: roads that were physically divided by median or structures would have a separate arc modeling each side of the road. If a road was not divided, then a single line modeled such streets. It was apparent from the orthophotography that GDT was inconsistent in the application of such rules. The GIS Team created a flag of arc segments (from orthophotography and field investigations) that were in error and Berger updated the modeling of roads. ATORS IDs were newly created or existing ones eliminated depending upon the modeling change and these were additionally tracked in the prior manner. PHASE II ( ): Upon completion of the contracted work in Phase I, the GIS Team performed the following modifications, toward supporting the final desired UNETRANS GIS transportation model: The end result of Phase II was the establishment of 2 representations of the City s street system; ROADS versus CARRIAGEWAYS. (Roads are defined on page 7, while Carriageways will be defined on page 8) Roads (single line street representation) were created Unique RoadIDs were created and assigned to one or more related carriageway arcs that correspond to a Road. Carriageways (single-double line street representations) were created Street Directions, Names, and Types were reviewed and corrected, per Central Address standards. In cases of divided streets, a suffix value, indicating direction of travel, was assigned for the purpose of differentiating between the two sides of the street. Odd-Even side addressing (Address Parity) of arcs were reviewed and corrected Address ranges were reviewed, corrected, or reassigned a true range Previously modeled complex street edges were split at alley intersections and alleys were incorporated and address adjusted per new arc segmentation Geometry was reviewed and spatial accuracies were improved once again. Intersection Standardization was reviewed and applied. Topology of both Roads and Carriageways was reviewed, improved, or established Inclusion of missing centerlines Exclusion of inappropriate centerlines 6

7 When should a street exist in centerlines model? Many issues came to light upon review of the source GDT data. The source data sometimes included a centerline feature for parking lot areas. At other times, the source data contradictorily excluded centerline features in parking lots. It was apparent that rules needed to be defined for the inclusion or exclusion of centerline features, and that a priority or weight of importance could be assigned to the inclusion of certain features. Rules: If a parking lot (typical of a location such as an apartment multi-family residential area) is actually assigned a street name, then a feature should be included. In the illustration below, Windsor Ct, Lake Terrace Ct, and Lake Shire Ct, are all parking lot areas and they serve as streets. Thus, they are included in the centerlines. However, these parking lot areas are private property and will therefore not participate in the referencing of City assets. 7

8 If a complex has addressing that is tied to or based upon a main City street and not to parking lot areas, then those arcs should not be included in the centerlines. In the illustration below, both complexes a. and b. have property addresses for Jennie Scher Road. Therefore, the parking lots features do not require centerlines. (In this area, it is truly only critical for Jennie Scher Road to be included for Asset and Work Order Management) a. b. Our Main Priority: It is most critical that centerlines falling within the public right-of-way are captured and included for supporting the Asset and Work Order Management programs. This is because private roads (typical of residential parking lot streets) will not be used to locate City assets nor used to track scheduled work, labor, time, or materials in the maintenance of City assets. Every attempt has been made to include streets that appear in Orthophotos, base mapping, or Central Address. 8

9 FEATURE DEFINITIONS: Traveled Way Land that is dedicated to vehicular transportation. Edges of the Traveled Way generally correspond to the base map Road Edge sub-type in the City s GIS. Edges may also be interpreted from orthophotography. However, base map features always take priority over imagery where there are positional discrepancies. Generally excludes acceleration lanes, deceleration lanes, and turn lanes that lie on the outside edges of the right-of-way. Medians and interior lanes of all types are included. Critical in the definition of Road feature type. ROAD A linear feature positioned along the center of the Traveled Way between two at-grade intersections. (It is always a single line representation, even when a divided road is present, such as with a median) Notes: Must only touch other Roads at their endpoints (nodes) unless the intersection is a bridge or tunnel. May be split to accommodate attribute changes (such as street name or address range). Generally follow the center of the median along divided roads. This may not always be the exact center of the traveled way, but it presents a neat appearance. Do not model traversability. Intersections of Road features will sometimes lie inside a median. Provide edges for many polygon feature classes. Relate to one or more Carriageways. Will be used for linear referencing in the City s work order management system. 9

10 Road Bed May be part of all of the Traveled Way. Streets that are divided by a median have two or more road beds. Streets that are not divided by a median have exactly one road bet that corresponds to the Traveled Way. Critical in the definition of Carriageway feature type. CARRIAGEWAY A linear feature positioned along the center of the Road Bed between two at-grade intersections. (When a street is physically divide by a median or structure, then the centerlines appear as double-line.) Notes: Divided roads typically have at least two parallel Carriageways between each intersection: one for each road bed. Model the actual traversability experienced by a moving vehicle. Must only other Carriageways at their endpoints unless an intersection is a bridge or tunnel. Must be split where Carriageway features intersect Road endpoints. May be split to accommodate attribute changes. Relate to Road features via the ROADID. Either one or many Carriageways must relate to a single Road. Plan to be used for routing analysis in the City s transportation model. Common Characteristics Between Roads & Carriageways: All features are digitized from South to North and West to East, in accordance with VDOT convention. Road and Carriageway features should have identical geometry along un-divided streets. Features are permitted to deviate slightly from the center of the road bed in order to avoid crossing parcel boundaries. This happens most frequently along alleys. 10

11 ROAD & CARRIAGEWAY ILLUSTRATIONS LEGEND In all of the following illustrations, you should note the following: Thicker dull lines represent ROADS Sharp contrasting dashed lines represent CARRIAGEWAYS Both Roads and Carriageways have arrows indicating from-to arc directionality

12 ROAD & CARRIAGEWAY RELATIONSHIP ( ROADID ): In the example below, a median is present. Therefore you have two Carriageway features following the Road Bed on either side of the street, and you have a single line representation that is running down the middle of the general Road Bed (Traveled Way). Every Road feature is assigned a unique value, called the ROADID. You can see the unique ROADID assigned to the Road feature is The Carriageway features are also assigned the ROADID value for which Road feature they correspond to. ROADID ties both feature classes together in order that a single street and address data table(s) can be maintained in one place, but related to features via the ROADID value. 12

13 INTERIOR CARRIAGEWAYS: Intersections involving divided streets will result in what are called Interior Carriageway features. In this example, there are 4 features in the ROAD features, while there are 8 features in the CARRIAGEWAY features. The intersection requires two Interior Carriageway features because the Carriageway also intersects a Road endpoint. You can see one Interior feature relates to the Road feature with ROADID = 72705, while the other relates to another Road feature with ROADID = A single Road feature segment, but two Carriageway arc segments 13

14 Interior Carriageway features will never carry any address information. a i. b. c. d j. h. e. g. f. Notes: At the intersection of W Broad St and N Belvidere St & Mundord St, note that there are exists 10 Interior Carriageway features, labeled a. through j. Address labels are turned on in the illustration. There are no addresses for these Interior Carriageway features. 14

15 Another Example of Interior Carriageways: Eight Interior Carriageway arc segments exist when two double-lined streets intersect. Observe how each of the four Road ROADIDs are related to two corresponding Interior Carriageway features. You can follow the arrows that point to highlight the ROADID relationship from Roads to Interior Carriageways. 15

16 CARRIAGEWAYID: A unique value also exists for each Carriageway feature, in order for each of these segments to be uniquely identified. These unique values are called the CARRIAGEWAY ID. Notes: Each Carriageway feature has the CarriagewayID labeled. They are all unique, including the Interior Carriageway features. 16

17 The next section describes the standardization of modeling intersections that was employed by the GIS Team during Phase II of centerlines improvements. STREET INTERSECTION STANDARDS: Single Carriageway (and Road) crosses Single Carriageway (and Road) Notes: 4 Road features Identical 4 Carriageway features All features will have address ranges associated 17

18 Double Carriageway crosses Double Carriageway Notes: 4 Road features follow the general Traveled Way and meet at central point in middle of the intersection. Carriageway features cross through intersection along divided Road Beds. These Interior Carriageways are divided into two different features when a Road feature is encountered. 18

19 Double Carriageway crosses Single Carriageway (and Road) Notes: There are 4 Road features, meeting at a point in the middle of the intersection. There are 8 Carriageway features. o See the sharp, smaller black arrow heads of carriageway arcs directions; there are two Interior arc segments. (reminder: there will not be any address ranges on the interior feature) o The other six arcs are made from Carriageway arcs that intersect one another. Interior Carriageway features will share ROADID value with corresponding, underlying Road features. 19

20 Single Carriageway (and Road) meets/terminates at Double Carriageway In this scenario, there is no cross-over, but rather an intersecting side street that terminates in the intersection. This illustration shows two cases of this. Notes: In this type of intersection a single Road feature meets at a point between two other Road features which follow the divided street s general Traveled Way. There is a single Carriageway feature that exists between the two divided Carriageway features. (reminder: there will not be any address ranges on the interior feature) 20

21 Single Carriageway (and Road) meets/terminates at Divided Double Carriageway In this scenario, it is apparent that a median prevents vehicle traffic flow to cross over to the far side. a b Notes: There are 3 Road features meeting at the general intersection of these two streets. There is NO Interior Carriageway While the single Carriageway entering from the side doesn t cross the median, the Carriageway on the other side of the median must be split in order to assign relationship to corresponding Road feature s ROADID. a. ROADID relates to divided Carriageway features. b. ROADID relates to divided Carriageway features. 21

22 Double Carriageway meets/terminates at Double Carriageway In this scenario, there is no cross-over, but rather an intersecting double-lined side street that terminates in the intersection of another double-lined street. The relationships of ROADID are also highlighted. a b c Notes: The double-lined street that enters from the side will always connect to a point location on the Carriageway endpoint at the far side of the intersection. There are 3 Road features (see ROADIDs of 64592, 64212, 64341). The solid black lines are pointing to the ROADID relationship that exists between Roads and Carriageways. a. Road feature relates to three Carriageway features. b. Road feature relates to two Interior Carriageway features in the intersection. c. This same Road feature relates to divided Carriageway features. 22

23 Double Carriageway crosses Single Carriageway (and Road) and becomes a Single Carriageway (and Road) Notes: There are 4 Road features. You can see a Road feature following straight through median and also down center of other intersecting streets; a simplified representation of Richmond s streets. There are 2 Interior Carriageway features. The standard in this scenario was to attempt NOT to have both Carriageway sides of the divided road connect to a single point at the intersection. 23

24 Double Carriageway crosses Double Carriageway and becomes a Single Carriageway (and Road) a c b Notes: There are 4 Road features. As on the prior slide, you can see a Road feature following straight through median(s) and also down center of other intersecting streets; a simplified representation of Richmond s streets. a. & b. The double-lined street that enters from the side will intersect with the first encountered Carriageway feature, then converge and connect to a point location (c.) on the Carriageway endpoint at the far side of the intersection. It then continues on as a single Carriageway corresponding with the Road feature. There are 4 Interior Carriageway features, and ROADID values are displayed for your comparison of the relationship to Road features. In such a situation we would attempt NOT to split the Interior Carriageways that correlate to Road feature with ROADID =

25 Double Carriageway becomes a Single Carriageway (and Road) without street intersection. Sometimes a street will have a median divide and then become undivided, without an intersection present. In this case, we standardized the convergence of divided Carriageway features into a single arc. Notes: A single Road feature is modeled down the middle of the Road Bed. The Carriageway becomes divided at the point where a median is encountered. Another Example: Often times a median may be split by a Road feature and the Carriageway is forked. Note the ROADID values of forked Carriageway relate to central Road feature. 25

26 Complicated Intersections Richmond is pockmarked with street intersections which do not match any of the situations described previously. In these cases, the GIS Team sought to have the streets come together to a point, which would be good for modeling Intersection point. The following are just a few examples, and by no means document all of the morphologies that were encountered. These examples merely illustrate the general technique of converging Carriageways (and Roads) to a single intersection point. Example 1 26

27 Example 2 This example illustrates how a median island is handled. Example 3 Here is an interesting intersection where one side of a divided Carriageway is met up with a single Carriageway (and Road) feature. 27

28 Example 4 28

29 Overpasses/Underpasses The following illustration shows orthophotography, railroad lines, and Carriageway features where an arterial street crosses the Downtown Expressway; Road features are not turned on, for the purpose of easing the visual interpretation of the rules applied for overpasses. Notes: The thick highlighted line represents a single selected Carriageway arc feature of the Downtown Expressway, which is passing underneath a bridge. This Carriageway feature does not have any terminating end points with the street features that pass over the bridge, because these features do not truly intersect. NO connectivity exists between Road or Carriageway features which pass over or under one another Road Features w/o Carriageways 29

30 CUL-DE-SACS: Carriageway features should terminate in a loop only if a cul-de-sac contains a nontraversable island in the center. Loops follow the center of the road way: make tear-drops, not lollipops. Node exists here Loops must consist of at least two features so that they can be topologically connected. The nodes connecting these features should be placed at the start fo the loop an don the opposite end. Always create two new features at the start of a loop. This will help: o Inner/outer issue, o Ensure more accurate placement during geo-coding Example 2: 30

31 ADDRESSING: INTRODUCTION In Phase II of Centerlines processing, the GIS Team displayed and reviewed the Central Address values for GIS Parcels: (the image below illustrates how this would have appeared.) Using the Edit Attributes and other out-of-the-box ArcMap Tools, plus some custom tools, developed by our GIS Analyst, the GIS Team members were able to assign and/or correct address ranges of our centerlines. The following pages illustrate our rules and methodologies used for addressing of street centerlines. 31

32 REAL ADDRESS RANGES Every attempt was made to assign an address range that reflected reality, or would result in the best (or more accurate) geocoding results. This means that the upper and lower bounds of the range may be adjusted so that geo-coded addresses will be positioned as close as possible to actual addresses. If property frontage existed for a section of street, then the actual address range was attempted to be assigned. In the example below, this block used to have a range of Left: , and right: You can see that an actual range was determined from interpreting the labeling of Central Addresses by parcels. 32

33 THEORETICAL ADDRESS RANGES Theoretical ranges were used only when there was inadequate parcel frontage to assign an address. If there was not property frontage and we therefore had a lack of Central Address labels for a street section, at least the GDT source data had already assigned a theoretical range. One of our tasks was to review the theoretical address ranges to make sure that they made sense, and to correct any issues encountered. Theoretical ranges follow the Census TIGER model of using hundreds values, e.g ; (in the example below, this 400 block of a street had no real property frontage and/or addressing; a theoretical address range was applied) It was sometimes discovered that addresses used by GDT were simply wrong or odd/even numbers were assigned to the wrong side of the street. These were all fixed based upon interpretation of Central Address and parcel labels (plus general trends and patterns we noted in the addressing of the blocks within a surrounding area). 33

34 PADDED ADDRESS RANGES Occasionally, real address range values were padded with assumed offsetting number values for non-existent parcels. This purposefully ensures that the actual addresses are not stretched over the entire length of the line. An average width of a typical parcel in the block in question was used to estimate the padding of address numbers. (in the example below both sides of the street did not have parcel frontage along the entire length of the street segment, so hypothesized address numbers were used so that, for example, 116 would geocoded about mid way along the north side of the line) No address frontage A second example: 34

35 SEGMENTATION OF ADDRESSES As mentioned previously, the GIS Team incorporated Alleys into the centerlines model. This resulted in the need to segment existing centerlines and to fix address ranges accordingly. This usually resulted in the assignment of a mix of Real ranges, Theoretical ranges, and Padded ranges. Example 1: Actual ranges were assigned for : , while a padded range as assumed on both the remaining high and low address ranges. Recall that attempts were made to use an average width of a typical parcel in the block in question for the padding of address number assignments. 35