[Tagging] Map maintenance with StreetComplete - Preferred tagging
bkil.hu+Aq at gmail.com
Fri Jul 24 22:16:28 UTC 2020
OpenStreetMap is a shared database - you generally shouldn’t annotate
POI with tags for your own use.
Tags should correspond to ground truth - hence they need to pass the
verifiability. If I resurvey the POI, will I conclude the same future
todo_check_date=* that you have previously added? What if the
tolerance between the two of us don’t match, and I conclude that it
needs to be resurveyed in 1 year, while you would be sure that it
needs to be resurveyed in 1 month?
This sounds a bit like if we started adding fixme=update on
everything, and that is something that we should avoid at all cost
(everything is fixme and needs updating on OSM by definition).
I think everyone should maintain their own todo list on their own
devices and/or in some critical cases in the form of map notes if they
need help from the community.
Viewing from a different perspective: the choice of survey priority
should be decided in situ locally by the mapper who has capacity to do
regular verification. If people adding new POI overburden maintainers
with too short deadlines, all POI will show up as expired. However,
maintainers only have a finite amount of free time, so they will need
to prioritize their mapping activities by the cost to benefit ratio.
Hence they will probably sort by when a POI was last surveyed,
rendering todo_check_date=* redundant at best.
By the way, if a proper amount of people were actually using OSM data
and their applications supported an easy feedback mechanism, such
legwork would be obsolete. For example, if one navigates to a POI that
they find closed, why couldn't they just report it? Or even better,
couldn't we use data mining to get this information from their
location and interaction traces as others do (subject to consent)?
And on the positive side: when a user checks into a venue with their
social application of choice (be it Diaspora or Friendica) or if the
respective wifi network name shows up on a scan nearby, couldn't we
consider these as affirming signs?
On Fri, Jul 24, 2020 at 11:39 PM Peter Elderson <pelderson at gmail.com> wrote:
> Op vr 24 jul. 2020 om 22:53 schreef Tobias Knerr <osm at tobias-knerr.de>:
>> On 24.07.20 14:13, Peter Elderson wrote:
>> > In comparable cases (non-OSM, but comparible checking schemes), I do not
>> > record the date it has been checked, I record the future date when it
>> > should be checked (again).
>> When it should be checked is opinion-based, though.
> True, and the opinion is the user's opinion at the time of the survey. You can suggest a default re-check date for the type of feature (might also be empty) and leave it up to the user to accept or change that.
>> The date when you last checked a shop's opening hours it is a fact. But
>> opinions on how often one should revisit a shop to check the opening
>> hours again may vary a lot between mappers. So I think the former is
>> more suitable to be added to the OSM database.
> It's a historic fact, but it doesn't drive any plan.
>> There are some comparatively rare cases where you know in advance that
>> something will change (e.g. with construction that is scheduled to be
>> finished by a particular date), but imo that's more the domain of
>> opening_date or temporary tags.
>> > The routine is then, ask if check_date is absent OR when the current
>> > date is past the check_date.
>> I don't think this is a big benefit compared to "... OR when the current
>> date is X months past the check_date".
> I think you are thinking code in the app, not maintaining a bunch of features such as 35000 routes or all the Stolpersteine in the area
> The difference is the determination of X. It's feature and opinion-dependent. Checking/displaying due checks is very simple, and doesn't have to know anything, just compare the tag with the date, and all pop up.
>> Also, I tend to prefer making software a little more complicated if it
>> lightens mappers' manual workload, so making at least some use of
>> history (e.g. so that no check_date needs to be set when a tag is first
>> added) seems reasonable to me.
> As a maintaining mapper, I would set the future check_date at entry time.
> Your plan sounds fine, but it will not be of much use to me. I still have to maintain an agenda and listst for checks in the future. If a future check mechanism were in place, I'd simply display a check map, just like a map showing all notes or all fixme's.
>> Tagging mailing list
>> Tagging at openstreetmap.org
> Tagging mailing list
> Tagging at openstreetmap.org
More information about the Tagging