[Talk-hu] Landuse polygonok (programozasi kockulas)

[Gergely Matefi]

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

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.
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.

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.

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.

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...

Üdv,
Gergő


On Fri, Mar 1, 2024 at 1:43 PM <osm2 at igor2.repo.hu> wrote:

> Szia,
>
> (az alabbiakban nem openstreetmapre relevans javaslatokat probalok tenni,
> pusztan meg nem valosulo rendszerek programozasi aspektusain merengek)
>
> On Fri, 1 Mar 2024, Gergely Matefi wrote:
>
> >Szia,
> >
> >a patchwork módszertan problémái akkor ütköznek ki jól, ha egy létez?
> nagyobb
>
> Koszi, ezekkel a problemakkal egyetertek.
>
> De ezek nem tunnek olyan bonyolultnak, hogy ha ez a modszer lett volna az
> ajanlott akkor ne lehetett volna ra egyszeruen hatekonyt toolt
> fejleszteni.
>
> Peldaul a ketteosztas technikaja: rajzolok egy way-t keresztbe a polygonon
> ugy, hogy a ket vege rajta van a korvonalon, de nem metszi mas reszeit.
> Ezutan a tool fogja, kettevagja az eredeti polygont a ket metszespont
> kozott, leduplikalja a behuzott osztovonalat (akarhany nodebol is alljon)
> es osszefuzi a 2-2 vonalszakaszt ketto szomszedos polygonna.
>
> Hogy hol osszam kette: en azt mondom, hogy barhol, nem kell hozza
> kifogas sem... Elsore nem latom, hogy mit veszt az ember azzal, ha egy
> nagy meretu nevtelen szantofold helyett ket kisebbet rajzol fel.
>
> A valosagban amugy is inkabb a forditjat latom: a muholdkepen egyertelmuen
> latszodo kisebb, valtozatos novenyzetu es valoszinuleg eltero tulajdonosu
> parcellak helyett az egesz fole van egy nagy farmland huzva. Azt nyilvan
> nem gondolom, hogy ezeket az adott esetben pici parcellakat egyesevel kene
> felrajzolni, de azt igen, hogy ilyenek menten kisebb darabokbol jobb lett
> volna, mint mindet osszevonva folyotol folyoig.
>
> <snip>
>
> >Kérdés, hogyan tudsz ebb?l a helyzetb?l úgy kijönni, hogy kétértelm?
> átfedéses
> >poligonok se maradjanak, és a felhasználók is kényelmesen, egyszer?en,
> gyorsan
> >tudjanak szerkeszteni.
>
> Ami nekem legjobban tetszett volna es kezeli ezt a kerdest is:
>
> 0. Itt most az area jelentse a a multipolygont es a tiszta, zart hurku
> wayt, de csak olyan objektumokat, amiket a megjeleniteskor fillezett
> sokszogkent szeretnenk kirajzolni. A tiszta azt jelenti, hogy nincs benne
> onmetszes (tehat egy "masni" topologia az mar kapasbol hiba es nem tudjuk
> mit rajzol).
>
> 1. Rajzolaskor az adott teruleten az egymast nem metszo (de korvonalakban
> akar osztozo) egyszeru areakbol taggelestol fuggetlenul egy terulet
> szerint sorbarendezett lista vagy heap keszul. Az egymast metszoket
> hibanak tekintjuk (az ellenorzo programokban jelezzuk) es azokra a
> renderelesi sorrend nem garantalt.
>
> 2. A rendereles a tag alapu sorrendet kovetve elkezdi csinalni a dolgat,
> barhogy is legyen ez implementalva az adott eszkozben; ha vannak
> renderelesi szintek, akkor egy szinten belul a fillezett teruletek
> rajzolasa meret szerinti sorrendben tortenik; ha nincs szintezes, akkor
> meg ugy altalaban az osszes fillezett objektum meret szerinti sorrebden
> rajzolodik. A nagyobbtol a kisebb fele haladunk.
>
> Az egymassal reszben atfedo eset nem letezik legalisan, mert egymast
> metszo teruleteket nem engedtunk meg. Kozos hatarvonalon a stroke marad
> csak kerdes, de ott lehet egymas melle kettot rajzolni, ehhez csak azt
> kell tudni eldonteni, hogy a vonal melyik oldala esik a polygon belseje
> (ha amugy tud fillezni, akkor ilyene mar van).
>
> Ez a rendszer kompatibilis lett volna a patchworkkel (atfedo elu areak), a
> multypologinokkal (egy area tipusu mutlipoly inner korvonala sem metszhet
> semmilyen masik area korvonalat). Az egyszeri felhasznalo meg siman
> odarajzolhat egy darab erdot a mezo kozepere, mint ha nem lenne holnap, es
> magatol azt fogja csinalni, amire szamit.
>
> Persze tokeletes modszer nincs, ennek is vannak kevesbe erdekes es csunya
> peremei is. Ami elsore eszembe jut:
>
> - valamivel dragabb a rendereles, mert sorba kell rakni dolgokat; de amugy
> is van level= tag; ha szepre akarod renderelni az utakat, akkor ott is
> szmit a sorrend, vagy hogy a stroke ne logjon egymasra; onamagaban a
> multipolyogonokat ossze kell szedni es renderelheto polygonna alakitani;
> ezek eleg bonyodalmas es draga muveletek, foleg ha orszag meretu adaton
> dolgozol; ezekhez kepest a teruletek kiszamolasa es rendezese mar nem
> tunik minosegi kulonbsegnek
>
> - olyat ebben nem lehet rajzolni, hogy egy kisebb area direkt a nagyobb
> ala keruljon (es emiatt egyaltalan ne latszodjon); gondolom letezhet eset,
> mikor direkt ez a cel; ha igen, akkor ezt valami taggelessel lehetett
> volna workaroundolni
>
> - ha van mondjuk egy mezod (way), azon belul egy sziget szeru erdod (way)
> es az egeszen keresztbe akarsz rajzolni egy hosszu folyot (ugy, hogy az is
> egy area a pontos alak miatt) es a mezon is atvag es az erdon is, akkor
> azt a folyot bizony fel kell szabdalnod a mezo es az erdo hataranak
> atlepesekor. Ezt mar csak azert is meg kell tenned, hogy elkeruld az
> egymast metszo areakat. Viszont ebbol az automatikusan kiadodik, hogy
> az erdon vagy a mezon beluli folyoszakasz garantaltan kisebb teruletu
> lesz, mint a mezo vagy az erdo, ezert fole kerul. (Ha nem kene
> felszabdalni, akkor elofordulhatna, hogy egy hosszu folyo osszessegeben
> nagyobb teruletu, mint a pici erdo, amit atszel, ezert az erdo ala
> kerul.)
>
>
> Nyilvan egy ilyen rendszerben is vannak olyan szerkesztesi esetek, amik
> macerasak, peldaul pont ez a folyoszabdalas. Viszont osszessegeben azert
> tetszett volna ez jobban, mert:
>
> - ebben minden nagyon lokalis, csak a szuken vett szomszedsagatol fugg
>
> - az egyszeru, hetkoznapi dolgokat ("itt latok egy erdot, gyorsan
> berajzolom") konnyu megcsinalni, es inkabb az amugy is bonyolultabb,
> ritkabb dolgokat (mindent atszelo folyo) nehezebb
>
> - azt hiszem a kezdo rajzolo, a kis teruletet letolto rajzolo, az ovatlan
> profi rajzolo, a nagy adatmennyiseget felautomata modon atturni
> kenyszerulo rajzolo is kisebb esellyel rontja el a meglevo objektumokat
>
>
> Udv,
>
> Igor2
> --
> Talk-hu levelezőlista
> Talk-hu at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hu
> Leiratkozás a fenti címen vagy <talk-hu-request at openstreetmap.org> címre
> egy levél, témája "unsubscribe", tartalma mindegy.
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.openstreetmap.org/pipermail/talk-hu/attachments/20240301/18b90689/attachment-0001.htm>