Also, bus routes are broken on all intersections Aulo has touched :(
route=roads are often broken or work in one direction only / road names missing on some parts.

I've finally got to updating it. Turned out quite ugly, I've tried different approaches, but all of them don't look good.

Also, there is some route Vana-Narva maantee which seems to start too early and contradicts Maaamet and osm name tags. Maybe should be fixed too.

Another discussion created by @Pikse
changeset/110759541

@Pikse there are multiple changesets by @Aulo which uglified roads. Lanes should not be mapped as separate roads.

I think that @Aulo should fix it back.

Another discussion
changeset/110758768

Thanks for this thorough analysys, fghj753.

>This means that routing engines will direct drivers to the residents via parking lot and sometimes via Irusilla.

Did you mean Iru tee? Anyway, it can be expected that a good routing engine could allow routing to an access=destination residential road, but routing by a highway=cycleway may be a bit questionable.

>That is technique often used with temporary road construction signs to indicate that restrictions are not applied at the moment.

Or maybe it's vandalism. Actually correct technique:
https://www.google.com/maps/@59.4262229,24.7569369,3a,41.5y,101.37h,88.53t/data=!3m6!1e1!3m4!1sHkLLPyCu6d6wuaEsvZ62QQ!2e0!7i13312!8i6656
Btw, they added an exclusion there, yay!

What is your opinion on making this a residential street?

Some more questionable combination of a do not enter and a bicycle way, seems like it's ok to assume things:
https://www.google.com/maps/@59.4683898,24.8678497,3a,45.2y,18.92h,89.94t/data=!3m6!1e1!3m4!1srfmjNFmN87cKBR6VhsdkTQ!2e0!7i13312!8i6656

Or not, I don't remember what turns are allowed from that road.

If I remember correctly, it has contradicting signs
1) Combined pedestrian/bicycle road sign
2) Do not enter sign with exclusion for residents (btw, do not enter sign applies to cyclists too, round red circle with a white background excludes them)
3) Residential road sign

The signs are kind of confusing there, but you have cut if off for cars completely. I'd say we should go for what practically is expected of this road.

In my opinion, this should be attached back to the Narva mnt and made residential. highway=residential is better than a cycle way as cyclists are often allowed on the road, but the routing software may completely ignore cycleways for cars. Also pedestrians may expect cars there.

Please fix it if you can, unless the signs changed or share your thoughts.

Hello, route way/129226648/history
is a residential road. Changing it back.

Noticed the same thing. I agree with fghj753. This makes the map a lot harder to read and contradicts convetion of making separate highways for physically separated roads.

If it got separated by bollards or something and you've decided to map it separatelly, then a bicycle lane from the road should be removed. It's a contraversial topic if bollards should make a cycleway separate osm.wiki/Talk:Key:cycleway#Corrections_to_descriptions_of_.22cycle_track.22

BTW, IMHO that node you added to way/943480756 doesn't make it prettier on the map.

Hello, you have added an incorrect bicycle path way/970994752
There is no separate bicycle path there, only a bicycle lane. It's already added. You can see it here https://www.cyclosm.org/#map=18/59.44047/24.75826/cyclosm

Please verify and rollback this change. I'm not removing it myself since Tallinn has recently added more bicycle paths and maybe something has changed, but I don't think they changed anything there except maybe adding red paint.

There is no ambiguity and you failed to demonstrate it. Only argumented thing is that it's hard to see park borders to which I again made an example that it happens on osm and there is no solution for a single raster renderer which wants to include overlapping information.

I don't see any point in continuing this argument as you ignore what I say. You may appeal to a broader public on osm help or forum and that may change my mind.

Things on maps overlap, you have to accept it. Like a grass on top of landuse=commercial will be green. It is still the same landuse, grass does not change that. I read map differently and for me it's clear that park includes the forest even if I don't see exact borders of the park in some places.

You have claimed that landuse cannot be consumed correctly and as I've demonstrated it can be.

So for me the issue is about more popular tag and a less popular unsupported one.

>In last comment I already brought the example of openstreetmap.org map that doesn't consume this data correctly: per its legend we can't really know that wooded area is part of park.

This is your personal opinion, should clients start to support landcover we will probably see the same picture.

> As far as I can see data that it has derived from OSM data just ignores wooded area that overlaps park.

Exactly, this prooves landuse data can be consumed correctly with natural=wood tagging.

Natural=wood is not a landuse tag. It may be used as such and it may be not. I didn't tag it as landuse=forest.

Could you give an example of a client consuming this data incorrectly? It IS a park and DOES have a forest. This is why I think the data is correct and it's ok for polygons to overlap. Here is an example of a client fully understanding the landuse. https://osmlanduse.org/#15.741974951963615/24.82777/59.46188/0/

While landcover may seem to offer better distinction, it is just not supported. And when having a choice between using a supported tag and an unsupported one, the choice should be clear.

Deciding if the forest or the park is more important to be on top is entirely up to the client and landcover would not fix that unless you are saying that we should rely on that it is unsupported and not drawn. BTW, it's not random, smaller areas get drawn on top of bigger.

Landcovers should be mapped in parks, amenity=park does NOT assume ANY vegetation, though you can probably expect grass by default.

Landcover may be a better tag in future, when the proposal is accepted and clients start to support it, but currently I don't see anything wrong with natural=wood.

Hello, I've reported this user for vandalism of Siider -> Piider names. He was already sent a blocking message by an admin.

I don't see a contradiction between a park and natural=wood. While your approach uses a tag which is not yet supported by most data consumers.

What are you trying to achieve?

Again, vandalism. removing a building to place a less accurate building in it's place.

I had a link to a facebook page in my changeset sources. Stop your vandalism.
https://www.facebook.com/siidrimaja/

Which maps/applications support landcover=trees?