[Tagging] Rarely verified and third-party data staleness in OpenStreetMap

[European Water Project]

Hi Paul,

>>>> Yep.  Because, as others have pointed out, implementing such a scheme
 >>>> in OSM is hard.  Not just technically hard, but "overcoming all the
people
>>>> who insist OSM MUST NOT do this" hard.

Can we focus our discussions to the technical aspects of different
solutions for storing key level last updated meta data date for the year
and month?  Unless we can develop a viable technical solution which has
demonstrable benefits for data quality, the issue of being able to win over
a large consensus of OSM users is moot.

Best regards,

Stuart



On Mon, 6 Apr 2020 at 16:51, Paul Allen <pla16021 at gmail.com> wrote:

> On Mon, 6 Apr 2020 at 15:17, Marc M. <marc_marc_irc at hotmail.com> wrote:
>
>> Le 06.04.20 à 15:09, Paul Allen a écrit :
>> > in your own app
>>
>> so every app 'll have it's own lascheck database ?
>>
>
> Those that want to know about last check dates.
>
> so when I do my annual check-up of all the POIs in my comfort zone,
>> It 'll need going into the different related quality monitoring
>> applications them to mark that it's up to date so that several of us,
>> on several applications, can use the work I've done ?
>>
>
> I'd hope QA tools would appear that can chase down refs.  What do you
> do now?  You go and look yourself.  If an app exists that means you
> don't have to check some things, that's an advantage.  Don't complain
> that there isn't an app for every POI you want to check.
>
>>
>> on paper, the argument "do this in your own db" is easy,
>> it allows not to have to think about the problems of outdated poi
>> badly detectable in osm
>>
>
> Yep.  Because, as others have pointed out, implementing such a scheme
> in OSM is hard.  Not just technically hard, but "overcoming all the people
> who insist OSM MUST NOT do this" hard.
>
>>
>> on a community level, it's the worst solution,
>
>
> It's certainly sub-optimal.  But at least there is a chance of it happening
> because the decision to implement it rests upon a single person.  This
> list will bun-fight over it for months, if not years, and nothing will come
> of it.
>
>
>> > say drinking_water:ewp_id
>>
>> or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID
>
>
> I didn't even know that existed.  I'm not sure I trust such IDs to survive
> intensive editing by newbies who can delete an object then add it
> with quite different tags.
>
>>
>> or a wikidata,
>
>
> If a wikidata object exists.  Given that I've mapped hamlets and villages
> around here that do not have wikidata objects, I doubt that every refill
> point will get one.
>
> that's avoid the need for several external database
>> to add their own id to the same object
>>
>
> That's sub-optimal, perhaps, but there's more chance of somebody who
> wrote a refill app giving all the refill points the app knows about an ID
> than
> them all appearing in wikidata.
>
> and if you still need a ref in osm, please don't use
>> drinking_water:ewp_id but a key like ref:*
>>
>
> Whatever.
>
> --
> Paul
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200406/4d8d8c39/attachment.htm>