smart-data-models/datamodel.parking

Parking Data Model

dataModel.Parking

These data models are intended to model entities relevant for parking use cases in smart cities scenarios. When feasible these models reuse types, properties and enumerations from DATEX II version 2.3. A data dictionary for DATEX II terms can be found at http://datexbrowser.tamtamresearch.com/. Nonetheless, these data models are intended to NGSI-based systems and many simplifications has been made with respect to DATEX II version 2.3.

List of data models

The following entity types are available:

• OffStreetParking. Off street parking

• OnStreetParking. A site, open space zone, on street, (metered or not) with direct access from a road, intended to park vehicles.

• ParkingAccess. Parking Access - TODO: Provide a complete Schema

• ParkingGroup. Parking Group

• ParkingSpot. A parking spot is an area well delimited where one vehicle can be parked.

Contributors

Link to the 7 current contributors of the data models of this Subject.

Contribution

You can raise an issue or submit your PR on existing data models

datamodel.parking's Issues

Swapped examples between normalized and key-values format

Some examples in the ParkingAccess, ParkingGroup and ParkingSpot data models are swapped between the normalized and key-values format. It occurs both in the examples directories and in the spec documents.

Typo "Geoproperty" instead of "GeoProperty" in the location property of OnStreetParking and OffStreetParking examples

Hi,

Noticed it as the broker complained when trying to persist the OffStreetParking example.

"iudx:SmartParking" part of the context in the OffStreetParking example, but not in OnStreetParking

Hi,

"iudx:SmartParking" is present in the context of the OffStreetParking example.
Is this normal ?

The broker - in my case Orion-LD - refuses - for that reason - to persist the OffStreetParking example.
It seems that it hasn't been able to resolve the uri.
Showing me this error message : NgsiInternalError: Timeout during download of an @context : iudx:SmartParking.
After removing it from the context, I can persist the entity in the broker.

Strangely this "iudx:SmartParking" part of the context is not present in the OnStreetParking example.

Should OnStreetParking's allowedVehicleType be a single value instead of an array?

Hello everyone,

In the schema for the OnStreetParking model, the description for the allowedVehicleType attribute mentions "Vehicle type allowed (only one per on street parking)". However, this attribute is defined as an array of values, instead of a single value.

The old Fiware Datamodel documentation used to describe this attribute as a Text value instead of List of Text, if I'm not mistaken. Is this just an outdated description for the updated model, or should this field still only allow for a single value? The description for the same attribute in the OffStreetParking model, on the other hand, does mention it can hold multiple values.

Thank you very much in advance and I apologize for any misunderstanding on my end. Have a good day!

Level of a parking spot in an offstreet parking

There is currently no easy way to indicate the level of a parking spot in an offstreet parking garage.

Could this field be added to the parking spot data model?

Some notes I can think of:

• It should not be mandatory since for most onstreet parkings, a level will not be applicable.
• This should be a string, since levels could be non-numerical as there can be half floors or other exceptions. Eg "1a"

Error wrapping lines in the generation of example.jsonld

dataModel.Parking/OffStreetParking/examples/example.jsonld

Lines 15 to 16 in 3c7393a

	"description": "Municipal car park located near the Trindade metro station "
	"and the Town Hall",

It seems to have an error when the script that automate the generation of examples wrap lines. It separates the text in a new line and include ending and starting quotation marks when it should not. This does not occurs in others examples (.json or normalized)

Updating to latest version of standardised parking model

The DATEX II parking publications data model was revised and published in 2022. This largely aligns to the Alliance for Parking Data Standards (APDS) specification, which is also represented in ISO TS 5206-1:2023. Can this content be updated?

missing location Attribut in ParkingGroup

in schema.json the reference to Location Commons is missing.

{
  "$ref": "https://smart-data-models.github.io/data-models/common-schema.json#/definitions/Location-Commons",
  "description": "All from Location-Commons [https://smart-data-models.github.io/data-models/common-schema.json#/definitions/Location-Commons](https://smart-data-models.github.io/data-models/common-schema.json#/definitions/Location-Commons)"
},

Alignment with the "Alliance for Parking Data Standards"

Are you aware of the Alliance for Parking Data Standards?
https://www.allianceforparkingdatastandards.org/

I am not affiliated, and have no access to the details, but I remembered its announcement from 30-May 2019, and thought it might be worthy of alignment:

"The Alliance for Parking Data Standards (APDS), formed by the International Parking & Mobility Institute (IPMI), the British Parking Association (BPA), and the European Parking Association (EPA), is a not-for-profit organization with the mission to develop, promote, manage, and maintain a uniform global standard that will allow organizations to share parking data across platforms worldwide."

onStreetParking permitActiveHours schema

Hey,

the description of permitActiveHours in the OnStreetParking schema mentions that The syntax must be conformant with schema.org, but it does not mention which schema.org Property it needs to be conformant with.
From the example "blueZonePermit": "Mo, Tu, We, Th, Fr, Sa 09:00-20:00" i guess https://schema.org/openingHours is used. Am i right here?

If openingHours is used, is there any possibility to specify special permitActiveHours for holidays?
If not, maybe it's worth considering the usage of https://schema.org/openingHoursSpecification as a more expressive alternative to openingHours, which allows the dayOfWeek to be PublicHolidays.

Bad text in occupancyModified[string] in offStreetParking

A silly thing

I think occupancyModified[string] is about Timestamp when occupancy was updated. Not the text mentioned

Isn't it?

Wrong observationDateTime in OnStreetParking and OffstreetParking examples ?

Hi,

The observationDateTime property has this value : "2021-03-11T15:51:02+05:30".

It seems to be disaligned with the other datetimes in the entity that all refer to "2018-09-21T12:00:00Z", for example the observedAt property of availableSpotNumber.

Always speaking about observationDateTime but this time about its format.
Should it be converted to "2021-03-11T10:21:02Z" according to the ETSI specification that restricts timezones to UTC in my comprehension ?

incorrect documentation on the allowed values of allowedVehicleType (VehicleTypeEnum)

We will be using the OnStreetParking datamodel.
According to the documentation, the allowedVehicleType attribute allows values defined by VehicleTypeEnum a DATEX 2 version 2.3.

There seems to be a mismatch:

• On the OnStreetParking documentation the value twoWheeledVehicle is not an allowed value of allowedVehicleType which is of type VehicleTypeEnum.

• However, on the DATEX 2 documentation it seems that VehicleTypeEnum does indeed include twoWheeledVehicle.

Can we assume that this is a simple documentation issue? If so can this be corrected? I can also do this if we agree on it 👍

extCategory property missing definition

The "extCategory" property of OffStreetParking is defined in the schema.json but not explained in the README nor used in examples. There is not definition of its use.

Should it be defined or removed?

Swagger yml for onStreetParking doesnt include the newly added attribute 'occupiedSpotNumber'

Following #17, when accessing the interactive specification the added attribute 'occupiedSpotNumber' is not present.

a field to store information about occupied spots (e.g. occupiedSpotNumber)

While developing an application that processed entities stored as OnStreetParking, we noticed that we can store the information about the total number of spot and the available number of parking spots.

Our application is mainly concerned about showing the current occupancy of the parking area. Which we are computing as the number of vehicles located in that OnStreetParking.

We solved this currently by making Available = Total - Occupied. However, this as a few downfalls:

• In our case sometimes more vehicles are parked than there are spots available, so Available becomes a negative number.
• If the parking capacities are updated then we must also take care of accordingly updating the Available field, which if not accounted for can lead to faulty issues.

For this reason, we wanted to know if it is possible to add an extra optional field to the datamodel such as occupiedSpotNumber?

Thanks :)

In OffStreetParking example occupancyModified is a Property

Should it be a Temporal Property instead ?

Question regarding the refParkingSite property of the ParkingGroup data model

According to the ParkingGroup data model, refParkingSite is a reference to an OffStreetParking or OnStreetParking entity. In the NGSI-LD examples, shouldn't the property refParkingSite have a value of "urn:ngsi-ld:OnStreetParking:daoiz-velarde-1-5" instead of "urn:ngsi-ld:ParkingSite:daoiz-velarde-1-5" (since the category of "urn:ngsi-ld:ParkingGroup:daoiz-velarde-1-5-disabled" is "onStreet")?

Make the OffStreetParking example broker-compatible

Hi,

I keep on developing python-ngsild-client, a Python library that allows to create and modify NGSI-LD entities effortlessly, and to interact with a NGSI-LD broker.

The Getting Started chapter uses the OffStreetParking normalized example to showcase how one can manipulate a complex Entity and persist it into the broker.
But unfortunately the udx:SmartParking context is not resolved by the broker then prevents the parking to be persisted.
I've added this minor fix.

from ngsildclient import Client, Entity, SmartDataModels

parking = Entity.load(SmartDataModels.SmartCities.Parking.OffStreetParking)
parking.ctx.remove("iudx:SmartParking")  # the fix !

client = Client()  # assumes that a local broker instance is running (localhost, default port=1026)
client.create(parking)  # ok

But it would be nice to be able to persist the example "as-is".
Would you mind removing this part of the context ?
Or if it's not possible maybe do you know a way to tell a broker to ignore a specific context ?