1.1 General<\/b><\/p>\n
This Technical Specification defines a model and identification principles for the main fixed objects related to public access to Public Transport (e.g. stop points, stop areas, stations, connection links, entrances, etc.), in particular:<\/p>\n
To identify the relevant functions which need a unique identification of fixed objects especially for the Passenger Information domain in a multi-modal, multi-operator context;<\/p>\n<\/li>\n
To identify the main fixed objects related to the Public Transport system, choosing a certain viewpoint, i.e. considering a certain level of detail (“granularity”) of the given description taking into account the needs of the identified functions;<\/p>\n<\/li>\n
To give a typology of these objects together with definitions;<\/p>\n<\/li>\n
To present relationships between the identified Public Transport objects;<\/p>\n<\/li>\n
To unambiguously describe these objects through their main properties (attributes);<\/p>\n<\/li>\n
To describe how to locate these objects in space through coordinates and through the link to topographic objects with a clear separation between the “Public Transport layer” and the “topographic layer” described in its turn by geographic objects;<\/p>\n<\/li>\n
To enable the assignment of data administration (responsibility for data maintenance) of each fixed object.<\/p>\n<\/li>\n<\/ul>\n
Geospatial location referencing techniques of PT objects (e.g. use of satellites, roadside equipment for positioning) or representation techniques on maps (projections) are outside the scope of this standard.<\/p>\n
1.2 Explicit Exclusions from Scope<\/b><\/p>\n
In order to limit the scope for this version of the Fixed Object Standard, certain types of potential Fixed Object have been excluded for the time being, but will be proposed for inclusion in a second or subsequent part of the standard. These include:<\/p>\n
Roadside Equipment such as Traffic Signals and Traffic Lights and approach information for Urban Traffic Management and Control Systems;<\/p>\n<\/li>\n
Road crossings and interchange data (though Access links may project onto tracks in other models that consider these, such as the EuroRoads project);<\/p>\n<\/li>\n
Parking: A Car Park Model defines the availability and nature of car, bicycle and other parking. IFOPT includes only a rudimentary Parking model to indicate the relationship of the car parks to the rest of the Stop Place model;<\/p>\n<\/li>\n
Relationships with the location referencing requirements of DATEX2 and TPEG.<\/p>\n<\/li>\n<\/ul>\n
Fixed Objects are concerned primarily with physical infrastructure and equipment as referenced by information services. Concepts that relate to fixed points that belong to other information layers, such as the structure of Tariff Zones or Fare stages (which belong to the fares layer of Transmodel) are not covered.<\/p>\n
IFOPT describes a generic structure for classifying Points of Interest, for example Museums, Stadiums, etc., but does not set out a recommended informative value set of Point Of Interest Categories.<\/p>\n
1.3 Exclusions from Terminology<\/b><\/p>\n
For the convenience of readers, the Terms and Definitions section of the IFOPT specification repeats definitions of certain key Transmodel concepts that are fundamental to understanding the IFOPT model. It does not repeat definitions of a number of other related Transmodel elements that are part of other Transmodel information layers, i.e. not specific to the Fixed Object layer, for example LINE, DESTINATION DISPLAY, PASSING TIME, or are not within the direct scope of the Fixed Object models, such as RAILWAY ELEMENT, RAILWAY JUNCTION, ROAD ELEMENT, ROAD JUNCTION.<\/p>\n
1.4 Approach \u2013 Modularisation<\/b><\/p>\n
1.4.1 General<\/b><\/p>\n
This Technical Specification builds on the Transmodel Standard to define four related sub models; See Figure 1.<\/p>\n
Each model is described as a set of entities, attributes and relationships with other models.<\/p>\n
These constituent models of the Fixed Object model are enumerated as follows:<\/p>\n
Stop Place Model:<\/b> Describes the detailed structure of a STOP PLACE (that is station, airport, etc) including physical points of access to vehicles and the paths between the points, including ACCESSIBILITY.<\/p>\n<\/li>\n<\/ul>\n NOTE The concept of stops and the links between them in the Stop Place Model is distinct from the STOP POINT and CONNECTION LINK concepts used in Transmodel to describe the logical stopping points and connections of journey patterns for timetables: the Stop Place model describes the stops and paths as actual physical locations in space.<\/p>\n<\/blockquote>\n Point of Interest Model:<\/b> Describes the structure of a POINT OF INTEREST including physical points of access, i.e. ENTRANCES. Also provides a model for a standardised POINT OF INTEREST CLASSIFICATION hierarchy \u2013 a means of providing a taxonomy of different types of POINT OF INTEREST relevant for journey planning.<\/p>\n<\/li>\n Gazetteer Topographical Model:<\/b> Provides a topographical representation of the settlements (cities, towns, villages, etc.) between which people travel. It is used to associate Stop and Station elements with the appropriate topographic names and concepts to support the functions of journey planning, stop finding, etc. The TOPOGRAPHICAL PLACE entities in the Gazetteer model may be referenced by the Stop Place and Point of Interest Model but do not reference the elements of those models.<\/p>\n<\/li>\n Administrative Model:<\/b> Provides an organisational model for assigning responsibility to create and maintain data as a collaborative process involving distributed stakeholders. Includes namespace management to manage the decentralised issuing of unique identifiers.<\/p>\n<\/li>\n<\/ul>\n The Stop Place Model is the mandatory part of the Fixed Object model. The other models are ancillary and may be implemented on an optional basis<\/p>\n 1.4.2 Motivation for Modularisation<\/b><\/p>\n This partitioning of Fixed Object into distinct sub-models is in particular of significance for data exchange. For data exchange, a model held on one computer system must typically be serialised into an XML document or other flat file format and then, after transmission, be de-serialised and rereferenced back into another model on a different system. In order to exchange data efficiently it must be possible to partition the data of a large model (for example all the bus stops in a country) into smaller coherent subsets (for example all the bus stops in a single area within a country) that include references to objects that are not included in the export (for example stops in adjacent areas, or the full definitions of the areas). This raises considerations for ensuring integrity of reference and in particular for the management of the identifiers that are used to implement the reference across different systems.<\/p>\n In practice the coherent subsets of data that are needed for efficient exchange must reflect the operational processes and frequency of change of the data. The four Fixed Object submodels represent four primary sets of data that usually will be exchanged as distinct documents between different parties on different timescales. Thus for example, the Administrative model is a small model that typically needs to be set up centrally with a view to coordinating the work of different stakeholders; once created, its data will change only occasionally, but it will be extensively referenced by other documents. At the other extreme, the Point of Interest and Stop Place models will need to be managed as discrete large data sets for each locality, each requiring detailed geographical surveying and local access knowledge for its creation and maintenance.<\/p>\n A second reason for modularisation is that it allows a more flexible and incremental approach to adoption of the standards.<\/p>\n 1.5 Approach \u2013 Modelling<\/b><\/p>\n 1.5.1 Relationship to Transmodel<\/b><\/p>\n The Fixed Object model is developed from the existing Transmodel as follows:<\/p>\n A number of existing Transmodel entities are referenced. In addition, the same separation of concerns and use of distinct layers for different levels of discourse is followed as in Transmodel.<\/p>\n<\/li>\n Some new entities and attributes are added that are not present in Transmodel 5.1.<\/p>\n<\/li>\n A few existing Transmodel entities are refined or their semantics clarified, notably that the Transmodel STOP POINT is actually a SCHEDULED STOP POINT and should be renamed as such.<\/p>\n<\/li>\n<\/ul>\n The Fixed Object submodels are expressed as an abstract model as per Transmodel, using the UML notation and the relationships of “association” or “inheritance” between named entities. This is the normative expression.<\/p>\n An example XML schema is provided as an informative concrete representation.<\/p>\n 1.5.2 Level of Detail & Use of Partially Populated models<\/b><\/p>\n Different applications will be concerned to describe a STOP PLACE to different levels of detail. The model is designed so that it may be used in sparsely or partially populated instances, as well as in fully or densely populated implementations. For example, the model should still be useful if only data for the Platforms of a Station are available, as opposed to a full data set that includes every access space, entrance and accessibility. This enables an incremental approach to capturing data over time.<\/p>\n For journey planning applications it is in any case necessary to reduce the complicated structure of a large interchange into a computationally tractable representation, and the model is designed to support an efficient computation by reducing an interchange to a small number of nodes and edges for the computation of navigation paths.<\/p>\n Thus there may be a difference between the data capture representation of a Stop Place, which aims to describe the full physical details of a terminus in a general purpose representation suitable for arbitrary data exchange, and a journey planning representation, which might be an optimised statically computed simplification of the full model to reduce a full set of links to a simplified graph for computing journeys and that is correlated with GIS, schedule and other data from other information layers. The fixed object model is concerned to describe the data capture model, but to do this in a way that is structured to meet the way that journey planners need to process and collate the captured data to create their own efficient representations.<\/p>\n 1.5.3 Data Administration<\/b><\/p>\n On a national scale, instances of a fixed object model can include large data sets (e.g. millions of locations, hundreds of thousands of stop places) that need to be gathered and managed on a distributed basis. The model should take into account how data can be partitioned into appropriate small subsets for the purposes of exchange as the payload of generic data exchange services. The IFOPT administrative model will support this.<\/p>\n Table 1 gives approximate total numbers of different types of fixed object nodes in an average European country (the number of links to each node will be much larger). The numbers of instances of different types of stop is significant both for their administration (it is the large data sets that must be partitioned), and for the schemes used to identify instances for public reference. The length of the public facing code should be large enough to handle the number of instances, yet should be as short as possible in order to be usable by humans. Textual names of objects are also subject to usability considerations. For some types of stop \u2013 for example airports or rail stations \u2013 the number of instances is quite small and there are intuitive names (typically the town name) that can be used for them. For other type of node, in particular bus stops and Points of Interest, there will be many more than can be named or easily remembered and there will be a need to describe a stop in several different ways, and with various qualifiers, to support stop finding and name discrimination tasks.<\/p>\n Table 1 \u2014 Indicative numbers of Access points<\/b><\/p>\n The informative XML XSD schema appended to this document gives an example of serialisation into useful packages.<\/p>\n 1.5.4 Stop Identification & Labelling<\/b><\/p>\n A particular use of Fixed Object model data is to enable stop and place finding by users of journey planners and other on-line applications. This requires the appropriate association of entities with topographical places. The Model is designed to allow for meaningful codes and labels to be constructed according to many different application and usage contexts.<\/p>\n 1.5.5 Relationship to GIS Standards<\/b><\/p>\n The Fixed Object model has a relationship to other standards describing the geographical features of a country, but is not itself a GIS standard. The Fixed Object model describes the semantic structure of stop places in a way that can be related to the Public Transport universe of discourse of Transmodel. Transmodel and the Fixed Object model exclude the detailed description of geographic features, and use standard GIS model elements to describe the GDF references needed to relate the Fixed Object model entities to the underlying GIS models.<\/p>\n The Location models used in the Fixed Object need to be represented in a way such that they can be projected onto a variety of geospatial representations. The Fixed Object model upholds the principles from Transmodel of separation of information layers and the use of Point and Link representations within the distinct layers which can be used to project elements between the models.<\/p>\n Point and Link and address data sufficient to make this projection are included in Fixed Objects: the choice of coordinate reference systems is open.<\/p>\n 1.5.6 Vertical Levels versus Altitude<\/b><\/p>\n Transport interchanges are often complex buildings with many interconnected levels. The labelling and description of the levels is used in describing stops and directions in PT info systems and so needs to be part of the Fixed Object model. This LEVEL is a distinct concept from that of a vertical spatial coordinate in that it is a semantic label (for example “Departures”, “Basement”, “Floor 1”, etc.). Altitude is in effect the z coordinate of a POINT.<\/p>\n 1.5.7 Security<\/b><\/p>\n The Fixed Object model describes data for exchange between responsible stakeholders. Such data may include information that is for internal operational use rather than general public use. Where appropriate, data can be flagged to indicate that its audience should be restricted.<\/p>\n 1.5.8 Scope of Phase 1<\/b><\/p>\n This first part of the IFOPT Technical Specification is restricted in its scope to a core set of objects relating to passenger information on public transport. We recognise that in future it may be useful to consider additional fixed objects relevant for traffic and transport such as Traffic lights, pedestrian crossings and Tariff Zones. Discussion of some of these elements needs to be in consultation with other CEN Working Groups<\/p>\n The first part of IFOPT covers the following entities:<\/p>\n Stop Model:<\/b> Rail Stations, Metro Stations, Bus and Coach Stations, On-street bus, tram coach and trolley bus stops and their associated Equipment. The same model may be used for Airports, Ship and Ferry Ports, Taxi ranks and other access points.<\/p>\n<\/li>\n Point of Interest Model:<\/b> Well known locations to which both Tourists and Residents are likely to wish to Travel, such as Museums, Parks, Stadia, Galleries, Law Courts, Prisons, etc. A classification mechanism is also provided.<\/p>\n<\/li>\n Topographical model:<\/b> Cities, Towns, Hamlets, Suburbs and Quarters and other settlements to which people may wish to travel and whose relation to Stop Places, Points of Interest and Addresses is relevant. It includes an Address model.<\/p>\n<\/li>\n Administrative Model:<\/b> An organisational structure or Administrators, roles and Administrative Areas used to manage other data elements. The Fixed Object models are conceived as discrete models, but share certain common concepts and base data type. Figure 2 indicates the dependencies between the different Fixed Object Models. The Stop Place and Point of Interest Models reference common concepts in the Administration and Topographical Models (though can be used with a minimal implementation of these concepts). Further application views may be constructed that reference some or all of the elements of the models. Further packages that reference these models can be added in future.<\/p>\n<\/li>\n<\/ul>\n The contents of the Stop Place Model and Point of Interest Model may be organised using elements established in the Administrative and Topographical Model. All the models assume the existence and reuse of common Address and generic data type packages. In any concrete implementation of the individual Fixed Object models in XML, these can be based on reusable XML subschema, with the logical dependencies shown in Figure 2. An informative XML schema is separately available at http:\/\/www.ifopt.org.uk.<\/p>\n","protected":false},"excerpt":{"rendered":" Road transport and traffic telematics. Public transport. Identification of fixed objects in public transport<\/b><\/p>\n\n
\n
\n
\n
\n\n
\n Published By<\/td>\n Publication Date<\/td>\n Number of Pages<\/td>\n<\/tr>\n \n BSI<\/b><\/a><\/td>\n 2010<\/td>\n 146<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"featured_media":230579,"template":"","meta":{"rank_math_lock_modified_date":false,"ep_exclude_from_search":false},"product_cat":[698,2641],"product_tag":[],"class_list":{"0":"post-230575","1":"product","2":"type-product","3":"status-publish","4":"has-post-thumbnail","6":"product_cat-35-240-60","7":"product_cat-bsi","9":"first","10":"instock","11":"sold-individually","12":"shipping-taxable","13":"purchasable","14":"product-type-simple"},"_links":{"self":[{"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/product\/230575","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/product"}],"about":[{"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/types\/product"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/media\/230579"}],"wp:attachment":[{"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/media?parent=230575"}],"wp:term":[{"taxonomy":"product_cat","embeddable":true,"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/product_cat?post=230575"},{"taxonomy":"product_tag","embeddable":true,"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/product_tag?post=230575"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}