Application should have sorting by distance for results

[nus-pe-bot]

Related to #5 but of an entirely different constraint -> application fails to capture the max acceptable distance constraint

• In the real world, if parking is not available within walking distance, drivers likely will choose take a cab or public transport
• While the application captures that availability affects this choice, it does not capture that distance plays a part

Given a list of results of my query,

• Distance plays a huge role as to where I will eventually part(can go as far as to say it determines where I choose to park)
• Knowing this, the application should allow me to sort a filter [NAME] result by distance from my destination location

Without #5 and #6, the application does not help me "choose where to park" but simply shows availability

---

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

[malcolmang]

Team's Response

Hi, thank you for your bug report.

This is a good suggestion, but rather than a Functionality Bug, would be classified as a Feature Flaw. Furthermore, the team would like to reject this as Not In Scope.

This would be a useful function indeed, but would require a lot of additional work, as well as actual money, to interface with a geofencing and map API, as well as GPS functionality. Geofencing API in particular costs money, an example of one such API: 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; meaning they can use the filter command to look for carparks that will be in proximity. For example, a driver going to Clementi Ave 3 may use filter clementi ave 3 to find carparks within that specific area. We contest that the app is reasonably useful in this way, and expecting a distance calculation would be out of scope and an unreasonable amount of work.

• 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 and Map API to do distance calculations for every carpark on the list will take more development time than the entire project itself, as well as be prohibitively expensive. 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):

--