Hi there and thank you for the kind response.

For this changeset I used Overpass to download landuse multipolygons with many members. I used regressions to also download everything that was attached to the members of those multipolygons. Then I cut up the multipolygons in JOSM mainly with the relation toolbox plugin and utilsplugin2.

Downloading everything that is attached to the relation members is important so you can safely edit the landuse multipolygons without interacting with other objects (roads, boundaries, other relations etc.) that are used as the edges of the multipolygons. Sometimes this still goes wrong when you reconstruct a natural=* multipolygon that uses a coastline or cliff as a member, because the natural=coastline/cliff may get retagged as a natural=wood/wetland/scrub/rock by JOSM's relation toolbox plugin.

I hope these tips can help you. If you need help with anything more specific you can send me a private message or find me hanging out in the OpenStreetMap World Discord server.

Hi there. Thanks for helping out with mapping this area. Could you please not attach street-side parking to the streets? Because that would imply that the parking areas go exactly to the centre lines of the streets, which is usually not the case.

Greetz,
Casper

Hi there. It looks like you mapped an unusual boundary relation on the hospital that you mapped. Hospitals should only be mapped as nodes or areas, so I have deleted the invalid relation.

Dan werken we precies tegen elkaar in, want ik maak van grasstroken landuse=gras, van weilanden landuse=meadow en van open graslanden in natuurgebieden natural=grassland. Dit is waarschijnlijk zo'n typisch thema binnen OSM waar we nooit een consensus over gaan bereiken. Zolang niemand bedenkt om hier een "edit war" over te gaan voeren ben ik niet van plan om hier moeilijk over te doen.

Hoi Peter. Grasstroken in het industriegebied zie ik niet als natural=grassland. Dat is een tag die ik eerder zou bewaren voor open grasvelden in bijv. natuurgebieden waar je ook groot wild tegen kunt komen. Hoe kijk jij daar tegenaan?

Hi. The waterway relations you mapped are not correct. A waterway relation is supposed to represent a single watercourse, not a collection of waterways.

Dankje voor de links. Ik krijg even mijn AHN-lagen in JOSM niet aan de praat, maar voor de goede orde heb ik mijn wijzigingen hier teruggedraaid in changeset/160010576.

Mocht ik nog eens de neiging krijgen om hier naar te kijken, dan zal ik me waarschijnlijk focussen op het verwijderen van stukken spoor die duidelijk niet meer bestaan, zoals in velden waar al tig jaar overheen is geploegd.

Fijn weekend :)

Hoi. Ik heb het niet met jou overlegd. Over welk veld heb je het hier?

Hi. I might have been a bit too rigorous with deleting the tags here. Others on the forum had suggested that this tag could go, so I simply went along with it.

Feel free to undo the deletion of the gnis:ftype tags if you know of an efficient way to do so, and otherwise I'll try to find some time to figure out a way that works.

Hoi A67. Dankje voor je wijziging. Ik wil je er wel even op wijzen dat we Youtube video's niet mogen gebruiken voor OSM. Op https://www.youtube.com/t/terms?sjid=6361050061228477017-EU staat namelijk het volgende: "U mag Content bekijken of luisteren voor uw persoonlijke, niet-commerciële gebruik."

Mappen op OSM valt onder commercieel gebruik, want OSM data mag voor commerciële doeleinden gebruikt worden.

I'm not in the mood to reply to all of that now. Convince the DWG that it should be mapped now and I'll let it be.

All of it is likely to change in the short term aftermath of the conflict. That is the reason.

I'm not getting into the politics of it. Go talk to the Israeli / Gaza community or the DWG.

I am familiar with how this works. I just missed where exactly the coastline broke, because my changeset covers most of NJ. Thank you for pointing it out. I'll be extra careful next time.

They keep creating sockpuppet accounts to turn half of Gaza into landuse=military. The DWG is already involved.

Thank you very much for providing this detailed insight into your workflow.

You mentioned how overlapping edges of ways would be challenging to unglue, but I don't see how this would be true. With a simple alt + left-click on the edge in JOSM you can easily select the next object in cases of overlap. It's not like you'll ever see five or more ways with overlapping edges, so I don't see how this would be a limiting factor to your (or anyone’s workflow).

On the other hand, these very large multipolygons are an issue for many mappers and data users alike. This method of mapping violates the "One feature, one OSM element" principle we have, which dictates that each field should be represented by its own polygon, where you have mapped all fields together as a single object. This gives data analysts the wrong idea that there are only a handful of landuse polygons mapped on the entire island, while the map clearly shows thousands of polygons. It’s also a substantial problem for other all other OSM mappers, who have never mapped like this, might fail to understand the complexity of these multipolygons and will undoubtly have trouble loading the data into their editors.

We do have a technical limit imposed on the number of members in a relation, although you’re not likely to hit that anytime soon: osm.wiki/Relation#Size. This Wiki page also recommends keeping relations small whenever possible.

My suggestion to you is that you change your mapping style to work with lines and areas that may have overlapping edges. This will improve the map for users and will make it easier for other mappers to contribute.

I (together with several mappers that I spoke to on Discord) would also like to see the existing multipolygons being converted into closed ways with the exception of cases where multipolygons are strictly necessary. If this is technically challenging for you, I’ll be happy to lend a hand, as I have experience with reconstructing large and complex multipolygons.

Let me know what you think of this, so we can figure out a plan that can satisfy everyone.

Best regards,

Casper

Thank you for the clarification.

I can see how areas set aside for growing food can be tagged as orchards or farmland, especially when the land is plowed or has fruit trees on it.

Allotments are communal places where multiple families may own or rent a plot to grow their food. Private backyards are not that. That said, I do see the need to distinguish these areas from large fields where farmers use their tractors etc.

Would it make sense to you to retag the landuse=allotments that are not actually allotments to leisure=garden + access=private with a relevant garden:type=vegetable_garden? The last tag is currently undocumented, but is already in use according to Taginfo and seems to fit your description well.

Best regards,

Casper

Hi. This must have been an error on my part. Sorry for that. Could you point out for me where that happened, so I can learn from my mistake?

Are you sure the urban patches of greenery are all correctly classified? way/1263019270 for example looks neither like an orchard nor like allotments, but more like someone's backyard.

I can help you to split up the large multipolygons.

Why are they so huge in the first place? Wouldn't it make more sense to turn them into closed ways, one for each individual area?