[Talk-hu] Landuse polygonok

osm2 at igor2.repo.hu osm2 at igor2.repo.hu
2024. Már. 1., P, 03:42:36 UTC



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


További információk a(z) Talk-hu levelezőlistáról