Mass-borttagning av multipolygoner i Sverige

Hej,

Är det ingen som reagerar på att en användare har gjort massredigering runt Stockholm där relationer tas bort och ersätts av vanliga ways? Detta ska tydligen förklaras med användrens åsikt om att relationer är dåliga, och svåra att använda i iD (web-editorn).
T.ex: Changeset: 140494427 | OpenStreetMap

I några tillfällen så är det legit att ta bort en relation som bara har 1 member: Way History: 221317321 | OpenStreetMap

Men här har alla relationer ersatts med dubbla ways per landcover-areal: OpenStreetMap

Så alla som har mappat areas med outer ways har fått sitt arbete utraderat och ersatt med ways med connected nodes.

image

Användaren har främst gjort det här i Stockholmsregionen overpass turbo men verkar ha en ambition om att göra det här i hela världen. Enligt forum-posts (ej svenskt forum) så används scripts.

Åsikter?

2 Likes

Tycker det är jättebra, att arbeta med multipolygoner är jobbigt och de borde endast användas när det är nödvändigt. Har själv fått spendera massa tid med att fixa meningslösa multipolygoner för saker som skogar och bostadsområden.

3 Likes

Tycker tvärtom, och skulle denna användare komma och göra samma i de områden jag aktivt karterar skulle jag bli ganska sur.

Kan hålla med om att multipolygoner kan vara svårare än de borde vara att jobba med, men tycker faktiskt att “vanliga” polygoner ofta är värre. Bättre att lösa de faktiska problemen (i editorerna) än att bara ersätta med ett annat problem, och samtidigt förvanska historiken.

Vilka möjligheter har vi som “OSM Sverige” att neka att det här görs här?

4 Likes

Först invänta fler åsikter :+1:

2 Likes
1 Like

See also 1-member multipolygons - #68 by Woazboat for a perspective on the topic that I share with Woazboat.

1 Like

Multipolygoner ska i mitt tycke bara användas när det är nödvändigt. Kan man rita t.ex. markanvändning som vanliga polygoner som förvisso angränsar till varandra så är det helt klart att föredra.

Däremot tycker jag inte att någon utomstående ska gå in och börja ta bort befintliga multipolygoner utan att söka konsensus här först, förutom multipolygoner med bara en medlem, det är ren uppstädning av data och okej.

4 Likes

Men… vilket komplett vansinne :open_mouth:

Av noder bygger man sträckor, och av sträckor bygger man relationer, det är ju så den ökande komplexiteten är konstruerad. MP existerar liksom av en orsak.

När man förstår hur relationer fungerar så underlättar de mer än försvårar, exemplet nedan visar på just det. Klicka i “kartdata” markera en way och försök välja en viss yta. Nästan omöjligt, “fel” yta väljs slumpmässigt. Hade det istället varit en MP så hade man med lätthet markerat en way, sett vilka relationer den ingår i och därefter valt rätt relation. Plättlätt.

Att han (jo, jag antar helt fräckt att det är en han) tycker att de är för svåra att hantera i en viss editor säger väl mer om editorn brister och hans egen förmåga än om relationerna själva. När jag tycker att nåt är svårt, så ser jag antingen till att lära mig hur det funkar, eller pysslar med nåt annat. Jag saboterar inte andras jobb bara för det.

Förutom att ta bort relationer som har ett syfte så gödslar han databasen med helt onödiga duplicerade noder.

Vansinne, komplett vansinne :frowning_face:

3 Likes

För mig som inte editerat så mycket (komplexa) saker så verkar användningen av multiploygon vara onödigt komplex då två olika areor delar en gemensam gräns. (Jag har inte ens uppfattat att man kan göra så). Jag har även låtit bli att justera objekt då jag inte förstått varför man delat en enkel fyrkant i två linjer och gjort en relation av det Relation: 16272596 | OpenStreetMap.

Med det sagt så ser jag dock inget behov av att mekaniskt börja bygga om en massa saker för sakens skull, särskilt inte då det är uppenbart att det inte finns någon konsensus.

Fallet du nämner @bagis är ett typexempel på när multipolygon inte behövs.

Om det istället hade varit så att den ena sträckan hade varit tex ett stängsel, och den andra sträckan en mur, är det klockrent att sammanfoga dem i en multipolygon för att säga “den här ytan definieras av muren och stängslet”.

Men i ditt exempel verkar det dessutom dubbelt feltolkat i och med att barrier=fence borde sitta på de båda delsträckorna, istället för i MPn (som definierar ytan).

Så ja, städning behövs nog. Men, det är å andra sidan inget unikt för MPer :slight_smile:

4 Likes

Exakt så som @Tomas_Marklund beskriver har jag gjort på något ställe med en lekplats. Runt halva lekplatsen går det ett staket som är 2m högt (typ plank), sen är det en öppning med en grusväg genom, och ett mindre staket längs andra sidan.

Multipolygon med delarna “öppningen”, “högt plank” samt “lågt staket” som tillsammans har tagningen för lekplatsen.

Skönt att höra att det verkar vara rätt :slightly_smiling_face:

2 Likes

Mer naturligt, alltså rent intuitivt för en nybörjare som mig, hade varit att göra en ny väg med samma noder som stängslet etc. som definierar lekplatsen.

1 Like

What I did is a very similar data cleanup. The 1-member MPs are also included in the effort.

Not necessarily. We also have closed ways to describe areas. There is no need to make multipolygons to describe all types of areas.

I already linked to Woazboat’s post about other benefits of closed ways compared to multipolygons.

Huh? Where? Adjacent ways share their nodes. No new nodes are created. On the contrary, a lot of excess data is removed.

I deliberately didn’t touch any fences. See this query: overpass turbo

1 Like

This sounds pretty much like the opposite of KISS - keep it simple, strong, one of the principles of OSM.

Of course not, I never said ALL areas. Many areas are more than ok with only a closed way. But not all, some require MPs or are just easier to handle with MPs.

Sorry, typo. I meant duplicate ways.

3 Likes

Do you have examples of unnamed landuse/natural polygons without inner ways that require a multipolygon? Note that I have made sure to preserve outer ways that are also used for other purposes like boundaries, barriers or even roads. Also, please disconnect your landuse areas from the roads.

Typos happen. I understand. If you worry about the number of ways you’ll be happy to know that in my edits I also reduced the number of ways by several thousands without affecting how the map looks. I did this by using JOSM’s relation toolbox to merge unclosed ways to make closed ways.

I just think that the project operates mainly under the umbrella of personal opinion. I, like @Tomas_Marklund think that relation-based landcover is by far easier to create and maintain and the result is much more clean and efficient.

I completely understand that users of iD or inexperienced user do not share the opinion, but its still an opinion. I personally feel that DUPLICATING nodes (connected or not) is extremely unnecessary and is much more labor intensive to maintain, and create, because it for example requires the user to “click in” all the nodes of the adjoining area to create the next area. If its 3 nodes one does not care, but if its say 600 nodes its an immense workload and the user either gives up quickly or opts to reduce quality of data to reduce the workload.

I’m also alarmed by the fact that @SomeoneElse actually supports, and would himself do this type of thing (if I understood him correctly in that changeset which I don’t remember which one it was now) when he would come across it. How could I report what I think is absolute vandalism if DWG members consider my work as “unnecessary”? Please correct me if I misunderstood but… I was indeed alarmed when I read that comment.

It’s also difficult to distinguish person from person here. These methods of mapping are not really all about experience or skill - but personal choices and methodology. I noticed that @riiga agrees with the “unnecessary relation” argument, while certainly being an experienced user. Personally, I would look at way-only-mapping as (sorry for the term, but…) noobie style mapping is likely done in iD but this is clearly not the case.

I would love to give an introductory course/webinar to anyone in Sweden (or anywhere) who wants to create landcover data in a more efficient way, but it would be strange if it was considered problematic to the wider community. Also, I would absolutely hate it if someone came into the areas I’ve spent years on improving to implement this kind of subjective change. It’s the kind of thing that would make me question my commitment to contributing to OSM.

Switching to English here - might as well, but anyone is free to write in either language as before.

6 Likes
  • If an area needs two natural tags, for instance both natural=coastline and natural=wood. Or do you propose creating duplicate ways (areas) here too?
  • If the outer ways have tags of their own, such as fence, wall, ditch, etc. Already mentioned above though.

Well, that is a completely different topic, not even remotely related to the multipolygons, so why bring them up here at all?

On a side note, such combined roads/landuses are a bitch to edit, and I try to disconnect areas from roads when I find them, if I have the energy. If only they were MPs at least, instead of duplicate ways :wink: Maybe you should direct you focus to these instead? It would be highly appreciated, but probably not by everyone (as always) :slight_smile:

Arguments in that direction sounds very much like “mapping for the renderer” :roll_eyes:

2 Likes

I explicitly do not edit these. If you run the query I used you’ll see that they are still there: overpass turbo

The tagged outer ways are all preserved.

Yeah sorry, that was a bit off-topic. It’s just that I encountered a bunch of these during my edits and wanted to bring it to your attention. We don’t need to dwell on it here.

On the contrary, I mean that I am not altering any rendering, I’m just changing the data structure of the polygons in question. But it was probably not necessary for me to mention it.

Of course everyone here may continue to write in Swedish. I have no issue with using a translator to understand and reply to your messages. I can also run my messages through Google Translate or Deepl if you wish.