We section long routes because it is very hard, if not impossible to keep big 
relations intact. Survey info would be entered on manageable sections. 

Mvg Peter Elderson

> Op 19 jul. 2018 om 23:41 heeft Warin <[email protected]> het volgende 
> geschreven:
> 
> There is a national route near me.. it is some 5,000 km long. Not many 
> walk/ride the entire length.
> 
> It is not complete in OSM, nor upto date. But there is a route .. broken in 
> places ...  I think of it as a guide rather than truth.
> 
> The survey:date would have to be added to each way of the relation and be 
> modified to survey:date:releationxxxx=*
> Sorry but I'm not doing for the 100s of ways involved ... too much work.
> 
>> On 20/07/18 07:06, Philip Barnes wrote:
>> 
>> 
>>> On 19 July 2018 20:57:20 BST, Peter Elderson <[email protected]> wrote:
>>> Just saw https://wiki.openstreetmap.org/wiki/Key%3Asurvey%3Adate
>>> Since survey:date is a documented tag, I will start using it to record
>>> route survey dates.
>>> Not on ways, but on sizeable hikingdare route relations.
>> A date on a hiking route relation is likely to be meaningless for the 
>> reasons already mentioned by DaveF. That being they will rarely be walked in 
>> their entirety but mappers will do sections here and there.
>> 
>> Using an example of my local long distance route, the Shropshire Way, I have 
>> systematically walked about half of it, so far that has taken over two 
>> years. Which date do I put on the relation?
>> 
>> Phil (trigpoint)
>> 
>>> See if I can get fellow mappers and walking route operators to join the
>>> effort.
>>> 
>>> 2018-07-19 18:39 GMT+02:00 Peter Elderson <[email protected]>:
>>> 
>>>> Thanks for the warning. Of course it is not the idea to delete
>>> anything
>>>> except when proven wrong.
>>>> I meant: information from outside sources, such as gpx-trackings,
>>> which
>>>> are older then the last completed survey, should not be entered into
>>> OSM.
>>>> Also remember that I'm talking about route information, not mapped
>>>> physical objects. We're not mapping individual waymarks, but routes
>>>> indicated by waymarks. Even if you remove the route relation, nothing
>>>> physical is taken from the map.
>>>> 
>>>> The survey date is the key data element here, if any kind of
>>> systematic
>>>> maintenance to the route relations is setup. Will it take? I don't
>>> know.
>>>> We'll see. The check&maintenance system for cycle node network and
>>> walking
>>>> node networks (vmarc.be) works like a charm, so I have good hope)
>>>> 
>>>> 2018-07-19 17:02 GMT+02:00 Kevin Kenny <[email protected]>:
>>>> 
>>>>> On Thu, Jul 19, 2018 at 7:22 AM Peter Elderson <[email protected]>
>>>>> wrote:
>>>>>> The goal of the idea is to tag the date of the last reality check.
>>> The
>>>>> best thing I have now is the date of the last edit, which most of
>>> the time
>>>>> results from e.g. a mapper's action (cut or remove) on a way that's
>>> part of
>>>>> the route relation.
>>>>>> I want to ensure that the route in the field and the route
>>> relation
>>>>> stay in sync, and when they don't (which is a 100% certainty) that
>>> you can
>>>>> tell at what point in time it did match.
>>>>>> Information older than that date (e.g. gpx-tracks) can be
>>> discarded,
>>>>> newer information can be entered, and edits after the survey date
>>> are new
>>>>> info which should be kept.
>>>>> 
>>>>> Keeping the field survey up to date is a laudable goal, and I've no
>>>>> objection to some sort of tagging that reports "this geometry was
>>>>> field surveyed on <date>." Making it fit with the data model will be
>>>>> challenging; it's not something that can be easily automated, given
>>>>> the variety of mappers' workflows.In the current world, to make
>>>>> something like this a reality you have to have an individual or
>>>>> organization that becomes the de facto 'owner' of the route and
>>> keeps
>>>>> track of its own surveys - and that isn't very OSMish. I think this
>>>>> could be worked around with sufficient cleverness.
>>>>> 
>>>>> But please, please, don't discard data older than a certain date.
>>> OSM
>>>>> is a very young project as geography goes. While out-of-date data
>>> can
>>>>> be misleading, the right thing to do is to inform, not to delete,
>>>>> particularly in cases where the out-of-date information is the only
>>>>> information that is available. It may also be the only information
>>>>> that can guide in recovering from an act of vandalism or a
>>>>> badly-considered import.
>>>>> 
>>>>> Perhaps I'm coming at this from the 'wrong' perspective. since a
>>> fair
>>>>> amount of my mapping is of features that nobody has yet seen fit to
>>>>> map at all, or that were once imported from external data that I
>>>>> consider hallucinatory. If someone with a GPS found a route passable
>>> a
>>>>> decade ago, that's a piece of information that I now have that I
>>>>> wouldn't have had otherwise. It could be that the route is no longer
>>>>> passable, has been relocated, or has been demolished, but without
>>> the
>>>>> old data, what reason do I have even to go and find out?
>>>>> 
>>>>> Moreover, the land remembers. I've been on trips where abandoned
>>>>> tracks and the grades of dismantled railroads, a century old and now
>>>>> grown to trees, have been important landmarks. I have no qualms
>>> about
>>>>> not showing them on a general-purpose map, but to an off-trail
>>> hiker,
>>>>> they are waymarks for eyes to see that can.
>>>>> 
>>>>> The right thing to do with 'stale' data - perhaps even 'proven
>>>>> incorrect' data - is to inform, not to discard.
>>>>> 
>>>>> _______________________________________________
>>>>> Tagging mailing list
>>>>> [email protected]
>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Vr gr Peter Elderson
>>>> 
> 
> 
> _______________________________________________
> Tagging mailing list
> [email protected]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to