Is there (now) a living zone here around [1]? From your Mapillary and my earlier visit, it doesn't look like it, but wanted to double check.

[1] way/1083248667

:) Gotta be fast with you around or there will nothing new left to map.

There are still a lot of minor details to map here though. Notably, all the grass dividers/medians/separators. But without aerial, they are a real pain. The only saving grace is that the building has an accurate cadaster outline, so it's at least possible to align features to it from footage.

In response to changeset/126375580.

Heya!

As far as I remember, this used to be how less-than-complete road works were tagged (i.e. the main `highway=x` keeps the tag).

But I see Wiki now says
"A deprecated option is to set the tag construction=yes." There are 4.9K uses of taginfo, so I am not sure when this was decided/changed. It does however suggest that `construction=minor` should be used for this particular purpose, so I'll change to that. There are 20.7K uses of that.

I didn't use `highway=construction` because the only major change currently is that they removed the top asphalt layer, leaving behind ground/sand/rocks, but there isn't any major work being done (at least, when I was here a couple times). I'm not sure if it's better to "close" the way with `highway=construction`. I have no idea if they intend to lay new asphalt or whatever else.

See also note/3357664.

Hi! Footways should only be tagged as `footway=sidewalk` when the road is directly or at least reasonably accessible from the sidewalk. In this area, footways are mostly not sidewalks, some just happen to be parallel to the road. Sidewalks to the router engines means that you can access and cross the road anywhere (or at least quickly/nearby) from it.

Ways like [1] are not sidewalks, they are far from the road. You would have to walk through grass and obstacles to get to the road.

Ways like [2] are basically crossings and leading to crossings. These would generally be sidewalks only if the "main" way is a also a sidewalk.

Ways like [3] are not part of any road to be sidewalks.

For example, [4] is a "real" sidewalk because it runs parallel to the road and you can directly access the road from it.

[1] way/107378321/
[2] way/1089410275/
[3] way/107375871/
[4] way/906335318/

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?