On Nov 20, 2017, at 11:32 AM, Gleb Smirnoff <gleb...@glebi.us> wrote: > Hi Steve, > that was a long rant, I enjoyed reading it.
Thank you, but I'd call it "moderate length" for me, I can and do (infamously) rant MUCH longer, as many will attest. > Your retelling of my > words is way better than my original text, which you could quote. > I regret that I yet can't produce such a good text in English. > That's why often for me it is easier to yield rather than argue > and stand my position. I did quote (in several place) your original words, so I'm not sure what your point is here, apologies for my confusion. We must use SOME language to communicate, and while this is talk-us, (and the USA has no official language, but English IS widely used), we use English. I am multilingual, but as English is my native tongue, I prefer it to Polish, Hungarian, French or Spanish, as I wouldn't be anywhere near as fluent. Regrets I am unable to converse with you in Russian. Your English seems quite fluent to me, I encourage you to continue the conversation as best you might without feeling the need to simply yield because of your language skills, you write quite well (believes this user of English). > TL;DR version of my reply: I'm not going to touch OSM data in USA > anymore. I am disappointed you would take so extreme a stance, as I wish to see quality edits done by quality editors to increase OSM's quality, and you can and do perform such edits. What many here are asking you to do is to tone down or stop with the "multipolygonization" that you do so much of, especially as it changes existing and correct data (simple polygons, sometimes as part of an import of official data). Many agree there simply is no need to do this. Existing, correct, (sometimes imported) polygons are important to keep updated when needed, but this becomes difficult after your multipolygonization process. Especially as it uses a JOSM plug-in which while you are clearly facile at using, is not at all widespread in the USA. The process of multipolygonization is understood, especially by more technically advanced and seasoned OSM editors, but it is the process of CONVERTING existing polygons to multipolygons on a widespread basis where it seems there is no good reason for this to occur (and indeed even frustrates import updates). This is what we are asking you not to do (so much of). Again, I agree that the end-result of your data is technically correct, and indeed it makes sense to do this "sharing of ways" in certain use cases (we can both cite many examples — I have certainly done this myself in places). But to go to (especially imported) existing data and rework them into much more complex structures when their simplicity is both sufficient and correct seems not only a waste of your good time and editing skills, it makes it difficult for others. > A longer version (I'll try). I assume we all agree that overlapping > or not reaching polygons where there is adjacency on the ground is > wrong. "Not-reaching," meaning they create small gaps or "gores," yes, those polygons are technically wrong. Polygons with overlapping ways, even where they share nodes (and even if they don't share nodes), no, those are not wrong. You may believe that these are "sloppy" or have superfluous data, and you may even prefer your multipolygon approach, but what that does is replaces simple and correct data with complex and correct data. I and others here see little point in doing that, especially as it frustrates beginners and complicates import updates. > So how can we properly express adjacency?<redacted for brevity> We know. We agree. We simply don't think this is a good idea to go and do this on existing data (on a medium- or large-scale, as you and your JOSM plugin do) where to do so simply isn't needed, and indeed complicates further data editing. > Yes, advanced multipolygons is a professional tool, and newcomers > may find it confusing. Moreover, seasoned mappers who have spent > lot of time may in JOSM, but never encountered them, may also find > it difficult initially. Replies on this thread confirm that. But, > please, guys, don't refuse to learn something new, simply because > it is difficult! C++ is more difficult than Visual Basic, so let's > call it "terrible"? Come on, JOSM itself is difficult, but everyone > who groked JOSM, never returns to Potlach. We are not refusing to learn this. We agree your method of data entry is valid, as we do it (as Frederik so excellently offers us an example) as well, WHERE IT IS WARRANTED TO DO SO. And, THAT IS NOT EVERYWHERE. > Look at Frederik Ramm's reply on this thread. One of the longest > term OSM contributors and member of OSMF Board supports multipolygons. > Doesn't that doubt your conviction? Try it out, before refusing it. I have entered and edited thousands of OSM multipolygons: I and many others are are not "against them." What we are asking is that you not "convert" existing, simple (sometimes imported) polygon data into multipolygon data for no particular good reason, except that you have a JOSM plugin and decide to use it on a relatively large scale. I humbly submit to you, sir, that your good editing skills are much better spent on other, more important tasks, ones with less confusing results. Again, please don't misunderstand me: I wish our editors (both software and people) were better users of multipolygons, as they are quite useful, and indeed there are certain things which are impossible without them. Unfortunately, our editors (software and people) are not as facile with multipolygons as we would like. This will improve with time. In the meantime, let's agree that polygons are also correct data structures to use, and indeed are sometimes even preferred (as with imports). They are not wrong, they are not sloppy, they might use a bit more data, but to many, they are preferred. It is possible for more than one style of data to represent accurately the truth on the ground. > P.S. I know that my attempt to convince you would be as fruitless > as if I tried to convince you to use metric units :) I am one of the most metric system-using people in the USA that I know, I started being metric in the 1970s. Please, making such assumptions is fraught with peril. Let us not assume about each other, it makes for a better dialog and project in the long-term. Gleb, I signed my missive "with respect" as I do respect your editing. As members of this project, we do offer respect to one another: look at how generous Douglas was with you as he greatly extended himself to better and fully understand your approach in his changeset comments. I hope the message you hear is that we wish you to continue making good contributions to OSM, including in North America and USA. And also, that you hear many of us as we say "please, Gleb, ease up on the over-multipolygonization of existing data, especially as their polygons may be part of imports." Yes, it can be hard to know which data are imported and which are not. Yes, it can be hard to know when data should be "properly" multipolygonized and when not. We only ask that you listen and consider, and it looks like you have and do. Thank you, SteveA California _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
