On Thu, Jul 30, 2020 at 12:40:58PM +0200, Martin Koppenhoefer wrote:
>
> > On 30. Jul 2020, at 10:39, ael wrote:
> >
> > often without survey, and then do not update the source, so
> > that tag becomes completely misleading.
>
> that’s what happens all the time. When I edit things that
sent from a phone
> On 30. Jul 2020, at 10:39, ael wrote:
>
> often without survey, and then do not update the source, so
> that tag becomes completely misleading.
that’s what happens all the time. When I edit things that already have a source
tag (generally source=Bing) I am removing it,
On Thu, Jul 30, 2020 at 01:55:45AM +0200, Martin Koppenhoefer wrote:
>
> > On 26. Jul 2020, at 23:58, ael wrote:
> >
> > Adding such source tags to a changeset seldom makes sense.
> > Most of my changesets are a mixture of local knowledge, surveys, gps,
> > photographic and video. I even
sent from a phone
> On 26. Jul 2020, at 23:58, ael wrote:
>
> Adding such source tags to a changeset seldom makes sense.
> Most of my changesets are a mixture of local knowledge, surveys, gps,
> photographic and video. I even occasionally use satellite imagery...
> So the source data needs to
on actual element) on top of filling new
> stuff might be enough in the long run.
>
>
>
> De :> ael
> > Envoyé :> dimanche 26 juillet 2020 23:56
> > À :> tagging@openstreetmap.org
> > Objet :> Re: [Tagging] Map maintenance with StreetComplete -
checks (could still
be prioritized based on actual element) on top of filling new stuff might be
enough in the long run.
De : ael
Envoyé : dimanche 26 juillet 2020 23:56
À : tagging@openstreetmap.org
Objet : Re: [Tagging] Map maintenance with StreetComplete
On Sun, Jul 26, 2020 at 10:03:17PM +0100, Cj Malone wrote:
> On Sat, 2020-07-25 at 16:42 +0200, Tobias Zwick wrote:
> >
> > So in a nutshell, the topic of how to find things based on old
> > sources is also very relevant for remote mappers.
>
> Technically there is survey:date and source:date
On Sat, 2020-07-25 at 16:42 +0200, Tobias Zwick wrote:
> If the date + *source* of the last change made on (the geometry of
> an) element was readily available, through the API or another meta-
> tag (source=bing, anyone? ;-) ), this would help to identify areas
> that should be updated because a
Hi Tobias, I've been giving this some thought. My conclusion is that
user validation of tags shouldn't be stored in the same database table
as the tags themselves. It's clear that as the map data ages, tag
validation is going to be a task with parallel and equal importance to
tagging itself, but
> I think it would help with community acceptance of a potentially large
> number of meta tags if you're somewhat frugal when it comes to adding
> new ones. [...]
>
> In practice, this could mean ...
>
> * ... not adding key:check_date when the key is first added, or when the
> value is changed
> adding check timestamps as string tags for every single tag seems a lot of
> bloat. One tag per object for me would be acceptable because it is indeed a
> valuable information when something was last verified and no changes were
> necessary.
Definitely it has the potential for that. And as
Thanks!
> Secondly, I think having to evaluate the history is a challenge. But do
> you have to?
No, I don't have to, thanks to such tags as check_date. But then again,
check_date, survey:date etc. only came to be invented because API
support was missing. It would be better to have somthing
> It is completely possible to add this functionality to the API in a
> backwards compatible fashion, at the cost of a long per tag in the
> current table (assuming that we don't need the information for historic
> object versions, so at a reasonable cost space wise. There are a couple
> of
Am 25.07.2020 um 03:45 schrieb Jarek Piórkowski:
>
> Well, a new API endpoint _could_ automatically read through the entire
> history of a node and note which tags changed when. It would
> essentially be doing what I do when I open the node history in JOSM
> and look when tags changed - only
On Fri, 24 Jul 2020 at 21:28, Jmapb wrote:
> On 7/24/2020 7:12 PM, Cj Malone wrote:
> >> OSM does not store edit timestamps for individual tags, only for the
> >> object as a whole. Finding out when a tag was changed requires a
> >> review of the entire history. I had to do this once when I saw a
On 7/24/2020 7:12 PM, Cj Malone wrote:
OSM does not store edit timestamps for individual tags, only for the
object as a whole. Finding out when a tag was changed requires a
review of the entire history. I had to do this once when I saw a
clear highway=motorway_link tagged as highway=motorway,
On Fri, 2020-07-24 at 17:48 -0500, Shawn K. Quinn wrote:
> On 7/24/20 17:20, Cj Malone wrote:
> > Alternatively if each storing when each tag has been validated is a
> > direction OSM wants to go, maybe it should be in the API. A client
> > like
> > StreetComplete could "touch" a tag to rev it's
On 7/24/20 17:20, Cj Malone wrote:
> Alternatively if each storing when each tag has been validated is a
> direction OSM wants to go, maybe it should be in the API. A client like
> StreetComplete could "touch" a tag to rev it's edited timestamp without
> actually changing the value.
OSM does not
On Fri, 2020-07-24 at 16:13 +0100, Jez Nicholson wrote:
> There must have been a long discussion on this, and I don't want to
> rehash it, but i'm surprised there was a positive response to adding
> check_date for individual attributesI can understand a check_date
> for a whole feature (as
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
sent from a phone
> On 24. Jul 2020, at 22:53, Tobias Knerr wrote:
>
> 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.
on the other hand the check
On 7/24/20 15:51, Tobias Knerr wrote:
> 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
Op vr 24 jul. 2020 om 22:53 schreef Tobias Knerr :
> 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
Hi Tobias,
congratulations on your successful microgrant proposal! :) Maintenance
of existing data is a growing concern as OSM matures, so it's important
that we explore workflows for it.
On 23.07.20 18:06, Tobias Zwick wrote:
> 2. Always record check_date or avoid tagging it where not
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.
The date when you last
There must have been a long discussion on this, and I don't want to rehash
it, but i'm surprised there was a positive response to adding check_date
for individual attributesI can understand a check_date for a whole
feature (as with the construction site), so for example a bus stop, I
might be
Firstly, I think this kind of application is very important for the
maintenance of the map. The thing has become too complicated for regular
people. So, kudo's!
Secondly, I think having to evaluate the history is a challenge. But do you
have to?
In comparable cases (non-OSM, but comparible
Jul 23, 2020, 18:06 by o...@westnordost.de:
> 1. Use check_date:smoothness or smoothness:check_date?
>
Both have some benefits, I am perfectly fine with both variants.
One gets check_date tags out of the way, one keeps tag and its
check date close to each other. In case of tie second seems
This should be more applicable in case the person walked by the said
object in person: https://wiki.openstreetmap.org/wiki/Key:survey:date
Also, I'd like to stay neutral in this question as of now, but I think
it would be possible to implement heuristic algorithms to reconstruct
the history of a
29 matches
Mail list logo
