<div dir="ltr"><div>Szia,</div><div><br></div><div>a patchwork módszertan problémái akkor ütköznek ki jól, ha egy létező nagyobb poligon közepére akar valaki újonnan egy kisebb poligont felrajzolni. Például egy nagy szántó közepére egy tanyát.</div><div>Patchwork módszer mellett ilyenkor először ketté kellene vágni a szántót, hogy a két részpoligon két oldalról ölelje körbe a tanyát. Jellemzően ehhez célszerű keresni valami természetes határvonalat, például a bekötő utat, aminek a mentén a két részpoligont illeszteni kell. Majd a tanya poligont felrajzolni, pontosan illesztve a két részpoligonhoz. Elég pepecselős és időgényes játék.</div><div><br></div><div>A szerkesztők jó része ezért nem foglalkozik ezzel, egyszerűen csak berajzolja a tanya poligont a szántó poligon tetejébe. Mivel ezzel átfedő poligonok jönnek létre, ezzel sérül a patchwork módszertan. Ha aztán valakit ez zavar, és javítani akarja, akkor meg előveszi a multipolygonos módszertant: multipolygonná alakítja a szántót, és inner tagként felveszi a tanyát. JOSM-mel ez kb. 1 perces munka, sokkal gyorsabb, mint átfedésmentes patchworköt kellene helyre állítani poligonok darabolásával.</div><div><br></div><div>Az, hogy ezek az átfedő poligonok létrejönnek, valószínűleg annak a következménye, hogy egy átlag felhasználónak sem a patchworkös, sem a multipolygons módszertan sem kényelmes. Ráadásul a tooling egyik módszertant sem kényszeríti ki, megengedi az átfedéses poligonokat. A patchwork vs multipolygon vita sok-sok éves sztori, pár évente fellángol. Nyilván azért nem tudott egyik módszertan sem győzni, mert mindegyiknek meg vannak a saját hátulütői is.</div><div><br></div><div>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.</div><div><br></div><div>Üdv,</div><div>Gergő</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 1, 2024 at 4:45 AM <<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"><br>
<br>
On Thu, 29 Feb 2024, Feri Veres wrote:<br>
<br>
>> Ezek alapjan valoban az jonne ki, hogy a nagy, lyuggatott landuse<br>
>> multipoly is jo es a folotte kulonallo, de mas landuse korvonalakat nem<br>
>> metszo kis landusok is. Ahol pedig nem renderelodik jol, ott a renderelot<br>
>> kell megjavitani (programozokent pontosan ertve a dolog nehezseget).<br>
><br>
><br>
> A renderel?t akkor lehet "megjavítani" ha definiálva van a pontos megjelenítési<br>
> módszer. Például adott típusú objektumokat adott másik típusú FÖLÉ kell<br>
> rajzolni (konkrét típus szerinti felsorolás), adott típusokat méret szerint<br>
> sorba KELL rendezni és a nagyobbakat rajzolni mögé. Definiálva, hogy mik azok<br>
> amiket EGYÜTT kell sorba rendezni.<br>
<br>
A masik levelemben megemlitettem ket szabalyrendszert, amivel meg lehetne <br>
fogni az egymast nem metszo atfedoket. Az egyik tagging alapu, a masik <br>
geometriai. (Az egymast nem metszes a multipolygon szigeteinel is <br>
kovetelmeny. Az egymassal el-atfedesben levoket megkulonboztetni az <br>
egymast atmetszoktol pedig nem veszesen nehez.)<br>
<br>
Nem arrol van szo, hogy nem lehet ilyeneket kidolgozni, hanem hogy <br>
jelenleg nincsen minden megejelnito altal elfogadott konvencio erre.<br>
<br>
Ugyanennyire nincs a mulipolygon fole kis terulet nem rajzolasra se minden <br>
felhasznalo altal elfogadott konvencio. Legalabbis a gyakorlat, az <br>
itteni levelezes es a "kozponti" angol nyelvu dokumentacio is ezt mutatja.<br>
<br>
Tehat szerintem nem erdemes azt mondani, hogy pusztan ez alapjan az egyik <br>
vagy a masik megoldas lenne jobb.<br>
<br>
> Ilyen szabályok híján mindenképpen lesz megjelenít? ami mást csinál mint a<br>
> másik. Csak másolgatják egymást a programok. Aztán meg implementációbeli<br>
> különbségek miatt mégsem. Vagy a másik úgy csinálta ugyan, de szerintem úgy nem<br>
> jó, ezért máshogy lesz.<br>
<br>
Mint ahogy minden felhasznalo is lathatoan maskepp szerkeszt, szoval <br>
adat/konvencio oldalrol sem egysegesebb semennyivel a helyzet, mint <br>
megjelenito oldalrol. Raadasul, ha jol ertem, nem minden nepszeru <br>
szerkesztoben van igazan jo tamogatas a landuse multipolys megkozelitesere <br>
(pl iD).<br>
<br>
Tehat a kerdes, ami szerintem abszolut nem objektiv dontes, hogy melyik <br>
problemat probalja meg a kozosseg megoldani.<br>
<br>
Ebben elter a preferenciank, szerintem az altalad is kedvelt <br>
multipolygonos megoldas felseleges komplexitast visz az adatokba, es ha <br>
rajtam mult volna, egesz mas iranyba indultam volna el a problema <br>
megoldasaval.<br>
<br>
Viszont nem kardoskodom az altalam preferalt megoldas mellett. <br>
Elfogadom, hogy itthon a tobbsegi dontes a lyukas multipoly landuse. Azt <br>
viszont nem fogadom el, hogy ez azert lenne, mert ez objektivan jobb, vagy <br>
altalaban konnyebben szerkesztheto. <br>
<br>
> Ennél egyszer?bb, ha nincs átfedés az alapvet? nagy területek (landuse,<br>
> landcover, natural, stb) dolgok közt.<br>
<br>
Vagy epp az egyszerubb, ha nincsenek hatalmas szantofold multipolygonok <br>
amikbol a kisebb erdok vannak kivagva, hanem egy szinten, patchwork <br>
szeruen illeszekedo areak vannak, es multipolygon csak ott, ahol valoban <br>
technikaiag indokolt (pl egyszeru areakent nem leirhato nevesitett <br>
objektum). Ez szinten atfedes-mentes. De nekem egy jol definialt nem <br>
metszo de atfedeses rendszer is jelentosen egyszerubbnek tunik, mint ez a <br>
multipoly lyuggatas. Izles kerdese.<br>
<br>
En elfogadom, hogy az itthoni kozosseg a multipolyt szereti, de azzal nem <br>
ertek egyet, hogy ezt valami objektivan jobb megoldaskent allitsuk be, ne <br>
pedig egy onkenyes valasztaskent. <br>
<br>
Raadasul az angol nyelvu "kozpontibb" dokumentacioban sehol nem talaltam <br>
nyomat ennek es felmerult nemet/osztrak ellenpelda is. Ez alapjan azt <br>
sem latom, hogy ez ugy altalaban a vilagban elfogadottan A Jo Megoldas <br>
lenne.<br>
<br>
<snip><br>
<br>
>> Viszont ekozben az latszik, hogy van ezt feluliro hazai<br>
>> gyakorlat/dokumentacio/ajanlas, ami inkabb a lyuggatott multipolygonokkal<br>
>> lefedest preferalja.<br>
><br>
> Szerintem a gyakorlat is azt mutatta, hogy ez így jól szerkeszthet?, egyértelm?<br>
> a megjelenítése, sok érv szólt mellette. Ha nem fut az ember folyton elrontott<br>
> (vagy másik típusú) elemekbe, akkor öröm vele dolgozni.<br>
<br>
Ezzel nem ertek egyet. Neked orom vele dolgozni, masoknak meg szivas. Es <br>
ez forditva is igaz. A gyakorlat (az adatbazis) azt mutatja, hogy adat <br>
boseggel akad mindkettobol, mindket tabornak sok kepviseloje van.<br>
<br>
Valoszinuleg mindketto megoldasbol talalunk olyan peldat is, ahol meg az <br>
adott modszer kedveloi szerint is rosszul sikerult a konkret objektum.<br>
<br>
> És lehet, hogy te sokkal jobbat implementálsz, ha eleve így indulsz el vele. A<br>
> JOSM-ban olyan megoldást használunk, amit ERRE kevesek, így nincs is erre<br>
> kiélezve.<br>
<br>
Nem fogom toolzasba vinni (pun intended).<br>
<br>
Nekem alapvetoen nem tetszik ez a landuse multipoly lyuggato rendszer. Ez <br>
szerintem egy amugy legitim adatszerkezet abuzalasa. Ez szamomra nem <br>
felhasznaloi felulet/tooling kerdese, hanem az adatbazis szerkezetenek <br>
kerdese. Ezert az a legvaloszinubb, hogy egyszeruen nem fogok landuseokat <br>
szerkeszteni, meghagyom masnak. Majd rakok fel note-okat, ahol szerintem a <br>
landuse=residential nem fedi peldaul az epuleteket.<br>
<br>
A szerkesztoprogramomba a relationok kezeleset mostanaban implementalom, <br>
ezert is orulok ennek a threadnek, sokat segitett abban, hogy <br>
jobban megertsem a tenyleges szerkesztesi gyakorlatot. <br>
<br>
Kelleni fog par specializaltabb dolog a turn restrictionokre meg a <br>
tomegkozlekedesi kapcsolatokra. Megjelenites szintjen multipolykat is kell <br>
tudnom kezelni. Plusz lyukas epuletet en is multipolykent akarok <br>
felvinni (de nem lyukasra szerintem overkill - sajnos sokfele latok <br>
ilyet is).<br>
<br>
Viszont mivel felhasznalokent nem tervezek landuseokat szerekszteni, ezert <br>
azon a vonalon eleg a minimumot megcsinalnom. Ami kb annyi, hogy <br>
type:id:role listakent tudja prezentalni a relationt, plusz kulon <br>
megrajzolt elem berakasa/kivetele.<br>
<br>
Udv,<br>
<br>
Igor2-- <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>