Closed janicki95 closed 1 month ago
Also detected a few:
regulation.contition.regulationStatus
: exists in the examples but no longer in the schemaRegulationType
enum: miscSuspensionOfBusway
type doesn't exist in the schema
UniqueStreetReferenceNumber.items.$ref
: #/defs/UniqueStreetReferenceNumber
-> #/$defs/UniqueStreetReferenceNumber
emissionClassificationEuro.items.$ref
: #/$defs/emissionClassificationEuroType
-> #/$defs/EmissionClassificationEuroType
UniqueStreetReferenceNumber.items.$ref
: #/$refs/UniqueStreetReferenceNumber
-> #/$defs/UniqueStreetReferenceNumber
Source.properties
: Provision
-> provision
Privision.properties
: RegulatedPlace
-> regulatedPlace
Privision.properties
: Regulation
-> regulation
RegulatedPlace.properties
: Geometry
-> geometry
ExternalReference
and DirectedLinear
/LinearGeometry
/PointGeometry
/Polygon
doesn't match between:
LinearGeometry
is "sibling" of ExternalReference
LinearGeometry
is "child" of ExternalReference
geometry
property type doesn't match:
geometry
is an objectgeometry
is an arrayThanks for raising this issue. We are reviewing and will update/fix as soon as possible.
In JSON-3.2.3-example-point-dtro.json
, externalReference
should now be a singular object, and its UniqueStreetReferenceNumber
property should be an array. I'd argue that all properties should begin with a lowercase letter or at least be consistent, ~but that doesn't really matter.~
It seems the validation on the server is case sensitive and expects to find a Source
or Consultation
property starting with a capital letter, so consistency would be appreciated!
On behalf of DfT:
Many thanks for raising these issues. The DfT D-TRO team have been reviewing and expect to imminently issue a data specification release (v3.2.4) which aims to address the issues raised.
On behalf of DfT:
Again, many thanks for raising these issues. Many of the issues raised have been addressed in the data specification release 3.2.4. In a small number of cases, the correction requires a code base change to the D-TRO Service and we have recorded the issue and resolution and will address in a future release of the data specification.
Lack of consistency between the v3.2.3 schema and examples given.
JSON schema expects the source->section property to be a string[] (array of string values). All examples provided show this property as a string value only. How do you want this property provided?
Example:
Schema: