[Talk-hu] Landuse polygonok

Feri Veres lion at cmsbazar.hu
2024. Már. 1., P, 20:23:30 UTC


Nincs ilyen szerkesztési videónk, többiek?

( https://wiki.openstreetmap.org/wiki/Hungary/videok )

Bemutatok egy példát. A dolog gyakorlatias oldalán maradva.

https://c64.rulez.org/~lion/osm/landuse1.jpg

Ha ez eleve multipoligonos rajz szerinti lenne (nem az), akkor tegyük 
fel, hogy folytatni szeretném a területet.A következő lépéseket teszem:

1. Behúzom az 1-es vonalat (2-3 pont)
2. A kék vonalat a két kapcsolódásánál elvágom ('p' gomb)
3. Kijelölöm a kék ívet és az 1-es vonalat
4. "Multipoligon létrehozása" (Ctrl-B), és címkézem (F3)

Aztán:

1. Behúzom a 2-3 számokkal jelölt vonalat.
2. Az elején meg a végén ahol beköt, ott "p" betűvel elvágom a zöld 
illetve kék vonalakat
3. Kijelölöm az 5 vonalat ami így körbeveszi (1-es vonal, kék vonal, 2-3 
vonal, zöld vonal, kék alsó ív)
4. "multipoligon létrehozása" (Ctrl-B) és címkézem

(Pontatlan a példa de a lényeget értjük.) (Kb 10 kattintás...)

Ha "patchwork" szerint szeretném, akkor pedig a vonalkövetéssel(???) 
szórakozva, vagy néhány pontot véletlenül kihagyva, több tucatnyi 
kattintgatással lekövetve az ELEVE MÁR MÁSOK ÁLTAL MEGRAJZOLT - tehát 
engem totál nem érdeklő geometriájú - vonalakat.

Alaposan ügyelve arra, hogy ne hagyjak ki pontokat - hozzáteszem, ki 
szokták hagyni: így születnek a kisebb törések mentén a hajszálvékony 
átfedések vagy hajszálvékony üres területek!

Ha esetleg még egy ÚTON is fut, akkor már van 3 vonalad egymás felett, 
nem öröm a szerkesztésük! (Bár én ellene vagyok az útra rárajzolásnak, a 
Wikibe is mellé javasoltam rajzolni.)

Szerencsére a nem multipoligonnal felvitt elemek multipoligonná 
alakítását is egész jól kezeli a JOSM, így általában a terület 
"upgradelésekor" inkább pont az ilyen összekötési hibák okoznak 
fejfájást. Ha tökéletes "patchwork" lenne, pikk pakk menne, így meg 
válogatja az ember, hogy melyik vonalak a "jobbak" a majdnem egymáson 
futókból... (Meg én az útról is leszedem, hisz a lakott terület például 
nem az út tégelyéig tart. Szóval gyakran szívás az átalakítás.)

2024. 03. 01. 4:42 keltezéssel, osm2 at igor2.repo.hu írta:
> 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.

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.


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

Adatfeldolgozót még nem írtam, de ha olyan API-val dolgozol, ami tud 
lyukas poligonokat renderelni, akkor semmi más követelmény nincs.

Minden "multipoligon" egy, a saját darab-vonalaiból álló zárt vonal. (A 
nyomtató programomban nemrég javítgattam az ezt feldolgozó rutint, 0 
Python tudással Pythonban. :) )

https://sourceforge.net/p/render-mymap/code/ci/7d0abef1714c7db9f16be8a49a01dabd87951087/




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

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


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

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. :-( )


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

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. ;-)  Ja de, hogy 
rendelelési szempontból meg nincs vele semmi feldolgozási tennivaló.

Üdv,
Feri



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