On 2014-06-09 18:28, Glenn Plas pointed out :
> http://wiki.openstreetmap.org/wiki/Key:survey:date
> http://taginfo.openstreetmap.org/keys/?key=survey:date
> *Keypad-Mapper: the survey date is saved with each address tag:*
> <http://wiki.openstreetmap.org/wiki/Keypad-Mapper_3#new_features_version_3.1>
Thanks Glenn...  I wasn't expecting it without a Key:survey !
Curiously, Key:survey:date does not define the date format at all.
Because it is mostly a Keymapper log, it's factually usually ISO, but,
one can (of course) find;
07/02/2007
<http://taginfo.openstreetmap.org/tags/?key=survey%3Adate&value=07%2F02%2F2007> 
February or July?
29/02/1988
<http://taginfo.openstreetmap.org/tags/?key=survey%3Adate&value=29%2F02%2F1988> 
He/She must have confused survey with another date
Furthermore, Key:survey:date just doesn't care to say if it applies to
nodes, ways, polygons and/or relations.
And it mentions a date of surveillance without saying of what.
Well, more than typically OSM;-)
As another comment, I find it inappropriate.
>> At first sight, the overpass API is able to use a regexp to look for
>> data but not for keys.
> I haven't found a way to do it.   You could create a union when you
> know what keys to search for (but that kinda misses your point I assume).
Overpass can only be used for what it can or should be improved.

On 2014-06-09 20:33, Marc Gemis wrote :
> On Mon, Jun 9, 2014 at 8:01 PM, André Pirard <a.pirard.pa...@gmail.com
> <mailto:a.pirard.pa...@gmail.com>> wrote:
>
>>     What if the previous mapper doesn't survey the same things I map
>>     ? What's the use of the survey date in that case?
>     That is the point I raised that unlike source=... survey:date
>     applies to all aspect of a map element.
>
>
>
> what is "all" aspect ? Let's take a highway
>
> - name
> - classification
> - surface
> - lanes
> - parking lanes
> - bicycle lanes/tracks
> - sidewalks
> - max weight, height, etc.
> - is overtaking allowed
> - crossings
> - others ?
>
> Since almost none of the streets in Belgium are surveyed for all this
> information, I still have to survey the street as it was never
> surveyed before. When I started mapping I forgot to survey certain
> things as I was not aware that it could be mapped. Assuming I would
> have put a date on it, I would still have to resurvey.
That is why (not surveying "all information") survey:date is
inappropriate in addition to being ill defined.
> It would also mean that you have to update the survey date on each
> item, even if you don't change anything on the element (as you most
> likely know). But this does not work when you put the survey date on
> the changeset, as resurveyed, unchanged elements would not be marked
> with this "survey date".
>
> Putting a survey date on each element will have a huge impact on how
> people map. So they have to touch all objects they saw during their
> survey, just to indicate that they are still there (also stuff like
> housenumbers, i.e. things that do not change often or not at all).
>
> Wonder who's willing to do that.
*/survey/* cannot do wonders, it mainly supplements an important
shortcoming of /*source*/.
For example, it is better when the source is /*visual*/ to know when the
feature has been visualized, or when a source publication date is given
to know that there is no more recent one.
source=survey date is indeed covering a lot but is sensible for a plain
road, a house, a bus stop, as long as we restrict ourselves to the
essential (required) tags and not fancy adorning.
Else, no wonders, but it's certainly not a last edit date that will do
better and I just can't figure how overpass can be imagined to search
that data.

In fact, my proposed wiki update is nothing really new but a more
precise definition of what already existed and a welcomed use of the ISO
date.
> I've seen a discussion a long time ago where someone asked whether it
> is possible to mark an are as "done". But is an area ever done ? E.g.
> someone recently proposed to map street_cabinets. So all complete area
> would suddenly become incomplete, because you can map this new thing.
>
> Isn't a map
> like http://www.itoworld.com/map/127?lon=4.44997&lat=51.08258&zoom=13
> not enough ? It's generated automatically and show where the most
> recent edits were done.
> This wouldn't require additional effort from the mappers and is
> probably a good enough approximation, not ?
>
> regards
>
> m
>

_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Reply via email to