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