[Talk-hu] Landuse polygonok (programozasi kockulas)

[osm2 at igor2.repo.hu]

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