[Talk-hu] Landuse polygonok

[Gergely Matefi]

Szia,

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

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.

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.

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.

Üdv,
Gergő


On Fri, Mar 1, 2024 at 4:45 AM <osm2 at igor2.repo.hu> wrote:

>
>
> On Thu, 29 Feb 2024, Feri Veres wrote:
>
> >> Ezek alapjan valoban az jonne ki, hogy a nagy, lyuggatott landuse
> >> multipoly is jo es a folotte kulonallo, de mas landuse korvonalakat nem
> >> metszo kis landusok is. Ahol pedig nem renderelodik jol, ott a
> renderelot
> >> kell megjavitani (programozokent pontosan ertve a dolog nehezseget).
> >
> >
> > A renderel?t akkor lehet "megjavítani" ha definiálva van a pontos
> megjelenítési
> > módszer. Például adott típusú objektumokat adott másik típusú FÖLÉ kell
> > rajzolni (konkrét típus szerinti felsorolás), adott típusokat méret
> szerint
> > sorba KELL rendezni és a nagyobbakat rajzolni mögé. Definiálva, hogy mik
> azok
> > amiket EGYÜTT kell sorba rendezni.
>
> A masik levelemben megemlitettem ket szabalyrendszert, amivel meg lehetne
> fogni az egymast nem metszo atfedoket. Az egyik tagging alapu, a masik
> geometriai. (Az egymast nem metszes a multipolygon szigeteinel is
> kovetelmeny. Az egymassal el-atfedesben levoket megkulonboztetni az
> egymast atmetszoktol pedig nem veszesen nehez.)
>
> Nem arrol van szo, hogy nem lehet ilyeneket kidolgozni, hanem hogy
> jelenleg nincsen minden megejelnito altal elfogadott konvencio erre.
>
> Ugyanennyire nincs a mulipolygon fole kis terulet nem rajzolasra se minden
> felhasznalo altal elfogadott konvencio. Legalabbis a gyakorlat, az
> itteni levelezes es a "kozponti" angol nyelvu dokumentacio is ezt mutatja.
>
> Tehat szerintem nem erdemes azt mondani, hogy pusztan ez alapjan az egyik
> vagy a masik megoldas lenne jobb.
>
> > Ilyen szabályok híján mindenképpen lesz megjelenít? ami mást csinál mint
> a
> > másik. Csak másolgatják egymást a programok. Aztán meg implementációbeli
> > különbségek miatt mégsem. Vagy a másik úgy csinálta ugyan, de szerintem
> úgy nem
> > jó, ezért máshogy lesz.
>
> Mint ahogy minden felhasznalo is lathatoan maskepp szerkeszt, szoval
> adat/konvencio oldalrol sem egysegesebb semennyivel a helyzet, mint
> megjelenito oldalrol. Raadasul, ha jol ertem, nem minden nepszeru
> szerkesztoben van igazan jo tamogatas a landuse multipolys megkozelitesere
> (pl iD).
>
> Tehat a kerdes, ami szerintem abszolut nem objektiv dontes, hogy melyik
> problemat probalja meg a kozosseg megoldani.
>
> Ebben elter a preferenciank, szerintem az altalad is kedvelt
> multipolygonos megoldas felseleges komplexitast visz az adatokba, es ha
> rajtam mult volna, egesz mas iranyba indultam volna el a problema
> megoldasaval.
>
> Viszont nem kardoskodom az altalam preferalt megoldas mellett.
> Elfogadom, hogy itthon a tobbsegi dontes a lyukas multipoly landuse. Azt
> viszont nem fogadom el, hogy ez azert lenne, mert ez objektivan jobb, vagy
> altalaban konnyebben szerkesztheto.
>
> > Ennél egyszer?bb, ha nincs átfedés az alapvet? nagy területek (landuse,
> > landcover, natural, stb) dolgok közt.
>
> Vagy epp az egyszerubb, ha nincsenek hatalmas szantofold multipolygonok
> amikbol a kisebb erdok vannak kivagva, hanem egy szinten, patchwork
> szeruen illeszekedo areak vannak, es multipolygon csak ott, ahol valoban
> technikaiag indokolt (pl egyszeru areakent nem leirhato nevesitett
> objektum). Ez szinten atfedes-mentes. De nekem egy jol definialt nem
> metszo de atfedeses rendszer is jelentosen egyszerubbnek tunik, mint ez a
> multipoly lyuggatas. Izles kerdese.
>
> En elfogadom, hogy az itthoni kozosseg a multipolyt szereti, de azzal nem
> ertek egyet, hogy ezt valami objektivan jobb megoldaskent allitsuk be, ne
> pedig egy onkenyes valasztaskent.
>
> 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.
>
> <snip>
>
> >> Viszont ekozben az latszik, hogy van ezt feluliro hazai
> >> gyakorlat/dokumentacio/ajanlas, ami inkabb a lyuggatott
> multipolygonokkal
> >> lefedest preferalja.
> >
> > Szerintem a gyakorlat is azt mutatta, hogy ez így jól szerkeszthet?,
> egyértelm?
> > a megjelenítése, sok érv szólt mellette. Ha nem fut az ember folyton
> elrontott
> > (vagy másik típusú) elemekbe, akkor öröm vele dolgozni.
>
> Ezzel nem ertek egyet. Neked orom vele dolgozni, masoknak meg szivas. Es
> ez forditva is igaz. A gyakorlat (az adatbazis) azt mutatja, hogy adat
> boseggel akad mindkettobol, mindket tabornak sok kepviseloje van.
>
> Valoszinuleg mindketto megoldasbol talalunk olyan peldat is, ahol meg az
> adott modszer kedveloi szerint is rosszul sikerult a konkret objektum.
>
> > És lehet, hogy te sokkal jobbat implementálsz, ha eleve így indulsz el
> vele. A
> > JOSM-ban olyan megoldást használunk, amit ERRE kevesek, így nincs is erre
> > kiélezve.
>
> Nem fogom toolzasba vinni (pun intended).
>
> 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.
>
> A szerkesztoprogramomba a relationok kezeleset mostanaban implementalom,
> ezert is orulok ennek a threadnek, sokat segitett abban, hogy
> jobban megertsem a tenyleges szerkesztesi gyakorlatot.
>
> Kelleni fog par specializaltabb dolog a turn restrictionokre meg a
> tomegkozlekedesi kapcsolatokra. Megjelenites szintjen multipolykat is kell
> tudnom kezelni. Plusz lyukas epuletet en is multipolykent akarok
> felvinni (de nem lyukasra szerintem overkill - sajnos sokfele latok
> ilyet is).
>
> Viszont mivel felhasznalokent nem tervezek landuseokat szerekszteni, ezert
> azon a vonalon eleg a minimumot megcsinalnom. Ami kb annyi, hogy
> type:id:role listakent tudja prezentalni a relationt, plusz kulon
> megrajzolt elem berakasa/kivetele.
>
> 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/bee17763/attachment-0001.htm>