"A térképen abból semmi nem látszik, hogy két egymást keresztező objektumnak van-e közös pontja."
Útvonaltervezési logikát NEM tárolunk geometriában.
Azért vicces, hogy ezt olyannak kell leírni, aki a saját vállát simogatja, hogy ő mennyire pro, de még egyszer:
Az adattárolást nem keverjük az üzleti logikával, az üzleti logikát nem keverjük a felhasználói felülettel.
Nem azt kell tárolni az adatbázisban, hogy
id|név|nettó|bruttó|áfa
1 |xyz|100 |127 |27
hanem azt, hogy
id|név|nettó|áfa
1 |xyz|100 |27
és készíteni egy függvényt:
bruttó (termék_id, áfakulcs)
ami kikeresi a termékhez tartozó nettó árat, áfa kulcsot, és kiszámítja a bruttó árat. És nem azt adja eredményül, hogy <div style="színes csicsás megjelenés">127 forint</div>, hanem annyit, hogy 127, mert a megjelenésről már a felhasználói felület gondoskodik, a saját szabályai szerint.
Az út geometriája adat.
Az útvonaltervezés az üzleti logika.
A térképen megjelenés (akár raszter, akár vektor) a felhasználói felület.
Nem szabad, illetve nem lehet összekeverni a rétegeket, mert körülményessé teszi a hibakeresést, és megakadályozza a fejlesztést. Ha a rétegek, megfelelően, külön vannak kezelve, akkor egyes rétegek cserélhetőek, vagy párhuzamosan működtethetőek: pl. új útvonaltervező beállítható , hogy sem az adatstruktúrán, sem a megjelenítésen nem kell változtatni.
Az, hogy geometriában tároljunk útvonaltervezési adatot, annyira illogikus, hogy azért kértem tőled a teljesítménybéli növekedések értékeit, mert azt gondoltam, hogy bizonyára olyan mértékű, ami ellensúlyozza a nyilvánvaló hátrányokat. De te ilyet nem tudtál felhozni, érvelésed lényege annyi volt, hogy szerinted ez jó ötlet.