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
