"Verified" Users / Locked Tags
This seems like a *very* bad idea. Who verifies whom? Locked from whom? Chillly 18:58, 11 December 2009 (UTC)
Frederiks initial stub for this page dates from Dec 2009. According to his first paragraph, he created it to trigger a brainstorming on the next generation OSM API. After a year of brainstorming, I feel that the page should move into something closer to a "plan" or a "specification" where emphasis is put on priorization and detailled description of features, which should go live with a next generation "API 0.7". Gubaer 16:41, 5 December 2010 (UTC)
- Now, a further 1 year has passed and it should be time to move on. Is there a process or schedule to follow? How was it when version 0.6 was developed? --Magol 08:46, 30 March 2012 (BST)
- We could rename the page "API v0.7 brainstorming" in order to make way for some more basic information without a list of random ideas on the "API v0.7" page -- Harry Wood (talk) 17:05, 17 October 2013 (UTC)
I am part of a team that resolve notes in Latam, and we have seen the following kind of improvements for the notes in the API. In fact, as part of the proposals we have found, there are not too much ideas for the notes, and that's why I am writing them here (not sure if this is the best place to report them). Also, I want to say that we perceive the notes as the voice of our users, and resolving the notes by creating a change in the map is hearing that voice.
- A note should include some information about the application/context that is doing the URL call. For example, if the app is a mobile phone, or a computer. This allows to understand the context of the note, and it allows us to conclude if the note is on the ground (lack of GPS precision), from the computer/or placing the pin (artificial position), from geometry (the center of the geometry). Also, the name of the app; in fact, we see the notes as the feedback option for many maps, and currently Instagram and Facebook are using OSM, and there is a feedback in these apps, but the text goes directly to them. Instead, if they start to use our notes, by identifying the application source, it could give us an idea of where to find more information about the missing or wrong place described on the note (visit the place in Instagram to gather more details, for example). This also helps a lot with anonymous notes, because most of them lack of information to perform a change on the map, and then the note is just closed; instead, with information about the context, we could get the extra information.
- If a user wants to create a note at a set of specific coordinates, and there is already an open note at the same exact position, then the API should not create another note, but instead add the text as a comment in the existing note. This allows us to identify notes with several comments, and process them faster, because there are many comments (even if the text is the same thing) about the same place. This happens a lot with notes from Maps.me about non-longer existing sites. Also, resolving notes on the same exact place creates an issue for the volunteers in the editors, because they can select only the most recent one (in JOSM), but it is not evident that the other notes on the same place can be accessed form the notes list.
- OSM should react at @ mentions in notes, by generating a message in the internal message system. Sometimes, notes are used to identify invalid things, and creating mentions could help to integrate the community of volunteers with the notes and the reports. Currently, notes are very independent of the rest of OSM options.