piebro/osm-data huggingface dataset:
mavl (2019-11-16 17:59:09+00:00): This changeset has been reverted fully or in part by changesets 77162861, 77164108, 77168783, 77165597, 77167134, 77158548, 77170414, 77161342 where the changeset comment is: The changesets are reverted [DWG has the request to revert the changesets. Reason: an incompatible source - https://www.openstreetmap.org/user_blocks/3257].
Supaplex (2019-08-09 17:26:09+00:00): 恭喜您透過 Maps.Me 完成第一次的地圖編輯！ 歡迎加入開放街圖，群眾共同參與，繪製生活週遭大家關心事物的共編地圖。Maps.Me App 採用開放街圖的地理資料，由社群而非商業公司建置的地理資料庫。以下是相關的參考資料，歡迎隨時指教與提問。

編輯須知
台灣的標示依循準則可參考 http://wiki.openstreetmap.org/wiki/Taiwan
常見的圖徵標示方式可參考 http://wiki.openstreetmap.org/wiki/Zh-hant:Map_Features
給Pokemon Go玩家的建議：https://wiki.openstreetmap.org/wiki/Tips_for_new_(Pokemon_Go)_mappers
組織性編輯指南：https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines

由於Maps.Me隨著軟體更新更新最新地圖，App裡的地圖資料版本可能略舊，透過Maps.Me增添商家等資料時有可能開放街圖上已經有了，請到http://www.osm.org 網站看是否要加的商家有沒有人加上去了。

台灣社群網站
台灣 OpenStreetMap 網站  https://osm.tw/
臉書粉絲頁OpenStreetMap台灣 https://www.facebook.com/openstreetmaptaiwan/
台灣社群Facebook社團 https://www.facebook.com/groups/OpenStreetMap.TW/
郵件論壇 https://lists.openstreetmap.org/listinfo/talk-tw
Telegram OpenStreetMap Taiwan https://t.me/joinchat/Aqu2IgnTuIidMfREdNmomQ
Telegram OpenStreetMap Asia  https://t.me/OpenStreetMapAsia
Slack https://osm-tw.signup.team/

Happy Mapping!
catdreamer (2019-08-25 08:57:44+00:00): 露營車?
N50 (2019-08-03 02:56:09+00:00): Why have you vandalized here, Mr. Amazon?
alivelis (2019-08-05 13:48:08+00:00): Hi N50,
 
Thanks for looking into my edit. This segment was added by me previously based on an old imagery. However, this mistake was captured in the review and hence I deleted the road as per the latest imagery. This deletion was done not with an intention of vandalism but with an aim to contribute only good data towards OSM. I have taken it as a lesson and will certainly use it in my future edits. Let me know in case you have any suggestions. 
 
Regards
alivelis
Supaplex (2019-08-09 17:26:29+00:00): 恭喜您完成第一次的地圖編輯！ 歡迎加入開放街圖，群眾共同參與，繪製生活週遭大家關心事物的共編地圖。以下是相關的參考資料，歡迎隨時指教與提問。

編輯須知
台灣的標示依循準則可參考 http://wiki.openstreetmap.org/wiki/Taiwan
常見的圖徵標示方式可參考 http://wiki.openstreetmap.org/wiki/Zh-hant:Map_Features
給Pokemon Go玩家的建議：https://wiki.openstreetmap.org/wiki/Tips_for_new_(Pokemon_Go)_mappers
組織性編輯指南：https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines

台灣社群網站
台灣 OpenStreetMap 網站  https://osm.tw/
臉書粉絲頁OpenStreetMap台灣 https://www.facebook.com/openstreetmaptaiwan/
台灣社群Facebook社團 https://www.facebook.com/groups/OpenStreetMap.TW/
郵件論壇 https://lists.openstreetmap.org/listinfo/talk-tw
Telegram OpenStreetMap Taiwan https://t.me/joinchat/Aqu2IgnTuIidMfREdNmomQ
Telegram OpenStreetMap Asia  https://t.me/OpenStreetMapAsia
Slack https://osm-tw.signup.team/

Happy Mapping!
user_8466505 (2020-09-14 22:24:55+00:00): Hey there! Is the juice place you added a juice bar?
Thanks,
TheAdventurer64
Yoqtan (2020-09-17 12:40:59+00:00): I assume you can call it that way?
It's a small shop cold pressing juice and putting that in small plastic bottles. Patrons pick up bottles from a large fridge and pay at the counter. There is no place to sit in the shop, nor outside the shop, it's all in takeaway
4004 (2019-07-28 16:55:22+00:00): здравствуйте и спасибо за информацию,
парковка - это площадной обьект, если рисовать будете полигон то в поиске увидите парковка.
а от буков "парковка" на замкнутом участке дороги парковка не появится
zetes-s (2019-07-28 18:46:40+00:00): Я недавно работаю в программе - еще учусь. Но парковки, которые я добавил, в городе появились.
4004 (2019-07-28 18:54:39+00:00): понятно, спасибо.
возможно, вам будет полезно пройти миникурс по редактору, справа панель с книжечкой
zetes-s (2019-07-28 18:57:34+00:00): Спасибо.
viloan (2019-07-28 06:34:54+00:00): Bem-vindo(a) ao OpenStreetMap e parabéns pela sua primeira edição! :-)

Temos um portal brasileiro sobre o OpenStreetMap, com várias informações úteis em https://wiki.openstreetmap.org/wiki/Brasil

Enquanto você está se acostumando com o OpenStreetMap, é recomendado que sempre pergunte aos usuários mais experientes antes de remover ou modificar objetos do mapa, especialmente aqueles que são aparentemente "estranhos" ou "fora do lugar".

Além disso, pedimos que não copie dados de mapas proprietários (como nomes de ruas do Google Maps, por exemplo) e que mapeie apenas o que existe na realidade.

Se você está mapeando por causa do Pokémon, dê uma olhada em https://blog.openstreetmap.org/2017/12/01/dicas-para-novos-mapeadores-pokemon-go/?lang=pt-pt
Se você está mapeando por causa do jogo do Harry Potter, as dicas e explicações na página anterior também são úteis para você.

Se tiver qualquer tipo de dúvida você pode entrar em contato com a comunidade brasileira através de algum dos canais disponíveis em https://wiki.openstreetmap.org/wiki/Pt:Contact
O canal "Comunidade" do Telegram costuma ser o mais movimentado.

Abraço e boa diversão com suas edições!
Munna Bhai Sahab (2019-07-28 08:11:03+00:00): You are right. This is a wrong place.
viloan (2019-07-28 06:40:24+00:00): Bem-vindo(a) ao OpenStreetMap e parabéns pela sua primeira edição! :-)

Temos um portal brasileiro sobre o OpenStreetMap, com várias informações úteis em https://wiki.openstreetmap.org/wiki/Brasil

Enquanto você está se acostumando com o OpenStreetMap, é recomendado que sempre pergunte aos usuários mais experientes antes de remover ou modificar objetos do mapa, especialmente aqueles que são aparentemente "estranhos" ou "fora do lugar".

Além disso, pedimos que não copie dados de mapas proprietários (como nomes de ruas do Google Maps, por exemplo) e que mapeie apenas o que existe na realidade.

Se você está mapeando por causa do Pokémon, dê uma olhada em https://blog.openstreetmap.org/2017/12/01/dicas-para-novos-mapeadores-pokemon-go/?lang=pt-pt
Se você está mapeando por causa do jogo do Harry Potter, as dicas e explicações na página anterior também são úteis para você.

Se tiver qualquer tipo de dúvida você pode entrar em contato com a comunidade brasileira através de algum dos canais disponíveis em https://wiki.openstreetmap.org/wiki/Pt:Contact
O canal "Comunidade" do Telegram costuma ser o mais movimentado.

Abraço e boa diversão com suas edições!
Famlam (2019-07-28 06:53:59+00:00): Blijkbaar heb ik per ongeluk een knoop met landuse=residential voor heel Nijmegen verbonden... Vermoed dat dit geen ramp is?
eggie (2019-07-28 07:41:32+00:00): Hier kun je zien dat de Houtlaan en de landuse=residential doordat je een serviceweg hebt verbonden  aan elkaar zitten.
Met G de nodes even losmaken. De landuse=residential iets verschuiven en dan de wegen weer aan elkaar plakken.
Je edits.. http://overpass-api.de/achavi/?changeset=72730664
Gr Eggie
eggie (2019-07-28 07:42:55+00:00): .. Maar natuurlijk niet de hele residential als vlak verschuiven, want die zal ergens anders vast ook wel geplakt zitten en dan krijg je daar wel schade. Het liefst zie ik zo'n residential helemaal los.
eggie (2019-07-28 08:13:45+00:00): De Houtlaan heb ik losgemaakt van de landuse=residential. 

Top.. Zag dat needless tagging hier al was verwijderd. Van voorgaande mapper nog geen reactie ontvangen, maar hij heeft ook verder niet meer gemapt.
eggie
eggie (2019-07-28 08:58:35+00:00): Wat ik zo tegenkwam met de validatie van josm heb ik ontdaan van needless tagging. 
Wie weet reageert mapper nog.
Famlam (2019-07-28 12:25:04+00:00): Dankjewel voor het oplossen! Ik heb helaas ook nog geen reactie ontvangen van die mapper.

Verrassend eigenlijk is dat deze changeset stelt dat ik ook het terrein van de RU heb aangepast (weg 4747311), maar de achavi link dat niet zegt. (De laatste klopt volgens mij ook, ik kan me niet herinneren dit aangepast te hebben)
eggie (2019-07-28 12:32:51+00:00): Zou er niet te lang over nadenken. :)
Aan de vele vragen die aan mapper zijn gesteld en waar hij nooit op heeft gereageerd denk ik niet dat er een reactie komt.
Famlam (2019-07-28 12:38:55+00:00): Stiekem heb ik er wel nog eventjes over nagedacht en dit gevonden ;)

https://josm.openstreetmap.de/ticket/17983
aharvey (2020-02-28 03:17:41+00:00): Hi I can't see any evidence of a cycleway at https://www.openstreetmap.org/way/286201267 see https://www.mapillary.com/map/im/vYDHTuJkM619XNBMk6GjAw has it since changed since July 2017?
ma-rt-in (2019-07-29 18:47:23+00:00): Hallo,
erstmal kann ich mir einen service-Weg in einem Wohngebiet mit maxspeed=10 schwer vorstellen. Zum Parkplatz: Entweden extra dann aber ohne zufahrtsweg oder an die Straße taggen.
vg
ClarkstonCorrect (2019-07-28 11:21:00+00:00): why
Munna Bhai Sahab (2019-07-28 08:08:13+00:00): good, all right
Владимир К (2020-03-16 17:53:14+00:00): Добрый день!
Заметил ваши правки и рекомендовал бы использовать снимки Maxar. здесь они явно свежее, есть новые объекты. а некоторых наоборот - уже нет, например https://www.openstreetmap.org/way/708189323 на Maxar уже нет
freebeer (2019-07-29 19:48:45+00:00): yep, this changeset is the second of the earlier linked trio around red bluff.  the vertical line only has node 970, while the horizontal pairs it with 968, while 969 is located somewhere else entirely.

in some edits i fix, i see four or more nodes piled up, so i wonder if they were meant to appear elsewhere, as i try to understand the amazon edits and place blame.

thanks
Adamant1 (2019-07-29 21:54:33+00:00): Hhhmmm, I check for this stuff on my end when doing edits and I never see it happening on the edit side. So, I'm under the impression this is something happening on iD Editor's side that isn't due to bad mapping habits. Who knows when its happening or why though.  If I read things on Amazon correctly they are using a modified version of iD Editor to do their mapping right?
freebeer (2019-07-31 10:54:27+00:00): blast.  my previous firefox session wherein i had links to the erroneous fence is gone, so i can't link directly to demonstrate my observations.

i've seen it enough to suspect a pattern.

amazon is not using what i consider a fork the way dragonflyBSD is a fork from freeLSD, but what i am guessing is a snapshot, earlier of .12, now of the iD .3 with the torism  bug, as of last week.  this is a guess based on outside observations of what i suspect in the us would be considered trade secrects or proprietary info.

as far as what is added, changed or removed, my guess it is minimal and likely not kept too up-to-date, but that is only a gut theory with nothing to back it up.  i don't follow iD development to know if amazon developers exist there to send things upstream.  my outside view of amazon differs slightly from my understanding of the intel/linux-kernel in terms of resources at the least.

but that isn't important as the errors i find do not seem to be limited to one fork, but apparently a general iD issue.

interesting you say you don't get the warnings mentioned above, when others take them as gospel and blindly mis-correct non-errors.  in any case, based on iD-only edits and guessing at its internal workings, it seems to emerge after correcting several instances  overnight what occasionally happens is

user draws a-b-c-d-e
although the osm node numbers assigned to your tee are out-of-order so maybe you started from one end, then continued from the other end to meet in the middle.  the sequential series is what i observe from amazon in almost all cases i analyse.

if a way is branched between two nodes, no problem.  here you choose point, say b, to branch from.  same also seen when branching from pre-existing non-iD nodes.

you drew from b to f and maybe beyond.  or you thought you did.

on upload, instead of a b to f link, iD creates a new node co-located with b, now f in sequence, adds that to abcde as afbcde or abfcde, i have not noted.

then from f branches to g and beyond, not touching the pre-existing b.

as b and f are co-located, i consider this bug to originated within iD, and nothing to do with your mapping habits.

it is also not consistent or the map would be flooded with these daily.  it only hits you as an extensive iD user a few times per month.

that amazon is probably contributing (without immediately identifying info as i continue to mention repeatedly) with this type of addition on a scale several times that of other iD users means  this presumably obscure bug has surfaced more often.

same with duped nodes in a way, when positions 12345 are mapped by nodes abcdefgh in order 1233345 (i think imissed one) or abcdcef.

since it is infrequent, i guess i can't ask anything more of you or anyone,, but should i point out future errors to you, or quietly fix them as EWONTFIX return codes from iD?

yes, i am cynical.
freebeer (2019-08-02 12:04:46+00:00): adam, i did not even notice that this was your 11'999th edit until just now.
 
but to add a further observation, from an amazon edit from nothingness i just mended, user drew a-b-c-d, then went back to branch from c. duplicate node e, co-locaated with c, was uploaded.  in the order of the first way, it was inserted a-b-e-c-d, e beiing the intersection, c unattached to branch e-f-...

note that it seems iD, presumably like potlatch that uses internal negative numbering in order of work, uploads the nodes in sequence so the osm-assigned numbers they receive correspond to the order they were created.  it seems not to be true for JOSM uploads with dupe nodes, where stepping node-by-node along a way (can you do that in iD?  seems not available in Potlatch1) shows numbers all over the place.

whether this ordering info helps to track down the bug is anyone's guess, but i felt it important to document this, meaningful or not.
Adamant1 (2019-08-02 19:58:57+00:00): Yep. That's pretty funny. It's pretty crazy I've had that many edits in only like 2 1/2 years also. All with no imports. I was totally planning on retiring at 10,000 edits, but now I'm thinking 20,000. I should probably call it good and get a girlfriend or something instead, but whatever. 

As far as your observation goes, I think it's spot (node?) on. Even if it rarely happens, I appreciate you putting the time and brain power into figuring it. As I think it would still be worth reporting to the iD Editor peeps if we (mostly you) can fully figure it out. Never happening would be better then rarely happening. Hopefully Amazon is using a branch of iD Editor that can be updated with the bug fix once it's applied to the upstream version. Although, my guess is not because they probably don't care. I looked to see if they had a Github page for their editor and it seems not. Facebook does though for their AI road editor. Which, bonus points to them for that. Amazon should follow their lead (or maybe they did and I just missed it). 

Anyway, good job figuring it out, probably.
freebeer (2019-08-04 11:10:26+00:00): by the way, don't you invoke your editor with a middle-button click in a new tab?  i'm into that habit because of how painfully slow reloading and redrawing any page is so by now i have something like a hundred tabs to sort through with enough works-in-progress that i almost hope for a crash or disconnect to give me a clean slate.  then remember to enable the notes layer and login before setting off again.

in general i think i've cleaned most of the dupe nodes outside california, to get a better handle on their frequency.  same with self-intersections that are starting to recur in ways i've not really been able to reproduce without effort in potlatch2, that seems to better safeguard against these things in a lightweight manner that would not surprise me if it were more efficient than the bulk of editing i see in many amazon changesets.  or i could be jaded by the beginner-friendliness, animations, and pop-ups iD offers when i can't refresh my screen in under a third of a second at best earlier, now actually worse.

determining the source of the bugs is probably not something i can do the way i was 40 or more years ago with FORTRAN i've long forgotten.  i'd probably cynically grep the source for rnd() or rand() or however the language in use i'd have to learn describes once-in-a-blue-edit functions.  or maybe search the code for
/* now let's annoy those snivelling Potlatch potheads by dumping bogus data  for them to fix */
but i'd abandon my criticism upon finding such an obvious and impossible smoking gun.

the best i can do is point out operator error so it doesn't flood the map at the rate amazon are contributing, and comment on the unusual cases like where six nodes get piled up in the hope someone who already has a grasp of the code, where to find it, and what the design intention is, will question that intention.  i've too often seen little documented code divert in reality from the intended flow, and i'm no longer maintaining any k0dez i know intimately where reproducible bugs can be tracked by me.  plus i can't even start iD now, not that i could reproduce these errors.

i suspect that amazon simply applies a few cosmetic patches (host is obvious) but doesn't do much to the innards, although i could see stripping out a bunch of unused functionality like brand name links and such.  luckily they do not seem to be doing showstopper edits like other organised teams (über/lyft/grab/can't-remember) making mincemeat of relations on the west coast in ways like i've cleaned after you somewhere, but worse, as it was regularly damaging map data every handful of edits.

it's just a matter of getting the fix(es) into iD in the first place.
BCNorwich (2019-08-02 17:08:07+00:00): I have amended your tags to suit https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dgolf_course
Please use this guide in the future.
eggie (2019-07-28 09:10:01+00:00): Dag oetAelse.. je hebt een yoegangsweg omgetagd in een fietspad. Staat hier een bord fietspad?  Het zal allemaal niet meer routeren, want op de kruising heb je een hek gezet met access=private. Staat dat hek wellicht op dat stukje toegangsweg?
Routeren doet het niet meer.
MVG,
Eggie
eggie (2019-07-28 10:03:19+00:00): reverted door Wijzigingenset #72733957
eggie (2019-07-28 09:11:51+00:00): e geeft aan source=BING.. Die achtergrondluchtfoto ligt enorm verschoven en wordt ernstig ontraden om te gebruiken!!
Gebruik de pdok luchtfoto actueeel. Die ligt goed. Kijk je nog even?
MVG,
Eggie
eggie (2019-07-28 10:02:53+00:00): reverted door Wijzigingenset #72733925
eggie (2019-07-28 09:13:12+00:00): Zolas met alles is alle begin moeilijk. Je moet het allemaal maar weten. foot en bicycle=yes beter verwijderen. dat is default op een fietspad en geeft nu een foutmelding. Haal je het weg|?

MVG,
Eggie
eggie (2019-07-28 09:14:26+00:00): Een verbinding met de Geverikstraat routeert niet meer wegens het plaatsen van een hek op de kruising met access=private
eggie (2019-07-28 09:33:14+00:00): Ik draai de changesets terug, want het was van oorsprong hier goed getagd. Er is hier geen fietspad . het hek staat verderop.
Het is onwaarschijnlijk dat dit verplaatst is midden op de kruising. Dat is fysiek onmogelijk. 
 Het is wel verboden voor motorvoertuigen . Dat klopt. 
Wanneer je nog vragen hebt stel ze gerust.
MVG,
Eggie
eggie (2019-07-28 10:02:24+00:00): reverted door Wijzigingenset #72733925
eggie (2019-07-28 09:33:44+00:00): Oke.. ik heb nog niets teruggedraaid. Ik kijk zo even verder.. Succes.
Eggie
eggie (2019-07-28 09:38:04+00:00): Nu heb je van de highway=service een highway=path gemaakt met access=no
Dat is het bord verboden toegang.
Weg met access=no :)
Ik denk dat de juiste tags zijn
highway=service
motor_vehicle=no
Evt moped=yes en mofa=yes omdat sommige routers daar weer motorvoertuigen in zien.
bicycle en foot is  default.. dus niet taggen. Kwaad kan het niet.
eggie (2019-07-28 10:01:37+00:00): reverted door  Wijzigingenset #72733806
Verder heb ik de aansluiting met het fietpad Europa laan wel routeerbaar gemaakt want dat kwam uit op een weg die op slot stond voor fietsers. Nu heeft het een verbinding met die toegangsweg. 
bicycle =yes toegevoegd voor de duidelijkheid. Eigenlijk niet nodig ..moped mofa toegevoegd. 
Een highway=path staat ook open voor alle tweewielers. 
Het routeert nu weer en dat was ook al  niet het geval voordat jij begon. 
De fout zat in de aansluiting met de Europalaan.
Gr eggie
eggie (2019-07-28 10:29:05+00:00): Dag Niels... even " ter leering ende vermaeck"   
We maken in OSM niet zelf adressen aan. Die komen rechtstreeks met import uit het kadster. (BAG import)
Je kunt dus het beste op de bestaande adresnodes bijtaggen.
4a ligt aan de zuidkant vlakbij. Graag dus adres verwijderen en info samenvoegen met BAG nr 4a.
MVG,
Eggie
eggie (2019-07-28 20:58:01+00:00): info samengevoegd met adresnode
user_5359 (2019-07-28 11:24:48+00:00): Welcome to OSM! Please don't mark the whole property as building. Only mark the building as building.
lbptoady (2019-07-29 07:19:02+00:00): Thanks for notifying me! I appreciate the correction!
omri_derhi (2019-07-28 10:05:58+00:00): used Bing imagery
!bm (2021-01-20 00:53:50+00:00): Hallo gandi, 

statt Löschen eines leerstehenden Geschäftslokals u.a. POI ist es in den allermeisten Fällen besser, disused:* zu setzen, s. https://wiki.openstreetmap.org/wiki/DE:Key:disused: (beachte generell  https://wiki.openstreetmap.org/wiki/Lifecycle_prefix )

Der Grund ist ganz einfach, dass die Chronik erhalten werden soll:
https://wiki.openstreetmap.org/wiki/DE:Good_practice#Erhalte_die_Chronik
https://wiki.openstreetmap.org/wiki/Keep_the_history

Im konkreten Fall wurde wieder eröffnet: https://www.openstreetmap.org/node/3332061409

--besteGrüße!bm
eggie (2019-07-28 10:25:30+00:00): Welkom bij OSM... bedankt voor je bijdrage, Svp niet de adresnummers veranderen. De notatie komt rechtstreeks vanuit het Kadaster. 
MVG,
eggie
abakus_uploader (2019-07-28 22:40:53+00:00): (Wiadomość automatyczna)
Cześć!
Otrzymujesz ten komentarz, ponieważ dodałeś lub zmodyfikowałeś adres, który jest niepełny lub błędny.
Adres powinien zawierać minimum trzy znaczniki: addr:city=[nazwa_miejscowosci] + addr:street=[nazwa_ulicy] + addr:housenumber=[numer_porządkowy].
Wyjątkiem są miejscowości bez nazwanych ulic - wtedy stosujemy znaczniki: addr:place=[nazwa_miejscowosci] + addr:housenumber=[numer_porządkowy].
Bez poprawnego oznaczenia adresów, nie będą one brane pod uwagę przez wyszukiwarki, dlatego warto je dostosować do ww. schematu (w zależności od sytuacji).
Więcej informacji na forum: https://forum.openstreetmap.org/viewtopic.php?id=5632 - a pytania najlepiej zadawać tu: https://forum.openstreetmap.org/viewtopic.php?pid=681873
Pozdrawiamy!
Mazda05 (2019-07-28 11:17:22+00:00): Нет причин для изменения класса дороги на tertiary и/или unclassified, так как автодорога федерального значения А154 на всём своём протяжении удовлетворяет необходимым требованиям highway=primary по соглашению о классификации автодорог в ВикиПроекте Россия https://wiki.openstreetmap.org/wiki/RU:Highway_classification. Цитаты: «highway=primary автомобильные дороги регионального значения, соединяющие крупные города и/или областные центры, дороги межрегионального значения, не являющиеся trunk»
«highway=tertiary более важные автомобильные дороги среди прочих автомобильных дорог местного значения, например соединяющие районные центры с сёлами, а также несколько сёл между собой»
«highway=unclassified остальные автомобильные дороги местного значения, образующие соединительную сеть дорог»
Mazda05 (2019-07-28 11:17:27+00:00): There is no reason to change the class of the road to "highway=tertiary" or "highway=unclassified", since the highway of federal significance A154 throughout its length meets the necessary requirements for "highway=primary" according to the agreement on the classification of roads in OSMWiki Russia https://wiki.openstreetmap.org/wiki/RU:Highway_classification
Quotes: «highway=primary - highways of regional significance connecting major cities and / or regional centers, highways of interregional significance that are not "highway=trunk"»
«highway=tertiary - is more important roads, among other local roads, for example, connecting district centers with villages, as well as several villages among themselves»
«highway=unclassified - other local roads forming the connecting road network»