[Talk-us] Multipolygonizing

[Gleb Smirnoff]

   Steve,

On Mon, Nov 20, 2017 at 12:23:53PM -0800, OSM Volunteer stevea wrote:
O> I did quote (in several place) your original words, so I'm not sure what your point is here, apologies for my confusion.
O> 
O> 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).

Of course I am not suggesting to use other language in US :) I just explained,
that as a discussion follows technical context, I am closely to par with native
speakers. But as it falls off, I really can't produce good texts. Writing the
previous reply took nearly an hour of my time! :) The other option was "screw
it up guys, I'm going home", which is yield and abandon these and future edits.

And retelling someone's words really makes different to quoting them. Even
without an explicit manipulation of sense the connotation changes.

Ok, let's get back on topic.

Looks like the acception of multipolygons here is not as bad as I initially
read in this email thread. So, we agree that at some level they are easier
to maintain that shared nodes. Do we?

Of course multipolygonizing couple of buildings that touch coastline in
Monterey was wrong. Sorry, I was in a multipolygonizing rage as I was
going through the coastline. :)

But the rest of the coastline? The nodes can be shared by any of:
1) coastline, 2) beach 3) county & state borders 4) marine preserve.
And there are ten's of thousands of nodes, because this is a natural
crazy curved line. This is the most clear example of where multipolygons
are way easier to draw and maintain than running multiple lines through
the same set of nodes!

O> ... 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).

Well, OSM started in 2006 and support for advanced multipolygons appeared
in 2011 (correct me if I am wrong). So, at time they came in there were
already fairly enough data in the database. Should we treat OSM as "write
only" database? E.g. we only add data, but don't improve already entered?
The advanced multipolygons appeared because there was a demand for them,
so why not use them for existing data, if resulting product becomes better?

Now, for the import updates. Here I am starting to understand the strong
pushback against my edits. Import updates is something I never heard
about! Please tell me more about that. Because in all other places that
I have edited (Russia, Ukraine, Georgia) imports were treated as something
that comes in once, and then is adopted into OSM. Do I understand you
correct that here you got recurring imports, where the import script needs
to find the object it created previously and edit it? Shoudn't this object
be protected then? At least a tag note="DO NOT EDIT ME"?

O> > A longer version (I'll try). I assume we all agree that overlapping
O> > or not reaching polygons where there is adjacency on the ground is
O> > wrong.
O> 
O> "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.

Actually by overlapping I meant polygons with non-zero shared surface.
I still assume you agree that this is wrong.

Those that share ways, or share nodes, or use different nodes with
exactly same coordinates, aren't overlapping, they are adjacent. Yes,
they are technically correct! However, maintaining them is a hell.
If you want to create an object that reuses already existing curves
in the database, you need to do a lot of click-job.

O> > So how can we properly express adjacency?<redacted for brevity>
O> 
O> 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.

I still stand that it makes easier further data editing. :(

All these coastline multipolygonizing was prerequisite to importing
State Marine Reserves. And indeed after preparations adding SMR
boundaries was 100x times easier. Here is example changeset of
adding a couple of SMRs once coastline is multipolygon:

http://www.openstreetmap.org/changeset/47115827

How small and concise it is! And if next year Department of Wildlife
will announce a new one, adding it would be again a minute task.

O> ... 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.

Sure, I don't claim that polygons are incorrect. I just find out that
at some level of map detail and fullness they are much more difficult
to maintain than advanced multipolygons. Yes, I mistakenly assumed
that everyone is familiar with the reltoolbox plugin, which is an
important part of making multipolygons easier.

Here is example, please open the area around this meadow in JOSM:

http://www.openstreetmap.org/relation/5926445#map=15/55.8569/37.2520

Just browse around in JOSM and try to do edits without committing them.
Add imaginary natural preserve there, or a military closed area. Or imagine
you want to go to higher detail, so you want to split existing forest into
a forest and a scrub. Anything that follows existing lines, can be instantly
added, with as much clicks as there are _lines_ in the boundary. Lines, not
nodes!

Compare that area to what we have around Santa Cruz. Imagine we could do
it better :)

O> 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.

I'm open to listen and learn about updated imports. Let's see how bad is
my damage, can it be resolved and how we can try to coexist the advanced
map management with imports.

-- 
Gleb Smirnoff