P.P.S @waterproof_19m, ma ei olegi varem EHRist geomeetria importimisele mõelnud, paistab, et nad kasutavad hoone kujude jaoks teistsugust allikat kui Maa-amet. (või on ministeeriumite ühishoone geomeetria registris lihtsalt vigane)

Warning: very long message. You can just copy this message to Word to make reading it more bearable.

Tere,

First off, let's start with a brief overview of history. When i became OSM mapper, there was an active building import by SviMik that was focusing on adding new buildings from Maa-amet (MA from now on). SviMik had a policy, that to avoid possible editing conflict (conflict as overwriting someone's work without their consent), his bot would only either add new buildings or update addresses on buildings last edited by selected users/bots (mostly large volume users such as Verbatium, xybot and juhanjuku). At same time buildings added by his MA imports had very high data quality. Because of trying to not interfere with possible future imports, I'm still not really proficient at mapping buildings.

Collection of some resources regarding to SviMik's import.
SviMik's OSM website that was used to validate the data before bot imported it - http://osm.svimik.com/?lang=en
Import notice/documentation on wiki - osm.wiki/Maa-amet#Import
Talk-ee mailing list on Svimik import - https://groups.google.com/g/openstreetmap-ee/c/HnD85p3Wg9s (there are few other threads related to imports there, but it's not worth linking them here)
SviMik_import - @SviMik_import

Importing new buildings as outlines is not really difficult per se, just download ETAK data shapefile from MA and upload them with Josm. Problem here is the OSM's expectations for quality. For example, the most obvious step is adding tags that are suitable for OSM object and not uploading buildings that are already added to OSM. However, there are more nuances which reveal themselves after you have decided to start this process. In Estonian context, MA's geometry data is sometimes too high quality for modern OSM expectations (e.g having 40+ nodes per circular way while OSM standard is 20) or has minor artefacts caused by technical limitations of their internal software (complex issue, but it results in too many nodes on a straight line).

Those were just issues i had with geometry import. Another dimension is getting the address data right. My import focused only on geometry, because tags were already updated by SviMik's import in 2019. However, i noticed that address field in the dataset was just single text field - it would be really difficult to try to generate address tags from this field. More reliable source might be MA's ADS (aadressiandmed), but since that's not downloadable, just an API, then i believe using it would quickly become bottleneck for the import process. SviMik's source code for import bots is not public, mine is indeed on github repo linked above.
In future I personally would like to also incorporate data from Ehitisregister (EHR), because from there we could get data for building level, building materials, age etc for hundreds of thousands of buildings, but sadly that's unresearched topic, meaning OSM community might not have knowledge on how to obtain and process EHR’s data or if it’s even legal (by having compatible license). MA and EHR aren't directly linked either, so it would require lot of additional work to get buildings in two datasets to match each other.

My import on wiki - osm.wiki/Maa-amet_building_geometry_update
ETAK dataset on MA server - https://geoportaal.maaamet.ee/est/Ruumiandmed/Eesti-topograafia-andmekogu/Laadi-ETAK-andmed-alla-p609.html
EHR example data https://livekluster.ehr.ee/ui/ehr/v1/building/120772119

Replying to qqqqqqqqqqqqqqqqqqqq's questions:
0.1) There are various wiki pages regarding to imports and their documentation. Almost all known imports are documented on osm.wiki/Import/Catalogue I think all known large-scale organised Estonian imports are featured on that table, just use ctrl+F to find them. If either of you is going to conduct an import, please start from osm.wiki/Import/Guidelines and AECoC for generic guidelines on topic.
0.2) MA-geom import's main principe was to refrain from touching nodes that hadn't been updated for at least decade. My initial plan back in 2021 was to run second phase of import in spring 2024 (to update SviMik's first import) and then third run around 2028..2030. I have no idea if SviMik has any plans with his import.
1) Yes, that's the script. Can't give any guarantees if it's going to work.
2.0) Regarding other importable building properties, refer to paragraph on EHR.
2.1) Road refs are relatively easy thing to import. You need to keep in mind two main caveats:
2.1.1) Roads on ground (and in OSM) usually follow logical path while road registry (and therefore ref-numbering) follow parcel and local gov boundaries, meaning that you will need to pay extra attention to matching lot of parallel and/or intersecting roads and splitting OSM ways accordingly.
2.1.2) OSM has route relations, so you'd need to put in extra effort to your import script to make sure you don't break them while splitting ways.
2.1) (continued) Past summer I was travelling between Tallinn-Pärnu and discovered there were discrepancies not just on-the-ground and in road registry, but even same road's different ends had different names. Best known example could be Pärnu maantee, which is called that way in Tallinn, Tallinna maantee in Pärnu, but Tallinn-Pärnu-Ikla road in official registry. Sample changeset/region: changeset/123379963 (this one was done by hand.)
2.2) As for finding other potentially interesting things to add, take a look at different applications and map layers offered by MA: https://geoportaal.maaamet.ee/est/Kaardirakendused-p2.html
Back in 2010 there was navigation aids' import. That might have some interesting value, but problem is that due to legal reasons MA is not really keen to distribute machine-readable data about them. Sea charts have information about shipwrecks, this information can be connected with Vrakiregister to add shipwrecks to OSM.

P.S I was told this comment should be a wiki page. Problem is that I'm replying to your discussion too directly, so converting it to wiki page will require lot of editing.

Once upon a time i was taught that cyclist can't ride on the street if there is designated cycleway next to it. Double checked traffic laws and streetlevel imagery - Yes, those restrictions can be removed.

PPS. You have previously mentioned you don't write neither reasonable changeset comments nor split changesets into smaller regions because you don't have time. However, this changeset is part of series of 17 changesets made in 2 hours. I think making two changesets, one for eastern and other for western hemisphere and including adequate changeset comments could have actually been faster than your current process.

I'd also like to point out language use of this changeset comment. This appears to be global changeset made by russian-speaking user (see created_by value) making changes mostly in Russia (see modified objects list), yet comment on this chset is in German.

Dear iWowik, what is this changeset's connection to Germany? Why is changeset comment in German, not English or Russian?

PS. According to https://resultmaps.neis-one.org/osm-discussion-comments?user=iWowik , the user has been notified and confirmed receiving the information about large changesets and changesets comments since April 2021.

Tere, Priit.
iD kaardiredaktoris vaikimisi kuvatav Bingi pildikiht, mida sa kasutasid, on kõige halvem valik, mis on Eestis saadaval. Kõige paremad on Esri ja Maa-ameti (Estonia Ortho, Estonia Cadastre) kihid. Kaardikihi vahetamise aken avaneb parempoolsest külgpaneelist või klaviatuuri otseteena klahvi "B" abil.
Üldpildis ei tekkinudki kuigi suuri vigu, välja arvatud jalgtee Tööstuse tänaval (way/556539564) ning Vihuri tn kurv (osm.org/edit?background=maaamet.ee-orto&way=438948859).

@SimonPoole That's pretty much default behaviour in Josm - if you use click-and-drag method for selection tool, then it will select all nodes and ways within area by default.
@Pan, after selecting them such way, you can press ctrl+F, insert `type:way` into searchbox and choose "Find in selection" from left-hand menu.

Dear Mr/Mrs McBlyat,

Judging by the lack of any further complaints I presume reboot has resolved the issue.

All the best, Fghj753

Dear Mr/Mrs McBlyat,

I'm sorry to hear about difficulties you are experiencing with using changeset visualization tools. That software can be highly overwhelming for a person who has just joined the OSM community. Sadly I was not able to replicate issue you were describing on some of the most common tools.
If you could specify which tools you are using and perhaps share general information about your computer hardware, perhaps we could diagnose the cause of this issue and maybe even find a solution to your problem.
For starters, let's begin with the most common troubleshooting step of most computer issues: have you tried turning it off and on again?

Best regards, Fghj753

Nicely done, welcome to OSM!
Three things to note:
1) I don't know how familiar are you already with OSM data schema, but OSM uses pairs of key and value (such as building=house). To show that one key has multiple values, people usually use semicolon ( ; ) as separator between those values. That is useful for cases like house-numbers on Village Quarter Road, where you currently used comma ( , ).
2) Don't worry, you have done well, but on right-hand-side of the screen is button with three stacked squares. This is used selecting the map layer. I tried to make small edit on church's parking lot and noticed that both Esri's and Mapbox's imageries have much better quality than Bing, which is selected by default. Take a look at all of them and pick one that provides most recent or highest definition imagery.
3) Thirdly, I encourage you to keep up great work you have done and also suggest you to explore various presets in iD editor (buttons that appear on right-hand side after you have created new object on map). You could make you neighbourhood stand out on map by marking it as residential area, adding grass patches around church or tag Plastic Surgery Center as clinic/other healthcare provider.

Typo in ch.set comment: inction -> junction

Forgot to mention in description, but i also removed approx. 5000 nodes from ways with over 100 nodes, where gap between two nodes was less than 30 cm.

Sorry, it was supposed to be two changesets: one in North-Columbia & West-Venezuela and other around Ecuador, but I forgot to check if previous changeset was closed and accidentally uploaded new changes to already open changeset.

Please consider keeping consecutive changes to same area in same changeset. Looks like changesets 115042339, 115042818 and 115042942 could all have been in single changeset.

Correction: Mixed up east and west: this changeset applies to SW, not east.

Correction: Mixed up east and west: this changeset applies to NE/SE, not west

Dear Mr/Mrs Grin,

As you may have noticed by now, making large changesets in OSM attracts angry comments made by mappers, who are demanding you to create changesets with smaller bounding boxes. Such mappers are often located in Western and/or Central Europe. Therefore i agree with Gurgly Pipe on the matter that either size or positioning of your changeset is not optimal considering it's content and advise you to split future changesets bit smaller.

As a user from rather small country, i strongly disagree with suggestion of splitting changesets by country's borders, because in Europe such actions could lead to unreasonably small changesets (often 1-3 changes per country). Instead, i would suggest splitting changesets by continents while keeping in mind mapper density (latter means splitting Western Europe). For example in your case there could be 3 changesets: changes in Usa, southern hemisphere (incl Vietnam) and in Europe.

As for other two users. I have noticed under different global changesets, how some people (not necessarily you, don't take this personally) have voiced complaints over too large changesets breaking their review workflow. I would like to hereby encourage you to refrain yourself from such retroactive behaviour and focus on being proactive instead. If you are using a review tool that doesn't open large changesets, what is long-term benefit of announcing it in most changeset discussions? Why not think ahead and address the cause (tool doesn't support large changesets) instead of effect (tool crashes when opening large changeset)? Presuming the tool used is open source, please do open a pull request or at least issue on on tool's git/website and at least attempt to fix the bug yourself.
For example: if Lee Carre doesn't want to see large changesets in their OSM changes feed, they could simply create plugin for the feed analyser, which could filter out all changesets with three-digit longitudinal width or encompassing equator, such as this one.

Tere,
Juhul, kui oled huvitatud rohkematele tänavatele sõiduradade ja suunaviitade lisamisest, siis ma tegin kunagi väikse tööriista, millega saab neid lisada pisut kergemini kui iD-ga: https://kallejre.github.io/geo/osm%20lane%20tool/

I had a chance to drive past there today and stopped at parking lot for survey. Well, actually there's no signs about being a parking lot. Put together quick drawing of possible osm features. https://cdn.discordapp.com/attachments/537315188039221301/892523230919786496/parnamae-narva.png
In essence, what you see on Mapillary (and streetview) is up to date and valid. No-entry sign comes after the parking lot entrance, but the public part does go across two lowered kerbs (thin white line on drawing).
Most crossings have standardized tactile paving (drawn as thick white line) except crossing on Linnuse tee, which uses mosaic paving (green). Linnuse tee can be entered from all 3 roads and turning to all 3.
Notable odd thing is crossing in parking lot (near tip of yellow arrow) which has traffic_calming=table only on parking lot's side, but not on Linnuse tee's side. SW cycleway has guard rail along northern side, but there's gap at southern corner of parking lot.
All 4 directions of the junction have traffic lights. While U-turn at Irusilla tn is possible, it's not realistic due to volume of traffic and narrow road section.

I think Linnuse tee (way/129226648) should be mapped as residential road, but since it's dead-end road, there's no point in adding complicated access restriction tags.

Current state of Linnuse tee is tagged as cycleway with
motor_vehicle=destination on segment from parking aisle in north until concrete block in south. This means that routing engines will direct drivers to the residents via parking lot and sometimes via Irusilla. Luckily, traffic signs on this junction (#map=19/59.46023/24.90521) are visible on about month old Mapillary imagery.

* Turning right from Narva mnt to Linnuse tee is allowed as per destination sign on https://www.mapillary.com/app/?pKey=1001641713992040
* So is left-turn also allowed: https://www.mapillary.com/app/?pKey=2870427889890013
* Notice how first sign is black-on-white while second is white-on-blue. That is caused by junction being located on the legal border of city.
* Traffic signs (No entry except residents) on Linnuse tee are visible on https://www.mapillary.com/app/?pKey=132240762253013
. * Going straight from Pärnamäe tee to Linnuse tee is also allowed as per that image series.
. * There are no visible signs on Linnuse tee and median on Narva mnt has dashed line. Therefore You can turn on all 3 directions from Linnuse tee. It has traffic lights btw.
. * The living-street sign is placed roughly at the spot where street moves from one jurisdiction to another, BUT it's rotated 90 degrees compared to what it should be. That is technique often used with temporary road construction signs to indicate that restrictions are not applied at the moment.
* As for southern end of the street, there are metal barriers visible on last week imagery, but i can't determine, if there are more traffic signs. https://fotoladu.maaamet.ee/etak.php?B=59.45880109804291&L=24.90564843766783&fotoladu
* Regarding conflicting traffic signs, both Tallinn, Jõelähtme and maybe Viimsi should be notified, because road follows along border of two.

No idea if caused by this changeset, but node/633025611 may need fixing as well. I am not sure if it has tactile paving though. Looks like non-standard rumble strip.

PS. This junction was recently redrawn on OSM and anyone fixing this may encounter inconsistent relations or lanewise tagging.