However osm.wiki/w/index.php?title=Relation:site&uselang=en#Alternatives says:
> If each member of the relation can be accurately represented by an area, replace each member with an area, then convert the relation into a multipolygon by retagging it as type=multipolygon and giving each member a role outer. For example, if what is considered a single school campus actually consists of multiple discontiguous sections that share the same identity, map each campus as a closed way with role outer together in a multipolygon relation tagged amenity=school.

Hmm, do you think it's rather like this?
While technically it seems more fitting, it is now not being rendered as a landuse on the standard layer + no name. And yes, while serving the renderer is not quite correct, the standard layer is used in some institutions (e.g. https://www.visitdaugavpils.lv/), where the absence of the well-known object name might seem confusing.

What are your thoughts on this?

While we're at it, I'll add a similar case. Daugavpils municipal(?) map https://kartes.lgia.gov.lv/?x=194299.12&y=658366.66&zoom=10&basemap=topokarte clearly shows that the parallel street is also named the same. I've tagged this accordingly in changeset/170010555. But... is it the same in the VZD data?

Hm, the rabbit hole goes deeper than I thought :)

What about the similar streets to the west from here? There I've also added the names based on the signs seen on Mapillary (which seems closer to the "ground truth"). Again, these do not have any names on https://kartes.lgia.gov.lv/?x=198761.60&y=663701.25&zoom=8&basemap=topokarte. Or is VARIS a different source?

That's all because I'm coming with the experience of StreetComplete quest primarily asking for residential and living street names. And I'm quite used to the cases where the same street name continues into the turns (especially with living streets).

Hello!

Why "incorrectly assigned street name"? See https://www.mapillary.com/app/?pKey=1407744789609071 and https://www.mapillary.com/app/?pKey=1086476083298707. Living streets should have names, which is indicated by the sign. https://www.mapillary.com/app/?pKey=255822533120370 shows the end of living street, so the transition to the unnamed unclassified road looks valid.

What? New aerial? Where? =D
---

Published using OSMCha: https://osmcha.org/changesets/175593721

Nice, but why this changeset on top of the previous one? Seemed ok before that...

Hi, could you draw the outline of this solar station (generator:source=solar), at least an approximate one?

Hi,
this sidewalk was already marked with sidewalk tags on the roads way/1291343766, way/1001384486 and way/23612173.

Oh, wow, thanks for the explanation!
I didn't know that this is not a strict rule, more like a rule of thumb. I would guess that the decision to downgrade the classification was made based on the surface. And the proposed classification would be reserved for the case this road gets asphalted and the northern connection to V673 finished. The current state now appears valid to me, unfortunately, not able to verify it onsite.

Following similar logic, that one short part of V694 (or even completely) to the west could be downgraded to highway=tertiary. I was, again, thinking of this as a strict rule with changeset/151454473

Hi,
I also don't get the motivation for the tag changes done by the previous changeset changeset/112092128. According to osm.wiki/Lv:Latvian_tagging_guidelines, the P-roads should be highway=primary, exactly how this highway was tagged initially.
The reference code remains P66, so there wasn't any official highway category downgrade. So I think, it should be fixed back to highway=primary.

Hello and welcome to OpenStreetMap!
Unfortunately, Google Street View is not allowed as a data source here, see osm.wiki/Google. You are welcome to use the alternative street-level imagery sources like Mapillary (or KartaView, Mapilio etc., see Map Data toolbar in iD editor). These services allow to upload own recordings that can later be safely used for OSM mapping.
In addition, local knowledge of the current situation and, especially, checking the situation on-site remain as reliable sources of information.
Happy mapping,
Cucazer

Čau! Vai way/1331445061, way/1331445062 un pārējie nav būtu landuse=grass un tad viens kopīgs leisure=park apkārt (ja to vispār var skaitīt par parku)? Citādi kaut kā neloģiski sanāk, ka vienā vietā ir 6 dažādi mazi parciņi...
Savukārt way/129399051 tika pārtegots uz highway=residential, tikmēr visi pārējie ceļi apkārt ir highway=living_street. Nedomāju, ka dzīvojama zona tiek pārktraukta uz šo mazo gabaliņu.
---

Published using OSMCha: https://osmcha.org/changesets/158829321

Hi, there's still node/7815115383 - double tagging?

Found the reference: https://osgeo-oceania.org/2023/07/18/qgis-training/
Also see way/1302388583 and surroundings

Thanks!
So you mean that some of the cutlines are not usable as track/path? I guess, it's not confidently identifiable just from the aerial imagery.

Hello, what was the intention for restoring leisure=swimming_pool tags, while having the same with abandoned:?
---

Published using OSMCha: https://osmcha.org/changesets/153476252

Hello, I'm not sure about the northern edge. Digital terrain imagery suggests that there is some water level 20-50 meters further out. Or is it now just a muddy reedbed with no constant water level? I'm not much familiar with this side of the lake though...
Nevertheless it's an improvement from the previous version!
---

Published using OSMCha: https://osmcha.org/changesets/153397008

Additional source: https://www.ievp.gov.lv/lv/strukturvieniba/daugavgrivas-cietums

Hello!
This changeset created a bunch of multipolygons (e.g. relation/17605455, relation/17605456) for the objects that were already marked as simple polygons. These didn't have any unusual geometries (as in osm.wiki/Relation:multipolygon#Examples_in_XML) to justify use of multipolygons. In this scenario converting simple ways to relations with many members just complicates further editing, as the features cannot be that easily separated.
What are your intentions with converting simple polygons to multipolygons?