Hey again! I added a fixme tag to most of the taps in [1]. I looked through a lot of them, compared to aerial and Mapillary and existing taps. My conclusion is that the municipality data is in some cases very approximate. The general area for them seems to be mostly accurate (like, none are in the middle of nowhere), but the exact locations (especially for older ones) are only accurate to an address or street, which in some cases (like Mežaparks above) means it's completely wrong. Hopefully, these can be surveyed and verified over time.

[1] changeset/126023696

See also my comments at changeset/125074466

For reference, see my comment at changeset/98300768

Hi!

A piste route should not be multiple relations with different values, rather the `piste:xxx` tags should be on the paths/tracks (or dedicated piste ways).[1]

I merged the route into a single relation and moved the values onto the relevant ways in [2] The route covers the whole "ski track", but individual ways signify the actual difficulty. (iD doesn't render this, but JOSM does.)

One thing is that I did not move the `lit=yes` tag from one of the routes[3] to ways because I am fairly sure some ways in it were not actually lit. Plus, the other piste segments were not tagged for `lit` at all, yet sections are part of the same tracks/paths. This makes me doubt that we can assume they are lit. We probably need a survey for that.

[1] route=piste#Tags_for_the_associated_ways
[2] changeset/125959596
[3] relation/11912487

Hi! Regarding crossings like [1], `crossing:island=yes` shouldn't be used if the traffic island is separately mapped.

[1] node/6294259129/history
[2] crossing:island=*#Alternatives

I changed individual `amenity=parking` to `amenity=parking_space` with `capacity=#`.

I guess that's a bit better, I think.

I am not sure what one would do if I couldn't count the capacity from aerial, because otherwise the default assumes 1 space. I have seen a bunch of examples where individual "boxes" are mapped as `amenity=parking` but there is no parking space separation.

I moved the yield sign. The problem was that is was on the intersection of multiple ways. (I added it before I added the areas). So the direction was messed up depending on the way you considered. It should be good now I think. It's still `direction=backward` though because it's "looking" in the opposite direction of the entrance/exit service way.

Hi! I'm not sure which service road (sections) you think are tagged incorrectly. As per wiki, the only sections I tagged as service=parking_aisle are the ones that are directly adjacent to parking spaces. The sections entering/exiting and turns without adjacent parking are not tagged as aisles.

Hi again. Just to let you know I deleted node/9962237084 at 57.0116037, 24.1461039 in Mežaparks. After surveying, there is nothing here except some paths and forest. If there is a tap somewhere else in Mežaparks, it's not here. So this coordinate must be approximate or wrong. Were there other coordinates for Mežaparks in the data?

Привет! Я удалил теги bicycle=designated, которые вы добавили к некоторым дорогам.[1] "designated" предназначен для легального доступа. В Латвии это велосипедные дорожки (раздельные и смешанные) - то есть где есть велосипедные дорожные знаки. Подробнее о теге в [2]. В местах, где нет особых правил велосипедного движения, дополнительные теги не нужны. Например, в жилой зоне предполагается, что велосипеды разрешены (и имеют приоритет) по умолчанию.

[1] changeset/125654444
[2] access=designated

Hey! I remember looking at the tags for barriers and "log" didn't seem right at the time but I didn't look much more into it.

To me, this is a log: [1]

While this node is not really a log: [2]

Even something like this I wouldn't think of as a log: [3]

I guess log has 7.5k usages and fallen_tree "only" 450. And I guess log is used for naturally fallen trees. I suppose these can be changed to log and instead I should tag access on these instead like foot=yes and bicycle=dismount and motor_vehicle=no or something.

I've tagged fallen trees a bunch over time.[4] If these should be logs, then I suppose all of these nodes should be converted too.

[1] https://www.mapillary.com/app/?pKey=656291435212346&focus=photo
[2] https://www.mapillary.com/app/?pKey=1569506096815253&focus=photo
[3] https://www.mapillary.com/app/?pKey=824014125429365&focus=photo
[4] https://overpass-turbo.eu/s/1lqt

Heya! You changed way/760920198/history to living street here, I changed it back to service. I'm assuming you were fixing something broadly and this one was a mistake, but letting you know just in case.

Hey! Regarding node/9766684080 . The sign plate itself is missing. But the support pole is still there (even the sign plate attachment points are visible). Since the pole remains, I believe `destroyed:` prefix is valid until it gets restored or removed. Probably need a survey to confirm that, but it's been like that for a while.

I'll check it next time I'm there. Although I have a feeling it is not. There is nothing there on Mapillary photos and I would have likely noticed it. But it could be nearby or hidden, or dismantled, or newly-installed.

Also, coincidentally, I added node/9962096749/history just before you added node/9962237086/history . I assumed it was a well pump because it has a literal handle for pumping. But your data seems to be for water mains taps. So I guess it's actually a fake handle that simply opens the tap...

In any case, you can see the accuracy here is some 20+ meters wrong. Obviously, much better than nothing, but there are likely more errors. Latvian municipality data is really spotty for such details in my experience.

Hi! Firstly, thanks a lot for adding these, they are really helpful for active travelling.

node/9962209170 was not there late July unless it's really hidden or really new. Are you sure this is where it is located? I realize that this is basically a data import, but do you know how accurate or reliable the data is?

By the way, tagging roads in a living zone (533) as highway=living_street is described in osm.wiki/Lv:Latvian_tagging_guidelines as local consensus

I guess that would work the same for routers or whatnot.

Personally, I have always used "only xxx" restrictions (osm.wiki/Relation:restriction#Mandatory_restriction) rather than "no xxx" restrictions when there's a specific sign/direction. It probably doesn't matter since this isn't following traffic signs but rather their logical results.

Anyway, thanks for taking a look.

Sveiki! Līdzīgi, kā iepriekšējā rediģējumā, ir diezgan daudz kļūdas. Minēšu galvenās:

Lietojot aerofoto, lūdzu būs uzmanīgiem ar nobīdi. Aerofoto nav garantēts sakrist. Vairāk info osm.wiki/Using_aerial_imagery

Šī nav ēka, bet "skapis" (man_made=street_cabinet). Un nosaukumā (name) nevajadzētu likt aprakstu (description). way/1082667652

Šīm stāvvietām (cik zinu) nekur nav norādītas zīmes par ierobežojumiem, tāpēc nevajadzētu likt access. way/1066167222; way/1066167214; way/1082667654

Lūdzu nedzēst potenciālo (highway=proposed) Āboliņu ielu. Šī iela ir kadastrā un blakus mājai ir adrese ar šo ielas nosaukumu. Šī ir otrā reize, kad tā tiek izdzēsta bez pamatojuma. way/739151324

Lūdzu nedzēst tādus punktus kā
tualetes (amenity=toilets). Cik zinu, tās joprojām tur ir. node/9792362155

Without the restriction, you are still allowed to do a u-turn though. Unless I'm missing something.

Hi! Was there a particular reason for deleting this turn restriction relation/14197217 ?