[Talk-hu] Landuse polygonok (programozasi kockulas)

[osm2 at igor2.repo.hu]

On Fri, 1 Mar 2024, Gergely Matefi wrote:

>Tetszik, hogy próbálsz algoritmikus megoldást találni :-)

Programozoi artalom!

>A rendering engine-knél ugye nem egyetlen motorról beszélünk, valószín?leg
>több száz vagy ezer különböz? motor van a világban.

Teljesen igazad van!

Viszont:

https://wiki.openstreetmap.org/wiki/Contribute_map_data

szerint "More than ten million contributors make OpenStreetMap possible." 
Ha mondjuk ezek kozul csak minden ezredik rajzolt valaha landuse-t, az 10 
ezer felhasznalo.

Ha innen nezzuk, melyiket lett volna konnyebb "masok altal 
implementaltatni":

- azt a szabalyrendszert, amit orszagonkent maskepp kell jol ertelmeznie 
10 ezer felhasznalonak, akik kozul sokan nem fognak nagyon elmelyedni az 
egeszben (vegulis csak egy vacak erdot akarnak odarakni)

- vagy 1000 szoftvert egy jol megirt specbol olyan programozoknak, akik 
kenytelenek ettol fuggetlenul is elmelyedni a temaban?

Masreszt ha a tokeletlen vilagunkban egyik sem sikerul, akkor mi okozza a 
nagyobb problemat egy random harmadik felnek:

- ha 10 ezer felhasznalo fele minimum egy vagy tobb modon csinalja ugy, 
hogy azt a felhasznalok egy masik csoportja hibasnak tartja, tehat az 
adatbazis lesz hibas/kenyelmetlen/csunya

- vagy ha 1000 szoftverbol a fele nem tokeletesen implementalta a 
specifikaciot?

Innen kozelitve szerintem az egyszerubb szerkesztesi szabalyrendszer a 
bonyolultabb renderelo programok aran jo uzlet. Ha epp rosszul sikerult 
programot hasznalok es ez zavar, max valtok masikra. De ha "rosszul 
sikerult" reszt latok az adatbazisban, nem tudok ennyire egyzeruen masikra 
valtani.

(Ez termeszetesen szubjektiv velemeny.)

>Amit utóbbiak esetén meg lehet tenni, hogy térkép gyártási id?ben
>kiszámoltatni a poligonok közötti "inner" relációkat. Inner reláció alatt a
>szokásos OSM definíciót értem: egy kisebb poligon megszakítja egy
>nagyobb poligon felületét. Ha van erre gyors algoritmikus megoldás, akkor
>már valóban feleslegessé válna, hogy kézzel hozzuk létre ezeket a
>relációkat. Rendering szempontjából megoldható lenne, hogy mondjuk 5 réteget
>definiálnánk, az 1. rétegbe kerülnének az alappoligonok, a 2.-ba az
>alappoligonok innerjei, a 3.-ba az innerek innerjei stb. Ez így már kezelhet?
>probléma lenne a kézi kütyük renderingjével is.

Igen, ezzel teljesen egyetertek. 

Kicsit altalanosabban nezve: olyan adatbazist es szerkesztesi szabalyokat 
szerintem nem lehet kitalalni, ami egyforman jol es azonnal hasznalhato a 
webes renderre, vektoros renderre, mindenfele automatizalt lekeresre, 
mobil eszkozokre, kezdok altali konnyu szerkesztesre. Nyilvan 
kompromisszumokat kell kotni az egymasnak ellentmondo kovetelmenyek 
kozott.

Az akkumulatoros kiseszkoz a landuse szempontjabol szerintem azert 
specialis es egyszeru eset, mert azt nem tartom valoszinunek hogy nagy (pl 
orszag) meretu terkepet akarnal ratolteni es megjeleniteni ugy, hogy azt 
az adatot nem kifejezetten erre optimalizaltad. Ha pedig az egesz 
adatbazisod (osm) nem szuken veve erre optimalizalva keszult, akkor 
mindenkeppen kell elofeldolgozas/konverzio. Ezt pedig pusztan az 
adatmennyiseg miatt eleve nagy szamitasi kapacitason es ramon futtatod. Ha 
pedig ez mindenkeppen van, akkor mar nem tunik veszesen nagy arnak ezt 
tovabb bonyolitani. Nyilvan csak akkor, ha lefut veges ido alatt (lasd 
lejjebb).

>Már csak azt a toolt hiányolom, amely ezt a gyakorlatban véges futásid?vel
>kiszámolná egy szép méretes PBF-re...

Mivel az egesz thread teoretikus elmelkedes, en a konkret toolokat nem 
hianyolom. De elgondolkozni rajtuk persze jo moka!

(Na innentol jon az igazi off-topic hegy, elnezest a listatol!)

Azt nem tudom, hogy masok hogyan csinalnak ilyesmit. Azt viszont tudom, 
hogy en a sajat programomban hogyan csinalnam, es abban a rendszerben nem 
tunik komplikaltnak vagy energiaigenyesnek egy meret szerinti rendezest 
bevenni rendereles kozben. A trukk az, hogy nem az egesz orszagra akarnam 
a rendezest megcsinalni, csak arra a kis reszre, amit ki kell rajzolnom. 
Ott pedig ket eset van:

- vagy be vagyok zoomolva es akkor legrosszabb esetben is csak par 
tizes nagysagrendu polygonrol esik csak be a rajzolasi bboxba

- vagy ki vagyok zoomolva, mondjuk egy egesz megyet nezek, de akkor meg 
kapasbol (meret alapjan es tagek alapjan) eldobok nagyon sok objektumot, 
meg sem probalom renderelni oket, mert ugysem latszananak, cserebe dragak 
lennenek; es igy kis kepernyon megint csak szazas nagysagrend marad (ez a 
patchworkos megadasra nem mukdne, mert ott kb minden 1 pixelnyi lenne es 
nem rajzolnam ki)

Ez az egesz pusztan annyi elofeldolgozast igenyelne, hogy minden fillezet 
sokszognek (barmilyen adattipusbol is jon) ki kell szamolni a teruletet.

Amit eredetileg felvetettel: lehetne fejjel lefele is csinalni, "egyszer" 
kiszamolni az egesz vilagra. En nem 5 szintu dolgo csinalnak, hanem egy 
nagy erdot, ahol minden fa egy lokalisan legnagyobb poly, a gyerekei pedig 
a benne foglalt kisebbek, rekurzivan. (A fakat lehetne tarolni akar nem 
multipolygon relationben, ha a relation tud relationt hivatkozni... Tehat 
meg be is ferhetne az elofeldolgozas eredmenye az OSM adatmodellbe, 5 
szintes limit nelkul is!) 

Ezek utan az elofeldolgozo a normal adatok kozul torolne a fillezett 
sokszogeket, de a fa relationokat az erdobol berakna. Kirajzolaskor csak 
az eppen lathato relation fakat rajzolnam ki, tetszoleges sorrendben (mert 
nem atfedok). Fankent fentrol lefele, mert igy mar z szerint rendezettek 
alulrol felfele.

Van nem kidolgozott otletkezdemenyem, hogy az erdo epitesenek hogyan 
allnek neki. Ha van eleg ram nagysagrendileg az egesz fillezett polygon 
halmazt ketszer tarolni, es nem metszik egymast a teruletek, akkor most 
ugy gonodolom, hogy ezt az erdot meg lehetne epiteni harom darab maximum 
O(n*log(n)) szintu egymas utan futtatott muvelettel, n a teruletek szama.

Perem: szabalytalan, egymast metszo esetben ez az otlet a fakon belul egy 
random dontest hozna elofeldolgozas kozben, viszont ket fa kozott 
rendereles kozben z-fight lenne.

(Ez milyen szuper challenge24 feladat lehetett volna abban az evben, 
mikor OSM feladat is volt a donton!)


Udv,

Igor2