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

[László Csatlós]

Igen, erre én is  gondoltam, a leírásban szerepel is, bár lehet nem elég
hangsúlyosan:
"Már meglévő területjelöléssel való ütközés/átfedés esetén érdemes a
relevánsabb információt megtartani, kiegészíteni (pl. Bing vagy helyismeret
alapján)."

Üdv,
Plutoz

2012. július 30. 10:28 NaTToMi írta, <nattomi at gmail.com>:

> Még annyit hozzátennék 8. pontnak - amit érdemes lenne a Wiki leírásba is
> felszerkeszteni -, hogy ha valaki elkezd importálni egy területet, ahol már
> lát felvitt területfunkció-adatokat (nem kizárólag a CLC-ből származókra
> értve), akkor okvetlen konzultáljon előtte az azokat felszerkesztőkkel.
> Ezek a "kézi" szerkesztések ugyanis sokszor pontosabbak, mint ami a CLC-ben
> szerepel. Én is több helyen javítottam a CLC-t és jó lenne, ha azok most
> nem törlődnének ki egy huszárvágással az új import technika miatt, mivel
> nagyon nehéz lenne reprodukálni őket. Ne felejtsük el azt sem, hogy a CLC
> adatok 2006-osak, most meg 2012-t írunk, sok minden megváltozott már.
>
> Üdv:
> Tomi
>
>
> On Saturday, July 28, 2012 11:07:54 PM UTC+2, Ferenc Veres wrote:
>>
>> Sziasztok!
>>
>> CLC berajzolással kapcsolatban lenne 1-2 kérdésem. A Wiki oldalak amiket
>> néztem:
>>
>> http://wiki.openstreetmap.org/**wiki/WikiProject_Hungary/**
>> Import%C3%A1l%C3%A1s/Corine_**Land_Cover_2006<http://wiki.openstreetmap.org/wiki/WikiProject_Hungary/Import%C3%A1l%C3%A1s/Corine_Land_Cover_2006>
>>
>> http://wiki.openstreetmap.org/**wiki/CLC_import_alternat%C3%**ADva<http://wiki.openstreetmap.org/wiki/CLC_import_alternat%C3%ADva>
>>
>> http://wiki.openstreetmap.org/**wiki/CLC_feldolgoz%C3%A1si_**
>> seg%C3%A9dlet<http://wiki.openstreetmap.org/wiki/CLC_feldolgoz%C3%A1si_seg%C3%A9dlet>
>>
>> 1. Óriási területek
>>
>> Zsolt írja, hogy a sok km-en keresztül húzódó területfunkciókat jobb
>> lenne kisebb darabokra vágni, akkor is, ha a CLC-ben ez egy db nagy
>> terület ami kanyarog a falvak között. A vágást az admin-boundary-ba való
>> bekötéssel javasolja.
>>
>> Erre Plutoz leírása úgy írja, hogy ideiglenesen kössük bele, amíg nem
>> érünk a szomszéd falu feldolgozáshoz, és részletesen taglalja, hogy hogy
>> kell akkor az admin-boundary-ról leválasztani az átmenetileg belekötött
>> területfunkció polyt.
>>
>> Én javaslataim:
>>
>> - jó ötlet, hogy tagoljuk, de szerintem ne az admin boundary vonal
>> mentén, hanem találomra akárhol 1-1 nagyobb egyenessel, ami nem fut
>> semmivel. Igaz, hogy bizonyos renderelőkben ekkor egy vonal lesz az
>> erdőben és ugyanolyan erdővel folytatódik, de mégis tisztább mint admin
>> boundary-kat "bántani".
>>
>> - 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.
>>
>> - Erre a "huszárvágásra" jó lenne valami fixme értéket rakni, pl
>>
>> fixme=continue and remove this line
>>
>> és esetleg a vonalnak adhatnánk a műszaki rajzokon szokásos "törés"
>> formát:
>>             /\
>> ------------  \  -----------------------------
>>                \/
>>
>> (Ez persze nem olyan fontos, de magunknak is segítség egy vizuális "itt
>> van vége, de csak átmenetileg")
>>
>> - admin boundaryba véglegesen?
>> - admin boundaryba ideiglenesen?
>> - végleges tagolás módja?
>> - ideiglenes lezárás módja?
>>
>> 2. ideiglenes feltöltések
>>
>> Amikor valami nincs kész, mert abbahagyja az ember a munkát, akkor vajon
>> mindent lezárjunk e, vagy tölthetünk fel befejezetlen multipoligonokat
>> is, amik nem zárnak semmibe. (Én így csináltam tegnap, mondván, ha
>> valaki piszkálja, úgyis látja, hogy friss szerkesztés, tehát hiába hibás
>> az adat, valószínűleg még dolgozik rajta a szerkesztő.)
>>
>> - zárjuk?
>> - ne zárjuk?
>>
>> 3. Egyelemű multiploigonok
>>
>> Plutoz féle CLC tagolóban az is multipoligon relation ami csak 1 db
>> téglalap (vagy más poligon). Ez lehetett volna sima "zárt vonal" is. API
>> V0.7-ben remélhetőleg már nem annyira lesz érezhető a különbség mint
>> most, de vajon ezeket hogy vigyük fel?
>>
>> - egyelemű multipolygon?
>> - vagy tegek átmásolása a vonalra és kapcsolat törlése?
>>
>> (Nekem mindegy, mert én bízok abban, hogy a fejlesztés olyan irányba
>> halad majd, hogy közeledik egymáshoz az egyvonalas meg a többelem
>>
>> 3. Ismeretlen területek (CLC ID="none?")
>>
>> Van pár vonal aminek semmi teg nincs a Plutoz féle CLC adatokban. De
>> BING-en mondjuk látom, hogy erdő. Akkor meg tudom csinálni az erdőt, de
>> vajon milyen egyéb címkéket tegyek rá? Én azt csináltam, hogy CTRL-C egy
>> másikon, CTRL-V ezen, majd a CLC ID-t "none?"-re átírtam. De így
>> legalább a source meg egyéb adatok jók.
>>
>> Tehát ez a kérdés csak azokra vonalkozik, ahol igenis van CLC vonal,
>> tehát jogos a copyright megjelölés, nem azokra, amit én találok majd ki
>> a BING alapján a lyukakba.
>>
>> 4. Régi landuse=residential vonal
>>
>> Volt residential körvonal, én rajzoltam pár hónapja. Viszont azt nagyon
>> hosszadalmas lett volna darabolgatni és a CLC import adatokat a régi
>> vonallal helyettesíteni, ráadásul SPLIT LINE (szükséges, mert pl a falu
>> 4 oldala mellékesen más területfunkcióhoz IS csatlakozik) után az OSM
>> jelenleg csak az egyik vonal history-ját tartja meg, a többit új
>> vonalként tölti fel, tehát nem mentenék meg elég "történeti adatot".
>>
>> Ehelyett azt csináltam, hogy a CLC vonalat részben az enyémre
>> igazítottam, mert az jobb volt az egyik oldalon (pontok mergelésével).
>> Így a CLC-s előrekonfigurált relációk sok segítségét ki tudtam
>> használni, de a forma mégis jobb lett. A résztvevő pontok egy része
>> pedig "történeti adatként" is tud szolgálni, mert a MERGE megtartja a
>> meglévő pontokat.
>>
>> 5. residential->"lakóút"
>>
>> landuse=residential lakóútként jelenik meg a kapcsolatok listáján.
>> remélem különválasztható a highway=residentialtól a fordításban! :-/
>>
>> 6. Wiki frissítése
>>
>> A wikiben javasolnám, hogy a szerkesztési módszert vegyük előre, Plutoz
>> odlaláról integráljuk a fő CLC-s import oldalba, és a "hogyan
>> konvertáljuk az adatokat" nagyon bonyolult technikai szekciót, ami most
>> már az adatok letölthetősége miatt nem is kell, toljuk hátra, vagy akár
>> egy külön oldalra.
>>
>> 7. Vonal folyó vagy széles folyó?
>>
>> A Szamos most egy vonal, de a CLC adatokból importálva egy folyó
>> szélességű riverbank. Mi legyen vele? Egyelőre főleg az egyik oldalára
>> töltöttem fel CLC vonalakat, így még esetleg ha riverbank lesz, akkor
>> menthető az eredeti vonal history-ja részben azzal, ha a másik partot
>> abból rajzolom. Bár ez is kétséges, mert már 1 db vonal-vágással is
>> tönkretehetem a history-t.
>> (Egyébként a SPLIT esetén megsemmisülő history se veszik el teljesen,
>> hiszen a vonal többi pontjai is megmaradnak és azokból továbbra is lehet
>> következtetni az eredetre.)
>>
>> - legyen e riverbank a vonal helyett?
>> - mit tegyünk a history megmentés érdekében, tekintve, hogy nem az egész
>> folyót importálom egyszerre, csak 1-2 km-es szakaszokat.
>>
>> Feri
>>
>  --
> Magyar OSM Levelezőlista - openstreetmap-hungary at googlegroups.com
> leiratkozás: openstreetmap-hungary+unsubscribe at googlegroups.com
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.openstreetmap.org/pipermail/talk-hu/attachments/20120730/76438662/attachment.htm>