Notes from website should include an indication the note was created here

[angoca]

Problem

Notes are created with an API call via a URL. Many applications offer the option to create notes. Most of them append a hashtag with the application's name (StreetComplete, OrganicMaps, Maps.me, OnOSM), which allows one to identify the source of the note. Also, notes can be created directly with a URL by providing all the necessary parameters.

When solving notes, knowing the note's origin could give an idea of its creation and what the user wanted to provide. Also, some notes are spam because they are created in a bulk way by using the URL directly.

Description

I want notes created from the website to include a hashtag or an extra test indicating they were created. This allows us, the resolvers, to identify these notes from other notes.

Screenshots

[tomhughes]

Notes are deliberately lightweight and do not include a lot of metadata and it really shouldn't matter what created them.

[angoca]

Just appending a #osm.org could be enough to identify the source.

I have solved thousands of notes, and it is always good to know how the note was created if it was from an app (on the ground) or on a computer (the location could not be very precise). If the note was from a mobile app, then the location could be very accurate or just a few meters far. Instead, from a computer (a website), the note could not be that accurate, because some people do not pay attention to it.

This is relevant if the note was created in the middle of nothing, and the text indicates there is, for example, a new shop. With a mobile app, I will think this is true, but from a website, this could be a misplaced note.

[angoca]

In this moment, there is an issue with Iranian notes in the middle of the ocean. It seems they were created with an OnOSM fork. But thanks to the hashtag, it was easy to identify the error. If something happens with the notes from the website, with a hashtag it will be easier to identify the source of the issue.

https://github.com/osmlab/onosm.org/issues/103

[matheusgomesms]

It is very useful to know where the note came from (and I actually believe this info should be somewhat mandatory). For example, notes created from Instagram (not sure how they do it) contain a lot of errors, and we are not sure if the notes came from there (except when the note creator mentions it).

For OSM.org, appending a #osm.org would not be something that should impact performance, and the gain obtained is way worth the extra bytes.

[Woazboat]

I don't think appending a hashtag to the comment text is the right way to go, but knowing the source application of the note would be useful

[angoca]

Sadly, the current OSM database model does not include anything to include the source of the note (I hope this is addressed in the next API version).

Another thing is that the OSM website is like any other OSM client in API terms. And many popular OSM clients are using hashtags for the notes: https://resultmaps.neis-one.org/osm-notes-country-custom?c=Germany&query=open hastags (#Mapy.cz, #organicmaps, #mapsme, #OSMyBiz) or specific text (via StreetComplete vXX.Y)

Appending the application name in the text string does not affect the note's text.

[pnorman]

If we want all applications to identify themselves in notes, we should change the notes data model rather than append text to the note.

[SomeoneElseOSM]

we should change the notes data model ...

To be honest, that sounds like something other than "notes". If someone wants to have a structured interaction with OSM data (suggesting changes, making changes validating changes...) there are a whole bunch of ways of doing that right now (task managers, Maproulette, to-do lists in editors...) that work with OSM data rather rather than relying on more metadata stored within OSM.

[matheusgomesms]

Wouldn't be easier to append a simple hashtag like #osm.org than change the whole notes structure or wait for an API update (which doesn't happen very often)? I am not sure how things work on the website development, but I would start with something that small, and then go for something more robust.

To the devs themselves: how hard would it be to append a hashtag to the notes created from the website? Would that impact performance considerably?

I believe that listening to the guys closing thousands of notes per year could be beneficial to the project.

[AntonKhorev]

To the devs themselves: how hard would it be to append a hashtag to the notes created from the website? Would that impact performance considerably?

It would be very easy. You probably can do it yourself by editing this line:

https://github.com/openstreetmap/openstreetmap-website/blob/0474a084cec51f7837575815bfbf0de0bd052447/app/assets/javascripts/index/new_note.js#L53

[tomhughes]

Easy to do, not necessarily easy to get merged. Please just stop with the hashtag obsession everybody.

[Helium314]

Ideally you would be able to put the application in a tag without hash, as suggested in https://github.com/openstreetmap/openstreetmap-website/issues/3626#issuecomment-1197807595

[AntonKhorev]

If Instagram notes come through fix the map page, it may be possible to capture the referrer and substitute it as a default note text.

[matheusgomesms]

The way I see it:

Problem

There is a clear problem for note solvers (as @angoca and many note-solvers face it) to sort them by priority. Low quality notes should not make noise among the good quality ones, and identifying the source of the notes is a great indicative of quality in order to prioritize work and work faster (eg.: coming from an app: usually good notes; coming from Instagram or OSM website, quality varies a lot).

Also, knowing the source can brings us some additional information as: is there some app that has some bugs and is creating bad or duplicate notes?

Proposed solutions:

1 - change the whole notes model or update the API to accommodate a new field source=, just like changesets 2 - append a hashtag like many apps currently do, while 1 is not done

Pros and Cons

1 - is a more elegant solution. However, it takes a lot of time to implement it (time and manpower that we don't have). Also, some users don't like this because notes are designed to be lightweight. 2 - is a very simple solution (already in use by many apps) that solves the problem, while 1 is not developed. If someday 1 is done, just a couple of clicks can revert the commit. However, it is not elegant at all, and some devs don't like hashtags for diverse reasons (not stated here yet in this issue, but I suppose they are valid).

---

Being said that, what is not clear to me is: why adding a small metadata on notes (being in form of source= or #) is such a bad thing? A note appending this info becomes now heavy?

Notes created by others apps are already carrying this very useful information; it's just OSM website that is failing on providing this info.

Is there any way to easily capture the referrer to know where all the notes came from, without implementing anything like the proposed solutions?

[gravitystorm]

Sadly, the current OSM database model does not include anything to include the source of the note (I hope this is addressed in the next API version).

In many circumstances we can change the data model between API revisions, if it can be done in backwards compatible way. Adding another field to an existing object is generally backwards-compatible.

If we want all applications to identify themselves in notes, we should change the notes data model rather than append text to the note.

I agree.

I am not sure how things work on the website development, but I would start with something that small, and then go for something more robust.

So this goes to the heart of why you'll find the maintainers wanting to do things properly, rather than making a "quick fix" first and hoping to sort it out properly later.

I have spent years, literally years now, refactoring and trying to sort out a long list of quick fixes and half-implemented features that were included in the source code and never revisited by the original authors. That's fine, I don't want to criticise fellow volunteers. But even with the best of intentions of people proposing new code for new features, very very few ever come back later to improve on their original work. So we maintainers need to be sure that if someone submits a new feature, that it's done right and we would be happy to maintain it ourselves over the long run. That doesn't mean that it needs to be perfect, iteration is always a good approach, but each iteration does need to be thought through and it does need to avoid making more work for us in the future.

When I started trying to refactor these problems I thought it would take a few months, but there is no end in sight and unfortunately lots of my ideas for new features for mappers are still waiting to be started.

I believe that listening to the guys closing thousands of notes per year could be beneficial to the project.

I absolutely agree, hearing from people using the site and API is key to making sure that we are building the right things. On the same side of that coin is listening to the maintainers, so that we can have a maintainable codebase that allows us some kind of forward velocity for features.

just like changesets

From my point of view, it's important that different parts of the API have some kind of consistency. For an absurd example, it's frustrating that Nodes and Notes use different formats for timestamps (yes really, timestamp="2022-07-28T09:47:39Z" vs <date_created>2013-04-24 16:30:25 UTC</date_created> - and yes, one is an attribute and the other an element, in addition!) or some objects are plural in API urls and some are singular, the list goes on. I think it would be better to have a consistent approach between Changesets and Notes to storing information about the application that creates them, rather than having the same data stored in two entirely different manners (tags vs inline hashtags) as is being proposed here.

[bkil]

Bigger problems we see with map notes are the following.

The name "note" itself is confusing users.

Would need a bit more elaboration of what it does on the interface before submission.

Sometimes, it is evident from the text of the map note that it was either created by mistake or that we will inevitably ask for further evidence (usually a website or photo). So it would be beneficial if we had a collaborative edited regexp or fuzzy rule set to which the interface could pop up a dialog during or before submission for confirmation with a canned recommendation text.

If one adds a note without logging in, they won't get notified if a mapper would ask for elaboration. Hence we usually just close this on first sight if any question comes up. Just mentioning about each POI that it might or might not be live today helps nobody if we need to survey it in person - these things clear up on a mapping party.

Registration should be made less painful.

Even without registration, there should be some easy way one adding a map note could be notified about feedback (for further questions or for just saying thank you after we acted upon it). This could be in the form of a PWA through 0-factor anonymous cookie-login or the user typing in their email or some other messaging contact that could be stored temporarily for a relay bot to forward messages in a pseudonymous manner.

[bkil]

But also, despite the fact that I don't think it will help that much, I would still support implementing the placement of the hashtag at the end of the comment (probably using a widely accepted character set, such as #OsmOrg #Osm_Org #OsmOrgWebsite #OpenStreetMapOrg etc.).

We understand that this is generating legacy code and a future maintenance burden, but the burden in this specific case is overstated. If we were required to bear quite a few kludges for years, I think it wouldn't be an issue to let this one slip through for a few months until the API change gets done.

Hopefully, nobody is expected to build starship architectures of downstream consumers whose life depends on keeping this as is during this short duration of time, but at the same time could be broadcasting vibes towards human note processors that OSM cares about them and caters to their needs when it is not a big expenditure to do so.

[woodpeck]

Side note, there's a 10 year old ticket about the same thing at #385

In my view, what I want for notes is "tags" in general; some may be created by the originating application, but I also want users to add tags to notes later, like "needs-survey" or maybe a marker of importance (see #3626). Because we have many people regularly looking at new notes in their area, "triaging" them if you will, but they won't be able to handle all notes immediately - some will require research or survey or questions need to be asked of the reporter. A proper tagging system would enable mappers to collaborate in this triage process. Mobile editors would, for example, prefer to highlight the "needs-survey" notes, and so on.

And no, please no hashtags.

[Woazboat]

In my view, what I want for notes is "tags" in general

Structured data for notes could also be used to link them with the OSM objects they are about instead of having to paste an object link (or worse, just an ID) into the note comment field.

[mmd-osm]

So for non anonymous notes we could (at least in theory) derive the source application information automatically once we have moved to OAuth 2 exclusively. No changes to the API or client apps would be needed in this case.