1 / 16

EuroRoadS for JRC Workshop Lars Wikström, Triona Editor of EuroRoadS deliverables D6.3, D6.6, D6.7

EuroRoadS for JRC Workshop Lars Wikström, Triona Editor of EuroRoadS deliverables D6.3, D6.6, D6.7. EuroRoadS scope. “EuroRoads will lay the ground for a pan-European road data infrastructure through a specification framework built on identified user requirements.”

andra
Télécharger la présentation

EuroRoadS for JRC Workshop Lars Wikström, Triona Editor of EuroRoadS deliverables D6.3, D6.6, D6.7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EuroRoadS for JRC Workshop Lars Wikström, Triona Editor of EuroRoadS deliverables D6.3, D6.6, D6.7

  2. EuroRoadS scope • “EuroRoads will lay the ground for a pan-European road data infrastructure through a specification framework built on identified user requirements.” • “It will be a key for opening up public sector road information, for promoting public-private partnership and for establishment of important applications within the areas of in-car navigation, fleet management, intelligent transport systems, mobility management, traffic management, road maintenance, traffic safety, environmental and society planning.” • Harmonisation of road data definitions - “define a common road data language” - and mechanisms for linking datasets at national borders. • http://www.euroroads.org

  3. EuroRoadS organization • WP1 – Project management • WP2 – Evaluation and quality control • WP3 – Awareness and dissemination of information • WP4 – Bussiness case • WP5 – User requirements • WP6 – Road data specification framework • WP7 – Demonstration • WP8 – Implementation plan • WP9 – Exploitation plan

  4. First of all! • The specifications from EuroRoadS WP6 primarily deals with data exchange. • Supply the means for a successful exchange of well defined road data datasets between data suppliers and data users. • No ”European Road Database” will be managed by EuroRoadS. • The EuroRoadS test project will also set up a metadata server (”a virtual vending machine for road data”)

  5. Handling of requirements • Output from WP5 work (see slide 3) • Use ISO 19100 – overall requirement for EuroRoadS • Take existing specifications for road data into account: • GDF (ISO/TC204) • RADEF (defined by CEDR) • Input from project members and others • Investigation of existing solutions • Several workshops • Draft documents  Comments  Final draft documents  Comments  Final documents

  6. Interpretation of ISO 19100 requirement for EuroRoadS WP6 Rules UML-Models… UML- Models… Encoding Rules (GML) ISO 19100 Profile EuroRoadS.xsd Exchange schema Universe of discourse Application schema “conceptual schema for data required by one or more applications” “set of one or more base standards and — where applicable — the identification of chosen clauses, classes, options and parameters of those base standards that are necessary for accomplishing a particular function” XML…

  7. WP6 – Document structure

  8. Model rationale • Delicate balance to adapt to existing data providers and data users. Many variations exist. • The core road network model supports a couple of variations regarding the spatial representation (e.g. geometry/topology). • The model separates (as does ISO 19100) the functional-/bussiness- entity/object from its spatial representation. Spatial representation is treated the same way as any attribute and not as the ”main thing”. • The functional object carries identity which is not affected when spatial or other characteristics change. It is possible to represent the same object with the same identity as purely geometric or topological depending on the needs. • The model supports different ways to attach attribution to the core road network and also separates attribution from the network itself.

  9. Model rationale... • There are difficulties in finding specific requirements for the model. ”Core European Road Data” is very general purpose. • The model must be flexible and extensible • Requirement to support incremental updates makes it even more delicate • Requires transactions • Requires ways to consistently handle object identity • Requires ways of Possibilities to update attributes only

  10. Core Network model • The road network is also a coordinate reference system. • Provides a way to locate other data relative to positions in the road network. • E.g. ”x meters from node y along route z in positive direction” • Some basic attributes (physical and functional classification, geometry/topology, temporal validity) defines what each entity represents in the real world and where (and optionally when) it is located. • The basic attributes also provides means for the specification and declaration of data quality • E.g. ”All roads classified as main road within that area have a positional accuracy...”

  11. Core Network Model • Road network entities has the ability to carry attributes • Any attribute can be invented and agreed and added to the model without changes in existing parts • Road network can be referenced via linear referencing mechanisms (LRM) • Other features with identity uses LRM to locate themselves relative to the network • Relies heavily on ISO 19103, 19107, 19133...

  12. Metadata and quality • Metadata (including quality) is loosely coupled with the rest of the model. • Uses scope descriptors to define the data subset for which metadata is valid. • E.g. ”All roads classified as main road within that area have a positional accuracy...” • Compliant with ISO 19115

  13. Updates • A requirement from the project specification. • Input from • ActMAP, SS 637007 (Swedish standard proposal) • The update model defines structures for representing updates • Does not define how that data is produced in the source database • Transactions collect updates to atomic operations to ensure data consistency • Updates represent instance level change • Add • Modify • Object • Attribute • Delete • CompositeUpdate (Split, Merge, Replace)

  14. <ER_Transaction> <transactionInfo>...</transactionInfo> <updates> <ER_Insert> <updateInfo>...</updateInfo> <insertedObject> <ER_RoadNode permanentId=”xx-yy”> ... </ER_RoadNode> </insertedObject> </ER_Insert> </updates> <ER_Transaction> ER_RoadNode(xx-yy/a) ER_RoadNode(xx-yy/a) ER_RoadNode(xx-yy/b) ER_RoadNode(xx-yy/b) Updates example

  15. UML modelling • ”Almost” required in ISO 19100 • UML dialect defined by ISO 19103 • Software industry standard • VERY well-known • Supported by many tools • ...though not always interoperable despite XMI • EuroRoadS has NOT actually officially chosen a tool, but uses MS Visio. • Why? • Price • Already used among project members • XMI-support??????

  16. The end... • Questions or comments can be sent to • lars.wikstrom@triona.se

More Related