[osm-hu] CLC próbák - kérdések

[Ferenc Veres]

2012.07.29. 1:35 keltezéssel, László Csatlós írta:
>     - ideiglenesen-bekötés végett pedig SEMMIKÉPPEN ne az admin-boundary-t
>     bántsuk, hanem szintén 1-2 huszárvágásos vonallal zárjuk a területet. E
>     különösen azért is fontos lenne, hogy a besegítőknek ne kelljen 1-1 mező
>     vagy erdő miatt az admin boundary kapcsolatokkal semmit csinálnia.
> 
> Aláírom, nem szép dolog, igazából csak esztétikai okokból történt eddig,
> ezáltal is szembetűnőbb volt, melyik település van kész és melyik nincs,
> azonban tényleges indok nem szól mellette (sőt, tényleg csak ellene),
> hogy boundaryba kössük.

OK.

Remélhetőleg akkor is észrevesszük, hogy meddig van kész, ha az
ideiglenes elvágásokat inkább csak arrafelé rajzoljuk, nem oda.

Egyébként tényleg nagyon nehéz a vizualizálása ennek az adathalmaznak.
Nem lehet a CLC-t valahogy "megnézni"? Szerkesztés közben sokszor jól
jönne, hogy "most akkor ez mi is" illetve "most akkor ez tényleg lyukas
itt" meg ilyesmik megerősítésére egy olyan ábra, amin egyszerűen a
CLC-vel van kitöltve minden. Nem tudom, hogy esetleg nem konvertáéható-e
olyan formára, hogy az openstreetmap.hu-n egy réteg legyen. Bár asszem
tud az OSM fájlokat betölteni, de még nem próbáltam. Meg akkor valami
köztes darabolás is kellene, de csak akkor, ha ezt tényleg
megjeleníthető lenne így.


>     - zárjuk?
>     - ne zárjuk?
> 
> 
> Szerintem ennek a JOSM warningolásán kívül (nem zárt multipolygon) nem
> tudom, van-e jelentősége, extrém esetekben lehetnek érdekes áthúzások a
> lezáratlan végek között, ami renderelési hibát okozhat, ezt talán ki
> kéne próbálni. Zsolt ezért is javasolta azt, hogy így viszonylag kis
> léptékkel haladva, településenként dolgozzuk fel, így nem kell hetekig
> ülni rajta, egy-egy település pedig maradéktalanul feldolgozható egy
> alkalommal és így nincs probléma a lezáratlan élekkel.
> Ha mégis nagyon sürgősen abba kéne hagyni és feltölteni, akkor pedig a
> korábbi "huszárvágást" itt is lehetne akkor ideiglenesen alkalmazni.

Ok, nem a nagyon sürgősekre gondoltam, hanem amikor pl otthagytam 2
napja és azóta csak kérdezgetek róla. Akkor ezt úgy fogjuk dokumentálni,
hogy illik lezárni.

>     - egyelemű multipolygon?
>     - vagy tegek átmásolása a vonalra és kapcsolat törlése?
> 
> Az eredeti fájlban minden vonalon ott van a tag, relációk csak
> inner/outer esetekben vannak. Az átalakítás során a vonalakról leszedem
> a tag-eket és relációkat szervezek belőlük. Ha ez így nem jó,
> módosíthatom úgy, hogy azok a relációk, amik egy tagúra jönnek ki,
> visszategye a tag-et a vonalra. Kérdés, hogy ez mekkora szerverterhelést
> jelent?

Mármint kinek milyen szervernek? Ez inkább felhasználói szerkesztési
kérdés szerintem. Egyelemű multipolygon előnye, hogy egyféle munkát kell
végezni, hátránya, hogy azoknál amik egyszerűek lennének, ott is a
bonyolultat kell csinálni.

Akkor én arra szavazok, hogy ha meg tudod oldani, akkor egy outer
poligon esetén legyen a vonal teggelve, de várjuk meg a többiek véleményét.

Indoklásom: a multipolygon relation több vonalból álló dolgokhoz való,
így ez "misuse"-nak tűnik.


>     3. Ismeretlen területek (CLC ID="none?")
> 
> Szemfüles voltál, előbb kiszúrtad ezeket, minthogy javíthattam volna
> őket. :)
> Ezek a vonalak a v0.1.7-be kerültek be, ezek eredetileg is tag nélküliek
> és az eredeti fájlban a relációk inner tagjait jelképezik.
> v0.1.8-ba hamarosan küldöm majd a megoldást, hogy ezek is a relációk
> szerves részét képezhessék.

Köszi, visszakeresem és pótolom a CLC ID-ket az új fájljaid alapján
hamarosan!

>     4. Régi landuse=residential vonal
> 
> Ezt ugye írtam már, ezek az adatok a pontosságuk és frissességük miatt
> sem tekinthetők szentírásnak, ezért is írták a wikire a többiek, hogy
> összedolgozás a meglévő adatokkal, mert tényleg előfordulhat, hogy a már
> berajzolt, jobb adatminőséget jelent. Ilyenkor minden szívfájdalom
> nélkül lehet törölni szerintem az érintett CLC részt és megtartani a már
> meglévőt (ha tényleg jobb minőséget jelent).

Igen, ezt Tamás is írta, akkor majd kiemeljük jobban a leírásban is, meg
mindenki figyeljen rá és konzultáljon a szerkesztővel. Én konkrétan és
mint írtam, a falul egyik oldalán a korábbit, a másik oldalán a CLC-t
tartottam meg (ez utóbbi úgy jött össze, hogy a CLC a telek végi
kerteket kerteknek (orchard) ábrázolta, én meg azt is bekerítettem
lakottnak, így a "részletgazdagabbat" kellett megtartani, látszott is a
BING-en, hogy azok a már itt korábban egyszer említett hosszú-telkek.)

Egyébként itt is igaz volt, hogy a Bingen pontosabban volt mint a
CLC-ben, tehát erősítsetek meg abban, hogy ezeket igenis kiigazítjuk,
akkor is, ha a Bing eltolás mértékére nincs referencia arrafelé.

Pl volt olyan erdőm, ami egy út 2 oldalán ugrált ide-oda, valójában meg
párhuzamosítani kellett az úttal az egyik oldalon! Ezeket fontos javítani.

> Amúgy nem világos pontosan, mire gondolsz az alatt, hogy megtartja a
> history-t vagy nem? Elvileg a törölt objektumokat is vissza lehet
> bányászni, vagy nem erre gondolsz? Ez nem teljesen tiszta.

Pedig ez lett volna a kérdés fontosabb része, hogy ha megnézed egy vonal
"Show history"-ját, akkor ott látszik, hogy eddig ki és miért
rajzolgatta, mozgatta, alakította, stb.  (Nem a törölt, hanem a meglévő
objektumokon, mert azokon egy kattintás.)

Ha viszont a CLC-ben importált vonalnak megvan az a nagy előnye, hogy
RELATION SZERKEZETI szempontból már eleve jó, akkor csábító azt
használni és a pontjait a régi határvonalra húzogatni (pontok
mergelésével). Így sima egér húzogatás az egész munka. A végén a régi
határvonalat törölni.

Ellenben, ha az a célom, hogy a vonalra kattintva "Show history"-val
látszódjon, hogy azt a vonalat valójában X-Y rajzolta 3 éve, és én most
csak a CLC alapján pontosítottam, akkor ezt nem tehetem, mert törlöm az
ő vonalát. Csak azt tehetem, hogy a régi vonalat az igényelt sarkokon
feldarabolom és a relation-ben KICSERÉLEM a 0-ID-s ÚJ importált vonalat
a régire.

A dolog szépséghibája, hogy daraboláskor az elvágott vonalból az egyik
újként fog megjelenni így is, tehát ha egy falu mostani körvonalát
mondjuk 5 darabra kell vágnom, és a kapcsolatokban a tagokat
lecserélgetnem, akkor összesen ebből egy olyan vonal lesz, ami nem 0-ás
ID-vel megy fel, hanem a komplett régi history-jával együtt.

Remélem így már érthető. PL itt egy ilyen history, 2 szerkesztése volt
ennek a vonalnak (csak egy random példa, nem dolgozok errefelé)

http://www.openstreetmap.org/browse/way/144411059/history

Véleményem szerint az amúgy is 0-zódó ID-k miatt nem érdemes ezzel
vacakolni az importált ÚJ vonalak mehetnek fel, és ahol érdemes, ott a
régi PONTOKBA mergeljük ezt az új vonalat, így legalább a pont
history-ján követhető valamennyire, a vonalén viszont egyáltalán nem.

(Korábban úgy merült ez fel, hogy ha egy pontból álló várat körvonal
alakú várrá rajzolunk át, akkor ILLIK a pontot beépíteni a várba,
például bejáratként vagy egyik sarkaként, hogy megtalálható legyen, hogy
ki rajzolta fel azt a várat már akár korábban is. Nem pedig egyszerűen
kitörölni a pont-várat vagy egyéb pont-objektumot.)

A leglényegtelenebb kérdés lett a leghosszabb. :-D

Feri