[Osmf-talk] Applications creating notes

Fri May 19 12:49:58 UTC 2023

>Why the sarcasm here?

This is not sarcasm but based on experience.

For validation to be most effective it needs to be done within a short time
frame of the mapping and tone of the feedback is very important. Give a
mapper feedback within an hour and it encourages them to do more and
corrects the problem at an early stage.  Within a couple of days isn't too
bad.

After a month they may have already changed their habits and resent your
feedback.

Now take a look at the number of HOT projects that have been fully
validated.  They are very few and far between.  This implies HOT validation
needs even more trained validators.

Next look at the time it takes to validate properly.  I assume you'll want
to load it into JOSM and run JOSM validation on the area?

Buildings are fun, with the JOSM buildgs_tool I can map a building
correctly tagged in two or three mouse clicks.  To correct an
existing poorly mapped building takes longer, especially if they haven't
even tagged it.  Asking validators to work on buildings isn't very
motivating for them.

Now we come to the formal changeset query method.  Many of the problems
will be mapped by new mappers with less than ten edits to their name.
First language often is not English. You come along a year later and query
their changeset. Think you're going to get a 100% response rate?
Strangely enough given the volume of errors just keeping track of which
changesets you've queried giving them reasonable time to respond is a
burden on the validator.

Then you get to the errors that across the map are substantial in number
but not easy to spot in a small area.  Duplicate buildings are an example
especially when they are on top of each other.  I think Fredrick identified
there are some 70,000 in the map but in one small area there may not be
any.  If you're validating you need to check them though to be able to say
they don't exist in this area.  If I spot them I delete one of the
duplicates but if it happens to be in an area that is a HOT project I don't
give any feedback to the HOT project.

How do you know if an area has been inspected for errors recently?  If you
don't know then you're simply duplicating work unnecessarily and we've
already noted that people who do validation work are the more experienced
mappers and we don't have enough of them.

On the subject of addresses I'd suggest the use of pluscodes from google.
Very simple and it works.

Cheerio John

On Fri, 19 May 2023 at 06:29, Christopher Beddow <
christopher.beddow at gmail.com> wrote:

> Why the sarcasm here?
>
> HOTOSM does a lot of validator training monthly. They do exactly that:
> validate changesets. But usually only for HOT projects.
>
> However, in iD editor, users have the example to mark a box asking for
> help reviewing the edits, and some users help do this (validation).
>
> In Switzerland many of my changesets get comments from other local users
> who catch some errors or ask for clarification why I did something, which
> might not be evident from imagery. They also resolve my notes that I leave
> from Every Door app, that are more complicated than mobile editing handles,
> before I get to them. It's very helpful and collaborative and not common in
> most regions. This is validation.
>
> Validation starts with just monitoring changesets in an area you care
> about, or being someone who turns on notes.  It could expand to monitor
> anonymous contributions of suggested edits from end users, which shouldn't
> be merged as-is and without validation.
>
> On Thu, May 18, 2023, 23:56 john whelan <jwhelan0112 at gmail.com> wrote:
>
>> >validator community
>>
>> I'm lost, who are these wonderful people and what do they do?
>>
>> It reminds me of a flowchart that has a box, "Then a miracle occurs."
>>
>> How do you know if something has been validated by someone who knows what
>> they are doing?  Or even been validated?
>>
>> I've been known to run my eye over an area that has a HOT project and
>> check for errors.  I didn't check any boxes on the project though.
>>
>> Many thanks
>>
>> Cheerio John
>>
>> On Thu, May 18, 2023, 17:50 Christopher Beddow <
>> christopher.beddow at gmail.com> wrote:
>>
>>> Could it help to not make feedback go direct to notes, but instead to
>>> some other open repository of suggested edits?
>>>
>>> Either way, garbage will pile up but it's worth analyzing and finding
>>> the gems. Users can choose to consult these off platform notes, or
>>> professional editing teams coming into a region, and algorithms can even
>>> help filter the likely spammy ones from high value, if wanted. Anonymous
>>> but high volume of raw data waiting to be converted to info or discarded.
>>> Though that seems what notes are already good for, but usually they are
>>> higher value, though often overlooked and hidden by default.
>>>
>>> But the point does stand: crowdsourcing is at its best when users care
>>> about the impact, are very engaged, and make careful, thoughtful edits.
>>> Growing that type of user is a clear best achievement. But growing the
>>> validator community, who can reliably act on high volumes of information is
>>> also an approach.
>>>
>>> On Thu, May 18, 2023, 21:37 Brian M. Sperlongano <zelonewolf at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, May 18, 2023 at 3:19 PM Alexander Heinlein <
>>>> alexander.heinlein at web.de> wrote:
>>>>
>>>>> regarding bad or missing data:
>>>>> We should probably create a (much) stronger focus on user feedback.
>>>>> Especially for users of commercial OSM-based software.
>>>>>
>>>>> Just an idea: All commercial OSM-based data users _must_[1] provide an
>>>>> user feedback channel. This means there _must_ be a way to create map
>>>>> notes, like there is already in various apps (Maps.Me, OsmAnd etc) in order
>>>>> to report missing/wrong POIs, addresses etc. Anonymous reports will
>>>>> probably be enough. Likewise, commercial OSM-based routers _must_ ask the
>>>>> user at the end about their experience. To make parsing easier, provide
>>>>> some typical answers additionally to a free-form text field. These answers
>>>>> could be: Report non-existing or impassable roads, report unnecessary
>>>>> detours, report wrong speed limits etc.
>>>>>
>>>>> Users must be able to dismiss these dialogs, i.e. skip the possibility
>>>>> to provide feedback. But they must have the most easiest way to provide
>>>>> feedback if they feel to do so.
>>>>>
>>>>> Of course this will create a certain amount of garbage input. But it
>>>>> will also create valuable input to improve our map data. And it will allow
>>>>> non-mappers to actually make a difference and to give them a certain idea
>>>>> about how OSM works.
>>>>>
>>>>
>>>> I operate a site that is heavily based on OSM data. I have explicitly
>>>> avoided building a capability for users to report problems with the map and
>>>> piping that to notes precisely because of the garbage input problem.
>>>> Instead, I just point them to OpenStreetMap and point out that any user can
>>>> edit it, and I've ended up with a small number of users that actively and
>>>> competently edit OSM as a result. I've seen enough horror stories from
>>>> other apps spamming notes that I under no circumstances want to be a
>>>> participant in perpetuating that problem. Also, since my site is a
>>>> "completeness tracker" (running every street in a city), it's become a
>>>> fairly effective tool for comprehensive on-foot surveys of streets in
>>>> places where my users are active.
>>>>
>>>> _______________________________________________
>>>> osmf-talk mailing list
>>>> osmf-talk at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/osmf-talk
>>>>
>>> _______________________________________________
>>> osmf-talk mailing list
>>> osmf-talk at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osmf-talk
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20230519/9b6a4606/attachment.htm>