HellMap's Comments
| 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
|
| 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
|
| 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
|
| 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
|
| 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ā
|
| 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. |