# [Tagging] Verifiability of geometry

Joseph Eisenberg joseph.eisenberg at gmail.com
Mon Jun 17 01:53:59 UTC 2019

Daniel, I find this whole conversation pretty off-topic for the
tagging forum. Perhaps "Talk" would be more appropriate, since you
closed the original discussion on github.

1)Simplification of geometries:

> There can be some simplification used (just beware of oversimplification, especially for bigger objects), but this is always worse than lack of simplification.

Have you every tried to edit an object that was imported badly, with
thousands of nodes a few meters apart?

I have edited riverbanks that were probably imported by a low-quality
automated process, and roads directly imported from GPS traces, and
they were very hard to fix (in retrospect I should have just deleted
them and redrawn from the new imagery...). That's why the "Fast
drawing mode" in JOSM always simplifies objects. Too many unnecessary
nodes is worse than too few. It's easy to add nodes to a rough sketch.
Removing badly drawn nodes is quite hard.

Database objects in OpenStreetMap are abstract representations of map
features, not precise copies of a satellite raster image.

2) Straits between curved coastlines:

>> straits between concave coasts are one dimensional entities, they have a width but they have no length.
> I see no support for this claim, so I completely don't agree with it:

The example is something like a wide strait between two small, thin
islands. Here the strait is just the point at the middle of the
channel between the two. You can't make a reasonable line or area out
of it, because both islands come to a sharp point, aimed at the
strait:

https://www.openstreetmap.org/node/3979746373#map=13/34.2944/135.0302

3) Node location verifiability:

>> the verifiability of a node location representing a feature exclusively depends on if multiple independent placements of the node converge to a single location. This is a completely scale independent problem meaning variance of different placements can be anywhere from less than a meter to hundreds of kilometers. This has no bearing on the principal verifiability.

>>>This sentence is very complex, I'm not sure what do you think.

Simplified: A node is verifiable if you get a bunch of different local
mappers together and ask them all to place a node (or move the node to
the correct location). As you add more and more nodes from more
people, the average location should become more and more accurate and
precise. There will always be a few outliers, but most of the dots
will be close enough together.

For a small object like an ATM, the nodes will probably be within a
few meters of each other, and the average location should be accurate
to the nearest meter or even the nearest 10 cm.

For a town, the nodes for the place=town will probably be a few 10s or
100's of meters apart, but the average location will probably be
within a circle of 10's of meters, since a town is much larger and
less precisely defined than an ATM.

For a large, vague feature like a sea, the nodes of different mappers
will probably be a many kilometers apart. Since the sea is 1000s of
times larger than the ATM and much less precisely defined, this is
normal, and it's good enough for a computer to guess where to place a
label and the size of a label on a map.

4) Gulf of Guinea

>When you have 4 different limits of the Gulf of Guinea for example ( https://commons.wikimedia.org/wiki/File:Limites_du_golfe_de_Guin%C3%A9e-fr.svg ), you will have 4 different central points which don't converge at all (the distance between the middle of A and D is roughly 1000 km), so using nodes does not help anything.

>At best one can put it in the A area as the common part of all of them, but this is indirectly choosing A area as proper, which is just hiding the problem, not getting rid of it.

We should choose the center of the smallest area that can be verified
to be that feature. For example, we don't label Paris as the
geographic center of Ile-de-France. Instead, we place the node near
the center of the main business district and historic centre of the
city of Paris, since this is where everyone can agree is in Paris.

You don't put the node of the place=city San Francisco in the middle
of the San Francisco bay, because that's the middle of the
metropolitan area, or the middle of the county. You don't even put it
in the middle of the land area of the city of San Francisco: you put
it near the city hall and the central business district, in the
northeast corner of the city on Market Street, because that's the
centre of San Francisco by the smallest definition (the historic
core).

Continued:

>The solution would be for example to ask local people from all 12 countries if they think this part of the coastline belongs to the bay and take their claim above what others (non-local people) say. At best, it will give you properly sourced shape. At worst, you may not get the consistent answer - then you might just simply not map it at all.

Ok, I'm a world traveler, but I'm not going to get visas for 12
African countries to map a single feature. This is impractical: that
is, it can't be done by most active OSM mappers, and certainly not by
local African mappers who should be in charge of their areas. And the
fact is that you won't get a consistent answer.

The most pratical source of data for a sea that covers multiple
countries would be old, historic maps in the public domain (eg USGS
maps of the world). Those old maps won't shown an area for the Gulf of
Guinea, they will just have a label near the center. That can help
place a node but it won't help you draw an area.

Fortunately, 2/3rds of the borders of the Gulf of Guinea are already
drawn: that's the coastline. If we have a node place 100 km off the
coast, that's enough to know that it should be shown starting at zoom
level z7 or z8 or something, and that's all a map-mapper needs to use
the information in the node. You don't need an area to make a map.

> We have areas for admin boundaries and coastlines, which are a burden, but
for the sake of verifiability we don't turn them into nodes for example,
out of the blue.

Coastlines are verifiable locally at every high tide

Administrative boundaries are not verifiable in all cases. That's why
I've mapped the "Kecematan" (Districts/counties) in Yahukimo as
place=county nodes - I know where the district office is located, but
there is not useful government map or dataset of the district borders.
I'd guess they are located at ridgetops and rivers, but I can't map
them until the government releases better data, since I would just be
guessing.

https://overpass-turbo.eu/s/JZs

There is no official source for the boundaries of most seas, straits
and bays on the high seas, so we can't rely on 3rd party datasets to
map these. The examples I've seen are low-quality and don't match
local information.

On 6/17/19, Daniel Koć <daniel at koć.pl> wrote:
> W dniu 16.06.2019 o 21:20, Christoph Hormann pisze:
>
>> You have stated disagreement with several of these statements but you
>> have not challenged them in any way by pointing out a logical error or
>> by arguing why the suggested approach how mappers should decide on how
>> to map things is of disadvantage to them or to the project as a whole.
>
>
> To have interpretation is not a logical error and I didn't claim that.
> But lack of objective support makes it just your opinion. It would be
> really bad if you would contradict yourself, but still it's just a weak
> point worth showing.
>
> Your strait definition for example does not contain logically fallacy,
> but is just unrelated to reality, as I have shown, which is still OK for
> philosophy, but bad for mapping, which is about actually representing
> the world outside. I think this is exactly disadvantage for the project.
>
>
>> I would suggest to you not to concentrate on your spontaneous emotional
>> reaction
>
> You did not see or hear me and you claim some personal statements, which
> are not only false, but also sound patronizing to me. Please, don't.
>
>
>> of dislike to views like mine that differ from your own but to
>> consider what objective arguments you have that support your position
>> and what long term consequences this would have.
>
> I have shown you a positive proposition of proper solving the problem of
> the example object. You have not shown that is logically wrong, so I
> guess it should enough for you, if you follow your own rules of proving,
> so here you lack some consistency.
>
> But what worries me more is that you just not even commented why this
> would be a bad thing for reasons other than logic.
>
>
>> You have made clear on a lot of occasions that you reject the concept of
>> verifiability as a
>
> No, I don't - it's just your interpretation.
>
> For some reason you claim that changing the type of geometry in the
> world of geometry into another type of geometry is OK. I wonder if you
> would change the name into some other name in the database? That's what
> I call verifiability. And I have not heard something like "verifiability
> is only for names and existence of the object", the verifiability of
> geometry was special case to make it clear. If you change the geometry
> in a subjective way, it does not sound like verifiable for me - you have
> introduced something virtual instead of real geometry.
>
> This rule does not tell anything about perceived expectations of
> mappers, but also nothing about perceived problems with maintenance. We
> have areas for admin boundaries and coastlines, which are a burden, but
> for the sake of verifiability we don't turn them into nodes for example,
> out of the blue. Even if they are huge and it means fixing them if they
> break.
>
>
> --
> "I see dead people" [Sixth Sense]
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>