@@ -467,9 +467,10 @@ The basis for modelling the information required for this use case is the NGSI-L
The query for parking sites within a given geographic area, e.g. around the current location of a car:
```
GET /ngsi-ld/v1/entities/?type=OnStreetParking,OffStreetParking&geoproperty=location&georel=near%3BmaxDistance==1000&geometry=Point&coordinates[-3.8040616,43.4631649]
It queries for all NGSI-LD Entities of type OnStreetParking or OffStreetParking, and geographically scopes it with the circle around the geographic point with coordinates -3.8040616,43.4631649 and a radius of 1000m.
...
...
@@ -521,6 +522,78 @@ In order to do this, the application needs to know the following:
## 6.3 Use Case: Query parking sites in the vicinity (UC2)
Use Case 2 (UC2) is about querying for a _free_ parking spot within the proximity of a car.
Figure 6.3-1 visualizes this scenario.

**Figure 6.3-1: UC2 - Query for free parking spots in the proximity**
The NGSI-LD Entity Type used is ParkingSpot, also from the NGSI-LD compatible Smart Data Model<ahref="#_ref_i.5">[i.5]</a> on Parking. For this purpose, we are only interested in the following properties of each parking spot:
- categrory
- location
- name
- parkingSite (relation)
- status
The query for parking spots within a given geographic area, e.g. within 100m around the current location of a car, filtered according to the status being _free_ and restricting the result to the elments: id, type, category, location, name and status:
```
GET /ngsi-ld/v1/entities/?type=ParkingSpot&geoproperty=location&georel=near%3BmaxDistance==100&geometry=Point&coordinates=[-3.8040616,43.4631649]&q=status==“free”&pick=id,type,category,location,name,status