"Did you try to find out why was the landuse mapped this way before declaring multipolygons useless and mass-converting them?"

That's one the reason why I started this discussion and my theory that you find it easier to edit with mps was confirmed.

This method might be an easier one for you but don't you understand that other editors find it very hard to edit the section in the map you were editing after you, especially iD users? iD editor is quite restrictive, it will straight up prevent user from doing actions that may or may not cause errors, like disconnecting members of a mp or performing actions on an element if it's not entirely visible. That's annoying, but iD is intuitive and modern, interface is visually appealing. That's why I use iD for mainly simple tasks. But randomly comming across areas mapped like multipolygons which I want to edit always makes me sigh and open JOSM to deal with them and then return to iD to finish what I started.

I don't know if there are but from my own experience I know that area borders divided into countless multipolygons make mapping extremely hard, especially for casual mappers who are not into advanced stuff like multipolygons. Other mappers have expressed frustration with this as well. And this can and will confuse new mappers who don't know anything about multipolygons and will be scared to touch them.

The main problem I have with this edit is that you restored multipolygons in first two locations I mentioned without changing almost anything else. Walls and fences around Ziedoņdārzs and Ivana kapi areas could have been easily added without recreating mps. You changed much more around south of Daugavas stadions so I don't have any particular complaints about those changes.

Again, if using this mp technique makes mapping easier, then keep using it. Just don't convert simple polygons to mps without any reason at all like you did in the first two locations.

You recreated multipolygons around Ivana kapi, aroudn Ziedoņdārzs and in areas south of Daugavas Stadions. The only useful changes done by you are at the third location.

What was the reason for it? They have no reason to exist! These elements can exist as simple polygons without problems!

I understand it might be easier to create areas which connect to each other using the multipolygon method. But I don't see a reason to restore multipolygons if you are not going to change anything there or if you're going to just move a few nodes around!

Fixing this edit without reverting your good edits seems very hard if not impossible. I might have to revert the entire change set if I'm not able to find a reliable way to fix this.

Izlaboju pats, jo, šķiet, nelasat izmaiņu komentārus.

Kāpēc skolas teritorija[1] tika pārvērsta par vārdā nenosauktu social_facility, bet skolas dati atstāti uz ēkas[2]?

[1] way/1092749083
[2] way/87825719

Smiltis ir daļa no spēļlaukuma, tāpēc šiem abiem elementiem nevajadzētu būt multipoligonā.

Es salaboju biedru lomas šajās relācijās: changeset/162433199

Izmaiņu vēsturē gan neparādīsies.

Do you think it is correct to change building names to versions you proposed? There are two companies operating in Latvia: Rimi Baltic and Rimi Latvia. Which one is operating here? If not clear, we could drop "Baltic" and simply name this surrounding commercial area "Rimi".

Generally, the name of the territory is added in the "name" tag of the surrounding land use element; otherwise, if there isn't a name, then the name of the company operating the territory is added. But, no matter what, each case should be evaluated individually. In this case, if it is not clear which company is operating in this territory, I would simply name it "Rimi".

I understand the problem with navigators routing through private access roads. That is something to be concerned about, and it indeed can confuse people. But the problems with how routers are programmed aren't the reason to change actual map data. The map should be as accurate as possible.

OSRM seems the most reliable routing solution. It avoids routing through roads marked with the "access=private" tag. Valhalla and GraphHopper ignore "access=private" values, but all three ignore roads with "access=no". Today another mapper changed access values for roads in Rimi territory. So, after a few weeks, OSRM should start routing accordingly.

Abās šajā izmaiņu kopā izveidotajās relācijās biedru lomas ir saliktas otrādāk. Šajos gadījumos "inner" vajag pārvērst
uz "outer" un "outer" uz "inner".

Jāņem vērā, ka multipoligona ārējai līnijai vienmēr jābūt "outer" lomā un elementam, kas ir iekšā, jābūt "inner" lomā.

Šajā[1] relācijā šai[2] līnijai jābūt "outer" nevis "inner" lomā. Un pārējiem diviem biedriem[3][4] jābūt "inner" nevis "outer" lomā. Tāpat arī otrā izveidotajā relācijā.

[1] relation/18690530
[2] way/1359072008
[3] way/216737542
[4] way/1359072009

Iekomentējāt pats savā izmaiņu kopā...

I merged the office node into the smaller building because it's unacceptable to add incorrect data like this. Add the node where the object actually exists on the ground, not wherever you want, to avoid creating confusion in people who navigate there.

And also, it is completely acceptable to have the name of the company added in "name" tag of the surrounding land use element. Why did you move it to operator?

I want to add that undelete option comes with a plugin called "undelete" and revert option comes with a plugin called "reverter". You can find plugins' list in Preferences menu.

Correct tag would be "disused:man_made=water_tower". But an alternative would be: "man_made=water_tower" with "disused=yes" to make it remain visible on the map.

At least this mapper did redraw these elements in the same changeset. They might not have fully mastered editing with JOSM yet, they're a new mapper after all. That's why they might be finding it easier and faster to just delete and redraw. Have you explained this mapper how to edit elements in JOSM efficiently at least once? Recommend ways how they can improve their editing experience?

Tags "disused" netika noņemts. Ja vieta ir atvērta, tad šis tags ir nederīgs.

*for each plot of brownfield area

Pameklēju wiki.osm.org un taginfo.osm.org, bet nevaru atrast ieteikumus, kā jāapzīmē koku lapotnes. Man šķiet, ka parasti neviens lapotni vizuāli nezīmē kokiem OSM'ā, vien apraksta to izmēru ar tagu osm.wiki/Tag:diameter_crown=. Taču var arī izgudrot jaunus tagus, ja vēlas zīmēt, piemēram, uzzīmēt lapotnes elementu un likt tree=foliage. Šo jautājumu derētu pajautāt community.openstreetmap.org, lai uzklausītu arī citu kartētāju idejas.

Nedrīkts likt meža elementu ap koku lapotnēm, ja tās ir lielas. Šajā izmaiņu kopā tas tika izdarīts ap dižozolu, bet ap dižozolu neviens cits koks, cits saprotu no ortofoto, neatrodas. Meža elementu liek tikai tad, ja vienā vietā ir daudz koku tuvu viens pie otra.

Tātad arī šeit [1] ir nepareizi?

[1] osm.org/#map=18/-54.179780/-36.711030

Kuros gadījumos tad "name" būtu jāizmanto?