Cool! It's weird when even the tools have different opinions on how things should be mapped. Osmose flags this as a building intersection.

Buildings shouldn't be inside other buildings. That's why the parking is tagged as building:part instead of building. If you want to tag it as a building, you should change the area of the adjacent building (with address 2) to not also cover the parking.

Maybe this is a footway? Did you forget to tag?

way/863836487

Orphan provides_feature!
relation/7517642#map=19/59.33402/18.06956

If Återvallsvägen 2-4 has been demolished, maybe just remove the buildings altogether?

Snyggt! Glöm inte att tagga cirkulationsplatser med junction=roundabout så att navigering funkar bättre!

Se t. ex. way/827602349

Maybe just remove the node?

Maybe we should just remove these. Its just confusing and there is no reference to any source for the proposal.

Hi! Nice job on mapping so many details!

One thing though: When mapping parking surface, make sure that the road leading to them cuts through the area so that routing softwares can properly find the way to them. It's better to make the parking area too large, overlapping onto the road (since this is the way any vehicle would enter/exit the parking anyway.

You can use this (hard-to-use) tool to edit advanced opening hours. Some examples at the bottom.
https://openingh.openstreetmap.de/evaluation_tool/

access=yes means any mode of transport is allowed, e.g. cars, bussens, horses. This doesn't make sense for steps. Please consider removing them. The default access is usually best.

changeset/87345750

Ah tänkte inte på det. Tankspridd. Fixar.

Hej, layer=0 behöver man inte skriva. Standardlagret är 0 om inget annat anges.

Vet du var huvudingångarna är?

Jag har gjort och kollat alla manuellt. Dvs. "accepterat" osmose förslag på ändring för varje objekt var för sig manuellt för att se att de verkar rimliga. Jag har utgått från att det inte spelar någon större roll om det var rätt eller fel innan.

Om det var rätt mappat så fick objektet lite mer info. Om det var fel mappat så är det fortfarande fel, fast med mer felaktig info. Det enda sättet att rätta det är ändå genom lokala mappers som märker att det är fel.

Jag håller inte med om att man ska anta all data är rätt, bara för att det nyligen är ändrat. Om man explicit vill hävda det kan man använda check_date eller survey:date.

Jag tror att det säkraste sättet för OSM att utvecklas är genom små, iterativa förändringar hela tiden (som detta). Det är värre att inte uppdatera data alls. Det leder mer troligen än ej till lägen där man behöver uppdatera massor av data vilket för många känns ännu läskigare (som i postnord-fallet). Worst case för mig är att OSM som helhet hamnar så långt efter verkligheten att det inte går att komma ikapp.

När jag var ny på OSM tyckte jag att det var jättesvårt eftersom det inte finns några riktiga standarder, alla gjorde lite olika. Osmose är bra på det sättet att man försiktigt kan standardisera lite grann.

Ok. Då föreslår jag att vi mappar respektive huvudingång/reception med en node, och låter resten vara omappat.

Märker också att landuse=education inte renderas med gul area. Funderar på vad man borde göra där. Hmm.

De applikationer som bara bryr sig om senaste datat (dvs majoriteten) behö er inte ladda ner hela historiken. Om man kan krympa storleken på den datan ens med 5 % så är väl det eftersträvansvärt?

Nej men det tillför inget heller eftersom bicycle=designated är default på highway=cycleway. Snarare så blir det skräpigt med alla extra taggar.