Corrigendum #2586

TN Rail - Remove duplicate attribute "fictitious" in TN-Rail xml schema

Added by Anja Hopfstock almost 5 years ago.

Status:New
Priority:Normal
Assignee:-
Category:-
Target version:-
Corrigendum: INSPIRE document/system:
Submitting Organisation: Discussion (link):https://themes.jrc.ec.europa.eu/discussion/view/26968/remove-duplicate-attribute-fictitious-in-tn-rail-xml-schema

Description

Issue:

error or intentional?
Duplicate attribute "fictitious"
    Network::Link: "Indicator that the centreline geometry of the link is a straight line with no intermediate control points – unless the straight line represents the geography in the resolution of the data set appropriately."
    RailwayLink: "The railway link does not represent a real and existing railway track but a fictitious trajectory."

 

Options:

In the IR, an attribute fictitious (voidable, Definition: "The railway link does not represent a real and existing railway track but a fictitious trajectory.") is defined for the type RailwayLink. However, through inheritance from Link (in the GNM), the class already has an attribute fictitious (not voidable, definition: "Indicator that the centreline geometry of the link is a straight line with no intermediate control points – unless the straight line represents the geography in the resolution of the data set appropriately.").

If the former, we could fix this error in the new version of the TN-Rail xml schema. However, this would mean that the xml schema would not be compliant with the IRs (until the error is fixed there as well).

The other option is obviously to keep the duplicate element (not a problem because they are in different namespaces) until the error (if it is one) is fixed in the IRs. In this case, it would however be good to agree on some guidance on which of the two fictitious elements to fill - probably the one in the GNM namespace since this is non-voidable. The other one should then always have the same value or be void.

Justification:

issue was previously known - It was reported by ESDIN in 12 May 2010 (DS-290) and also by Clemens Portele on August 2010 (DS-359). Both issues (linked as duplicates) were reported some time after delivering DS TN v3.0 (by October 2009), which I think it was the last version delivered by the TWG. I also provided feedback for the DS updates done afterwards, mainly for DS TN v3.0.1 (e.g. schema constraints, compatibility with RINF, etc.) delivered by April 2010.

Probably the issue remained open (as DS-290 and DS-359 still remain now) and the change pending to be implemented.

Also available in: Atom PDF