<div dir="ltr"><div>Tetszik, hogy próbálsz algoritmikus megoldást találni :-)</div><div><br></div><div>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.</div><div>Ahol a térkép valamilyen centralizált eszközön renderelődik, pl. webszerverek, ott még könnyebb ezen változtatni. A megjelenítők másik része kézi kütyükön (okostelefonok, tabletek, GPS eszközök) fut, ezeken már erősebbek a korlátok. Esetenként a rendering zárt forrású, és nem tudunk rajta módosítani (pl. Garmin), máskor ha módosítható is, évekbe telhet, mire egy frissítés beépül az appokba és kikerül a telefonokra.</div><div><br></div><div>A kézi kütyük esetén, egy magas számítási igényű algoritmus hamar leszívná az aksit - emiatt eleve nem célszerű túl bonyolult renderinget kihelyezni, poligon méreteket számolgatni stb. Nemcsak nem célszerű, de ilyet ezek a renderingek nem is tudnak.</div><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>Üdv,</div><div>Gergő</div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 1, 2024 at 1:43 PM <<a href="mailto:osm2@igor2.repo.hu">osm2@igor2.repo.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Szia,<br>
<br>
(az alabbiakban nem openstreetmapre relevans javaslatokat probalok tenni, <br>
pusztan meg nem valosulo rendszerek programozasi aspektusain merengek)<br>
<br>
On Fri, 1 Mar 2024, Gergely Matefi wrote:<br>
<br>
>Szia,<br>
><br>
>a patchwork módszertan problémái akkor ütköznek ki jól, ha egy létez? nagyobb<br>
<br>
Koszi, ezekkel a problemakkal egyetertek. <br>
<br>
De ezek nem tunnek olyan bonyolultnak, hogy ha ez a modszer lett volna az <br>
ajanlott akkor ne lehetett volna ra egyszeruen hatekonyt toolt <br>
fejleszteni.<br>
<br>
Peldaul a ketteosztas technikaja: rajzolok egy way-t keresztbe a polygonon <br>
ugy, hogy a ket vege rajta van a korvonalon, de nem metszi mas reszeit. <br>
Ezutan a tool fogja, kettevagja az eredeti polygont a ket metszespont <br>
kozott, leduplikalja a behuzott osztovonalat (akarhany nodebol is alljon) <br>
es osszefuzi a 2-2 vonalszakaszt ketto szomszedos polygonna.<br>
<br>
Hogy hol osszam kette: en azt mondom, hogy barhol, nem kell hozza <br>
kifogas sem... Elsore nem latom, hogy mit veszt az ember azzal, ha egy <br>
nagy meretu nevtelen szantofold helyett ket kisebbet rajzol fel. <br>
<br>
A valosagban amugy is inkabb a forditjat latom: a muholdkepen egyertelmuen <br>
latszodo kisebb, valtozatos novenyzetu es valoszinuleg eltero tulajdonosu <br>
parcellak helyett az egesz fole van egy nagy farmland huzva. Azt nyilvan <br>
nem gondolom, hogy ezeket az adott esetben pici parcellakat egyesevel kene <br>
felrajzolni, de azt igen, hogy ilyenek menten kisebb darabokbol jobb lett <br>
volna, mint mindet osszevonva folyotol folyoig.<br>
<br>
<snip><br>
<br>
>Kérdés, hogyan tudsz ebb?l a helyzetb?l úgy kijönni, hogy kétértelm? átfedéses<br>
>poligonok se maradjanak, és a felhasználók is kényelmesen, egyszer?en, gyorsan<br>
>tudjanak szerkeszteni.<br>
<br>
Ami nekem legjobban tetszett volna es kezeli ezt a kerdest is:<br>
<br>
0. Itt most az area jelentse a a multipolygont es a tiszta, zart hurku <br>
wayt, de csak olyan objektumokat, amiket a megjeleniteskor fillezett <br>
sokszogkent szeretnenk kirajzolni. A tiszta azt jelenti, hogy nincs benne <br>
onmetszes (tehat egy "masni" topologia az mar kapasbol hiba es nem tudjuk <br>
mit rajzol).<br>
<br>
1. Rajzolaskor az adott teruleten az egymast nem metszo (de korvonalakban <br>
akar osztozo) egyszeru areakbol taggelestol fuggetlenul egy terulet <br>
szerint sorbarendezett lista vagy heap keszul. Az egymast metszoket <br>
hibanak tekintjuk (az ellenorzo programokban jelezzuk) es azokra a <br>
renderelesi sorrend nem garantalt.<br>
<br>
2. A rendereles a tag alapu sorrendet kovetve elkezdi csinalni a dolgat, <br>
barhogy is legyen ez implementalva az adott eszkozben; ha vannak <br>
renderelesi szintek, akkor egy szinten belul a fillezett teruletek <br>
rajzolasa meret szerinti sorrendben tortenik; ha nincs szintezes, akkor <br>
meg ugy altalaban az osszes fillezett objektum meret szerinti sorrebden <br>
rajzolodik. A nagyobbtol a kisebb fele haladunk.<br>
<br>
Az egymassal reszben atfedo eset nem letezik legalisan, mert egymast <br>
metszo teruleteket nem engedtunk meg. Kozos hatarvonalon a stroke marad <br>
csak kerdes, de ott lehet egymas melle kettot rajzolni, ehhez csak azt <br>
kell tudni eldonteni, hogy a vonal melyik oldala esik a polygon belseje <br>
(ha amugy tud fillezni, akkor ilyene mar van).<br>
<br>
Ez a rendszer kompatibilis lett volna a patchworkkel (atfedo elu areak), a <br>
multypologinokkal (egy area tipusu mutlipoly inner korvonala sem metszhet <br>
semmilyen masik area korvonalat). Az egyszeri felhasznalo meg siman <br>
odarajzolhat egy darab erdot a mezo kozepere, mint ha nem lenne holnap, es <br>
magatol azt fogja csinalni, amire szamit.<br>
<br>
Persze tokeletes modszer nincs, ennek is vannak kevesbe erdekes es csunya <br>
peremei is. Ami elsore eszembe jut:<br>
<br>
- valamivel dragabb a rendereles, mert sorba kell rakni dolgokat; de amugy <br>
is van level= tag; ha szepre akarod renderelni az utakat, akkor ott is <br>
szmit a sorrend, vagy hogy a stroke ne logjon egymasra; onamagaban a <br>
multipolyogonokat ossze kell szedni es renderelheto polygonna alakitani; <br>
ezek eleg bonyodalmas es draga muveletek, foleg ha orszag meretu adaton <br>
dolgozol; ezekhez kepest a teruletek kiszamolasa es rendezese mar nem <br>
tunik minosegi kulonbsegnek<br>
<br>
- olyat ebben nem lehet rajzolni, hogy egy kisebb area direkt a nagyobb <br>
ala keruljon (es emiatt egyaltalan ne latszodjon); gondolom letezhet eset, <br>
mikor direkt ez a cel; ha igen, akkor ezt valami taggelessel lehetett <br>
volna workaroundolni<br>
<br>
- ha van mondjuk egy mezod (way), azon belul egy sziget szeru erdod (way) <br>
es az egeszen keresztbe akarsz rajzolni egy hosszu folyot (ugy, hogy az is <br>
egy area a pontos alak miatt) es a mezon is atvag es az erdon is, akkor <br>
azt a folyot bizony fel kell szabdalnod a mezo es az erdo hataranak <br>
atlepesekor. Ezt mar csak azert is meg kell tenned, hogy elkeruld az <br>
egymast metszo areakat. Viszont ebbol az automatikusan kiadodik, hogy <br>
az erdon vagy a mezon beluli folyoszakasz garantaltan kisebb teruletu <br>
lesz, mint a mezo vagy az erdo, ezert fole kerul. (Ha nem kene <br>
felszabdalni, akkor elofordulhatna, hogy egy hosszu folyo osszessegeben <br>
nagyobb teruletu, mint a pici erdo, amit atszel, ezert az erdo ala <br>
kerul.) <br>
<br>
<br>
Nyilvan egy ilyen rendszerben is vannak olyan szerkesztesi esetek, amik <br>
macerasak, peldaul pont ez a folyoszabdalas. Viszont osszessegeben azert <br>
tetszett volna ez jobban, mert:<br>
<br>
- ebben minden nagyon lokalis, csak a szuken vett szomszedsagatol fugg<br>
<br>
- az egyszeru, hetkoznapi dolgokat ("itt latok egy erdot, gyorsan <br>
berajzolom") konnyu megcsinalni, es inkabb az amugy is bonyolultabb, <br>
ritkabb dolgokat (mindent atszelo folyo) nehezebb<br>
<br>
- azt hiszem a kezdo rajzolo, a kis teruletet letolto rajzolo, az ovatlan <br>
profi rajzolo, a nagy adatmennyiseget felautomata modon atturni <br>
kenyszerulo rajzolo is kisebb esellyel rontja el a meglevo objektumokat<br>
<br>
<br>
Udv,<br>
<br>
Igor2<br>
-- <br>
Talk-hu levelezőlista<br>
<a href="mailto:Talk-hu@openstreetmap.org" target="_blank">Talk-hu@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-hu" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-hu</a><br>
Leiratkozás a fenti címen vagy <<a href="mailto:talk-hu-request@openstreetmap.org" target="_blank">talk-hu-request@openstreetmap.org</a>> címre egy levél, témája "unsubscribe", tartalma mindegy.<br>
</blockquote></div></div>