AIM ATCO-CIF Format

Using ATCO-CIF for AIM Data Transfer

Action Information Management Ltd Maps In Action® Version 15 – September 2005

ACTION INFORMATION MANAGEMENT LTD 129 Devizes Road, Hilperton, Trowbridge Wiltshire BA14 7SZ Tel: +44 (0)1225 711200 Fax: +44 (0)1225 711222

Document information Document ID

609

Version

15

Version date

27/04/2005

Created by

Tim Rigley [email protected]

Software version Notes Filename

Atco-cif_formats.doc

Date & time printed

17/06/2004 10:42

Total number of pages

35

2

© 2004 Action Information Management Ltd

Contents Background

5

Permitted Deviations

5

File Naming / Separation

5

Data Update

5

Terminology & General Rules

6

Record of Changes Changes made in version 7 Changes made in version 8 Changes made in version 9 Changes made in version 10 Changes made in version 11 Changes made in version 12 Changes made in version 13 Changes made in version 14 Changes made in version 15

7 7 7 7 7 7 7 7 7 8

OVERALL FILE LAYOUT

9

STANDARD RECORD FORMATS

11

PROPRIETARY RECORD FORMATS Term Date Definition record Timetable Group Definition record Timetable Stop List record Timetable Date record Note record Service Details record Timetable Row List Entries Journey Additional Details record Event Additional Details record

12 12 12 12 13 13 13 13 14 15

APPENDIX 1 – GEOGRAPHICAL DATA

16

Timetable Software Not Supporting Geographical Data

16

Timetable Software Supporting Geographical Stop Data

16

Timetable Software Supporting Full Geographical Data

17

Track Data File Layout

18

Proprietary Record Formats Additional Stop Data record

18 18

AIM ATCO-CIF – August 2005

3

Stop Road Names record Track Definition Track Element Geographical Link Geographical Link Element Geographical Link Element Additional Information Geographical Link Element Road Information Geographical Link Point Alternative Geographical Link Point Destination

19 19 20 21 21 21 21 22 22 22

APPENDIX 2 – STANDARD RECORD FORMATS File Header record Journey Header record Journey Date Running record Journey Note record Origin record Intermediate record Destination record Location record Additional Location Information record Alternative Location record Operator Record 1 Operator Record 2 Route Association Record Journey Association Record

23 23 24 24 24 25 25 26 26 26 26 27 27 27 28

APPENDIX 3 – REGISTRATION DATA

29

Registration Data File Layout

29

Proprietary Record Formats Route Registration record Operator Name / Phone Number Record Operator Trading Name Record Operator's Address 1 Record Licence & Registration Numbers Record Licence & Registration Numbers Record Traffic Areas Record Summary of Changes part 1 Record Summary of Changes part 2 Record Subsidy Details Record

30 30 30 30 30 30 31 31 31 31 31

APPENDIX 4 – FARES DATA

4

32

Fares Data File Layout

32

Fare Record Formats

33

© 2004 Action Information Management Ltd

Background The ATCO-CIF format is a loose standard, which can be used for a variety of purposes, and is based around the concept of Journeys. The AIM PTI data model is based around the concept of timetables, as perceived by the general public. Some implementations of the ATCO-CIF format do not contain sufficient information to guarantee the correct construction of such timetables. This document describes a specific implementation, with proprietary extensions and rules for ordering of data, that allows this information to be determined.

Permitted Deviations Where an existing ATCO-CIF implementation contains sufficient data (as defined below) to construct timetables correctly, this format may be acceptable, subject to confirmation from Action Information Management.

File Naming / Separation All files will have the .cif file extension. Individual timetables/services may be supplied in separate files or in one large file. Where they are supplied in one file, this may also contain the details of locations and operators. Alternatively, this information may be supplied in a separate reference file. Where timetables/services are supplied in separate files, then a distinct reference file of locations and operators is still preferred. Where geographical data is being supplied (see Appendix 1), this may be included in the reference file, as a separate geographical data file, or within the relevant timetable files. Supplying individual timetables in separate files is the preferred method, except for route registrations where all timetables pertaining to a registration should be in the same file.

Data Update The AIM database is updated by replacement of source files (i.e. ATCO-CIF files, as specified in this document). Updates fall into one of three categories. Corrections, where the original data was inaccurate and should be updated as soon as possible; Scheduled timetable updates, where a new timetable is to be implemented on a given date; Reference data updates, where a change to the reference (or geographical) data is required. Scheduled updates may, or may not, include reference data updates. Reference data updates require the file(s) containing the reference (or geographical) data to be replaced with a new, complete, file. This data will then supersede the old data. If each timetable is supplied in a separate file, then corrections must be made by supplying a new file with the same name as the file being corrected. Scheduled timetable updates should be made by supplying a timetable file with a different name to that being superseded, and the appropriate start date. This allows both timetables to exist during the period when the new timetable comes into effect.

If all the timetables are supplied in one file, then the entire file must be re-supplied for any updates. Scheduled updates will require the file to contain both the old and new timetables (with appropriate start and end dates)

AIM ATCO-CIF – August 2005

5

Terminology & General Rules In this document, a Journey is the movement of a vehicle described by a chronologically increasing set of stopping points from an origin location to a destination. A Service is a label attached to a group of journeys with (more or less) common stopping points. The Route Number (or Service Number) is used to identify a service to the public. A Timetable is a collection of journeys made by one or more similar services in the same direction on a specific set of days. The journeys are assumed to appear in an appropriate chronological order. A Timetable Group is a collection of timetables which are related in some way. For example, they may be for similar journeys on different days, or one may be the reverse direction of another. Timetables which contain journeys made by the same Service are automatically grouped. Other groups may be defined specifically (e.g. where a different service provides the Sunday or return journeys, or where two timetables should be merged and displayed as one). A Track is the exact sequence of stops which make up a bus journey for a particular service. The track references an AIM database of geographical stop data, rather than the published stop names. Each timetable has a Stop List associated with it, which is like a track, but lists all the stops for all the tracks associated with the journeys in one timetable. Usually, only some of the stops in the Stop List (and Tracks) appear in a published timetable; these are designated as Timing Points. The tracks must include all stops, not just timing points; however, only the timing points need to be listed in the timetable file. The stop names in the left-hand column of the published timetable correspond exactly to the timing points from the Stop List. If the timetable were expanded to include all stops, not just timing points, then the Stop List would match the list of stop names in the lefthand column. Note that a timetable file should either include only the timing points or all the stops, not a mixture. A Timetable Row List is a list of stop names corresponding to the rows of a displayed timetable. If a timetable file includes only Timing Points, then this list represents the rows in the published timetable, and must exactly correspond with the Timing Points from the Stop List. Otherwise, the timetable file must include all intermediate stops (with times) and this list must correspond exactly with the entire Stop List. Where a timing point or stop is required to appear with two rows, for distinct arrive and depart times, in the displayed timetable, then it must have two consecutive entries in the Timetable Row List in the timetable file. It must also have a double entry in the Stop List (set Double Entry flag during Stop List creation). However the tracks will always have only one entry per stop, and timetable file will contain one record (QO, QI or QT) per timing point (or intermediate stop), with the QI records having two different times where required.

Each journey has a specified set of Days Of Operation, which describe the days of the week when that journey operates. The Days of operation for a timetable must include all the days on which all its journeys operate. Where a journey calls at additional/different stops on some of its days of operation, the timetable must have separate columns, with different tracks and different days of operation; a textual footnote indicating this variation is not acceptable and will lead to incorrect journey planning information.

6

© 2004 Action Information Management Ltd

A Term is a period of time with a start and end date, which affects when a journey operates. The Days of operation may be restricted to within or without a particular set of Terms, identified by a single reference code used to define related Terms. Note that although the phrases “school days” and “holidays” are often used to refer to Terms, these need not be identified with academic terms. If no Terms are defined then any Term related restrictions to the Days of operation will be ignored, and all days will be treated as both within and without that Term. An Operator is a company which operates vehicles to make the journeys. Different journeys on the same service may have different operators.

Record of Changes Changes made in version 7 • • • • •

Various changes to reflect changes in acceptable usage such as optional fields Various description changes to reflect change of AIM data model from 8 to 12 character stop references (for NaPTAN support). Corrected Hail and Ride markers in ZE and GE records. Corrected position of Location : Prefix field in GS record. Document re-set into AIM standard document format.

Changes made in version 8 •

Added Alternative Geographical Point (GQ) record to support eastings and northings greater than 8 digits.

Changes made in version 9 •

Added GD record (destinations) and extended GE record.

Changes made in version 10 •

Added AIM Daycode to ZD and ZJ records.

Changes made in version 11 •

Modified GD and GE records to use owner codes instead of operators and support the Short Running destination flag.

Changes made in version 12 •

Added support for QE (standard ATCO-CIF) record.

Changes made in version 13 •

Added Low Floor Bus flag to ZJ record.

Changes made in version 14 •

Added new Crew ID to ZE record.

AIM ATCO-CIF – August 2005

7

Changes made in version 15 •

8

Added Fares Files Structures as Appendix 4.

© 2004 Action Information Management Ltd

Overall File Layout

The files will contain the following record types in the order specified. This table shows how the data would appear in one large file. The heavy lines show where data may be split into separate files. Note that the records must appear in the file(s) in the order indicated. Section

Sub-section

File header (one per file) Reference data

Record type ATCO-CIF

Locations (repeat as often as required)

QL QB QA GS GR

Operators (repeat as often as required)

QP

Associations

QX

QQ

QY

Timetable header

Timetable groups (as many as required) Term dates (repeat as often as required) Stop List Days of operation Timetable note (none or more)

AIM ATCO-CIF – August 2005

Description/comment Source product identifies specific implementation type. Use AIM for a specific implementation conforming precisely to this specification. Location text as in published timetables – may differ from name in AIM geographical stops database.

Optional (see section on geographical data) Optional (see section on geographical data) Optional (see section on geographical data) Optional (see section on geographical data) Used by AIM to match with pre-supplied operator list.

Not used. Optional Optional

ZG

Proprietary extension as described below. Optional

ZT

Proprietary extension as described below. Optional

ZL ZD ZN

Proprietary extension as described below. Proprietary extension as described below. Proprietary extension as described below. (But similar to QN record)

9

Timetable journeys (one per column, in chronological sequence)

Service details (one per service used) Timetable Row List (one per line that appears in the timetable) Journey header

ZS ZA (or QB) ZN QS ZJ QE QN (or ZN)

Journey events (one per timing point in the track)

1 0

QO QI QT ZE ZN

Proprietary extension as described below. NB: Journeys with a service number not listed here will be ignored. Location name Optional timetable row note As per ATCO-CIF standard. Operator, Days of operation and Route Number fields required. Proprietary extension as described below. Optional date exception records. NB: Terms defined in ZT/ZD/ZJ records will take precedence over QE records. Footnote code for journey. If required, some of these may be interpreted to further modify the days of operation. As per ATCO-CIF standard. As per ATCO-CIF standard. As per ATCO-CIF standard. Optional – Additional event data Optional – journey event note

© 2004 Action Information Management Ltd

Standard Record Formats

The standard ATCO-CIF version 05.00 records (starting with Q) are all used with their usual formats, although not all fields are used. (A copy of the relevant parts of the specification is included as an appendix to this document.) Where the record structure includes a transaction type (New, Delete, Revise), New should always be specified (this field will be read as New in any case). Modifications are always made by supplying new timetables (with newer Start dates). Deletions are made by separately specifying a termination date for a service. Note that the timetable header allows QB records to be used to list the timing points; although this is not strictly the usage specified in standard ATCO-CIF, it is a convention that has been used elsewhere. Anyone wishing to adhere strictly to the ATCO-CIF specification, or specify different stop names for particular timetables, should use the proprietary extension ZA instead.

AIM ATCO-CIF – August 2005

11

Proprietary Record Formats

The following proprietary record formats have been defined for this specification. The numbers indicate the length and position of each field in the record. All records are mandatory unless stated otherwise.

Term Date Definition record Record identity Term code Start date End date Description

2 (1) 6 (3) 8 (9) 8 (17) 50 (25)

ZT Unique code used to identify a related set of terms First date of this term Last date of this term Description of term set (e.g. “St Ethelred’s School”)

Optional - only stored for first occurrence of term code

Timetable Group Definition record Record identity Group identifier Service reference Reverse directions

2 (1) 8 (3) 8 (11) 1 (19)

ZG Used to identify all records defining one group. The ID of a service belonging to this group. N – treat directions normally (default) Y – merge Outbound into Inbound merged timetable and vice-versa (similarly merge A into C and vice-versa)

Timetable Stop List record Record identity Service reference

2 (1) 8 (3)

Stop list number

3 (11)

Direction of travel

1 (14)

1 2

ZL ID of service whose Stop List describes all the stops for all journeys on this timetable. Stop List for this service, used to describe the timetable. Usually has the format S01, S02 etc. May be blank if timetable rows include intermediate stops with stops references used by AIM. O (outbound) I (inbound) C (circular, clockwise - O can be used instead) A (circular, anticlockwise - I can be used instead)

© 2004 Action Information Management Ltd

Timetable Date record Record identity Start date Last date Days of operation

2 (1) 8 (3) 8 (11) 64 (19)

Term code

6 (83)

AIM Daycode

7 (89)

ZD Start date of operation of this timetable (yyyymmdd). Last date of operation of this timetable - Optional Textual description of days of operation (e.g. “Mondays to Saturdays, excluding Bank Holidays”). Identifies the set of terms used if Days of operation includes term-related aspect. Days of operation of the timetable in AIM Hexcode format. For AIM use only.

Note record Record identity Note code Note text

2 (1) 5 (3) 72 (8)

ZN Identifier for note (may be left blank for timetable notes) Full text of note

NB – This record is context sensitive. Depending on where it appears, it may define a note for a timetable (timetable header), a row (timing point list), a journey (journey header), or a journey event (after a QO, QI or QT record). The standard ATCO-CIF record QN may be used instead.

Service Details record Record identity Service reference Service number

2 (1) 8 (3) 4 (12)

Description

50 (15)

ZS As specified by AIM Number used as a public identifier, and which appear as the Route number in the QS records. Optional.

Timetable Row List Entries Record identity Transaction type Location reference Full location

2 (1) 1 (3) 12 (4) 48 (16)

Publicity Point flag

2 (64)

Working Point flag

2 (66)

Timing Point flag

2 (68)

AIM ATCO-CIF – August 2005

ZA (Note, ZB or QB accepted as equivalent) Not used (should always be N for New) As specified in QL records in reference section Text of location Optional – text from stop data is normally used. P1 = This is a Publicity Point P0 = Not a Publicity Point Optional – can be derived from events W1 = This is a Working Point W0 = Not a Working Point Optional – can be derived from events T1 = This is a Timing Point T0 = Not a Timing Point Optional – can be derived from events

13

Journey Additional Details record Record identity Service reference Track number

2 (1) 8 (3) 3 (11)

Origin timetable row index Dest. timetable row index

3 (14)

Term code

6 (20)

Same Vehicle As …

3 (26)

Depot Code Journey/ETM number

5 (29) 8 (34)

Crew Duty ID Tendered/Commercial

8 (42) 1 (50)

Fare Stage Table AIM Daycode

9 (51) 7 (60)

Low Floor Bus flag

2 (67)

1 4

3 (17)

ZJ ID of service for this Journey, as specified by AIM Number of track defined for this service which this Journey follows. Which timetable row (within ZA records) this journey starts at (the first timetable row is number 1). Which timetable row (within ZA records) this journey ends at (the first timetable row is number 1). Identifies the set of terms used to interpret term-time day code modifiers. Optional Identifies that this journey is a continuation of an earlier journey in a timetable for a circular service. Values are : space or 0 not a continuation -1 continuation of previous journey -2 continuation of last journey but one -3 continuation of last journey but two etc. Depot from which this vehicle runs. Optional Number used to identify this journey (e.g. for use with ticket machines). Optional ID of vehicle crew for (the start of) this journey. Optional Whether the journey is tendered or commercial. Values are : T Tendered journey C Commercial journey M Mixed (part T, part C) space Unspecified Identifies the Fare Stage Table for this journey. Optional Days of operation of the Journey in AIM Hexcode format. For AIM use only. L0 = This journey is not served by a low floor bus. L1 = The operator of this service intends to use a low floor vehicle for this journey.

© 2004 Action Information Management Ltd

Event Additional Details record applies to previous QO/QI/QT record, all fields optional Record identity Tendered

2 (1) 1 (3)

Hail and Ride indicator

2 (4)

Origin Fare Stage Number Destination Fare Stage Number Published arrival time to one second accuracy

3 (6)

Published departure time to one second accuracy

6 (18)

Publicity Point flag

2 (24)

Working Point flag

2 (26)

Crew Duty ID

8 (28)

AIM ATCO-CIF – August 2005

3 (9) 6 (12)

ZE Whether the event is on a Tendered or Commercial part of the journey. Values are T or C (or blank) H0 = Normal stops (not Hail and Ride) H1 = Start of Hail and Ride section of track H2 = End of Hail and Ride section of track H3 = Stop within Hail and Ride section of track H = Use value from Track (or 0 if not known) Fare Stage number of previous fare stage (used when this event is the origin of a journey leg). Fare Stage number of next fare stage (used when this event is the destination of a journey leg). Arrival time (hhmmss – 24 hour clock: 000000-235959) NB – the AIM system accepts times up to 475959, used for journeys running beyond midnight but considered late journeys from the “previous” day. Departure time (hhmmss – 24 hour clock: 000000-235959) NB – the AIM system accepts times up to 475959, used for journeys running beyond midnight but considered late journeys from the “previous” day. P1 = This is a Publicity Point P0 = Not a Publicity Point W1 = This is a Working Point W0 = Not a Working Point ID of vehicle crew from this event onwards. Leave blank to assume the same crew as the previous event (or that defined for the journey, on the first event).

15

APPENDIX 1 – Geographical Data

The AIM timetable import process requires certain geographical data to exist before timetables can be imported. This data includes Stops (with grid references), Tracks and Stop Lists. The Tracks and Stop Lists refer to the Stops, and include intermediate grid references used to draw the path of a track on a map.

Timetable Software Not Supporting Geographical Data If the timetable software generating the ATCO-CIF output does not support geographical data (or such features are not being used), then this data will be created and maintained using software supplied by AIM. In this case, the timetable software will need to store the AIM service reference codes and Track/Stop List numbers, and include them as described in the main specification above. The timetable locations will be linked to the AIM geographical stops by matching them against the corresponding timing points in the Stop List.

Timetable Software Supporting Geographical Stop Data If the timetable software generating the ATCO-CIF output supports geographical stop data, then this data can be exported to the AIM database using the ATCO-CIF format. In this case, the reference data must include the QB records with grid references (in metres). For some older AIM systems, the location codes must be no longer than 8 characters, and guaranteed unique within the target system (i.e. they must not conflict with stop references from other data providers). The QA records can be used to supply and alternative name, and the proprietary records GS and GR used to supply additional data beyond the scope of the ATCO-CIF 5 records, but supported by the AIM data model. Note that when location codes longer than 8 characters are used with the proprietary records (GS and GR), the reference must be split into two parts – the first four characters being called the prefix (but stored near the end of the record) and the latter 8 characters being called the local reference. (This separation and terminology have been chosen to reflect the usual usage, e.g. with NaPTAN).

1 6

© 2004 Action Information Management Ltd

If the AIM software is being used to create the tracks, then the stop data must be imported into the AIM stop database before track creation can begin. AIM must be made aware when the reference data contains the definitive source of geographical stop data, so that the data can be processed accordingly.

Timetable Software Supporting Full Geographical Data If the timetable software generating the ATCO-CIF output supports tracks as well as stops, then this data can be exported to the AIM databases using a further extension of the ATCOCIF format. The stop data is provided within the reference data as described above. The track data (including stop lists) is defined in an additional section of the ATCO-CIF data. This can either be in the same file as the reference data, or a separate file, as long as it can be processed before the timetable data. Each track is made up of a sequence of stops, with a geographical link giving the sequence of lines on a map which show the path followed by a bus from this stop to the next. The same geographical link between two stops may be used on more than one track, and probably will. A geographical link may be made up of a number of intermediate links. This could be used to separate a link based on the different roads that it follows. Note that when location codes longer than 8 characters are used with these proprietary records, the reference must be split into two parts – the first four characters being called the prefix (but stored near the end of the record) and the latter 8 characters being called the local reference. (This separation and terminology have been chosen to reflect the usual usage, e.g. with NaPTAN).

AIM ATCO-CIF – August 2005

17

Track Data File Layout The track data ATCO-CIF file uses a number of proprietary record types. Note that each track definition is followed by its elements in the correct sequence. Similarly, each geographical link is followed by its points in the correct sequence.

Section

Sub-section

File header (one per file) Reference data Track data

Record type

Description/comment

ATCO-CIF

Source product identifies specific implementation type. Use AIM for a specific implementation conforming precisely to this specification. Destination name Track definition

Destinations Track (repeat for number of tracks)

GD GT GE

Geographical Link (repeat for number of links)

GL GX GA GO GP or GQ

Track element (one per stop per track) Geographical route linking two stops

Geographical Link Element (optional) Geo. Link El. additional info (optional) Geo. Link El. road info (optional) Point on a geographical link

Proprietary Record Formats The following proprietary record formats have been defined to support geographical data.

Additional Stop Data record Record identity Location : local reference Stop Type

2 (1) 8 (3) 1 (11)

Bi-directional flag

1 (12)

Plate number Premises Location : prefix

20 (13) 50 (33) 4 (83)

1 8

GS Last 8 characters of the location code from the QL record. S = Shelter H = Hail & Ride G = Ghost Blank otherwise Y indicates that only one physical stop exists, although the buses stop on both sides of the road (travelling in different directions). Otherwise specify N (the default) Any unique identification appearing on the physical stop. Name of premises where the stop is located. Prefix, when location code is more than 8 characters.

© 2004 Action Information Management Ltd

Stop Road Names record Record identity Location : local reference Main Road Side Street Location : prefix

2 (1) 8 (3) 50 (11) 50 (61) 4 (111)

GR Last 8 characters of the location code from the QL record. Name of road in which the stop is located Name of side street, when stop is located at or near a junction. Prefix, when location code is more than 8 characters.

Track Definition Record identity Track reference

2 (1) 12 (3)

Origin : local reference

8 (15)

Destination : local ref.

8 (23)

Description Fare Stage Table Effective From Date Origin : prefix Destination : prefix

50 (31) 9 (81) 8 (90) 4 (98) 4 (102)

AIM ATCO-CIF – August 2005

GT The first 8 characters are the service reference of the service that this Track or Stop List applies to (right-padded with a space if necessary). The next three characters are either a three-digit number for a Track, or S followed by a two-digit number for a Stop List. Location of the first stop in the Track / Stop List. (Last 8 characters of the code from the QL record) Location of the last stop in the Track / Stop List. (Last 8 characters of the code from the QL record) Description of track – Optional Identifies the Fare Stage Table for this journey - Optional Date at which track becomes effective. - Optional Prefix for origin (if location code >8 characters) Prefix for destination (if location code >8 characters)

19

Track Element Record identity Track reference Location : local reference

2 (1) 12 (3) 8 (15)

Geographical link

10 (23)

GE As per track definition Location of stop that this track element links from. (Last 8 characters of the code from the QL record) ID of geographical link from this location to next or 0 if this is the last element in the track

Can always be 0 in a Stop List Activity flag

1 (33)

B = both Pick up and Set down (default) P = Pick up only S = Set down only N = Neither (pass only)

Only required for Tracks Timing point indicator

2 (34)

T1 = Timing point (appears in timetable)

T0 = Not timing point Fare stage indicator

2 (36)

F1 = Fare stage F0 = Not fare stage

Only required for Tracks Hail and Ride indicator

2 (38)

Fare Stage Number Location : prefix Publicity Point flag

3 (40) 4 (43) 2 (47)

H0 = Normal stops (not Hail and Ride) H1 = Start of Hail and Ride section of track H2 = End of Hail and Ride section of track H3 = Stop within Hail and Ride section of track Identifies fare stage within Fare Stage Table - Optional Prefix for location (if location code >8 characters) P1 = This is a Publicity Point P0 = Not a Publicity Point

Only required for Timing Point Lists Working Point flag

2 (49)

Unused Destination ID

4 (51) 10 (55)

Short Running flag

2 (65)

W1 = This is a Working Point W0 = Not a Working Point

Only required for Timing Point Lists

2 0

Placeholder for compatibility with earlier specification. Destination ID as specified in a previous GD record. This specifies the displayed destination (which may change during a track) If this is not specified, the destination name is taken from the next track element record where the destination is specified (if there is one) If no destinations are specified, the destination name can be taken from track destination stop. S0 = The Destination ID is used as described above. S1 = The Destination ID is only used if the trip ends at this stop, otherwise it is treated as if it were not specified.

© 2004 Action Information Management Ltd

Geographical Link Record identity ID Variation

2 (1) 10 (3) 2 (13)

Origin : local reference

8 (15)

Destination : local ref.

8 (23)

Distance Description Origin : prefix Destination : prefix

8 (31) 50 (39) 4 (89) 4 (93)

GL Unique ID of this geographical link Identifies links between the same pair of stops. Optional (since ID must be unique anyway) Location of the first stop in the Track / Stop List. (Last 8 characters of the code from the QL record) Location of the first stop in the Track / Stop List. (Last 8 characters of the code from the QL record) Road distance (in metres) of the link Description of this link - Optional Prefix for origin (if location code >8 characters) Prefix for destination (if location code >8 characters)

Geographical Link Element Record identity ID Link ID Distance

2 (1) 10 (3) 10 (13) 10 (23)

GX Unique ID of this link element ID of the Link this element belongs to Distance in centimetres

Geographical Link Element Additional Information Record identity ID Time Cost Instructions Heading

2 (1) 10 (3) 10(13) 7 (23) 50 (30) 30 (80)

GA Unique ID of link element Duration in seconds Cost in pence Turning instructions Heading description

Geographical Link Element Road Information Record identity ID Road Name Road Number Road Reference

AIM ATCO-CIF – August 2005

2 (1) 10 (3) 50 (13) 5 (63) 13 (68)

GO Unique ID of link element Road name Road number OSCAR reference (Optional)

21

Geographical Link Point Record identity Link ID

2 (1) 10 (3)

Grid reference easting Grid reference northing Grid Number Line Number

8 (13) 8 (21) 3 (29) 3 (32)

GP ID of link this point belongs to –link element if one exists, otherwise the parent geographical link. Grid reference easting (in centimetres) of Link Point Grid reference northing (in centimetres) of Link Point Number identifying grid used Number identifying which line this Point belongs to

Alternative Geographical Link Point Record identity Link ID

2 (1) 10 (3)

Grid reference easting Grid reference northing Grid Number Line Number

11 (13) 11 (24) 3 (35) 3 (38)

GQ ID of link this point belongs to –link element if one exists, otherwise the parent geographical link. Grid reference easting (in centimetres) of Link Point Grid reference northing (in centimetres) of Link Point Number identifying grid used Number identifying which line this Point belongs to

Destination Record identity Unused Destination ID Blind number Destination name

2 (1) 4 (3) 10 (7) 6 (17) 50 (23)

Owner Code

2 (73)

2 2

GD Placeholder for compatibility with earlier specification. Numeric ID of the destination (unique to the owner) Bus sign blind number for the destination Name of the destination (e.g. ‘London’, ‘City Centre’, ‘Bus Station’) Unique code indicating the creator of the destination. This should match the first two characters of the track reference of tracks using this destination.

© 2004 Action Information Management Ltd

APPENDIX 2 – Standard Record Formats

The following record formats, from the ATCO-CIF version 5.00 specification, are used within the AIM implementation. Where specific requirements or restrictions are needed to conform to the AIM data model, then these are noted in italics. Data fields not available in the source data may be left blank unless marked as Mandatory.

File Header record File Type Version (Major) Version (Minor) File Originator Source Product

8 (1) 2 (9) 2 (11) 32 (13) 16 (45)

Production Date Production Time

8 (61) 6 (69)

AIM ATCO-CIF – August 2005

ATCO-CIF – File identifier Release version of CIF format (currently 5) Revision of release (currently 00) Name of source of file Name of source product. Where the AIM implementation CIF format is supported alongside some other, include (AIM) in this string. Date of file production (yyyymmdd) Time of file production (hhmmss)

23

Journey Header record Record Identity Transaction Type Operator Unique Journey Identifier First date of operation Last date of operation Operates on Mondays Operates on Tuesdays Operates on Wednesdays Operates on Thursdays Operates on Fridays Operates on Saturdays Operates on Sundays School Term Time Bank Holidays

2 (1) 1 (3) 4 (4) 6 (8) 8 (14) 8 (22) 1 (30) 1 (31) 1 (32) 1 (33) 1 (34) 1 (35) 1 (36) 1 (37) 1 (38)

QS N, D, R (Always use N) Short code form of operator - Mandatory Unique identifier of journey within operator Start date of operation of journey (yyyymmdd) - Mandatory Last date of operation of journey (yyyymmdd) 1 = Operates; 0 = Does not operate ditto ditto ditto ditto ditto ditto S = Term time only; H = holidays only; blank otherwise X = except bank holidays; B = bank holidays only; A = also on bank holidays; blank otherwise

This section is mandatory Route Number Running Board Vehicle Type Registration Number Route Direction

4 (39) 6 (43) 8 (49) 8 (57) 1 (65)

Identifier used by the public (= Service number, mandatory) Operator identifier of journey1 User code for vehicle type Traffic commissioners registration number User code to indicate direction of route

Optional, but preferably one of :O (outbound) I (inbound) C (circular, clockwise - O can be used instead) A (circular, anticlockwise - I can be used instead)

Journey Date Running record Record identity Start of exceptional period End of exceptional period Operation code

2 (1) 8 (3)

QE Date (yyyymmdd)

8 (11) 1 (19)

Date (yyyymmdd) 0=Journey does not operate between these dates 1=Journey operates between these dates Note: These dates are implemented in AIM’s data model as “Term Dates”. Where AIM Term Dates are explicitly specified in ZT, ZJ or ZD records these will be used in preference to dates specified in QE records.

Journey Note record Record identity

2 (1)

QN

Quoted from ATCO-CIF spec. AIM’s usage is an identifier (unique to an operator and depot) that identifies a collection of journeys run by the same vehicle. Some providers call this a Bus Working Number. 1

Note code Note text

5 (3) 72 (8)

Abbreviation for note appended to journey Full text of note

Origin record Record Identity Location Published departure time

2 (1) 12 (3) 4 (15)

Bay Number Timing point indicator Fare stage indicator

3 (19) 2 (22) 2 (24)

QO Short code form of origin location - Mandatory Departure time (hhmm – 24 hour clock: 0001-2359) Mandatory. NB – the AIM system accepts times up to 4759, used for journeys running after midnight but considered late journeys from the “previous” day. Bay/Stop identifier T1 = Timing point; T0 = Not timing point - Mandatory F1 = Fare stage; F0 = Not fare stage

Intermediate record Record Identity Location Published arrival time

2 (1) 12 (3) 4 (15)

Published departure time

4 (19)

Activity Flag

1 (23)

Bay Number Timing point indicator Fare stage indicator

3 (24) 2 (27) 2 (29)

AIM ATCO-CIF – August 2005

QI Short code form of intermediate location - Mandatory Arrival time (hhmm – 24 hour clock: 0001-2359) Mandatory. NB – the AIM system accepts times up to 4759, used for journeys running beyond midnight but considered late journeys from the “previous” day. Departure time (hhmm – 24 hour clock: 0001-2359) Mandatory. NB – the AIM system accepts times up to 4759, used for journeys running beyond midnight but considered late journeys from the “previous” day. B = Both Pick up and Set down P = Pick up only S = Set down only N = Neither Pick up nor Set Down (pass only) Bay/Stop identifier T1 = Timing point; T0 = Not timing point - Mandatory F1 = Fare stage; F0 = Not fare stage

25

Destination record Record Identity Location Published arrival time

2 (1) 12 (3) 4 (15)

Bay Number Timing point indicator Fare stage indicator

3 (19) 2 (22) 2 (24)

QT Short code form of destination location - Mandatory Arrival time (hhmm – 24 hour clock: 0001-2359) Mandatory. NB – the AIM system accepts times up to 4759, used for journeys running beyond midnight but considered late journeys from the “previous” day. Bay/Stop identifier T1 = Timing point; T0 = Not timing point - Mandatory F1 = Fare stage; F0 = Not fare stage

Location record Record Identity Transaction Type Location

2 (1) 1 (3) 12 (4)

Full Location Gazetteer Code Point Type

48 (16) 1 (64) 1 (65)

QL N, D, R (Always use N) Short code form of location; used to identify this location throughout timetable files. Mandatory. When used as the definitive geographical stop data, this must not conflict with other stops within the AIM system. Full text of location - Mandatory User code to indicate type of location entry B, S, P, R, I, D

Additional Location Information record Record Identity Transaction Type Location Grid reference easting Grid reference northing District name

2 (1) 1 (3) 12 (4) 8 (16) 8 (24) 24 (32)

Town name

24 (56)

QB N, D, R (Always use N) Short form of location Grid reference easting of location (in metres) Grid reference northing of location (in metres) Form of location to be used when specific location is not required Higher level form of location to be used when specific location is not required.

Alternative Location record Record Identity Transaction Type Location Full Location Gazetteer Code

2 (1) 1 (3) 12 (4) 48 (16) 1 (64)

QA N, D, R (Always use N) Short form of location Alternative full text form of location. User code to indicate type of entry

Operator Record 1 Record Identity Transaction Type Operator Operator Short Form Operator Legal Name Enquiry Phone Contact Phone

2 (1) 1 (3) 4 (4) 24 (8) 48 (32) 12 (80) 12 (92)

QP N, D, R (Always use N) Short form of operator identifier Short form of operator name used for publicity Full form of operator name Phone number of travel enquiry service Phone number for other enquiries

Operator Record 2 Record Identity Operator Address

2 (1) 78 (3)

QQ Operator contact address, in comma separated form

Route Association Record Record Identity Transaction Type Operator 1 Route Number 1 Route Direction 1 Operator 2 Route Number 2 Route Direction 2 First date of operation Last date of operation Operates on Mondays Operates on Tuesdays Operates on Wednesdays Operates on Thursdays Operates on Fridays Operates on Saturdays Operates on Sundays Location Association Type

2 (1) 1 (3) 4 (4) 4 (8) 1 (12) 4 (13) 4 (17) 1 (21) 8 (22) 8 (30) 7 (38)

12 (45) 1 (57)

QX N, D, R (Always use N) Short form of first operator First route number Direction code of first route Short form of second operator Second route number Direction code of second route Start date of operation of association (yyyymmdd) Last date of operation of association (yyyymmdd) 1 = Operates; 0 = Does not operate ditto ditto ditto ditto ditto ditto Short form of location of association J = Routes join – route 1 should be through route S = Routes split – route 1 should be through route B = Routes cross border G = Guaranteed connection C = Vehicles change route number

Journey Association Record Record Identity Transaction Type Operator 1 Journey Identifier 1 Operator 2 Journey Identifier 2 First date of operation Last date of operation Operates on Mondays Operates on Tuesdays Operates on Wednesdays Operates on Thursdays Operates on Fridays Operates on Saturdays Operates on Sundays Location Association Type

2 (1) 1 (3) 4 (4) 6 (8) 4 (14) 6 (18) 8 (24) 8 (32) 7 (40)

12 (47) 1 (59)

QY N, D, R (Always use N) Short form of first operator First journey identifier Short form of second operator Second journey identifier Start date of operation of association (yyyymmdd) Last date of operation of association (yyyymmdd) 1 = Operates; 0 = Does not operate ditto ditto ditto ditto ditto ditto Short form of location of association J = Routes join – route 1 should be through route S = Routes split – route 1 should be through route B = Routes cross border G = Guaranteed connection C = Vehicles change route number

APPENDIX 3 – Registration Data

Registration Data File Layout The registration data ATCO-CIF file uses a number of proprietary record types. Note that each registration definition is followed by its elements in the correct sequence. Record type

Description/comment

File header (one per file)

ATCO-CIF

Registration data

RR RO

Source product identifies specific implementation type. Use AIM for a specific implementation conforming precisely to this specification. Route Registration

Section

Sub-section

RN RA RD RL RT RC RX RS

AIM ATCO-CIF – August 2005

Operator Name / Phone number Operator Trading Name

Operator Address 1 Operator Address 2 Licence & Registration Numbers Traffic Areas Summary of Changes part 1 Summary of Changes part 2 Subsidy Details

29

Proprietary Record Formats The following proprietary record formats have been defined to support registration data.

Route Registration record Record identity Name Position Date Cancel Ch’g Route Description Ch’g Stops Ch’g Stopping Ch’g Reversing Ch’g Timetable Ch’g Other

2 (1) 35 (3) 35 (38) 8 (73) 1 (81) 1 (82) 1 (83) 1 (84) 1 (85) 1 (86) 1 (87)

RR Name of person submitting registration Position in company of person submitting registration Date when changes take effect (yyyymmdd) Applying to cancel registration (Y/N) Route description is changing (Y/N) Bus stop and stopping places are changing (Y/N) Stopping arrangements are changing (Y/N) Reversing Manoeuvres are changing (Y/N) Timetables are changing (Y/N) Other things are changing (Y/N)

Operator Name / Phone Number Record Record identity Name Phone Number

2 (1) 80 (3) 15 (83)

RO Name, which appears on the PSV operator's licence Telephone number

Operator Trading Name Record Record identity Trading Name

2 (1) 80 (3)

RN Trading Name

Operator's Address 1 Record Record identity Address Line 1 Address Line 2

2 (1) 55 (3) 55 (58)

RA First line of the Address Second line of the Address

Licence & Registration Numbers Record Record identity Address Line 3 Address Line 4 Address Line 5

3 0

2 (1) 55 (3) 35 (58) 20 (93)

RD Third line of the Address Fourth line of the Address Fifth line of the Address

© 2004 Action Information Management Ltd

Licence & Registration Numbers Record Record identity Licence Number 1 Licence Number 2 Licence Number 3 Licence Number 4 Registration Number 1 Registration Number 2 Registration Number 3 Registration Number 4

2 (1) 8 (3) 8 (11) 8 (19) 8 (27) 8 (32) 8 (40) 8 (48) 8 (56)

RL First licence/permit number Second licence/permit number (optional) Third licence/permit number (optional) Fourth licence/permit number (optional) First registration number Second registration number (optional) Third registration number (optional) Fourth registration number (optional)

Traffic Areas Record Record identity Traffic Area 1 Traffic Area 2 Traffic Area 3 Traffic Area 4

2 (1) 35 (3) 35 (38) 35 (73) 35 (108)

RT First Traffic Area in which service is registered Second Traffic Area in which service is registered (optional) Third Traffic Area in which service is registered (optional) Fourth Traffic Area in which service is registered (optional)

Summary of Changes part 1 Record Record identity First line of summary Second line of summary

2 (1) 55 (3) 55 (58)

RC First line of summary of changes for ‘Notices and Proceedings’ Second line of summary of changes (optional)

Summary of Changes part 2 Record Record identity Third line of summary

2 (1) 55 (3)

Fourth line of summary

55 (58)

RX Third line of summary of changes for ‘Notices and Proceedings’ (optional) Fourth line of summary of changes (optional)

Subsidy Details Record Record identity Subsidy type

2 (1) 1 (3)

First authority Second authority First authority

35 (4) 35 (39) 35 (74)

AIM ATCO-CIF – August 2005

RS Is any part subsidised ? (N = No subsidy, W = Wholly subsidised, P = Partly subsidised) Name of first authority providing subsidy. Name of second authority providing subsidy (optional) Name of first authority providing subsidy (optional)

31

APPENDIX 4 – Fares Data

Fares Data File Layout The Fare data ATCO-CIF file uses a number of proprietary record types. All the new Fare records are prefixed with ‘F’. The following record types have been added to support Fares.

Section

File header (one per file) Fare Referenc e Data Fare Project data

Sub-sections

Record type

Description/comment

ATCOCIF

Source product identifies specific implementation type. Use AIM for a specific implementation conforming precisely to this specification. Fare Ticket Data – The ticket types available for a particular operator.

Fare Tickets

Fare Ticket Data

FC

Fare Project Data

Fare Project

FJ

Fare Rule Data Fare Table data

FR FX FT FS FP FL FK FA FE

3 2

Fare Project Header. This should be followed by all the Fare records related to this project. Fare Validity Rules Data Fare Rule Validity Dates Fare Table – A record exists for each Fare Table in the project. Fare Stage – Must appear in sequence order after associated Fare Table. Fare Stage Stop Record. – Fare Stages associated to Stops. Fare Leg – Contains all possible Legs for current Fare Table. Fare Leg Ticket - Contains the Fare and Ticket Type for each Fare Leg. Fare Table Track Record. – Fare Tables associated to Tracks. Fare Stage Track Element Record. Fare Stages associated to Track Elements.

© 2004 Action Information Management Ltd

Fare Record Formats Fare Ticket record Record identity Provider Owner Code Operator Ref

2 (1) 2 (3) 5 (5)

Ticket Variant Ticket Name Passenger

1 (10) 30 (11) 1 (41)

Journey Type

1 (42)

Zone Type

1 (43)

Zone Ref Period

30 (44) 1 (74)

Value Notes

3 (75) 40 (78)

FC Owner Code of TrackBuilder Provider Operator reference (as defined by the regional Data Manager) Ticket Variant (A-Z) Ticket Name A - Adult C - Child X - Concession G - Group S - Single R - Return Z - Zone M - Many N - Not Defined D - Day Out X – Concession Zone Reference. Period Type D – Days W – Weeks M – Months U – Unlimited Period Value Ticket Note.

Fare Project record Record identity Provider Owner Code Operator Ref

2 (1) 2 (3) 5 (5)

Installation Variant Start date Project Name

1 (10) 8 (11) 20 (19)

Superseded date Approver Source

8 (39) 2 (47) 2 (49)

FJ Owner Code of TrackBuilder Provider Operator reference (as defined by the regional Data Manager) Installation Variant Date the project is valid from. Format yyyymmdd The Project Name assigned by the Fare Table Reader Application. Project superseded date. Format yyyymmdd Approving organisation. The Source organisation.

2 (1) 2 (3) 20 (5) 2 (25) 2 (27) 8 (29)

FR Owner Code of TrackBuilder Provider Rule Name Minimum Age Maximum Age Rule Day Code

Fare Rule record Record identity Provider Owner Code Rule Name Min Age Max Age Day Code

AIM ATCO-CIF – August 2005

33

Monday From Monday To Tuesday From Tuesday To Wednesday From Wednesday To Thursday From Thursday To Friday From Friday To Saturday From Saturday To Sunday From Sunday To

6 (37) 6 (43) 6 (49) 6 (55) 6 (61) 6 (67) 6 (73) 6 (79) 6 (85) 6 (91) 6 (97) 6 (103) 6 (109) 6 (115)

Monday From Time (hhmmss) Monday To Time (hhmmss) Tuesday From Time (hhmmss) Tuesday To Time (hhmmss) Wednesday From Time (hhmmss) Wednesday To Time (hhmmss) Thursday From Time (hhmmss) Thursday To Time (hhmmss) Friday From Time (hhmmss) Friday To Time (hhmmss) Saturday From Time (hhmmss) Saturday To Time (hhmmss) Sunday From Time (hhmmss) Sunday To Time (hhmmss)

Record identity Start Date

2 (1) 8 (3)

End Date Notes

8 (11) 100 (19)

FX Start Date – The date 99999999 indicates a date range that is never valid. End Date Notes associated to the FR

Fare Rule Validity Date record

Fare Table record Record identity Table Name Rules Defined

2 (1) 44 (3) 1 (47)

Bi-Directional

1 (48)

Notes

70 (49)

FT Fare Table Name assigned in Fare Table reader 1 – Rules Associated with this Fare Table. 0 – No Rules Associated with this Fare Table. 1 – Fare Table is Bi-Directional. 0 – Fare Table is Uni-Directional. Notes associated with a Fare Table.

Fare Stage record Record identity Fare Stage Sequence Number

2 (1) 4 (3)

Fare Stage Number Fare Stage Name Excluded

5 (7) 50 (12) 1 (62)

Zone

1 (63)

Zone Ref

30 (64)

FS Unique Sequence Number of Fare Stage in FareTable. Fare stage number from source data. 0 -99999 Fare Stage Name. 1 - Fare Stage is Excluded 0 - Fare Stage is NOT Excluded 1 - Fare Stage is a Zone 0 - Fare Stage is NOT a Zone Zone Reference

Note : Fare Stage records must appear in sequence after the associated Fare Table Record.

3 4

© 2004 Action Information Management Ltd

Fare Stage Stop record Record identity Fare Stage Sequence Number Stop Ref Direction

2 (1) 4 (3) 12 (7) 1(19)

FP Sequence Number of Fare Stage in FareTable. Stop Ref. Direction. (0) Direction A (1) Direction B.

Note : Each Fare Stage Stop record must appear after the associated Fare Table Record.

Fare Leg record Record identity Start Fare Stage Number End Fare Stage Number

2 (1) 4 (3) 4 (7)

FL Start Fare stage Sequence Number. End Fare stage Sequence Number.

Record identity Provider Owner Code Operator Ref

2 (1) 2 (3) 5 (5)

Ticket Variant Ticket Name Fare Fare Rule Name.

1 (10) 30 (11) 5(41) 20 (46)

FK Owner Code of TrackBuilder Provider Operator reference (as defined by the regional Data Manager) Ticket Variant (A-Z) Ticket Name Fare 0 > 65535 Fare Rule Name..

2 (1) 80 (3) 12 (83)

FA Fare Table Reference Reference from Track Table.

Fare Leg Ticket record

Fare Table Track record Record identity FareTable Ref Track Reference

Note : Fare Table Track records must appear after the related Fare Table Record.

Fare Stage Track Element record Record identity Start Fare Stage Sequence Number End Fare Stage Sequence Num

2 (1) 4 (3) 4 (7)

FE Sequence Number of Fare Stage to use at start of journey. Sequence Number of Fare Stage to use at End start of journey.

Note : Fare Stage Track Element records must appear in sequence after the associated Fare Table Track Record.

AIM ATCO-CIF – August 2005

35

Maps In Action - https://groups.google.com/group/opendatamanchester/attach/.../Atco-cif_formats.pdf?...

APPENDIX 2 – STANDARD RECORD FORMATS. 23. File Header record. 23 ... The Route Number (or Service Number) is used to identify a service to the public ...

288KB Sizes 1 Downloads 91 Views

Recommend Documents

ConvNets-Based Action Recognition from Depth Maps ...
Fig.2 Kinect Sensors source from Apple. Fig.3 Deep Learning source from VLab MIT. REFERENCE. 1. B. R. Abidi, Y. Zheng, A. V. Gribok, and M. A. Abidi, ...

Random maps in physical systems
Jun 1, 2004 - Quasiperiodic signals can be transformed into random dynamics using ... Ulam and von Neumann [9,10] proved that the logistic map Xn+1 ...

Schematic Maps in the Laboratory
by the London Underground diagram, has four angles (horizontal, vertical, and 45˚ diagonals, giving eight ... as a result of canvassing various graphic designers [13, page. 151]. These range from very general and ..... even in cases where the line.

HTML5 in Action - GitHub
on the client machine between sessions. The data can be overwritten or erased only by the application itself or by the user performing a manual clear down of the local stor- age area. The API of the sessionStorage attribute is identical to that of th

Pugmarks in action - immr
provide “scent” http://www.forbes.com/sites/forrester/2013/10/17/there-is-no-internet-of-things/ ... Unobtrusive plug-in for browser (Chrome) and Android app.

Google Maps
and local business information-including business locations, contact information, and driving directions. Start your search in this box: Begin your search with a ...

Pugmarks in action - immr
currently available for. Chrome browser and on Android ... Unobtrusive plug-in for browser (Chrome) and Android app. Who is Pugmarks for? Users who wish to ...

Spring in Action
xii. 11.3 Automatic JPA repositories with Spring Data 318. Defining query methods 320 □. Declaring custom queries 323. Mixing in custom functionality 324. 11.4 Summary 326. 12 Working with NoSQL databases 327. 12.1 Persisting documents with MongoDB

Mule in Action
... Second Edition is a totally-revised guide covering Mule 3 fundamentals and best ... performance tuning, and BPM orchestration, and explore cloud API ... John D'Emic is a principal solutions architect and Victor Romero a solutions architect,.

Hibernate in Action
guage; how to configure Hibernate for use in both managed and unmanaged .... retrieval methods such as the query by criteria (QBC) API, which is a typesafe ...

Fingerprint Authentication in Action - GitHub
My name is Ben Oberkfell, I'm an Android developer at American Express on the US ... developer.android.com/resources/dashboard/screens.html ... Page 10 ...

Microbiology in Action
microbes have an active impact on our lives. We have framed the ... All these forms of life interact with one another and with the soil to create continually changing conditions. This allows an on-going evolution of soil habitats. The activity of liv

Hibernate in Action
Purchase of Hibernate in Action includes free access to a private web forum where you can ..... means in the context of object-oriented application development.

Seeing mind in action - PhilPapers
Sep 13, 2011 - 1For example, Alan Leslie writes that “One of the most important powers of the human mind is to conceive of and think about itself and other minds. Because the mental states of others (and indeed ourselves) are completely hidden from

Economics: Principles in Action - PDFKUL.COM
Pay and Benefits. •President is paid $400K/year. •$100K nontaxable travel allowance—$50K nontaxable expense account. •President gets to live in the 132- room White House. •Secret Service protection for 10 yrs. (pre Clinton Presidents get li

Seeing mind in action - PhilPapers
Sep 13, 2011 - the case with another's mentality. Peering more closely, moving around, or manipulating another's head will never bring their mentality into direct view—at least not in a way analogous to co-present aspects of solid opaque objects. T

Google Maps Engine Cookbook
Sep 3, 2014 - In Google Maps Engine, you always follow these three basic steps to make a map: A. Upload data ... Check the status message at the top of the page to see when it's finished. Recipe 1 | Map with point .... outlines for each polygon (stat

Your local maps - AppGeo
Modern and responsive web interface that is continuously updated to include new features ... (such as owner information) and maps for the public. • Support and ...

A comparison between concept maps, mind maps ...
without drawbacks 15–17 and they may not fit all types of target groups (such as non-academics), learning tasks (i.e. developing .... There is a myriad of node-link mapping methods from such diverse areas as psychology, computer .... and facilitati

Happy Halloween! maps
Where it's black, carve all the way through. Remove a layer where it's gray. 4. Add light and be safe with candles! maps maps.google.com ...

Your local maps - AppGeo
What zoning district am I in?, When is trash pickup at this address?, Am I in a flood zone?, What is the valuation of properties on this street? MapGeo delivers the same powerful tools and maps to smartphones, tablets, and desktops ensuring everyone

Your local maps - AppGeo
powerful tools and maps to smartphones, tablets, and desktops ensuring everyone has access to the answers they need no matter where they are. Maps are made to be ... FROM ASSESSING DATABASE. YOUR CUSTOM MAP. LAYER ON CARTO. SHARE. View data from anyw

Portfolio My Maps
members area was integrated using Wordpress with our team needing to match the design of the main front end site. ... PHP and also rewrote a number of theme files. We added the ability for job seekers to apply directly from the Chase ...