[Tagging] Accuracy of survey

[Warin]

On 30/12/2014 6:41 AM, tagging-request at openstreetmap.org wrote:
> Date: Mon, 29 Dec 2014 15:27:23 +0100
> From: Kotya Karapetyan <kotya.lists at gmail.com>
> To: Rainer Fügenstein <rfu at oudeis.org>, "Tag discussion, strategy and
> 	related tools" <tagging at openstreetmap.org>
> Subject: Re: [Tagging] Accuracy of survey
> Message-ID:
> 	<CAK2dJ-wHwQAJZ+0-OXjUE9Bhn-w1eLdcYPM4Am4xidn2Fp5PeA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> Since such reference points are quite common, I would support the idea of
> creating a special tag for them, requiring that they are not moved. However
> we need a clear consensus on how we define the "sufficient" accuracy and
> how the data for such points will be updated.
Ultimate 'accuracy'? You do realise that the tectonic plates are moving? 
So your reference points need to include a date so they can be corrected 
for the drift. You'll find that data is available for those survey 
reference points .. together with their precision. Do you want to update 
these points to maintain their 'accuracy'? How often?
Survey reference points are 'quite common' in built up areas ... but not 
in remote locations. And depending an the age and how precise the survey 
was will have some effect on their 'accuracy'. One surveor in Australia 
forget to allow for the temperature effect on this measurement chain 
.... back when chains were used.
>
> I disagree with the point of view that an accuracy sufficient for consumer
> GPS devices is sufficient for OSM and therefore there is no problem here.
> Nobody ever declared that OSM is for smartphone users. We are trying to map
> the world, and accuracy should be of primary interest for this project.
>

Again the word 'accuracy'.

Context 1.
I have advised one mapper in their diary that most, if not all, users 
will be using their data entry with similar equipment to what they have 
.. so any 'inaccuracy' will also be present for the other users. Thus 
what they map should represent what is there and should be usable as a 
map .. considering that the GPS information may be very vague under the 
tree cover present and the local cliffs etc.

Context 2
I will be mapping a track that is covered in a few places  .. by an over 
hanging cliff. As such it is not visible by satellite .. nor will the 
GPS track be that 'accurate'. So I'll be mapping it from the available 
information that I have then - a few photos, my track and the satellite 
image. It will take me about a week to traverse the area. No shops etc.

I would rather have the less 'accurate' representation of what is there 
compared to a blank area. I've plotted one track that goes from one 
place to another (personal knowledge).. where it is not visible on the 
satellite view I've plotted it as a straight line.. I know it is not a 
straight line but it is the best I can do and conveys the information 
that the track is connected, and being straight in that hilly area also 
conveys that the information is a guide. I know there is a similar tack 
a bit north of this track .. but cannot reliably get the entry and exit 
points .. so have left that off as I view it as unreliable for use.  I 
have come across similar in other areas of the world .. but I found the 
satellite image had better information - so 'improved' the information.

--------------------------
OSM primary interest?
1) to be USEFULL.
  meaning to have information desired by the user
sufficient representation and detail  to be able to navigate to a 
desired place.

Many usefull maps have distortion - to include more details on 
particular objects or to simply emphasise to those objects.

OSM renders distort road widths according to their classification .. 
that is normal mapping for road navigation. If you wanted air navigation 
then the actual road width would be better to render, with runways 
having more emphasis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20141230/3b12ef8e/attachment.html>