Application should allow searching by zip code

[nus-pe-bot]

This application misses the constraint that "people never park too far from where they are headed"

• searching for parking "clementi" leads to a wide number of results that could vary by kilo-meters in distance
• this makes the results largely not useful

Again, I bring this up "if the feature is implemented to work in a certain way but it could have been implemented to work in a better way (from the end-user's point of view) without much additional effort"

• IMO, this feature is not at all useful unless I can search by zip code of my destination

---

_{[original: nus-cs2113-AY2223S1/pe-interim#285] [original labels: type.FeatureFlaw severity.High]}

[malcolmang]

Team's Response

Hi, thank you for your bug report.

This is a good suggestion, but the team would like to reject this as Not In Scope.

The LTA API does not provide the full address with zip code for each carpark. Therefore, for this feature to work, it would require a Geofencing API, such as the one below:

https://developers.google.com/location-context/geofencing

As such, we would see this as not in scope as described below:

To break it down point by point:

• if fixing the feature flaw is essential for the app to be reasonably useful: The app still helps you "choose where to park" given that usually drivers know the rough address of the place they are driving to. In your example, instead of doing filter clementi, one could do filter clementi ave 3, if they are driving around that area, which will narrow the search down to carparks within immediate proximity. Therefore, this feature is still reasonably useful to look for available carparks in whatever area you want to drive to.

• if the feature is implemented to work in a certain way but it could have been implemented to work in a better way (from the end-user's point of view) without much additional effort: The important section here is without much additional effort: using a Geofencing API for every carpark on the list will be prohibitively expensive and incur much development time (interfacing with a whole new API, parsing based on coordinate data). We contest that this feature, while nice to have, will require much additional effort, and thus is out of scope.

We would then mark this as a feature to be rolled out in future versions, rather than something critical to this current version, as shown below:

The second point (the user cannot attempt to use the missing feature) is satisfied, and thus qualifies for the not in scope response.

Duplicate status (if any):

--