OpenStreetMap logo OpenStreetMap

Changeset When Comment
126023696 over 3 years ago

See also my comments at changeset/125074466

125959596 over 3 years ago

For reference, see my comment at changeset/98300768

98300768 over 3 years ago

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

125374733 over 3 years ago

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

125877134 over 3 years ago

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.

125877134 over 3 years ago

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.

125877134 over 3 years ago

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.

125074466 over 3 years ago

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?

107249412 over 3 years ago

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

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

125485019 over 3 years ago

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

125235854 over 3 years ago

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.

125170723 over 3 years ago

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.

125074466 over 3 years ago

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.

125074466 over 3 years ago

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?

125081989 over 3 years ago

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

124302301 over 3 years ago

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.

124299519 over 3 years ago

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

124302301 over 3 years ago

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

124302301 over 3 years ago

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

124303401 over 3 years ago

Hi! Just to let you know, I changed these service roads partially back to parking isles, since the "side" ones do indeed access the (double) parking rows.

changeset/125177061