European Commission logo
INSPIRE Community Forum

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

Dear TN experts,

when working on the update of the Annex I xml schemas (MIWP-18a), where the MS agreed we should publish backwards-incompatible new versions of all the schemas, I wondered whether we should use the opportunity to remove the duplicate fictitious element in the current TN-Rail xml schema.

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.").

My question is whether this is an error or intentional.

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.

Opinions?

  • Anja HOPFSTOCK

    By Anja HOPFSTOCK

    Dear Michael,

    in the ELF-project we have noticed that the attribute fictitious appears twice: there is fictitious for Network::Link and RailwayLink.  This is confusing and should be corrected or clarified.

    Best regards,

    Anja

  • Alexander RAMAGE

    By Alexander RAMAGE

    Anja - having reviewed the information, both of the attributes are useful; however in my view the GNM "fictitious" should have a new name to make the meaning of the attribute more sensible.

    A possible name would be no_geometry.

    What do others think.

    Alex Ramage

     

  • Michael LUTZ

    Alex,

    sorry to disagree - in my view both definitions state the same:

    • 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."

    I also checked the old issue tracker that we used during the data specifications development and discovered that the duplication was already reported in 2010 by ESDIN and Clemens Portele (see http://inspire-twg.jrc.ec.europa.eu/jira/browse/DS-290 and http://inspire-twg.jrc.ec.europa.eu/jira/browse/DS-359). It was agreed to remove the fictitious attribute in RailwayLink, but for some reason this update was never done.

    So I would indeed propose to either remove the tn-r:fictitious element from the schema (option 1) or to leave it in (for consistency with the IR), but clearly mark it as deprecated or "to be deleted" in the schema, so that it is not being used (option 2).

    Preferences for option 1 or 2?

    Michael

  • Jordi ESCRIU

    Dear Michael and All,

    As I explained to Anja during the INSPIRE GWF 2015 we were two persons working at the same time in the TN and related schemas (GNM, TN Common, TN sub-themes). Hence, there is room for some inconsistencies related to last-hour changes / decisions.

    If I remember well the fictitious attribute was initially proposed in the TN schemas and finally promoted to the GNM. Meanwhile, It was probably maintained in the TN Rail schema by mistake (my fault).

    As Michael said, the 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.

    I would go for Option 2 proposed by Michael - Keep the duplicated attribute untill IR is amended, but providign guidelines on how to proceed. But in my opinion, the MIG should discuss which is the best option (1 or 2).

    Jordi

  • Dominique LAURENT

    By Dominique LAURENT

    When filling the matching table for Railway, IGN France has decided to fill both attributes (with default value : FALSE). But, of course, would be nice to get a new version of the .XSD file with the duplicated attribute removed or deprecated.