To be honest Tod, I don't think we want to add a *:confirmed= tag to every existing tag over time.
But as we've both suggested, maybe the solution to Andre's issue is just to make better use of the date stamps already there ? David On Mon, 2014-06-09 at 17:21 -0700, Tod Fitch wrote: > Am I missing the fact that we have history on all changes and you can detect > from the history when some tag like surface=unpaved was added to a way? > > So that takes care of the initial survey date. Maybe added a *:confirmed=yes > where * is the tag (e.g. surface:confirmed=yes) if it is still unpaved at a > later date. And again the change will be tagged with the time and when the > *:confirmed tag was added or changed. > > -Tod > > > > On Jun 9, 2014, at 5:13 PM, David Bannon wrote: > > > > > I am not sure that I like (eg) survey:date > > > > A typical road will have a range of data associated with it, lets try it > > - > > source=survey > > name=blah > > highway=unclassified > > surface=unpaved > > lanes=1 > > survey:date=2014-06-10 > > > > I guess that makes good sense, but what if the initial source was, say, > > bing ? > > > > source=bing > > name=blar > > highway=unclassified > > surface=unpaved > > lanes=1 > > survey:date=2014-06-10 > > > > Now, looking at that, does it mean that someone used bing to get the > > initial data on 10th June or was that a later survey ? I'd expect the > > bing mappers (bless them, don't want to start that again!) to time stamp > > their entries just as much as a survey mapper. But now we have the term > > 'survey' there even though no survey has taken place. > > > > I'd prefer a simple date stamp approach, date=2014-06-10. In fact, > > should it be automated ? I have not looked at the raw data for a while, > > does it include a date stamp we should be using for Andre's purpose ? > > > > (Sorry Andre, cannot remember how to do the mark above the 'e' in your > > name. Very rude of me.) > > > > David > > > > On Mon, 2014-06-09 at 18:01 +0200, André Pirard wrote: > >> On 2014-06-09 11:59, Glenn Plas wrote : > >> > >>> On 09-06-14 08:31, André Pirard wrote: > >>> > >>>> Hi, > >>>> > >>>> Some data of the map changes often, in particular what's on the > >>>> road: traffic signs, bus lines etc. > >>>> It would be interesting if someone tackling a region could > >>>> determine what in his interests was checked the longest ago. > >>>> Hence the need for a date at the beginning of the data that is not > >>>> of the source of information if any but that indicates when that > >>>> source, visual observation or other was still current last. The > >>>> someone would deal with the oldest in priority and update that > >>>> date if that can be said. The data field of the query result would > >>>> be sorted to determine the oldest ones. > >>>> Is the source:survey date appropriate for that, pardon my limited > >>>> English ... > >>> Hi Andre, > >>> > >>> I think that the correct key is survey:date. > >> Thank you for replying and confirming that high precision is needed in > >> this too fuzzy OSM world. > >> I found no "survey:" key, if I look for > >> http://wiki.openstreetmap.org/wiki/survey, it falls back on key:source > >> http://wiki.openstreetmap.org/wiki/Survey#Annotation (which is a non > >> existing label). > >> What I'm talking about is Key:source and more specifically its phrase > >> "source:name=survey 10 November 2012". > >> That is, data consisting of lowercase "survey" followed by a mandatory > >> one and only single blank... > >>> KeyMapper 3 also uses it. > >> Using an URL to spare 50 people a search, indeed, thanks. > >> So, either we warn Keymapper that they use unofficial tagging that > >> escapes an overpass search, > >> or I still have to learn what many people are trying to teach me: that > >> OSM is nothing but fuzzy (sending cars the wrong one-way) and that the > >> overpass query has to be extra huge. > >> survey:date is not providing for telling what has been > >>> It's a good idea to start including this in my regular edits, I'm > >>> going to add those as well. There is added value in it. I think > >>> it's best to do this on the changeset but that might go unnoticed > >>> when editing, also in josm. > >> It's useful in JOSM to save ourselves checking the same element 36 > >> times but mostly with overpass to make oneself a to do list. > >>> But that tag on every object seems like overkill. > >> Of course, only what often "changes without notice". > >> > >> At first sight, the overpass API is able to use a regexp to look for > >> data but not for keys. > >> Any trick? > >> > >> André. > >> > >> > >> > >> > >> _______________________________________________ > >> Tagging mailing list > >> Tagging@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/tagging > > > > > > > > _______________________________________________ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
