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

Wed Jun 29 06:14:47 CEST 2022

There are probably millions of "false" nodes of building and landuse
digitized with older sources. Here
<https://www.openstreetmap.org/way/290722343> is one of many examples. As
stated at least two times earlier, of course they should be corrected
whenever better sources are available. In the case of a huge forest, yes it
probably does imply cutting some ways of the relation, deleting them and
correcting them. That's not the point I am trying to make, though.

Le mar. 28 juin 2022 à 23:02, Marc Mongenet <marc.mongenet at gmail.com> a
écrit :

> 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
>>
> _______________________________________________
> 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/20220629/aece5825/attachment-0001.htm>