bkil (2018-08-07 20:13:44+00:00): Itt az eredeti szövegezés onnan indult ki, hogy egyesek berajzoltak egy parkoló körvonalat (vagy ház), majd tettek a közepére egy parkoló (vagy étterem) node-ot is, hogy a renderer oda rakja az ikont. Itt nem ez a helyzet - nem áll fel a redundancia és a duplikáció a két ábrázolni kívánt entitás között, ami jelen esetben az épület és az étterem.
https://wiki.openstreetmap.org/wiki/Good_practice#One_feature.2C_one_OSM_element

A térképen ábrázolunk egy épület entitást a hozzá kapcsolódó tulajdonságokkal (mint például a szín, szintek száma, tetőszerkezet, anyaga, architektúra, stb), és egy ettől koncepcióban eltérő étterem entitást (telefonszám, felszolgált ételek, házhoz szállítás) mely az épület fizikai határain belül található a megadott emelete(ke)n. Ízlés kérdése, hogy középre tesszük-e, bár ha a bejárathoz kicsit rakjuk az további információval szolgál.

Mint megállapítottuk, sokszor a hátsó rész raktár vagy ipari előkészítő és a padlástérben laknak is, emiatt fennáll az az érdekes helyzet, melyben az épületre helytelen mind a building=residential/house, mind a building=commercial/retail.

Most a gondolatkísérlet kedvéért tegyük fel, hogy senki nem lakik fent, nincs raktár, ipari főzőegység és semmi más az épületben, így az kizárólag 100% étterem. Mint fent már utaltam rá, az egyetlen entitáson levő túl sok címke maga zavarja a kiigazodást a felhasználó számára, ezért javaslom a szétbontást ekkor is ha csak van értelme.

Viszont ebben az esetben egy további érv, hogy bár a két entitásnak lehetnek közösen értelmezhető jellemzői, mint például az air_conditioning=* (ezt amúgy a POI node-ra javaslom inkább mivel szoba szinten változhat), viszont ahogy egy házra nem értelmezhető a kiszolgált ételek fajtája vagy a házhoz szállítás és telefonszám sem szigorúan köthető 1:1 hozzárendeléssel egy épülethez, ugyanúgy értelmetlen egy étteremnek az anyaga vagy színe. Ellenben még ellentmondásos címkék is előfordulhatnak, például a start_date=* jelentheti az épület építésének idejét illetve az étterem megnyitását is.

Bár szigorúan véve házszáma is csak az épületnek van és az éttermet nem a házszám határozza meg, hanem hogy pontosan melyik épület melyik részén található (emelet, ajtó, szárny, folyosó, stb). Nagy épületekben levő POI megadáskor különösen szembeötlő a haszontalan redundancia ahol minden POI-nak ugyanaz a házszáma. Azt az OSM data usereknek le kell tudnia (előbb vagy utóbb) kezelnie, hogyha adott házszámra keresek akkor az adott házban levő össze POI-t adja vissza eredményként, mert csak így van értelme.

Úgy érzem, hogy már elég sok érvet sorakoztattam fel amellett, hogy miért kell leválasztott entitásként kezelni egy házat és a benne levő POI-kat. Azt nem kötöm ki, hogy pontosan milyen módon legyenek szeparálva, erre egy példa ha az épület egy terület, míg a POI benne egy pont, de ugyanolyan helyes alternatíva az étterem entitást a tulajdonolt vagy bérelt telek vagy épületrész körvonalaként ábrázolni, főleg ha ezen belül sokféle dolog található. Egyelőre az utóbbit túl nagy munkának érzem a legtöbb esetben minimális megtérüléssel, ezért preferálom az előbbit.

Valószínűleg indítok erről egy wiki oldalt és kiküldöm a listára is mostanában.