Feedback on slackmap proposal document

[rorystephenson]

This is my feedback/comments on the proposal document.

A couple of minor notes on line info

1. In the concepts section there is no mention of a line having an optionally defined length/height.
2. Under initial functionalities I think we can potentially omit: "Creating the line supports drawing line on the map interactively with automatic distance measurement" or at least make the automatically measured distance an optional suggestion as we often laser lines to have a more exact idea of length/height.

Editing permissions

Editing rights vs Reviewing rights

I would like to suggest an alternative editing model which is used on a similar app I work on (a climbing topo app). Rather than changes being based on having permission to edit a line/spot etc we can allow anyone to propose a change and then restrict the 'reviewing' of those changes to relevant users/associations. If the user has reviewing rights then their changes can be instantly applied. Some pros:

1. Users are potentially more likely to submit data (e.g. photo of an anchor or line length) if they can do so without having to first ask for permission to change the line/spot and then come back and make the change if permission is granted.
2. Less trust is required between the owner of the spot/line. Rather than needing to trust the user enough to grant them editing rights (even for a week as suggested) you can choose whether to accept the change on the merits of the data that is submitted (e.g. is the line length obviously wrong or is the photo of the anchor actually the wrong anchor).

Hierarchical editing permissions

In the climbing app I work on we have a hierarchical structure for editing permissions where you can be granted editor rights for a country, region or just a spot. I can imagine for example a national federation having rights to edit any lines in the country or similarly a regional association having rights to modify anything in their region (e.g. a user submitted a line in an area where slacklining is actually not allowed so it should be deleted). I'm not sure whether we'd want such a system from the start and it's worth considering carefully as we would have to categorise all lines/spots in countries/regions in order to achieve this. On the one hand it may be too much for an MVP and on the other it may be harder to add on later.

Importing of data

1. How will we group imported lines in to spots (and does every line have to belong to a spot)? Perhaps manually?
2. Who will the owner of imported lines/spots be? (I presume that the slackmap data contains which user created a line.)

The second question actually depends on whether we will import users from the Slackmap data (no idea if there are legal considerations on that). The proposal states that we will only support ISA user accounts which leaves us with the following options:

1. Don't import the user data. This may frustrate slackmap users who find that they have no right to edit/delete the lines they added in slackmap v2.
2. Allow associating the ISA user with one or more slackmap v1 users. This could be done via matching email or by adding a mechanism to slackmap v1 which allows you to associate a user with the slackmap v2 user (I'm imagining something like those google oauth grant windows).

Even if we consider that out of scope for MVP I would suggest, assuming that the user data is available and lines have associated users, that we import the data/associations to allow us to add this feature in the future.

[0gust1]

On "Importing of data":

How will we group imported lines in to spots (and does every line have to belong to a spot)? Perhaps manually?

on current Slackmap, there is the concepts of "slackline area" and "lines". In some slackline areas, users has also defined lines, on others not.
It seems there is no logical link (in data sense) between the 2 entities. This link could eventually be reconstructed (if it is the needed/wanted data model) by a geographical calculation using the long/lat coordinates of the "lines" and the long/lat coordinates of the "slackline area". I was wondering if the geospatial capabilites of PostgreSQL could help on this kind of topic... (instead of running a complicated script over the existing data to calculate this).

(I presume that the slackmap data contains which user created a line.)

I did some digging in Slackmap data (but only the part that is returned by the API, I've not looked into database.), and unfortunately, the (spot <=> user) association seems inconsistent. For some spots, you get the user in the JSON response, for others not.
It is to be confirmed, but I can easily give some examples/ data URLS if needed.

[rorystephenson]

Thanks for the replies!

So I would suggest that when we have access to the data we should check again if there is a more meaningful relationship between spot/line and if lines have users and, if so, import that data to allow us to use it in the future.

Using PostgreSQL geospatial capabilities can be interesting to investigate once we've got the MVP out (as Can mentioned in his response it's probably not worth it for MVP).

[Can-Sahin]

• Hmm 'reviewing' concept sounds nicer. I will give it a thought to see if there might be a hidden aspect to it. But sounds better.
• The hierarchical permissions is something considered before but presents a lot of complex things initially which I would really avoid. I think it's something that should be shaped in time depending on the actual need of people when they start using the new version.
• Matching Facebook user to a line and creating initial ownership would be a challenge for sure. Can't say anything yet.
  • Alternatively, we go with 'not importing user data' and reach out to associations to sign into the system where we assign the lines in their regions directly to them and people can later review. It would be annoying to lose your right for your line added earlier but you cannot edit the line anyway now :D At least people will have still the ability to update by sending reviews.
• Same goes for matching lines and spots

[rorystephenson]

• Hmm 'reviewing' concept sounds nicer. I will give it a thought to see if there might be a hidden aspect to it. But sounds better.

The only drawback I'm aware of is it's potentially harder to implement. In the app I work on I'm only handling the frontend but I know that it is implemented with a duplicate table for each entity that you want to allow edits/reviews of. When a user makes an edit an entry is made in to the review table with a reference to the original row in the main table. I haven't investigated much, there may be other ways to implement it.

• The hierarchical permissions is something considered before but presents a lot of complex things initially which I would really avoid. I think it's something that should be shaped in time depending on the actual need of people when they start using the new version.

Fair enough.

• Matching Facebook user to a line and creating initial ownership would be a challenge for sure. Can't say anything yet.

When we get access to the data if there is anything that can potentially allow us to link accounts then I think we should consider importing the slackmap users (in a separate table) and store the slackmap user id on the line/spot so that we have the option of doing this matching if we decide it's a good idea in the future.

• Alternatively, we go with 'not importing user data' and reach out to associations to sign into the system where we assign the lines in their regions directly to them and people can later review. It would be annoying to lose your right for your line added earlier but you cannot edit the line anyway now :D At least people will have still the ability to update by sending reviews.

That could work as well!