Hi! When deleting buildings, please check source/source:addr tags. Buildings with 2023 in source might not be visible in current orthophoto, but can be visible in kiirortofoto: https://fotoladu.maaamet.ee/?basemap=kiirortofoto&zlevel=15,27.28146,58.20663&fotoarhiiv&overlay=tyhi

Currently I restored this deleted building: way/1222925761/history

PS: Maa-amet põhikaart is updated once per year. Maa-amet also has "Kaart" imagery that is updated daily and can be used in iD as custom background:

https://kaart.maaamet.ee/wms/alus-geo?LAYERS=CORINE,BAASKAART,KAART24,HALDUSPIIRID,TEED,KYLAD&STYLES=&FORMAT=image/jpeg&CRS=EPSG:3857&WIDTH=256&HEIGHT=256&BBOX={bbox}&VERSION=1.3.0&SERVICE=WMS&REQUEST=GetMap

According to wiki changing building tag to ruins is not the best practice. If building type is missing then it doesn't matter if you replace "yes" with "ruins". But generally any other value in building tag shouldn't be overwritten.

It's just two nodes with same location, both connected to a way. Current version of iD suggest merging these node when editing:
node/11291352728
node/11291333520

Varemetes hoone - way/231841578

Antud juhul peaks building=yes silt vist ikkagi alles jääma?

Mulle endale tundub, et varemete kaardistamisel on building=yes + ruins=yes kõige levinum.

Alternatiivina peaks ka ruins:building=yes sobima.

Hi Guido,
I've noticed that you, or your bot script, have been fixing this duplicate node issue for Naya Kabir edits for quite long time.

Could it be that is caused by a bug in Go Map?
https://github.com/bryceco/GoMap/issues/206

Have you noticed similar issues with other Go Map changesets?

Hi! I noticed that the newly created building part [/way/1217080636](way/1217080636) is with building=apartments tag. I believe correct tagging would be to use building:part=apartments without building tag.

Although this is not wrong, what is the benefit, if both the building and the building parts have full address? This is such a minor thing, but I believe the address shouldn't be duplicated on both elements. Sure, if you include additional details like addr:unit to building part, then it's perfectly fine.

Raja esialgsel kaardistamisel, mis oli aastal 2015, märgiti selgelt, et tegu on planeeritava rajaga: "planned sport track".

Kommentaar "ei leidnud mingit nähtavat rada" viitab otseselt sellele, et antud planeeritud rada jäi kahjuks paberi peale:
changeset/30920562

Antud gps logi pole vastavuses selle planeeritud rajaga:
@juhanjuku/traces/10712855

Ka väikeste metsaradade kaardistamisel tuleb lähtuda sellest, mis reaalselt olemas on:
osm.wiki/Verifiability

Tundub, et sellest planeeritud rajast pole mitte midagi välja tulnud. Strava heatmapi järgi on seal metsas liikumist küll, aga mitte mööda neid radu. Kustutasin planeeritud raja ära: changeset/142027751

Most bike routers don't allow cycling on highway=footway anyway, unless there is an addition bicycle yes/designated tag. And I think this is generally a good thing. In this way/1115986757 example, bicycle tag is mostly useless since it only connects pedestrian footways.

I've seen several "kergliiklusteid" that are not properly connected to the rest of cycling network. Meaning crossings are footways without bicycle tag. In such cases it is necessary change it to fix bike routing.

But please, don't use bike dismount unless this is really needed and there are actual signs for that like in way/1136290745

FYI - fixme in node/11206280748

I can confirm the motocross race track does indeed cross with XCO bike trail:

https://fotoladu.maaamet.ee/?basemap=kiirortofoto&zlevel=15,26.94990,59.36051&overlay=tyhi
https://www.strava.com/heatmap#18.14/26.95021/59.36020/gray/ride

Here is how I would rank the possible tagging options, if this bog trail is indeed unridable for most of the time by bike.

1) leaving it as just "highway=path" is the worst option, since routers have no clue if this section is usable by bike.

2) Adding "bicycle=no" is better, but technically incorrect.

3/4) Adding "mtb:scale=6" to is technically correct if the trail is unridable by a skilled MTB rider.

3/4) Using highway=footway instead.

The thing is there is no "you probably don't want to go there with a bike" tag that is widely supported by routers. There is a class:bicycle tag: class:bicycle=* but this is not established one and it has some other issues as well. In case you want make sure that the bike routers won't accidentally direct someone to a bog, then mtb:scale=6 could be effectively used for that. IMO it is far better to use this than access tag. Access tag shouldn't be subjective like mtb:scale.

But better yet, I'd use highway=footway without bicycle tag. Then 99% of bike routers would avoid it.

PS: and to muddy the waters even further, winter mountainbiking is also a thing and with the right conditions you could ride on ice and snow that is on top of frozen bog.

I agree with qqqqqqqqqqqqqqqqqqqq, generally it is a bad practice to use bicycle=no tag for paths, that are not suitable for bikes at all.

As an alternative you could use:

1) highway=footway with appropriate surface tag.

2) mtb:scale=6 - this essentially means impassable by MTB. But keep in mind that there are some fatbike and MTB rides who like to ride on very difficult terrain.

I have personally surveyed way/1127876697 way/277874021 and part of way/1124645979 that's between these two paths. That section was ridable and quite far from "physically impossible to cycle".

Not*

Note sure what kind of issue Apirnus wants to resolve.

Mustika Keskuse Apteek is already mapped in OSM:
node/7755823506/history

Opening hours from the photo (https://westnordost.de/p/149089.jpg) along with name and operator where correct from version 1 with Rocketdata import.

It does look strange.

Just for reference, Maa-amet has mapped this as a stream:
https://geoportaal.maaamet.ee/index.php?lang_id=1&page_id=872&etak_id=2242633

About these historic tags - I suppose addr:* tags can be useful and it looks address is valid as well:
https://xgis.maaamet.ee/adsavalik/CU02095490

But I believe maaamet:ETAK and source should be deleted since these are no longer relevant.

Restored the path after a survey.

changeset/140464374

Considering that highway=path is already quite ambiguous, adding just surface=asphalt would be misleading. In a urban environment it should be safe to assume surface=asphalt has excellent smoothness. I personally wouldn't use surface tag at all since half of the year this path is covered with moss/mud/leaves/snow/ice. If you really need to use surface tag then "paved" should be acceptable.

Sure, not actually suggestion to use asfaldipuru or any other nonstandard tag.

way/48865157 - is surface=asphalt actually useful without any additional tags? If I recall correctly something like https://taginfo.openstreetmap.org/tags/surface=asfaldipuru might be more appropriate in this case