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
