Kādēļ ceļam way/34582752 nomainīts kods no V1047 uz V9? Līdz ar to arī maršruta relācija vairs neatbilst. Arī Baldones iela nav nosaukums šim posmam.

Kādēļ izdzēsti tilta celiņi way/1317156828 un way/1324455641 lai iezīmētu tieši tur pat?

Lūdzu nezīmēt krustojumus ar neeksistējošiem ceļiem - šeit nav atsevišķu `link` kā way/1488052037 vai way/1488052038 , ja nekas nav pa gadu mainījies.

Šeit pārejai nav saliņa node/12255838615 , ja katras brauktuves pāreja ir iezīmēta atsevišķi. (Un otra pāreja nav līdz galam iekartēta.)

Šie mazie celiņu laukumu posmi kā way/1488052035 nav `highway=pedestrian`, bet `area:highway=footway`.

Sveiki,

Nosaukumus vajadzētu pievienot tikai, ja tie ir oficiāli vai vismaz labi zināmi. "Dūņezera piknikvieta" izklausās drīzāk pēc apraksta. Vai te ir kāda (jauna) zīme vai norāde ar nosaukumu?

Please don't change roads that access multiple properties to driveways, especially if they have separate "lines" in the cadaster, in this case way/425515678 . Normally, only the final access road section in the private property is a driveway.

I think the entrance node to the building should not be on the way itself, but rather on an offshoot of the way. Currently, navigating along the way implies using the entrance. Kind of like barrier=*#How_to_map_barrier_nodes

Šeit way/1489434747 nevarēs būt access=private, jo 35. ēkā ir publiski-pieejams veikals.

Šeit laukums ar sētu un līdz ar to sēta pievienota pie ceļa node/13651278954

Šeit sēta ir pievienota ceļam node/13647818522

Sveiki,

Lūdzu nepievieno access=private un barrier=fence laukumiem, kas nav privātas teritorijas un pārklāj publiskus ceļus un infrastruktūru. Pirms pievienot šādas vērtības visai teritorijai, vispirms šāds laukums tad ir jāpārzīmē tieši pa sētu robežām, ja tur tiešām apkārt ir pilnībā sēta un tikai sēta. Piemēram, šis laukums way/1489227173 "nogrieza" ielas posmu un dzelzceļu. Vai arī šis way/1489227166/ pāri ceļam.

Ja ir jau iezīmētas sētas atsevišķi, tad nevar likt laukumam klāt vēl vienu barrier=fence iekartējot vienu sētu divas reizes. Piemēram, šeit jau bija daļa sētu iezīmētas - piemēram, way/1489227174. Tagad ir divas savstarpēji šķības sētas viena otru pārklājot way/374246441.

Nevar arī likt šādi barrier=fence, ja nav tiešām visā perimetrā sēta. Piemēram, šeit sēta pārklājas ar vairākām ēkām - way/1489227175. Nevar būt sēta un mājas siena reizē un šeit sētas ir jākartē ar atsevišķām līnijām.

Sētas arī pārklājas ar celiņiem, piemēram - way/1156223905/ vai way/1156223908. Tad šeit ir savienojumā jānorāda, vai te ir vārti vai kas cits, jo pašlaik sēta "lido" pa virsu celiņam, bet celiņi joprojām savieno navigāciju caur teritoriju kā publisku.

You are adding train stopping location points to the route as platforms (`platform`), but they should be stop locations (`stop`). The actual platform is the way or area that is drawn for the platform where passengers wait and board for this specific route.

Diemžēl problēma, ka Bing nobīde var mainīties pat vienas vietas ietvaros, jo tas no satelīta un visādu iemeslu dēļ ir šķībs. Šeit drošvien, jo te ir neliels pakalns tieši parkam pa vidu un ap to uz visām pusēm nobīdes, bet tagad paskatoties vēl, es arī nezinu kāpēc tik smaga lokāla nobīde.

Jā, veikalam bija šis punkts node/6576756038/history tur pat, kur ēka ar `shop=convenience`.

The name of the road should not be a description, the tags of the elements describe it. The access should be private, which is the more common way of tagging these. It should also not be a full unclassified road if it's just property access, but rather a driveway. I also fixed landuse to residential, although I am not sure about the primary use.

No kāda ortofoto tieši tu šo esi zīmējis? Šeit gandrīz viss ir nobīdīts par pārdesmit metriem, izskatās, ka uz ļoti šķībo Bing. Līdz šim viss bija iezīmēts precīzi pēc 7/8 LVM ortofoto.

Šeit veikals divreiz way/1339243889, šeit stāvvieta way/1472984150, šeit DUS way/1487120155, šeit rotaļu laukums way/1488829126

Čau,

Kā jau minētu, nekartē lūdzu vienu objektu vairākas reizes kartē. Šeit DUS amenity=fuel bija iekartēts trīs reizes - kā laukums, kā punkts un kā ēka - way/1469730038, node/2200265297, way/1469730037 .

The bot uses address data from https://data.gov.lv/dati/dataset/varis-atvertie-dati , which doesn't have these cadastral address assignments directly, just one address per location and the bot tries to place it at that location. I personally agree with you that the bot should not remove this, I'm just not sure how to implement this. Normally, the land owner is supposed to request VZD to fix the location. I'd like there to be a distance threshold in bot's logic to allow someone to manually "assign" a building on OSM. Or it could involve the bot parsing something like https://data.gov.lv/dati/dataset/kadastra-informacijas-sistemas-atvertie-dati/resource/2aeea249-6948-4713-92c2-e01543ea0f33 which I believe has data for each building. You'd need to talk to the bot author (on Zulip or something), I don't really know more technical details.

The short answer is because the official address point location is not on the church building, but away from it on a (non-existent/new) building outline in cadaster. It also looks like 51, not 49, which is already assigned to the building west.

Ēkas nav, bet ortofoto redzamas - tās kāds var atkal iezīmēt, ja atstāt kartē tukšu vietu. Daudz vietās tā pa jaunu tiek sazīmētas nojauktas ēkas, ceļi un viss kas.

Žogs ir gar ietvi, bet tikai līdz dienvidu sienai. Mapillary nevar redzēt uz sāniem; es pēc tam jaunākas bildes izlikšu. Es kartē atzīmēju to posmu.

Sveiki,

Ēkas nevajadzētu dzēst, kamēr tās redzamas ortofoto, ja neko citu to vietā neiezīmē. Jo pēc tam nav iespējams noteikt daudzus gadus, vai te ir neiezīmēta ēka un jebkurš cits to iezīmēs, kas bieži notiek. Te pat no kadastra vēl ēku kontūras nav noņemtas. Šeit arī adrešu punkti līdz ar ēkām nodzēsti (bots gan tos atjauno, bet vēsture elementiem pazūd). Un siena dienvidos šeit nemaz nav nojaukta.

Es atjaunoju.

Šādos gadījumos vislabāk lietot osm.wiki/Lifecycle_prefix