Š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

The signs (at least the North one, but I assume both) have been replaced and now say "Anniņmuižas Jaunā pamatskola".

Sveiki,

Ja uz celiņiem nav veloceļu zīmes, tad tie nav veloceļi neatkarīgi no tā, kā to kāds kaut kur plānojis vai cik tas līdzīgs citiem celiņiem. Pēc CSN šeit ir parasts gājēju ceļš/ietve un nevar to atzīmēt kā veloceļu kartē. Ja pašvaldība uzliks zīmes, tad arī atzīmēsim.

Hello,

As mentioned before, changing the stops does not update the routes themselves. Please either update the transport routes when editing or leave a note or a review request so they can be reviewed and fixed. Otherwise, you are leaving an incorrect route layout and missing stops.

I have fixed the routes here.

Thanks

Yeah, I agree, this sucks and should probably remain a multipolygon until OSM has a proper site relation support for features with independent "parts". I was fixing a bunch of schools and started encountering this case with different values for parts, such as you cannot really use ref=* with multipolygon members because they are not areas as such - what happens if you split one of the ways? Now there are 2 outer ways - so do they both get a ref=*? And what if another feature uses the way - how does it know the ref isn't for it? But yeah, site relation doesn't seem like a better option either, so I changed it back to a multipolygon.

Kas šeit ir mainījies? Ir jāiezīmē izmaiņas tā, lai citiem kartētājiem vēlāk nerastos neskaidrības, jo tagad tas izskatās no ortofoto (un visticamāk vēl 3+ gadus tā izskatīsies) pēc neiezīmēta savienojuma un jebkurš to var pa jaunu iezīmēt. Jau iepriekš jautāju par blakus changeset/178731175 .

After checking these additions, a whole lot of these are non-existent and seemingly made up. Especially random street lights everywhere. Many duplicates, dubious tags, incorrect values, etc. I've reverted this edit. I am not sure the author actually surveyed any of this in person. Not sure what is even correct, but it all needs to be resurveyed.