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?

Esmu jau izlasījis to wiki lapu un nepiekrītu šim teikumam. Pārāk daudz balstīties tikai uz wiki teikto neiesaku. Wiki rakstītais nav cieši jāievēro, tas ir tikai jāņem kā padoms. Plus, šo wiki jebkurš var labot. Tai skaitā arī šajā lapā kāds var kādreiz šo teikumu pārveidot, rakstot, ka koku rindas jādzēš ārā, ja atsevišķi koki ir salikti.

Nevajag uztraukties vai kaut kur kaut kas ir redzams vai nē. Ja kaut kas nav redzams, tad tā ir konkrētās kartes renderētāja "vaina", nevis lietotāja "vaina".

Manuprāt, koku rindas būtu jāliek tikai tad, ja lietotājs nevar (ja ortofoto nav skaidrs un ielas attēls nav pieejams, piemēram) vai nevēlas likt katru koku atsevišķi. Bet, ja ir katrs koks ielikts atsevišķi, tad koku rindas elements zaudē jēgu un būtu jādzēš ārā.