[Talk-hu] Landuse polygonok

[osm2 at igor2.repo.hu]

On Fri, 1 Mar 2024, Feri Veres wrote:

>> Tehat szerintem nem erdemes azt mondani, hogy pusztan ez alapjan az egyik
>> vagy a masik megoldas lenne jobb.
>
> Rajzolni kell és kiderül.
>
> Sokan nem szóltak most hozzá, akik egyébként maximálisan ezt a módszert
> támogatják, azért mert használják és szeretik.

Ahogy vegig mondtam: elfogadom, hogy itthon a tobbsegi velemeny a 
multipolygont tamogatja. Azt nem fogadom el, hogy ez azert lenne, mert ez 
az objektiven a jobb megoldas. Ez a sok hasonloan jo/rossz megoldas kozul 
az egyik, amit a kozosseg kivalasztott. Mashol meg mast valasztottak.

Nem probalok meg senkit meggyozni arrol, hogy egy masik modszer objektive 
jobb, nem probalom meg megtamadni vagy atalakitani a kialakult hazai 
gyakorlatot. Valojaban az egyetlen dolog, amirol megprobaltalak meggyozni 
az az, hogy ez a dontes nem objektiven jobb rendszert eredmenyez, pusztan 
egy onkenyes dontes tobb hasonloan jo/rossz modszer kozott.

> ?szintén szólva, GYAKORLATI megfontolásból én a "patchworkös" (és pl a másik
> leveledben szántóföld szétvágós) módszered esetén is a multipoligonokat
> részesíteném el?nyben, a fentebb leírt egyszer?sége miatt.

Szamodra ez egyszerubb, mert eleve ezt a modszert kedveled. Masok szamara 
meg mas egyszerubb, mert ok azt a modszert kedvelik. Ezzel nincs semmi 
problema, de azert erdemes latni, hogy ezek nem valami nagy globalis 
objektiv igazsagok, csak szemelyes, sokszor toolhoz kotott preferenciak. 

(En is pont GYAKORLATI szempontbol nem kedvelem a multipolys rendszert. 
Csak kettonknek mast jelent a gyakorlat. Pedig regen en is JOSM-ot 
hasznaltam - es mar akkor is rondanak talaltam a multipolygon bizonyos 
felhasznalasait.)

>
>> Raadasul az angol nyelvu "kozpontibb" dokumentacioban sehol nem talaltam
>> nyomat ennek es felmerult nemet/osztrak ellenpelda is. Ez alapjan azt
>> sem latom, hogy ez ugy altalaban a vilagban elfogadottan A Jo Megoldas
>> lenne.
>
> Mindenben igazad van (nincs de-facto jobb vagy rosszabb stb), de próbáld meg
> rajzolni mindkett?t JOSM-ban. :)

Itt a kulcs: JOSM.

"Nem a renderelonek terkepezunk". De a szerkesztoprogramnak igen?

Nekem ugy tunik, hogy egy fontos erv vegig az, hogy JOSM-al mit egyszeru, 
kenyelmes vagy gyors rajzolni. Tehat reszben bizonyos szerkesztoprogram 
UI-janak tervezzuk a szerkesztesi szabalyrendszert.

Szamomra ez idegen megkozelites, en inkabb abbol indulok ki, hogy az 
adatbazis es annak megertese, tool-fuggetlen szerkesztese/feldolgozasa 
szempontjabol mi tunik jonak, aztan majd ahhoz kell idomitani a 
szerkesztoprogramokat es a megjelenitoket. 

(A felreertes elkerulese vegett: nem javaslom, hogy barmilyen dontest vagy 
konvenciot alakitsunk at es mindem szoftvert irjunk at, pusztan azt 
allitom, hogy ha eppenseggel egy masik modszer terjedt volna el, akkor 
arra lettek volna optimalizalva bizonyos szerksztok/renderelok, de attol 
meg azok mellett se lett volna jo erv az, hogy egy adott program epp ezt 
tudja jol csinalni.)

> Mondjuk 3-3 órát. (Nem viccelek. Csak sajnálom, hogy a JOSM eleve nem jön képbe
> és emiatt szinte kizárt, hogy megpróbálod. :-( )

Szamomra ez nem UI kerdes. Raadasul ezt ugy tudom mondani, hogy nekem 
sokkal nagyobb a szabadsagom ebben: mivel sajat szerkesztoprogramom van, 
egeszen konkretan azt irok bele, amit akarok. Ha a multipolys landuse 
megkozelites tetszene, es ilyesmit akarnek szerkeszteni, akkor irnek bele 
egy koteg olyan specializalt UI kodot, ami azt teszi hatekonnya.

Az en problemaim: a lokalitas vs. globalitas kerdese es a komplexitas 
elosztasa az gyakori/egyszeru es ritka/egzotikus esetek, a kezdo es a 
profi szereksztok kozott. Valoszinuleg ezeket nem sikerult jol 
megfogalmaznom.

>
>> Nekem alapvetoen nem tetszik ez a landuse multipoly lyuggato rendszer. Ez
>> szerintem egy amugy legitim adatszerkezet abuzalasa. Ez szamomra nem
>> felhasznaloi felulet/tooling kerdese, hanem az adatbazis szerkezetenek
>> kerdese. Ezert az a legvaloszinubb, hogy egyszeruen nem fogok landuseokat
>> szerkeszteni, meghagyom masnak. Majd rakok fel note-okat, ahol szerintem a
>> landuse=residential nem fedi peldaul az epuleteket.
>
> Adatbázis szerkezeti szempontból ezek vonalak, amik EGYSZER vannak berajzolva
> és KÉTSZER felhasználva. Meglep, hogy egy szoftverfejleszt?nek nem ez a
> kézenfekv? megoldás.

Az _egyik_ kezenfekvo megoldas. A hatranya az, hogy elveszted a 
lokalitast: barmelyik vonal lehet 7 multipolygon vagy relation resze. A 
kezdo szerkeszto gyanutlanul arrebb rak, elvag, kitorol valamit. Lat 2 
objektumot, ami erintett, azokkat megerti, azokkal foglalkozik. Aztan 
kiderul, hogy van meg 5 masik, amit nem vett eszre.

Lehetseges okos UI-t irni, ami erre is figyel? Abszolut. Erdemes? Izles 
kerdese: szerintem nem, szerintem jobb eleve ugy tervezni dolgokat, hogy 
egy lokalis szerkeszteshez csak lokalisan kell korulnezni es ha elrontom, 
akkor maximum lokalis hibat okoz. Cserebe tobb, neha reszben redundans 
adat keletkezik.

Ez a jobb? Izles kerdese. En peldaul inkabb irntam volna arra UI-t, hogy 
ne kelljen kezzel berajzolni az atfedo vonalszakaszokat, es inkabb 
megbekelnek azzal, hogy ugyanaz a sok nodeos vonalszakasz 7 alkalommal is 
le van irva 7 kulon way-ben.

(UI-t valoszunuleg egyforman jot lehetne irni barmelyik modszerre.)

Megjegyzem: az altalam leginkabb kedvelt megoldas, az egymas fole 
rajzolas, kevesbe szenved ettol az atfedo vonalas dologtol, mert ott csak 
a legkulso, legnagyobb landuse areak (a fak gyokerei) akarnak 
egymassal erintkezni.


A masik nagy hatrany az, hogy igy a komplexitast ugy osztjuk el, hogy az 
egyszeru/gyakori eset (pici erdofolt a mezon, amit lathatoan eleg sokan 
"elrontanak") is es a bonyolult/ritka eset (mindenkeppen egyertlemuen es 
hezagmentesem akarom lefedni az orszagot) is nagyjabol egyforman, 
kozepesen komplikalt. Az en szubjektiv izlesem az, hogy szeretem ugy 
elosztani a komplexitast, hogy az egyszeru/gyakori eset legyen nagyon 
konnyu, akkor is, ha ettol a bonyolult/ritka eset nehezebbe valik.

> Adat szempontból meg fele annyi vonal. Szerkesztési szempontból meg fele annyi
> vonal meghúzását igényli. Nem tudok több érvet. ;-)

Azzal a kiegeszitessel, hogy a mai napon, a te kedvenc 
szerkesztoprogramodban. En ezt a problemat soha nem azon a szemuvegen at 
neztem, hogy epp a JOSM-ban epp ma mi kenyelmes es mi nem, ma epp mire van 
plugined benne es mire nincs. (Gombhoz kabat?)

Adat darabszam: igen, az adatok kereszthivatkozasaval nagyon sokat lehet 
sporolni darabszamban. Az megint (szubjektiv) dontes kerdese, hogy inkabb 
a lokalis, sokszor duplikalt, de egymastol kevesbe fuggo adatokat 
szeretjuk-e, vagy inkabb egy globalis, minden-mindennel-osszefuggo, 
kereszthivatkozo halozatot. Raadasul nem fekete-feher: tomegkozlekedesi 
halozatok vagy turn restrictionok eseten en sem latom akkora problemanak 
az osszelinkelest (pedig ott is serti a lokalitast).

Ha egy pillanatra leveszed errol a JOSM-ot, es csak ugy altalaban azt 
nezed meg, hogy mennyi ido megerteni, konkret, darabra lebontott 
objektumokat atlatni "papiron", akkor az en szemelyes, szubjektiv 
velemenyem az, hogy landuse eseten a lokalitas jobb, mint a globalis 
megkozelites. Cserebe a tarolando adatmennyiseg valoban nagyobb 
(megintcsak szubjektiv dontes kerdese, hogy ez-e a fontos; ha az, akkor 
tag key-eket miert visszuk fel egyesevel es redundansan stringkent?). 

De nem akarlak (soha nem akartalak) meggyozni ezekrol. Az egyetlen dolog, 
amirol gyozkodtelek az az, hogy a preferenciad pontosan annyira 
szubjektiv, mint az enyem, es az, hogy itthon melyik valasztodott ki 
szinten egy szubjektiv dontesnek tunik. Tehat ha barmin valtoztahatnek, az 
csak a megfogalmazas lenne: az olyasmik, mint "ez a kenyemlesebb", "ez az 
egyszerubb" szerintem felrevezetoek, a valosag inkabb: "ez az elfogadott", 
"ezt valasztottuk".


> Ja de, hogy rendelelési szempontból meg nincs vele semmi feldolgozási tennivaló.

Van tennivalo: ossze kell szedni a multipolygon relation reszeit es fel 
kell beloluk epiteni a polygont. (Sajnos) ismerek nehany polygon 
abrazolasi/renderelesi modellt, de ezek kozul epp egyik sem olyan, aminek 
1:1 oda lehetne adni egy kupac random vonalszakaszt azzal, hogy inner meg 
outer, aztan majd abbol osszerakja. Amikkel eddig talalkoztam azok 
legtobbszor ket fele megkozelites kozul valsztottak: vagy felharomszogelt 
bemenetet varnak (2d, vagy 3d feluletmodell), vagy tiszta, zart polyline 
hurkokat (2d). OSM multipolygonrol mindketto konvertalast jelent. A lyukak 
nem jelentenek kulonosebb problemat egyik esetben sem (trivialis 
fuggoleges vonalakkal lyukankent felszabdalni egy lyukas polygont ha a 
renderelo csak lyukmenteset tamogat)

Nem amellett ervelek, hogy ez jo vagy rossz. Ennel tavolabbrol nezve 
ervelek: ez az aspektus nem szamit. Szerintem ebbol a szemptontbol ket 
modon tervezheted meg az adatbazist:

1. ugy, hogy egy konkret renderelonek azonnal, atalakitas nelkul jo 
legyen; de akkor az osszes tobbi, ettol eltero renderelon nem segitettel, 
plusz az adatbazist es a szerkesztest egy renderelesi implementacios 
reszletnek vetettel ala;

2. ugy, hogy nem erdekelnek a renderlok, mert ugyis sokfelek es 
megcsinaljak a sajat elofeldolgozasukat. Megtervezed mas 
szempontbol, aztan minden renderelo konvertalja, ahogy neki jo. 

En a masodik megkozelitest szeretem, ezert az en preferenciamban elenyeszo 
sullyal szerepel az, hogy mire konnyu renderelot irni (szinte biztosan 
ugyis at kell alakitani, barhogy is kaptad az adatot). Szinten kis sullyal 
szamit, hogy ebben a pillanatban eppen mire van kihegyezve a JOSM vagy 
barmelyik masik szerkeszto: ezeket konnyebb atalakitani, pluginezni, mint 
egy szereksztesi konvenciot megvaltoztatni. Raadasul ha eleve maskepp lett 
volna kitalalva az ajanlas, akkor valoszinuleg arra lett volna 
"megkenyelmesitve" a JOSM (vagy a barmi).


Javaslat: azt hiszem ezt a hosszu, valoszinleg keveseket erdeklo temat 
lezarhatnank: 

- a megoldas mar reg megszuletett (nem en fogok landuseokat szerkeszteni)

- nagyon sokat tanultam es ertettem meg a dolog kulonbozo aspektusairol 
(koszonom!)

Barmelyik modszer programozasi reszleteirol, pusztan a kockulas urugyen is 
nagyon szivesen gondolkozom es beszelgetek, de azt inkabb off-list kene.

Udv,

Igor2