Re: [osm-hu] CLC próbák - kérdések
László Csatlós
plutoz01 at gmail.com
2012. Júl. 28., Szo, 23:35:41 UTC
Sziasztok!
Feri felvetéseihez csatolom a meglátásaimat.
1. Óriási területek:
Igen, tényleg vannak fél megyényi területek és tényleg ésszerű lenne
valamilyen bevett módszer szerint feldarabolni őket. Ahogy utána olvastam,
egy relációban már a 300 tag is soknak számít (a hátterét nem ismerem,
miért), és ezek a területek bőven túlszárnyalják azt. Ez a szerkesztőben is
kényelmetlen, amikor egy incomplete relációhoz még ~5.000 pontot kell
letölteni, csak hogy ellenőrizni lehessen a multipolygon folytonosságát,
szóval a szükségessége megkérdőjelezhetetlen.
> - 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.
>
> - 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?
>
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.
>
> 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?
>
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?
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.
>
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.
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).
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.
7. Vonal folyó vagy széles folyó?
>
> - 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.
>
Nem sokat foglalkoztam a témával, de ahogy én tudom, kb. 5 méteres
folyószélesség fölött már érdemes jelölni a riverbank-et is. Hogy melyik
kell? Erre nem tudom a választ, amit én láttam, ott egyidejűleg megvolt
mind a két megoldás kb. Dunavarsánynál de talán az egész Duna mentén is.
Ennek szerintem azért lehet értelme, mert kellően távoli nagyítás esetén a
riverbank már nem kerül renderelésre, azonban a vonal még igen.
Azt hiszem, ez is szép hosszú levél lett, remélem volt türelmetek
végigolvasni. :)
Üdv,
Plutoz
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.openstreetmap.org/pipermail/talk-hu/attachments/20120729/eeda75b7/attachment.htm>
További információk a(z) Talk-hu levelezőlistáról