[Tagging] [OSM-talk-be] generalized survey and consequences

[Tod Fitch]

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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging