Once you have these components, you can create a time zone network attribute. These relationships allow Network Analyst to determine that these streets have a UTC offset of -6 hours from November to March and an offset of -5 from March to November.Īs shown in the graphic, you need a time zones table and a TimeZoneID field on your edge source feature classes before you can configure time zones on the network dataset. The MSTimeZone value then relates the streets to the Central Standard Time key in the registry. In this diagram, streets with a TimeZoneID value of 2 are highlighted and related to the Central Standard Time record in the TimeZones table. (It's more common to see integer values as identifiers and foreign keys however, the registry uses text to identify time zones.) The registry provides information to Network Analyst about the UTC offset and any date ranges for daylight saving time. The MSTimeZone field in the time zone table is also a foreign key, but to an entry in the Windows registry. The TimeZoneID value is a foreign key to a time zone table, which resides in the same workspace as the network dataset and stores a list of time zones. The conceptual diagram below shows a general overview of how this works.Ī TimeZoneID field on the edge source features indicates which time zone the features are in. The ArcGIS Network Analyst extension retrieves the UTC offsets and daylight saving time rules for time zones from the Windows registry. The time zones and their rules are stored in the Windows registry. Fortunately, later versions of Windows operating systems take care of this by delivering any time zone changes in the world to your computer through Windows updates. These rules can change frequently keeping track of all current and past rules is a difficult task. Local rules specify what the UTC offset should be whether or not daylight saving time is observed and, if it is, the offset and date ranges for daylight saving. Time zones have a temporal offset with respect to Coordinated Universal Time (UTC). Alternatively, when time zones are configured on the network dataset, the times you enter are automatically set to the local time of the underlying edge, and Network Analyst handles the time conversions internally. If time zones aren't configured, you would have to manually convert one or both of the time window values to the default time zone. For example, assume you add two stops-one in the eastern time zone and another in the central time zone-and want to set both their time windows to be 8:00 a.m. Irrespective of whether a network dataset that spans multiple time zones is traffic enabled or not, configuring a time zone attribute makes it easier to enter and interpret time-of-day properties-like time windows and arrival or departure times-because their time values always refer to local time. and crosses into another at 8:13 a.m., which is 7:13 a.m. The directions here show that a vehicle starts in one time zone at 8:00 a.m. The accuracy of travel times in a traffic-enabled network dataset is thus maintained. local time and the edge in the central time zone is correctly evaluated for 7:13 a.m. If time zones are configured properly, however, the cost of the edge in the eastern time zone is evaluated for 8:13 a.m. or possibly some other time of the day, depending on what the default time zone is. This means that instead of retrieving the travel time for the edge in the central time zone for 7:13 a.m., it could retrieve the travel time for 8:13 a.m. If a time zone attribute is not configured, the network dataset will ignore the time differential and retrieve the edges' travel times based on only one time zone. a route analysis traverses two adjacent edges, starting from one edge in the eastern time zone and continuing along another in the central time zone. To better understand why it is critical to set up a time zone attribute on a traffic-enabled network dataset that spans multiple time zones, assume that at 8:13 a.m. Why time zones are relevant to network analysis Also, configuring time zones is unnecessary if you never perform network analyses using a time-based impedance with a start time. For example, if a network dataset that doesn't support live traffic falls entirely within a single time zone, you don't need to configure time zones. Configuring a time-zone attribute on a live-traffic enabled network dataset is always required however, it isn't always necessary to configure a time-zone attribute on network datasets that don't support live traffic.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |