DavidGonzalezFernandez
commented
1 year ago Proposal of optional especification:
After testing various specifications for routes, I have come to the conclusion that one optimal way to store and work with routes is as follows:
Information to be stored for each route
- A unique identifier (e.g., timestamp followed by a sequence of random characters).
- Author's WebID (to maintain consistency with #4).
- A name that cannot be null and, in my opinion, should be of length greater than 0.
- An optional description to allow the user to add textual information about the route.
- A list of locations. The route would only store the information necessary to access the corresponding file where each location is stored and retreive its content. Also, the order in which the locations appear in the list is important: the first location would be the beginning of the route, the next would be the next stop, and so on until reaching the last location, which would be the end of the route.
Reasoning
By storing a "reference" to the location, we achieve the following benefits:
- If a location belongs to more than one route, the information is not duplicated, and only one modification is necessary.
- If the location specification is modified, the route specification does not need to be modified.
- If we allow adding friends' locations to our route, we eliminate problems related to ownership of own information, ease of modification/removal of own information, reliability, and non-repudiation.
For now, we will focus on the information that needs to be stored, and in the near future, we will focus on the specific format, names, and types of data.
I invite everyone to have a friendly conversation and propose adding, removing, or modifying information to what I have suggested. To give the conversation more context, I suggest including the reason/rationale for your proposal.
Furthermore, I encourage groups who intend to include "routes" in their application but do not wish to participate in the discussion to use the common specification that we will reach in a few days. This will ensure that not only the main specification is interoperable, but also that at least some of the optional specifications are as well.
I am creating a new issue to differentiate between the core specifications that all our applications must adhere to in order to meet the minimum requirements and the specifications that constitute optional features and thus not all apps will need to implement. Also having smaller issues will help keep the conversations more organized.
Here, we can discuss how to implement the optional feature of routes.
@Omitg24 commented:
When implementing routes, it is not sufficient to only store the geographical coordinates of each point. It is also important to assign a descriptive title to each point and to maintain a specific order for the points along the route.
Assigning a title to each point can provide valuable information about the location and purpose of that point, such as a landmark or destination. This information can be useful for users who are following the route, as well as for developers who may need to reference or modify the route data. This can be achieved by either associating each point with a title, or storing the route as a sequence of locations (from the main specification).
Maintaining a specific order for the points along the route is also important, as it reflects the intended sequence of the route. This order can be based on the order in which the points are received (or on other criteria such as distance or importance). By preserving the order of the points, the route can be accurately represented and communicated to users who are following the route or analyzing the data.