Re: [Talk-us] Multipolygonizing

[Rihards]

On 2017.11.20. 23:29, Kevin Kenny wrote:
> I'm somewhat relieved to hear Gleb and Frederik injecting a voice
> indicating that 'shared ways' separating regions might be an
> acceptable approach, because I've adopted it myself. Well, to some
> extent, any way.
> 
> I'm generally against sharing ways EXCEPT when topology demands it -as
> it often does. It's pretty nonsensical to start going to shared ways
> just because a building abuts a parking field, for instance.

revisiting this thread, i have to clarify that multipolygons for big
objects like administrative areas, large national parks and similar
entities seem fine to me, and often are the only reasonable approach.

where they do not seem to provide benefit and only make things much
harder are smaller objects - think most
residential/commercial/industrial landuse, parking areas, buildings
(except where used to "cut a hole" in a building).

i got reminded about this when attempting to improve a fuel station
recently. i intended to split car wash in a separate area, move tags
from a node to area and similar. in this case, the serviceway area
around the building, the building itself, the grassy areas there - they
all were mapped as multipolygons from short way segments.
i could have untangled that, but it would take some time. i gave up.

> Still, if two adjacent polygons are the same sort of thing, or
> specifically defined to be conterminous, then I certainly want to
> share the boundary. By the "same sort of thing," I mean administrative
> regions that share a boundary, or different land uses (following our
> presumption that a piece of land has only one land use), or different
> types of land cover (including water). And 'specifically defined to be
> coterminous' includes things like parks that stop at a waterfront.
> 
> I would tend to avoid shared ways for things like a wood that stops at
> the boundary line of a protected area. The trees don't know where the
> boundary is, and the boundary won't move if the adjacent landowner
> allows his plot to go back to nature.
> 
> There are several reasons for shared ways between topologically adjacent 
> areas.
> 
> (1) Data consistency. This is the primary reason. As Gleb points out,
> if a shared boundary is a single way, there's no chance that someone
> will retrace the boundary of one of the neighbouring regions without
> retracing the other, or will enter them inconsistently in the first
> place.
> 
> (2) Rendering. We've already discovered for boundary=administrative
> that representing bordering regions as separate polygons sharing only
> nodes rules out using things like dashed-line rendering, because each
> boundary will be rendered twice, and there is nothing to ensure that
> the dashes will be in the same relative phase; dashed lines tend to
> turn into solid lines in such a scheme. That's one of several reasons
> that we have tried to keep shared ways on all boundary=administrative
> meshes. I foresee in the future (and already confront in my own
> rendering) cases where protected areas, or even things like
> leisure=park, are rendered similarly and therefore need shared ways to
> get a clear display.
> 
> (3) Ease of editing (for better-informed or better-tooled users). At
> least for me, working in JOSM, I find updating a mesh of multipolygons
> with shared ways to be fairly straightforward. Split the ways at any
> new corners, draw any new ways, update the touching regions, delete
> any obsolete ways. Sure, it's a different workflow than the one for
> simple polygons, but for that workflow, I find myself retracing over
> long sets of points, or else splitting, duplicating, reversing and
> rejoining ways. The duplicated ways are difficult to work with, since
> they share all the points, and I have to puzzle over some pretty
> subtle things to understand which copy I'm working with. By contrast,
> the split and joined ways in a shared-ways structure always have
> distinct geometry.
> 
> By contrast, the chief argument against multipolygons is that they are
> unfriendly to newcomers.  I'll happily concede this point in part.
> They certainly demand a somewhat deeper understanding of the data
> model, and the newcomer-friendly tools such as Potlatch don't really
> do them competently. This argument is stronger that Gleb and Frederik
> appear to recognize. Given the difficulty of recruiting mappers, we
> surely want to make life as easy as possible for newbies, even if that
> comes at some expense in the ease of use for the old hands.
> 
> That said, how likely is a newcomer to be editing a complex mesh of
> land use or land cover and not mess up the topology, however it's
> represented? I suspect that new mappers attempting to adjust these
> features will always wind up creating overlaps, gores and broken
> multipolygons. (SOME multipolygons are unavoidable because areas have
> enclaves or exclaves!) Moreover, part of the newcomer-unfriendliness
> comes from the fact that examples of shared ways 

Re: [Talk-us] Multipolygonizing

[Andy Townsend]

On 20/11/2017 23:30, Ian Dees wrote:


Please remember to stay on topic and friendly. This thread seems to be 
drifting off into a discussion about the merits of OSM editors.


Well, my comment about editors wasn't supposed to be offtopic, since the 
question of data being "... far easier to understand and maintain, 
especially for novice mappers" was one of the points raised at the very 
top of the thread.


It's perhaps worth mentioning that in each of iD, P2* and JOSM (without 
plugins) it's possible to swap without too much difficulty between the 
two relations and the constituent ways at 
http://www.openstreetmap.org/#map=19/36.62063/-121.90621  P2's internal 
visualiser fails with the park visualisation though, and I can't see a 
way to select the marine nature reserve without deliberately selecting 
the "relations this way is a member of" at the left, so I'm still not 
convinced that this area is as newbie-friendly as it was before.


Best Regards,
Andy


* if you are surprised by this perhaps you haven't looked at one or 
another editor for a while - it might be worth revisiting.


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[OSM Volunteer stevea]

On Nov 21, 2017, at 1:27 PM, Gleb Smirnoff  wrote:
> Okay, I will withhold myself from touching polygons in the Santa Cruz County
> for next couple of years, and let's see how your future experience with
> SCCGIS goes on. We can get back to this question later in scope of Santa Cruz.

This is a very happy result, thank you for the good (if rather public in 
talk-us) dialog.  I think it was beneficial to the greater OSM community that 
our dialog was so public, as Kevin and I have been discussing "shared ways in 
multipolygons vs. regular polygons" off-list for some time, and I've always 
known this trend towards "shared ways" would deeply affect a large import I 
keep updated in my county.  I believe this topic has made other OSM 
importers/maintainers of mostly- or exclusively-polygon data wonder what the 
best course of action is as OSM evolves to "shared ways" becoming more and more 
common.  I hope it has helped a better consensus to emerge – it feels like it 
is doing so locally.

What is emerging (at least here, between me and Gleb) is that there will come a 
point in either initial/original imports that are largely or exclusively 
polygon-only when it simple becomes time to "bite the bullet" and do the 
initial work to convert these to multipolygon as the trend towards "shared 
ways" grows.  Yes, that is lots of work up front, but I believe in advance that 
it will be worth it in the editing time/efforts saved in the future as Gleb and 
Kevin have pointed out its many editing benefits.  (I agree it is easier to 
maintain such "edges," boundaries especially, including landuse, which are 
"shared ways" as multipolygons allow us to do.  EXCEPT in large, existing 
imports!).

> Meanwhile, do I understand that my initial understanding of strong consensus
> against multipolygons in the USA overall was wrong reading? First few emails
> in the thread made me think so.

Gleb, it was a sort of misunderstanding, and it doesn't seem important to lay 
blame on anybody in particular.  What is important is that we seem to agree 
that while polygons certainly have their place and aren't going away, 
multipolygons are here to stay as well, and there is a distinct trend towards 
using them in a "shared way" context where it makes sense to do so.  (The good 
examples that Kevin listed, likely more).  Yes, as Frederik said, it can be a 
matter of taste which is better, as both are correct (one is harder to edit in 
one context, the other is harder to edit in another context), and so we should 
not be spending time "converting" from polygons to multipolygons.  However, 
where it makes sense to use multipolygons in NEW data, let us enter them as 
such.

> I'd like to continue working on coastline, and map all remaining SMRs and
> later maintain them. I also want keep using multipolygons in any regular
> edits. Are there any objections?

If by "regular edits" you mean adding NEW data, no, I have no objection.  If 
you want to "convert" existing polygons to multipolygons, yes, I (and others) 
object.

Thank you once again for good, productive dialog!

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Joel Holdsworth]

On 21/11/17 14:29, Gleb Smirnoff wrote:

   Steve,

On Mon, Nov 20, 2017 at 04:34:18PM -0800, OSM Volunteer stevea wrote:
O> If the reltoolbox plug-in as as powerful as I am beginning to understand it 
may be (I appreciate the introduction, Gleb), and given my agreement that certain 
use cases (especially landuse) benefit greatly from multipolygonized boundaries 
(they do), I actually CAN imagine that the SCCGIS V4 landuse import data (in 2019 
or 2020) could become multipolygon.  This likely would involve a pre-upload 
translation of polygon data into mulitipolygon using the tool, then conflation 
(which has to be done anyway).  Except, we upload multipolygons as we delete 
existing polygons during the conflation-and-upload phase.
O>
O> I wanted to offer that bright spot of hope to anybody's lingering beliefs that I am 
"mule-entrenched" in my beliefs that existing polygons are always superior.  They are not.  
They make updates harder, but I think I can get over that, as I can be convinced that "once done, 
the time investment is worth it" for the future benefits that multipolygons bring.

Okay, I will withhold myself from touching polygons in the Santa Cruz County
for next couple of years, and let's see how your future experience with
SCCGIS goes on. We can get back to this question later in scope of Santa Cruz.

Meanwhile, do I understand that my initial understanding of strong consensus
against multipolygons in the USA overall was wrong reading? First few emails
in the thread made me think so.

I'd like to continue working on coastline, and map all remaining SMRs and
later maintain them. I also want keep using multipolygons in any regular
edits. Are there any objections?



I use multipolygons extensively for the land cover around Rocky Mountain 
National Park.


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Gleb Smirnoff]

  Steve,

On Mon, Nov 20, 2017 at 04:34:18PM -0800, OSM Volunteer stevea wrote:
O> If the reltoolbox plug-in as as powerful as I am beginning to understand it 
may be (I appreciate the introduction, Gleb), and given my agreement that 
certain use cases (especially landuse) benefit greatly from multipolygonized 
boundaries (they do), I actually CAN imagine that the SCCGIS V4 landuse import 
data (in 2019 or 2020) could become multipolygon.  This likely would involve a 
pre-upload translation of polygon data into mulitipolygon using the tool, then 
conflation (which has to be done anyway).  Except, we upload multipolygons as 
we delete existing polygons during the conflation-and-upload phase.
O> 
O> I wanted to offer that bright spot of hope to anybody's lingering beliefs 
that I am "mule-entrenched" in my beliefs that existing polygons are always 
superior.  They are not.  They make updates harder, but I think I can get over 
that, as I can be convinced that "once done, the time investment is worth it" 
for the future benefits that multipolygons bring.

Okay, I will withhold myself from touching polygons in the Santa Cruz County
for next couple of years, and let's see how your future experience with
SCCGIS goes on. We can get back to this question later in scope of Santa Cruz.

Meanwhile, do I understand that my initial understanding of strong consensus
against multipolygons in the USA overall was wrong reading? First few emails
in the thread made me think so.

I'd like to continue working on coastline, and map all remaining SMRs and
later maintain them. I also want keep using multipolygons in any regular
edits. Are there any objections?

-- 
Gleb Smirnoff

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Frederik Ramm]

Gleb,

On 11/21/2017 12:02 AM, Gleb Smirnoff wrote:
> 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. :)

We have a general (unwritten) convention in OSM and that is "don't force
your taste on other mappers".

When you edit data contributed by others, and you improve it with your
own knowledge or data collected on the ground, then nobody expects any
restraint from you - improve away!

However, in matters of taste - where you are NOT adding information, and
instead just changing the represenation of the data in the database - we
tend to say: It is for you to decide the style in which YOU contribute,
but do not try to overrule others and force your style on them.

(There's another issue that mappers never agree on, and that's whether
when there's a track on the edge of the forest and beyond that, a
meadow, all three should share nodes, or whether room is to be left to
the left and right of the track because "the forest doesn't end in the
middle of the track").

These things are matters of taste, and neither representation is more
correct or contains more information than the other; two stubborn
mappers at loggerheads could potentially re-style an area from one style
to the other and back every week.

Hence: Apply your personal style to new contributions that you make, but
don't go around applying it to contibutions made by others. This sort of
"cleanup" benefits few but your personal sense of orderliness, and your
time is better spent actually improving data instead of just fiddling
with how the same data is represented in the database.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[OSM Volunteer stevea]

Briefly (thanks for the reminder, again, Ian!):

If the reltoolbox plug-in as as powerful as I am beginning to understand it may 
be (I appreciate the introduction, Gleb), and given my agreement that certain 
use cases (especially landuse) benefit greatly from multipolygonized boundaries 
(they do), I actually CAN imagine that the SCCGIS V4 landuse import data (in 
2019 or 2020) could become multipolygon.  This likely would involve a 
pre-upload translation of polygon data into mulitipolygon using the tool, then 
conflation (which has to be done anyway).  Except, we upload multipolygons as 
we delete existing polygons during the conflation-and-upload phase.

I wanted to offer that bright spot of hope to anybody's lingering beliefs that 
I am "mule-entrenched" in my beliefs that existing polygons are always 
superior.  They are not.  They make updates harder, but I think I can get over 
that, as I can be convinced that "once done, the time investment is worth it" 
for the future benefits that multipolygons bring.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Kevin Kenny]

On Mon, Nov 20, 2017 at 6:15 PM, OSM Volunteer stevea
 wrote:
> Please, ENTER data using shared ways where it makes sense to do so.  Nobody 
> is saying "don't do that."  ALSO, please be aware that existing 
> NON-multipolygon data (especially imports and other "curated" data) may very 
> well suffer from the process of being "multipolygonized."  There is a balance 
> to be struck, and I would be very disheartened to see our map become "dumbed 
> down" by data which should be multipolygon somehow become twisted into not.

The cases where I have intentionally converted curated, imported data
to shared ways have all been in imports that I curate myself. I wind
up treating the result as being no different as any other imported
object that's subsequently been modified by a local mapper. If a
reimport discovers that the last user to touch the object wasn't the
import user ID, it flags the upstream data for manual conflation, and
does nothing. Even when it does find that it was the last modifier of
the object, the most it does is to prime JOSM with the proposed change
and let me confirm and commit. The largest data set that I work with
has a couple of thousand polygons. I've done two reimports, each of
which have changed a couple of dozen. Of those, a handful, few enough
to count on fingers, have been subsequently modified by local mappers.
While the initial import ran over a couple of months, an annual
reimport takes me maybe a couple of evenings.

Yes, I did hear a sentiment calling for "dumbing down" the map - and
it wasn't so much you specifically, as that the early returns appeared
to be shaping up into yet another Europe-North America divide. I know
that your position is considerably more subtle; we've discussed this
one fairly extensively already. I just really want to nip the idea in
the bud that simplicity is preferable to correctness.

I'm also fairly cross, because I've discovered in the last week that
two large multipolygon relations that I had spent hours on setting up
had been dismembered. Since they were born in an import (however much
manual editing and conflation was done), I'm not comfortable with
restoring the data, even though significant information has been lost
by the manual changes. In both cases, the topology was damaged by the
Potlatch user, who then 'repaired' things by moving tagging that had
been on the relation to some, but not all, of the outer ways of the
modified object. These were two different users. I suppose this
reinforces both the case that multipolygons should be used only as a
last resort and that imports damage the community, but I'm sad to see
regions of the map lose tagging that had previously been informative,
and begin to feel that my hands are tied from repairing them.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Ian Dees]

Hi everybody!

Please remember to stay on topic and friendly. This thread seems to be
drifting off into a discussion about the merits of OSM editors.

Also remember that long replies tend to result in people talking past one
another. Short, sweet, and to the point helps a conversation stay on topic.

-Ian
Your friendly talk-us moderator

On Mon, Nov 20, 2017 at 5:24 PM, Andy Townsend  wrote:

> On 20/11/2017 19:36, Gleb Smirnoff wrote:
>
>> Come on, JOSM itself is difficult, but everyone
>> who groked JOSM, never returns to Potlach.
>>
>
> Untrue.  Each of the OSM editors has strengths and weaknesses - it's
> simply a case of finding the best tool for the job.  In some cases that
> might be JOSM; in some cases it might be something completely different
> (StreetComplete?).  JOSM isn't the best at everything - it has a user
> interface out of the fifth circle of hell and seems intent on dragging the
> user straight back there.  It fails with some stuff that is "basic" to e.g.
> Potlatch (mapping with waypoints recorded with information in them as you
> go for example).  See questions such as https://help.openstreetmap.org
> /questions/7675/josm-is-it-possible-to-convert-an-individual
> -waypoint-in-a-gpx-file-to-a-node for a bit more discussion on that.
>
> Best Regards,
> Andy
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Andy Townsend]

On 20/11/2017 19:36, Gleb Smirnoff wrote:

Come on, JOSM itself is difficult, but everyone
who groked JOSM, never returns to Potlach.


Untrue.  Each of the OSM editors has strengths and weaknesses - it's 
simply a case of finding the best tool for the job.  In some cases that 
might be JOSM; in some cases it might be something completely different 
(StreetComplete?).  JOSM isn't the best at everything - it has a user 
interface out of the fifth circle of hell and seems intent on dragging 
the user straight back there.  It fails with some stuff that is "basic" 
to e.g. Potlatch (mapping with waypoints recorded with information in 
them as you go for example).  See questions such as 
https://help.openstreetmap.org/questions/7675/josm-is-it-possible-to-convert-an-individual-waypoint-in-a-gpx-file-to-a-node 
for a bit more discussion on that.


Best Regards,
Andy


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[OSM Volunteer stevea]

Kevin and others:  please do not misunderstand me.  There ARE times when shared 
ways between multipolygons is an elegant and THE correct solution, as you, I 
and many others have found to be true and edited into existence many times.  By 
no means do I advocate that where such beauty has been completed that it be 
torn apart and reverted to simple polygons, that would be a giant step 
backwards.  These solutions are NOT "too complicated," and it is a 
misunderstanding of what I have been saying in this thread to think so.

Your statement that "mechanical edits (often by the JOSM tool reltoolbox) 
running roughshod over carefully curated data" strikes at the bullseye of what 
I wish to convey.  Such trampling really makes updating imported (curated) data 
quite difficult, and OSM really DOES want to encourage the updating of imported 
data.  I AM saying:  please BE CAREFUL multipolygonizing polygons, especially 
where tagging or changeset data might indicate they are part of an import or a 
curated set of data.

It may be that as other geodata, especially those which align well with the 
idea that "shared ways are a good idea in these data," become better aligned 
with OSM's multipolygon data structure, this situation greatly improves.  Now, 
there is some alignment, though it is not perfect; for example, shapefile data 
imported into JOSM are either "OK after import" or "come close enough to easily 
fix" (in my opinion).  But concomitant with this is that OSM editors — 
software, novices, intermediates and experts alike — not be afraid of or 
intimidated by relations and/or multipolygons (and editing them).  While our 
"primitive types" of nodes and ways are relatively easy to learn, relations are 
not, but we MUST prioritize it as an important task that even beginning users 
better familiarize themselves and gain comfort with these more complex types of 
data — early, and often.

Please, ENTER data using shared ways where it makes sense to do so.  Nobody is 
saying "don't do that."  ALSO, please be aware that existing NON-multipolygon 
data (especially imports and other "curated" data) may very well suffer from 
the process of being "multipolygonized."  There is a balance to be struck, and 
I would be very disheartened to see our map become "dumbed down" by data which 
should be multipolygon somehow become twisted into not.

SteveA
California

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Gleb Smirnoff]

  Kevin,

On Mon, Nov 20, 2017 at 04:29:56PM -0500, Kevin Kenny wrote:
K> (3) Ease of editing (for better-informed or better-tooled users). At
K> least for me, working in JOSM, I find updating a mesh of multipolygons
K> with shared ways to be fairly straightforward. Split the ways at any
K> new corners, draw any new ways, update the touching regions, delete
K> any obsolete ways. Sure, it's a different workflow than the one for
K> simple polygons, but for that workflow, I find myself retracing over
K> long sets of points, or else splitting, duplicating, reversing and
K> rejoining ways. The duplicated ways are difficult to work with, since
K> they share all the points, and I have to puzzle over some pretty
K> subtle things to understand which copy I'm working with. By contrast,
K> the split and joined ways in a shared-ways structure always have
K> distinct geometry.

Thanks for this paragraph! This was text that was right on my tongue,
but I failed to wordsmith it properly.

-- 
Gleb Smirnoff

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Gleb Smirnoff]

On Mon, Nov 20, 2017 at 02:13:44PM -0800, OSM Volunteer stevea wrote:
O> Plug-ins that offer "power tools" beyond that?  Well, caveat usor.

Note that a large part of current JOSM base functionality before was
in plugins. So, doesn't make sense to diminish some tool because it
isn't in base. Whether some code goes into JOSM or stays as plugin is
driven by two things: 1) number of plugin users 2) willingness of plugin
author to yield his code to JOSM repo, meaning disown his code. And
for many people that also means lose commit access to their code.

-- 
Gleb Smirnoff

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[OSM Volunteer stevea]

Thank you, Kevin for your thoughtful and rather complete reply!

Mark Wagner  wrote:
> Of course, this only works for ordinary relations.  If the way you
> clicked on is shared by two or more relations, you need to go
> through the far more complicated method of playing with the
> relation-editor dialog.

It is no secret that using either iD or Potlatch for relation editing is 
difficult and error-prone, nigh unto impossible for novice editors to either 
understand or perform easily.  By contrast, while it does take some practice to 
learn, I find JOSM's relation editor to be a straightforward method to edit OSM 
relations.  In short, the "four pane dialog" (not strictly correct, but it 
pedagogically suffices) consists of "key-value pairs on top, (left and right); 
member elements and selections on bottom (left and right)."  Along with the 
buttons to the left of and between the bottom two panes (sort, reverse, select, 
move, ...), you have all you need to edit relations.  This is a modeless (not 
modal) dialog, meaning that while the relation editing window is open, 
selections (e.g. click, drag a selection box...) and operations (e.g. split or 
join...) can/should be performed on underlying data in the geography editing 
window.  Taken together, these are the seeds of learning how to effectively 
edit relations in JOSM.

Plug-ins that offer "power tools" beyond that?  Well, caveat usor.

I wholeheartedly agree with much said in this thread:  both polygons and 
multipolygons are perfectly valid data structures to use in cases where 
choosing one or the other is a matter of taste, preference, use-case, or all 
three.  (Some uses absolutely require multipolygons, and that is that, other 
uses offer a choice of polygons OR multipolygons, where one or the other are 
equally correct).  Notwithstanding JOSM's current paradigm noted above, our 
tools have a ways to go before they present simple methods to edit relations 
(type multipolygon or others) so that all and sundry are comfortable editing 
them.  OSM gets better at this, though it is taking some time to get there.

I believe a most important result from this thread is that there are many use 
cases where either polygons OR multipolygons are correct.  Really, we are not 
very far apart from rather fully agreeing with one another.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Kevin Kenny]

I'm somewhat relieved to hear Gleb and Frederik injecting a voice
indicating that 'shared ways' separating regions might be an
acceptable approach, because I've adopted it myself. Well, to some
extent, any way.

I'm generally against sharing ways EXCEPT when topology demands it -as
it often does. It's pretty nonsensical to start going to shared ways
just because a building abuts a parking field, for instance.

Still, if two adjacent polygons are the same sort of thing, or
specifically defined to be conterminous, then I certainly want to
share the boundary. By the "same sort of thing," I mean administrative
regions that share a boundary, or different land uses (following our
presumption that a piece of land has only one land use), or different
types of land cover (including water). And 'specifically defined to be
coterminous' includes things like parks that stop at a waterfront.

I would tend to avoid shared ways for things like a wood that stops at
the boundary line of a protected area. The trees don't know where the
boundary is, and the boundary won't move if the adjacent landowner
allows his plot to go back to nature.

There are several reasons for shared ways between topologically adjacent areas.

(1) Data consistency. This is the primary reason. As Gleb points out,
if a shared boundary is a single way, there's no chance that someone
will retrace the boundary of one of the neighbouring regions without
retracing the other, or will enter them inconsistently in the first
place.

(2) Rendering. We've already discovered for boundary=administrative
that representing bordering regions as separate polygons sharing only
nodes rules out using things like dashed-line rendering, because each
boundary will be rendered twice, and there is nothing to ensure that
the dashes will be in the same relative phase; dashed lines tend to
turn into solid lines in such a scheme. That's one of several reasons
that we have tried to keep shared ways on all boundary=administrative
meshes. I foresee in the future (and already confront in my own
rendering) cases where protected areas, or even things like
leisure=park, are rendered similarly and therefore need shared ways to
get a clear display.

(3) Ease of editing (for better-informed or better-tooled users). At
least for me, working in JOSM, I find updating a mesh of multipolygons
with shared ways to be fairly straightforward. Split the ways at any
new corners, draw any new ways, update the touching regions, delete
any obsolete ways. Sure, it's a different workflow than the one for
simple polygons, but for that workflow, I find myself retracing over
long sets of points, or else splitting, duplicating, reversing and
rejoining ways. The duplicated ways are difficult to work with, since
they share all the points, and I have to puzzle over some pretty
subtle things to understand which copy I'm working with. By contrast,
the split and joined ways in a shared-ways structure always have
distinct geometry.

By contrast, the chief argument against multipolygons is that they are
unfriendly to newcomers.  I'll happily concede this point in part.
They certainly demand a somewhat deeper understanding of the data
model, and the newcomer-friendly tools such as Potlatch don't really
do them competently. This argument is stronger that Gleb and Frederik
appear to recognize. Given the difficulty of recruiting mappers, we
surely want to make life as easy as possible for newbies, even if that
comes at some expense in the ease of use for the old hands.

That said, how likely is a newcomer to be editing a complex mesh of
land use or land cover and not mess up the topology, however it's
represented? I suspect that new mappers attempting to adjust these
features will always wind up creating overlaps, gores and broken
multipolygons. (SOME multipolygons are unavoidable because areas have
enclaves or exclaves!) Moreover, part of the newcomer-unfriendliness
comes from the fact that examples of shared ways are sparse, and tend
to be on stable things like administrative regions, the shorelines of
large waterbodies, and similar features that newcomers are
(rightfully) a little afraid to edit in the first place.  Heck, how
many newcomers will even recognize that topology is important?

I may have a somewhat warped view of things. I got into using shared
ways when tidying conflicting imports of various public lands in New
York State, where there were many gores among county and township
lines, shorelines, and the boundaries of various sorts of protected
area. The boundaries are topologically complex, and being constrained
to deal with them by retracing partial ways would be a nightmare.
Shared ways was really the only approach that worked, and from what I
hear, for complex cases, it's still considered acceptable. That's a
relief!

Once I became fluent with the approach of using shared ways, I've come
to use it when, for instance, adding landcover or land use polygons
even in my own neighbourhood. Even there, it 

Re: [Talk-us] Multipolygonizing

[Gleb Smirnoff]

On Mon, Nov 20, 2017 at 11:43:34AM -0800, Mark Wagner wrote:
M> > (I couldn't for the life of  me figure out how to add a way to a
M> > relation!)
M> 
M> Select a way currently part of the relation.  Shift-click on the way
M> you want to add.  Select "Update multipolygon" from the "Tools" menu,
M> or hit Ctrl+Shift+B.  Simple.
M> 
M> Of course, this only works for ordinary relations.  If the way you
M> clicked on is shared by two or more relations, you need to go
M> through the far more complicated method of playing with the
M> relation-editor dialog.

Or use "reltoolbox" plugin, where there is a notion of current  
 
relation, and while you got your relation selected as current,  
 
adding or removing objects to it is clicking "+" or "-" icon on 
 
the sidebar, having object selected. For multipolygons it will also 
 
set "outer" or "inner" role automatically.  

-- 
Gleb Smirnoff

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[OSM Volunteer stevea]

On Nov 20, 2017, at 11:32 AM, Gleb Smirnoff  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?

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 

Re: [Talk-us] Multipolygonizing

[Joel Holdsworth]

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. So how can we properly express adjacency? The simple way is
to run two polygons through the same subset of nodes. The advanced
is to separate this subset into a single line, which will now
belong to two multipolygons. I will try to convince you that using
advanced is easier, when it comes to "heavy" objects, like landuse=
or natural=. Imagine someone has mapped a forest, with a good
detail, precisely following its border with a farmland. Now you
want to map this farmland. In the simple way you need to follow
all nodes your predessor had drawn, clicking all the nodes, be it
25 nodes or 100. In the advanced way, you don't. You instantly
reuse his line for your new polygon. This was a most typical example
of benefits that advanced multipolygons provide.




I use them for this all the time.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Mike N]

On 11/20/2017 2:36 PM, Gleb Smirnoff wrote:

In the simple way you need to follow
all nodes your predessor had drawn, clicking all the nodes, be it
25 nodes or 100. In the advanced way, you don't. You instantly
reuse his line for your new polygon. This was a most typical example
of benefits that advanced multipolygons provide.


  This is a good example where multipolygons make sense.   I have run 
into this in the past and naturally migrated to a multipolygon instead 
of clicking through hundreds of nodes.


  However for smaller landuse areas such as residential neighborhoods 
or shopping centers, there may be only 4-20 nodes per adjacent polygon. 
 For those cases, I find that multipolygons only increase the load on 
future maintenance and present a major confusion factor for new users.


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Gleb Smirnoff]

  Hi Steve,

that was a long rant, I enjoyed reading it. 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.

TL;DR version of my reply: I'm not going to touch OSM data in USA
anymore.

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. So how can we properly express adjacency? The simple way is
to run two polygons through the same subset of nodes. The advanced
is to separate this subset into a single line, which will now
belong to two multipolygons. I will try to convince you that using
advanced is easier, when it comes to "heavy" objects, like landuse=
or natural=. Imagine someone has mapped a forest, with a good
detail, precisely following its border with a farmland. Now you
want to map this farmland. In the simple way you need to follow
all nodes your predessor had drawn, clicking all the nodes, be it
25 nodes or 100. In the advanced way, you don't. You instantly
reuse his line for your new polygon. This was a most typical example
of benefits that advanced multipolygons provide.

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.

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.

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 :)

On Mon, Nov 20, 2017 at 09:58:53AM -0800, OSM Volunteer stevea wrote:
O> I very much agree with Douglas and Rihards that glebius' mapping is (around 
here) unusual, "terrible" and difficult to parse, even for experienced mappers 
who have been mapping for most of the history of OSM, like me.  Glebius is 
right in my backyard and I've found his coastal "restructurings" (e.g. 
http://www.osm.org/changeset/46756097) to be bizarre and unnecessary, often 
overwriting correct official (county GIS imported) data simply to not "share 
some nodes" or "improve the mess."  He claims that "the consensus in Russia is 
that advanced polygons is the way to go."  Well, not here, I assure both 
Glebuis and the talk-us list of that unequivocally.
O> 
O> Glebius uses a JOSM plugin (and it AMAZES him that this functionality has 
not yet been built into JOSM's base code!) called "reltoolbox."  It promulgates 
what he calls "advanced multipolygons" and in the below-noted changeset 
acknowledges that he believes these "became a world wide consensus," but of 
course, they have not.  Glebius has glibly assumed reltoolbox and its resulting 
data is widespread, when in fact it is not:  neither locally, regionally, nor 
continentally.  He further says the "quality of OSM data in USA is much worse 
than in other countries" when in fact, my small county of Santa Cruz (through a 
wiki-documented process of both importing local government landuse polygons and 
painfully though lovingly improving them over three revisions and many years) 
actually won a Gold Star Award at BestOfOSM.org for "nearly perfect landuse."  
Well, before glebius snarled up a perfectly geometrically valid coastline and 
many of its landuse polygons, amenities, parks, marinas and recreation areas in 
Santa Cruz before I manually reverted a good number of his "fixes."
O> 
O> Glebius may believe he is "saving data" by "reducing overlapping nodes," but 
the added complexity to do this in multipolygons is distinctly confusing to 
many (most) OSM volunteers, especially beginners who find multipolygons 
confusing or intimidating.  I'm not saying glebius' practices or resulting data 
are wrong, but rather that when they overwrite perfectly already-correct data, 
his time is likely better spent on other OSM tasks.  Especially when he rudely 
calls correct and even award-winning data "a mess."
O> 
O> Please, glebius, don't do this here.  Everybody else in our community find 
your submissions to be confusing and difficult to maintain, this practice is 
ANYTHING BUT widespread (here in North America), you are overwriting valid data 
in a way that makes it nearly impossible to update with better data (especially 
when part of import updates) and whatever small cost you believe you are saving 
in either elegance or the amount of data in the map is very much outweighed by 
"simpler is better."  Simple, while 

Re: [Talk-us] Multipolygonizing

[Mark Wagner]

On Mon, 20 Nov 2017 10:15:01 -0800
Evin Fairchild  wrote:

> (I couldn't for the life of  me figure out how to add a way to a
> relation!)

Select a way currently part of the relation.  Shift-click on the way
you want to add.  Select "Update multipolygon" from the "Tools" menu,
or hit Ctrl+Shift+B.  Simple.

Of course, this only works for ordinary relations.  If the way you
clicked on is shared by two or more relations, you need to go
through the far more complicated method of playing with the
relation-editor dialog.

-- 
Mark

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Andy Townsend]

On 20/11/2017 17:58, OSM Volunteer stevea wrote:

...  Glebius is right in my backyard and I've found his coastal "restructurings" (e.g. 
http://www.osm.org/changeset/46756097) to be bizarre and unnecessary, often overwriting correct official (county GIS 
imported) data simply to not "share some nodes" or "improve the mess."  He claims that "the 
consensus in Russia is that advanced polygons is the way to go."  Well, not here, I assure both Glebuis and the 
talk-us list of that unequivocally.


I'm not a local, just an occasional visitor to the area, but have 
certainly had similar conversations with non-local mappers deciding that 
(for example) a car park near me should be composed of 4 separate ways 
each part of 2 or 3 multipolygons.  The thing that's in shortest supply 
in OSM is mappers, and anything that prevents people from contributing 
should be frowned upon.


I'm guessing he won't be reading talk-us but he does read and reply to 
changeset comments, so I'd suggest commenting there on any particular 
changes worth talking about.


Best Regards,

Andy


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Evin Fairchild]

Yeah, using multipolygons for everything is quite overkill, and it
certainly does overcomplicate things, and not just for new users, but for
experienced users as well. I mean, if it requires some plugin that I've
never heard of in JOSM to easily edit it, then it's too complicated. I
typically prefer using Potlatch 2 to edit OSM because I find JOSM to be
really user-unfriendly, (I couldn't for the life of me figure out how to
add a way to a relation!) so I prefer that things are kept simple as
possible for idiots like me.

-Evin (compdude)

On Nov 20, 2017 9:59 AM, "OSM Volunteer stevea" 
wrote:

> I very much agree with Douglas and Rihards that glebius' mapping is
> (around here) unusual, "terrible" and difficult to parse, even for
> experienced mappers who have been mapping for most of the history of OSM,
> like me.  Glebius is right in my backyard and I've found his coastal
> "restructurings" (e.g. http://www.osm.org/changeset/46756097) to be
> bizarre and unnecessary, often overwriting correct official (county GIS
> imported) data simply to not "share some nodes" or "improve the mess."  He
> claims that "the consensus in Russia is that advanced polygons is the way
> to go."  Well, not here, I assure both Glebuis and the talk-us list of that
> unequivocally.
>
> Glebius uses a JOSM plugin (and it AMAZES him that this functionality has
> not yet been built into JOSM's base code!) called "reltoolbox."  It
> promulgates what he calls "advanced multipolygons" and in the below-noted
> changeset acknowledges that he believes these "became a world wide
> consensus," but of course, they have not.  Glebius has glibly assumed
> reltoolbox and its resulting data is widespread, when in fact it is not:
> neither locally, regionally, nor continentally.  He further says the
> "quality of OSM data in USA is much worse than in other countries" when in
> fact, my small county of Santa Cruz (through a wiki-documented process of
> both importing local government landuse polygons and painfully though
> lovingly improving them over three revisions and many years) actually won a
> Gold Star Award at BestOfOSM.org for "nearly perfect landuse."  Well,
> before glebius snarled up a perfectly geometrically valid coastline and
> many of its landuse polygons, amenities, parks, marinas and recreation
> areas in Santa Cruz before I manually reverted a good number of his "fixes."
>
> Glebius may believe he is "saving data" by "reducing overlapping nodes,"
> but the added complexity to do this in multipolygons is distinctly
> confusing to many (most) OSM volunteers, especially beginners who find
> multipolygons confusing or intimidating.  I'm not saying glebius' practices
> or resulting data are wrong, but rather that when they overwrite perfectly
> already-correct data, his time is likely better spent on other OSM tasks.
> Especially when he rudely calls correct and even award-winning data "a
> mess."
>
> Please, glebius, don't do this here.  Everybody else in our community find
> your submissions to be confusing and difficult to maintain, this practice
> is ANYTHING BUT widespread (here in North America), you are overwriting
> valid data in a way that makes it nearly impossible to update with better
> data (especially when part of import updates) and whatever small cost you
> believe you are saving in either elegance or the amount of data in the map
> is very much outweighed by "simpler is better."  Simple, while it may share
> a few nodes or overlap some ways, isn't wrong, it is far easier to
> understand and maintain, especially for novice mappers, and ESPECIALLY when
> updates to imported data essentially rely on the "simple polygon" paradigm
> which already works so well in our map.
>
> With respect,
> SteveA
> California
>
>
> Douglas Hembry  writes:
> > Greetings everyone,
> > I've just had a short changeset discussion with mapper glebius prompted
> > by changeset 46612750 "Properly multipolygonize Monterey coast line". My
> > understanding is that the map of this stretch of coastline has been
> > restructured to avoid adjacent ways that share nodes. Accordingly, only
> > a single way ever connects any set of nodes, and the single way
> > participates, if necessary, in multiple relations. A result of this is
> > that in a high density area like downtown Monterey Bay many small areas
> > like building footprints or pedestrian areas are defined as distinct
> > multipolygons, with several ways (outers) making up the outline. An
> > example at:
> >
> > https://www.openstreetmap.org/#map=18/36.61726/-121.90045
> >
> > (look at Hovden Way near the top, or the outline of 700 Cannery Row,
> > further down near Bubba Gump, comprised of seven outer ways)
> >
> > glebius believes that this approach (with the help of the reltoolbox
> > JOSM plugin) is easier and less error-prone than having multiple simple
> > closed ways (eg, a building footprint and an adjacent pedestrian area)
> > 

Re: [Talk-us] Multipolygonizing

[OSM Volunteer stevea]

I very much agree with Douglas and Rihards that glebius' mapping is (around 
here) unusual, "terrible" and difficult to parse, even for experienced mappers 
who have been mapping for most of the history of OSM, like me.  Glebius is 
right in my backyard and I've found his coastal "restructurings" (e.g. 
http://www.osm.org/changeset/46756097) to be bizarre and unnecessary, often 
overwriting correct official (county GIS imported) data simply to not "share 
some nodes" or "improve the mess."  He claims that "the consensus in Russia is 
that advanced polygons is the way to go."  Well, not here, I assure both 
Glebuis and the talk-us list of that unequivocally.

Glebius uses a JOSM plugin (and it AMAZES him that this functionality has not 
yet been built into JOSM's base code!) called "reltoolbox."  It promulgates 
what he calls "advanced multipolygons" and in the below-noted changeset 
acknowledges that he believes these "became a world wide consensus," but of 
course, they have not.  Glebius has glibly assumed reltoolbox and its resulting 
data is widespread, when in fact it is not:  neither locally, regionally, nor 
continentally.  He further says the "quality of OSM data in USA is much worse 
than in other countries" when in fact, my small county of Santa Cruz (through a 
wiki-documented process of both importing local government landuse polygons and 
painfully though lovingly improving them over three revisions and many years) 
actually won a Gold Star Award at BestOfOSM.org for "nearly perfect landuse."  
Well, before glebius snarled up a perfectly geometrically valid coastline and 
many of its landuse polygons, amenities, parks, marinas and recreation areas in 
Santa Cruz before I manually reverted a good number of his "fixes."

Glebius may believe he is "saving data" by "reducing overlapping nodes," but 
the added complexity to do this in multipolygons is distinctly confusing to 
many (most) OSM volunteers, especially beginners who find multipolygons 
confusing or intimidating.  I'm not saying glebius' practices or resulting data 
are wrong, but rather that when they overwrite perfectly already-correct data, 
his time is likely better spent on other OSM tasks.  Especially when he rudely 
calls correct and even award-winning data "a mess."

Please, glebius, don't do this here.  Everybody else in our community find your 
submissions to be confusing and difficult to maintain, this practice is 
ANYTHING BUT widespread (here in North America), you are overwriting valid data 
in a way that makes it nearly impossible to update with better data (especially 
when part of import updates) and whatever small cost you believe you are saving 
in either elegance or the amount of data in the map is very much outweighed by 
"simpler is better."  Simple, while it may share a few nodes or overlap some 
ways, isn't wrong, it is far easier to understand and maintain, especially for 
novice mappers, and ESPECIALLY when updates to imported data essentially rely 
on the "simple polygon" paradigm which already works so well in our map.

With respect,
SteveA
California


Douglas Hembry  writes:
> Greetings everyone,
> I've just had a short changeset discussion with mapper glebius prompted 
> by changeset 46612750 "Properly multipolygonize Monterey coast line". My 
> understanding is that the map of this stretch of coastline has been 
> restructured to avoid adjacent ways that share nodes. Accordingly, only 
> a single way ever connects any set of nodes, and the single way 
> participates, if necessary, in multiple relations. A result of this is 
> that in a high density area like downtown Monterey Bay many small areas 
> like building footprints or pedestrian areas are defined as distinct 
> multipolygons, with several ways (outers) making up the outline. An 
> example at:
> 
> https://www.openstreetmap.org/#map=18/36.61726/-121.90045
> 
> (look at Hovden Way near the top, or the outline of 700 Cannery Row, 
> further down near Bubba Gump, comprised of seven outer ways)
> 
> glebius believes that this approach (with the help of the reltoolbox 
> JOSM plugin) is easier and less error-prone than having multiple simple 
> closed ways (eg, a building footprint and an adjacent pedestrian area) 
> sharing a set of nodes on their adjacent boundary. . (I hope I'm 
> representing this accurately, glebius will correct me if I'm getting it 
> wrong).
> 
> In my limited experience I've never encountered this before, and at 
> first sight I'm not convinced, particularly when considering future 
> maintenance. I told glebius that I wanted to find out  what the 
> community thought. Is this just one more valid optional way of mapping? 
> To be recommended for adoption if possible? Or to be avoided? Thoughts?

And Rihards  writes
> not an authoritative opinion : it's terrible. mapping contiguous areas
> as multipolygons results in data that is extremely hard to modify (think
> splitting landuse from a 

Re: [Talk-us] Multipolygonizing

[Frederik Ramm]

Hi,

On 11/19/2017 11:48 PM, Douglas Hembry wrote:
> glebius believes that this approach (with the help of the reltoolbox 
> JOSM plugin) is easier and less error-prone than having multiple simple 
> closed ways (eg, a building footprint and an adjacent pedestrian area) 
> sharing a set of nodes on their adjacent boundary. . (I hope I'm 
> representing this accurately, glebius will correct me if I'm getting it 
> wrong).

He's not entirely wrong; this approach is something we have come to
expect when you have a mesh of areas, like for example county
administrative areas: One begins where the other ends, and allowing each
to have its own "way" connecting the nodes would only increase the
amount of data and complicate editing.

However, when it comes to very small areas, like adjacent buildings or
landuse areas that only share a handful of nodes, introducing a relation
seems an unnecessary complexity.

It is most often mappers with an IT background and an unwillingness, or
even inability, to accept that there can be more than one way to do it
right - they tend to follow the "everything is a multipolygon" approach.
I've occasionally had to forcibly convince them to re-think that
approach because they were essentially turning their home turf into a
creative multipolygon landscape that nobody else dared edit. This is
IMHO the foremost reason against this "multipoligonism" - you're making
things harder to edit for others.

(Another frequent hobby of multipolygon fans is combining several
disjunct areas, say three landuse=farmland areas, into one multipolygon,
because this "saves" space, since landuse=farmland then only needs to be
tagged once not three times. IMHO this is only acceptable if the three
areas have more in common than being farmland; for example if the three
areas together share a local name or so.)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Mike N]

On 11/19/2017 5:48 PM, Douglas Hembry wrote:

I told glebius that I wanted to find out  what the
community thought. Is this just one more valid optional way of mapping?
To be recommended for adoption if possible? Or to be avoided? Thoughts?


  I have this situation locally where much of the adjacent landuse was 
created as multipolygon.  It definitely takes longer to modify these 
areas for new construction.  That is in JOSM without that special 
toolbox which I hadn't used before.


  I can't imagine what it must be like for a newcomer (with any editor).


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Multipolygonizing

[Rihards]

On 2017.11.20. 00:48, Douglas Hembry wrote:
> Greetings everyone,
> I've just had a short changeset discussion with mapper glebius prompted 
> by changeset 46612750 "Properly multipolygonize Monterey coast line". My 
> understanding is that the map of this stretch of coastline has been 
> restructured to avoid adjacent ways that share nodes. Accordingly, only 
> a single way ever connects any set of nodes, and the single way 
> participates, if necessary, in multiple relations. A result of this is 
> that in a high density area like downtown Monterey Bay many small areas 
> like building footprints or pedestrian areas are defined as distinct 
> multipolygons, with several ways (outers) making up the outline. An 
> example at:
> 
> https://www.openstreetmap.org/#map=18/36.61726/-121.90045
> 
> (look at Hovden Way near the top, or the outline of 700 Cannery Row, 
> further down near Bubba Gump, comprised of seven outer ways)
> 
> glebius believes that this approach (with the help of the reltoolbox 
> JOSM plugin) is easier and less error-prone than having multiple simple 
> closed ways (eg, a building footprint and an adjacent pedestrian area) 
> sharing a set of nodes on their adjacent boundary. . (I hope I'm 
> representing this accurately, glebius will correct me if I'm getting it 
> wrong).
> 
> In my limited experience I've never encountered this before, and at 
> first sight I'm not convinced, particularly when considering future 
> maintenance. I told glebius that I wanted to find out  what the 
> community thought. Is this just one more valid optional way of mapping? 
> To be recommended for adoption if possible? Or to be avoided? Thoughts?

not an authoritative opinion : it's terrible. mapping contiguous areas
as multipolygons results in data that is extremely hard to modify (think
splitting landuse from a building) and is more than a minefield for newbies.

personally, i either redo these as separate ways when i have the time
(original authors do not object as they have went either mad or out of
energy after working with multipolygons too much), or give up and leave
the area outdated - i don't have the skills to maintain that.
-- 
 Rihards

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Multipolygonizing

[Douglas Hembry]

Greetings everyone,
I've just had a short changeset discussion with mapper glebius prompted 
by changeset 46612750 "Properly multipolygonize Monterey coast line". My 
understanding is that the map of this stretch of coastline has been 
restructured to avoid adjacent ways that share nodes. Accordingly, only 
a single way ever connects any set of nodes, and the single way 
participates, if necessary, in multiple relations. A result of this is 
that in a high density area like downtown Monterey Bay many small areas 
like building footprints or pedestrian areas are defined as distinct 
multipolygons, with several ways (outers) making up the outline. An 
example at:

https://www.openstreetmap.org/#map=18/36.61726/-121.90045

(look at Hovden Way near the top, or the outline of 700 Cannery Row, 
further down near Bubba Gump, comprised of seven outer ways)

glebius believes that this approach (with the help of the reltoolbox 
JOSM plugin) is easier and less error-prone than having multiple simple 
closed ways (eg, a building footprint and an adjacent pedestrian area) 
sharing a set of nodes on their adjacent boundary. . (I hope I'm 
representing this accurately, glebius will correct me if I'm getting it 
wrong).

In my limited experience I've never encountered this before, and at 
first sight I'm not convinced, particularly when considering future 
maintenance. I told glebius that I wanted to find out  what the 
community thought. Is this just one more valid optional way of mapping? 
To be recommended for adoption if possible? Or to be avoided? Thoughts?

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us