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.

Tere, Kas on mingi oluline põhjus, miks on vaja osad sõidurajad nii pikkade eraldiseisvate joontena joonistada? (rõhk sõnal "pikkade")
Näiteks pööre Pärnamäe teelt Narva mnt-le võiks olla ~6-7 korda lühem (350 vs 50 m; way/979841381). Ma saan täiesti aru eri suundadeks jagamise kasulikkusest, aga mitte sellest, miks nad nii vara peavad hargnema. Ametlikult öeldakse vist, et tee peaks hargnema füüsilise takistuse juurest (ohutussaar keset teed) või erandjuhul pidevjoone algusest, aga mitte kunagi uue pöörderaja algusest.
Tegelikult näevad ka mõned bussiliinid selle muudatuse tulemusel kummalised välja (vt Iru bussipeatus), aga nende pärast pole hetkel vaja muretseda.

I'm really sorry. Situation was caused because i used overpass query for only (high)ways and nodes, but didn't include relations. Issue is impacting up to 1219 ways in 13 changesets in 2 cities.
Such changes were made in Tallinn, Tartu and Haapsalu. Latter was done with iD, so no relations were broken there.

Should these changes be reverted (and later in far future properly recreated) or is it worth attempting to fix up? In first case, are there solutions to split ways based on ends of current ways while properly slicing relations as well? In latter case useful tools might be Josm's relations' plugin and OSM inspector (http://tools.geofabrik.de/osmi/?view=pubtrans_routes). I have neither competence to fix the situation nor time to readd lanes (using iD) in case of revert. These splittings didn't affect only bus routes, but also road route relations as well.

Affected changesets:
changeset/109705088
changeset/109706438
changeset/109706513
changeset/109708590
changeset/109710326
changeset/109710842
changeset/110061689
changeset/110064342
changeset/110076297
changeset/110383287
changeset/110409629
changeset/110423518
changeset/110424431

PS. Thanks for your incredible effort you have previously shown to add those bus routes to OSM!

Ma hakkasin kirjutama kommentaari, et Maa-ameti kaart ei näitagi poodide asukohti, aga tuleb välja, et mõned üksikud ettevõtted on kaardile siiski kantud [1]. Samuti kuvatakse Terviseameti kaartidel apteeke [2] ja ujulaid [3]. See, et kasutaja poolt allikana kasutatav andmekogu (nt Maa-ameti kaart) ei sisalda teatud nähtuste klassi (nt alkoholipoode), ei tähenda, et nimetatud nähtuseid ei eksisteeriks.

[1] - https://xgis.maaamet.ee/xgis2/page/link/oJW2jm0y
[2] - https://xgis.maaamet.ee/xgis2/page/link/I4N9yY02
[3] - https://xgis.maaamet.ee/xgis2/page/app/terviseamet_veetervis

Objektide liigutamine pika vahemaa taha ongi muudetud võimalikult keeruliseks, sest tihti on juhtunud, et keegi võtab kinni mõnest ristmikust ning tõstab selle kogemata paralleeltänavale. Näiteks saaks Gonsiori tänav teha läbi Kadrioru pargi hüppe Narva maanteele.

Viga parandatud kogumis changeset/109665545

Tere,
Tekkis küsimus, kas Truumu diagnostika töökoda asub Petrooleumi tänaval või Pärnu maanteel? Hetkel jääb käesolevast muudatusest mulje, nagu oleks ettevõte avanud Petrooleumi tn-l teise esinduse ning Pärnu mnt-l lammutatud majas asuv esindus on endiselt samas kohas avatud, kuid on vahepeal saanud uue aadressi. Kas tegu on veaga ning kas võin duplikaadi eemaldada, või soovid ise proovida olukorda parandada? Juhul kui ettevõte kolis ühest kohast teise, on mõistlik võtta vana (Pärnu mnt-l asuv) variant ja tõsta see Petrooleumi tn-le. Hetkel samas kohas asuva sõlme võib kustutada.
Ette tänades, Fghj753.

Ok then. Thanks for replying.

Hello,
I noticed you are using custom script to upload bus stops to OSM. Due to slightly diagonal shape Norway, changesets covering entire Norway like this one will also cover most populous parts of neighbouring countries, which may upset some people. Is it possible to split your changesets somewhere between latitude 64..66N?
I took a look at your upload script and it's processing based on counties. Seems like easiest solution to implement would be running two copies of script: one which excludes counties ["18", "54"]; other version excludes others ["03", "11", "15", "30", "34", "38", "42", "46", "50"]. Downside of this approach means having to input your password twice. Alternative is perhaps segregating lines 974-994 to separate function, passing excluded counties to function via arguments and calling it twice.
Do you mind looking into splitting changesets?

Parandatud. Review no longer needed.

Thanks for route_master relations tip.
I think relations not being edited in this set was probably due to limitation of Level0 editor, which only loads first 500 elements. Relations are usually listed at the end of overpass results set and therefore editor dropped them due to meeting limit on maximum number of elements.

Sorry for global changeset. I tried to introduce bounding box to overpass query but global query was only way to run it without getting any errors.
Changed elements where value of colour=* was clearly hexadeciamal number (matched regex `^[0-9a-fA-F]{6}$`), but didn't have prefixed `#`.
Query was [out:xml][timeout:60]; ( nwr["colour"~"^[0-9a-fA-F]{6}$"];); out meta;