Reverted

Reverted

Reverted

Yes, smaller more precise areas are better, but it is not good to combine them into one multipolygon which then creates one geometry in GIS database. Another thing is topology: areas should not overlap one another. We have automated QA checks for this in Lithuania.

I've disassembled farmland/residential areas from multipolygons to simple polygons, and fixed topology errors (overlapping polygons) in LITHUANIA, not in Moscow as your changeset comment states :-)

OsmAnd includes such addresses as most people do want to have them. If you want, you can always create your own custom map with whatever features and symbolisation you desire - it is called OsmAnd Map Creator.

Road classification is mapped to official one, as that gives more information on how the roads are maintained. Unclassified are roads which DO NOT have an official classification - which are not part of nation-wide road network. So unclassified does not relate to "in the village" or "outside of the village".

Duplicate/overlapping data of buildings was created, I've removed/fixed that.

Nikita, you're missing the point: address and building have NOTHING in common. There are a lot of buildings with no addresses, buildings with more than one address, addresses without buildings. For example a land parcel can have an address assigned and no building: you can order pizza or call paramedics to that address and it will be delivered right to that land parcel. Possibility to find/locate addresses is the reason why we have a real/official data of addresses in OSM. Address=location in SPACE, not "building ~name". Not all municipality address data has been imported yet: it is a lot of hard work, Trakai is in the queue (I will move it up, to be the next one to be imported:-).

Prašau netrinti gerų duomenų. Adreso egzistavimui nereikalingas joks fizinis objektas. Pakeitimas atšauktas.

Address is something which exists only in municipality records. It might have a "reflection on the ground" but not necessarily. Therefore we have the same addresses as municipality. Inventing addresses would be pointless.
Municipality provides addresses as open data therefore it is perfectly fine to have it in OSM. 99% of data in OSM is taken/adapted from other sources (note: ortophotograpic map is also a "different" map so vectorising features from ORT10LT is exactly the same as taking data from non ortophoto maps. We needed the same kind of permission to use ORT10LT as we have for importing addresses.
The same goes for proposed roads. Note: it is only data, you can decide what data to include or exclude from your map.

Adresai yra pildomi pagal oficialius Vilniaus savivaldybės duomenis. Adresas egzistuoja nepriklausomai nuo pastato. T.y. yra adresų, kurie egzistuoja, nors jokio pastato nėra.

Šiuo pakeitimu buvo bevardei gatvei pridėtas pavadinimas „Pumpėnų“: http://openmap-168413.ew.r.appspot.com/changeset/95311286

Bet tai jokių problemų, išsiaiškinome kaip kur kas, duomenys dabar tvarkingi. Sėkmės! :-)

There is one and only one official source for waterbodies - UETK. All other sources are irrelevant and smetimes even harmful (when outdated more than say 5 years, as toponyms change monthly). Wikipedia is a secondary thing for us so it is updated slower than OpenStreetMap. One more thing - wikipedia license is not suitable for its data to be used in OpenStreetMap.

Taip, toks yra aikštelės adresas. Bet Pumpėnų gatvė yra ta, kuri eina į garažus, link FM Perkūnas maniežo (ji jau yra pažymėta).

Ne, čia ne Pumpėnų gatvė.

Čia gyvi duomenys, gyva duombazė. Atšauktas CRAP.ME keitimas.

All lake data has already been updated according to contemporary situation, not according to outdated data. No fixes needed in Lithuania.

Restored correct wetland values, fixed broken forest polygon, removed pointless one-item relations. "Id" is a very bad editor.

Jei service=driveway netinkama klasifikacija, tai reikia įvesti kitą - tinkamesnę. Jei tinkamesnės nėra, tada tegul lieka driveway :-)