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

[RB]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.ch/pipermail/talk-ch/attachments/20220628/a62c7abd/attachment-0001.htm>