[talk-ch] vandalism under the pretense of "simplifying"

Tue Jun 28 23:01:28 CEST 2022

The user of a map always expects the ground to be more detailed than the
map, not less. So an untrue angle on a low-detail map is just an
expected imprecision. But an angle on a high-precision map that cannot be
found on the ground is an error. That's why a map should never contain more
nodes that can be actually sourced on the ground.

Here is an example of what I think is map-damaging over-use of nodes:
https://www.openstreetmap.org/way/486080164#map=19/46.12555/7.04733
As can be seen in
https://www.google.fr/maps/@46.1258023,7.0471608,3a,66.5y,229.3h,96.9t/data=!3m6!1e1!3m4!1sQVDSGzUZz5Y7Z2ArooH30Q!2e0!7i13312!8i6656
the landuse limit is straight from the road to the broadleaved tree.
But the OSM way contains at least 22 nodes (and as many angles) between the
road and the tree, which are wrong, and should be deleted from the map. But
it is so much work to fix so many nodes that I would probably delete the
whole way and trace a new one if I decided to fix it.

Marc

Le mar. 28 juin 2022 à 22:19, RB <tanrub at gmail.com> a écrit :

> That's the whole point. We clearly see a regression, untrue angles, etc
> because the user uses an simplifying tool (probably
> https://josm.openstreetmap.de/wiki/Help/Action/SimplifyWay ) instead of
> manually simplifying while staying as close to the ground truth as
> possible.  That's the whole point I am trying to make. Of course improving
> incorrect data is desirable. Of course achieving the same "truth" with
> fewer nodes is desirable.
>
> Altering the data and regressing from the truth with automated tools
> because of personal opinions of what the data should be or not be is not.
>
>
>
> Le mar. 28 juin 2022 à 22:11, RB <tanrub at gmail.com> a écrit :
>
>> Why not both? The surface and the individual trees when available? And if
>> possible the species of the trees... It would be time consuming though. It
>> reminds me a nice
>> <https://en.wikipedia.org/wiki/On_Exactitude_in_Science> short story of
>> Borges <https://en.wikipedia.org/wiki/On_Exactitude_in_Science>, but I
>> am afraid we digress.
>>
>> Le mar. 28 juin 2022 à 21:58, Kt47uo5uVzW <kt47uo5uVzW at protonmail.com> a
>> écrit :
>>
>>> You are right that "map for the server" should not be applied. But in my
>>> opinion, this discussion is not primarily about this argument, but rather
>>> about the discussion of how precise mapping makes sense for a forest.
>>>
>>> Just for my interest: when you talk about "precise data", could you
>>> possibly explain with this example what you find "precise" about it?
>>> https://www.openstreetmap.org/way/1073747263
>>> Presumably you could have tagged every single tree with less number of
>>> nodes. Why not just like this? Wouldn't it be more precise?
>>>
>>> I also don't think that these mappers had bad intentions or even
>>> "attacked" OSM. It's just different views on what level of detail makes
>>> sense in reality. At least I and some others share the opinion of these
>>> mappers. That is why I find the discussion important and hope that we
>>> would find a good Swiss compromise.
>>>
>>>
>>> Sent with Proton Mail <https://proton.me/> secure email.
>>>
>>> ------- Original Message -------
>>> On Tuesday, June 28th, 2022 at 3:58 AM, RB <tanrub at gmail.com> wrote:
>>>
>>> Thanks a lot for the various replies.
>>>
>>> There are several things to unpack and the discussion is quite
>>> interesting.
>>>
>>> Regarding the risk of "memory overload", the wiki
>>> <https://wiki.openstreetmap.org/wiki/Micromapping> states that
>>> "(technical) increase of volume will increase requirements in processing
>>> power, *but Moore's law and cheaper hdds every year are always there*.
>>> This might be more complicated when we will speak about geospatial queries
>>> rather than simple linear read/write patterns." and there isn't any clear
>>> direction against micromapping. We are clearly dealing here with an
>>> arbitrary decision by one user. Similar to the principle of not "mapping
>>> for the renderer", I don't think that anyone should "map for the server",
>>> especially when acting upon a personal intuition in contradiction with the
>>> wiki and particularly before damaging other people's work.
>>>
>>> Regarding the possible imprecision, as Danilo pointed out, the
>>> appropriate way to deal with it would be to correct it / shift it, not to
>>> damage the data.
>>>
>>> Finally, I understand that different people have different more or less
>>> valid prejudices (including of course me) regarding openstreetmap. The
>>> healthy attitude consists in mapping differently, not attacking existing
>>> precise data. The argument thant "Valais still has so much potential" very
>>> much also applies to the data attackers. I would like to point out that
>>> this argument is somewhat childish considering the amount of "useful" data
>>> that I have contributed in Valais as well as in the developing world.
>>>
>>> Le lun. 27 juin 2022 à 22:36, Michael Flamm <michael.flamm at micoda.ch> a
>>> écrit :
>>>
>>>> In my point of view, the debate about the optimal precision of mapping
>>>> is an important one. I would very much welcome inputs from experts that are
>>>> able to evaluate potential memory overload impacts as well as increased
>>>> rendering calculation times linked to a massive rise of the number of nodes
>>>> for a given object.
>>>>
>>>> This being said, my main concern with « too precise » mapping is data
>>>> maintenance over time. For a lot of objects, « Ground Truth » is not a
>>>> permanent feature! For example, forest limits evolve over time, as well as
>>>> parking spaces alongside a street (just to mention another parallel
>>>> discussion thread).
>>>>
>>>> @RB: Having looked at some regions you pointed out, I saw quite a
>>>> number of imprecise landuse cover objects if checked against the SwissImage
>>>> aerials (that are only a few years more recent than the Digital Globe 2017
>>>> used for your initial mapping). How are you going to restore ground truth
>>>> for those objects? It will imply to slightly move hundreds or even
>>>> thousands of nodes, in other words a tremendous amount of work!
>>>>
>>>> If you like precise mapping, maybe checking buildings and landuse cover
>>>> in urban areas might bring more added value to the map? (especially in
>>>> areas where construction works continually lead to much more relevant map
>>>> changes).
>>>>
>>>>
>>>> Le 27 juin 2022 à 16:08, Sentalize <sentalize at yahoo.de> a écrit :
>>>>
>>>> I'm not sure this is an "attack" .. in the case cited, I find the
>>>> simplified version not that much worse. How many nodes do we want in an
>>>> object? 10 per meter? 10'000? Beauty is in the eye of the beholder, of
>>>> course, and I as well prefer a somewhat nicely rounded road than a triangle
>>>> etc .. but it's not very clear where too much becomes too much. Extreme
>>>> detail doesn't necessarily provide a better rendered image or more
>>>> information and could just lead to overloaded mobile devices. But I have no
>>>> idea where the ideal nodecount should be.
>>>>
>>>> Am Montag, 27. Juni 2022 um 11:38:26 MESZ hat RB <tanrub at gmail.com>
>>>> Folgendes geschrieben:
>>>>
>>>>
>>>> A user is destroying precise landuse mapping in Wallis. "Simplifying"
>>>> in this case turns precise landuse cover into weird angles and destroys the
>>>> work done by the previous contributors while harming the OSM database. Such
>>>> moves could furthermore clearly be perceived as aggressive.
>>>> Typical examples of the vandalism can be observed there
>>>> https://www.openstreetmap.org/way/965324922/history#map=19/46.02973/7.11287
>>>>
>>>> What is the appropriate way to react to such attacks against the
>>>> project?
>>>> _______________________________________________
>>>> talk-ch mailing list
>>>> talk-ch at openstreetmap.ch
>>>> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
>>>> _______________________________________________
>>>> talk-ch mailing list
>>>> talk-ch at openstreetmap.ch
>>>> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
>>>>
>>>>
>>>> _______________________________________________
>>>> talk-ch mailing list
>>>> talk-ch at openstreetmap.ch
>>>> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
>>>>
>>>
>>> _______________________________________________
>>> talk-ch mailing list
>>> talk-ch at openstreetmap.ch
>>> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
>>>
>> _______________________________________________
> talk-ch mailing list
> talk-ch at openstreetmap.ch
> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.ch/pipermail/talk-ch/attachments/20220628/7cb7942e/attachment-0001.htm>