turistautak.hu

Előzmények

urbalazs	hozzászólásai \| válasz erre \| 2010.01.21 10:33:25 (37841)
UPDATE poligons SET deleted = 1 WHERE region_id IS NULL Ilyen kellene? Invalid értékek: NULL: 2439 db (üres): 1 db - ezt átteszem NULL-ra Bács-Kiskun: 14 db - ezzel mi legyen? CLC: 319 db - ezzel mi legyen? gödöllői: 1 db - ezt átteszem godolloire N/A: 1 db - ezt átteszem NULL-ra A többi OK [előzmény: (37838) kovrob, 2010.01.21 08:15:48]

kovrob	hozzászólásai \| válasz erre \| 2010.01.21 08:15:48 (37838)
Amennyiben van időd rá akkor SZERINTEM futtas le egy update-et a polygons táblán, és update-eld a deleted mezőt where region_id not in "tájegységek". [előzmény: (37835) laszloistvan, 2010.01.21 07:11:20]

laszloistvan	hozzászólásai \| válasz erre \| 2010.01.21 07:11:20 (37835)
Ezek után barátja lennék egy mezőnek (pl. 'aktiv'), ami kétséget kizáróan eldönti, hogy egy objektum (leginkább poligon) végülis van vagy nincs. A kezelést adatbázison belül kéne megoldani - egy paradigmaváltáskor is csak egyszer, a kimenetekkel meg ezt figyelni. [előzmény: (37832) kovrob, 2010.01.21 06:37:04]

kovrob	hozzászólásai \| válasz erre \| 2010.01.21 06:37:04 (37832)
Rendbe kellene rakni a db-ben. Az elegánsabb. :) [előzmény: (37830) laszloistvan, 2010.01.21 06:29:29]

laszloistvan

hozzászólásai | válasz erre | 2010.01.21 06:29:29 (37830)

(kovrob 37812-re is)

Igen, a kimenet-gyártáshoz is használtam ezt a paramétert: ' ... AND region_id'' ' - és eddig egész jól működött is.
Csak most úgy értettem, hogy ez nem kell, csak a 'code' és 'deleted' mezők. Ha viszont mégis, akkor igazán gáz a helyzet, mert a 'region_id' kissé elkurvult: már nem csak annyi, hogy tájegység neve vagy üres, hanem olykor NULL, olykor 'CLC', és még ki tudja...

Az .mp generálás adott tájegységre történik, így ott egyszerű a kritérium, de egy nem-tájegység alapú, globális lekérdezésben most vagyoljam végig az összes (jelenleg érvényes) tájegység-nevet? Hát nem lenne elegáns...

[előzmény: (37822) bpeti68, 2010.01.20 21:54:01]

bpeti68

hozzászólásai | válasz erre | 2010.01.20 21:54:01 (37822)

Úgy emlékszem, a lekérdezés gyorsítása miatt az mp-be csak azok a poligonok kerültek, melyek tájegység (region_id ?) tulajdonsága ki volt töltve. Ez, ha jól emlékszem tavalyi téma, mikor még lassú volt a szerver.
A gond abból keletkezett (meglátásom szerint), ha valaki új felületet rajzolt, vagy lyukasztott és nem töltötte ki vagy hibásan töltötte ki a tájegység paramétert. Az upload.php sem ellenőrizte ezt. Így a felület felment, de vissza már nem jött. A rajzoló meg vakarta a fejét, hogy most akkor berajzoltam, vagy nem? És rosszabb esetben berajzolta megint, vagy más rajzolta be mert nem tudta, hogy ott van már.
(Szerintem)

[előzmény: (37808) laszloistvan, 2010.01.20 19:14:25]

laszloistvan

hozzászólásai | válasz erre | 2010.01.20 19:14:25 (37808)

Vagy még egy példa, ami nem ilyen CLC-pótlásból származik szerintem:

Kisalföld, két id: 29066; 29067 - Babarcsi-tó (nem Barbacsi inkább? - de ez most mindegy...)

Az látszik az adatbázisban, hogy tibbigeo tevékenységéhez köthető mindkettő, de nem mondanám, hogy az ő rajzolói hibája, mert az .mp-ben nincs duplázva, nem látszik, rajzolói szinten javítani sem lehet, tehát nem hiba.
A szerveri mechanizmusban, vagy a reformfolyamatban lehet valami, amit nem értek, ha tudja valaki, szóljon.

[előzmény: (37802) laszloistvan, 2010.01.20 17:35:36]

laszloistvan	hozzászólásai \| válasz erre \| 2010.01.20 17:35:36 (37802)
Pl. Bicsérd, két id: 111; 52593. És a 'mecsek' tele van ilyenekkel. Itt még gyógyszer lehetne a régi jó régió :-) (region_id) figyelése, de egyrészt az se megoldás mindenre, másrészt nem szeretnék többet gányolni, mint amennyi szükséges - azért van a reform, hogy elegáns legyen. :-) [előzmény: (37801) kovrob, 2010.01.20 16:54:03]

kovrob	hozzászólásai \| válasz erre \| 2010.01.20 16:54:03 (37801)
Amennyiben ez csak a polygons táblára igaz, akkor a legvalószínűbb ok a duplikálódás. Tudsz mondani konkrét id-ket? [előzmény: (37800) laszloistvan, 2010.01.20 16:48:23]

laszloistvan

hozzászólásai | válasz erre | 2010.01.20 16:48:23 (37800)

...Akkor a reform-ügybe és az adatbázisba belelátó emberek közül kérdeznék valakit valamiről, amire eddig Andrástól nem jött válasz:

A reformmal az egyes objektumcsoportokat gyártó kimeneti lekérdezések tudomásom szerint elvileg a 'code=0x... AND NOT deleted' kritériumig egyszerűsödnek. Ha így van, ezt üdvözlöm, és eszerint próbálkozom, de így az eredményben ismétlődések vannak (leginkább a polygons tábla lekérdezéseinél, legalábbis ott feltűnő). Ezen ismétlődések egy része nem olyan úgymond rajzolási hiba, ami publikusan látszik a rajzolók felé az .mp-ben, tehát van valami lekérdezési konvenció, amivel az .mp mint etalon gyártódik, de amit eddig nem sikerült kiderítenem, pedig futottam pár kört konkrét esetek körül.

Ha valaki tudja a titkot, legyen szíves, ossza meg velem, köszi.

[előzmény: (37799) 2010.01.20 15:12:05]

hozzászólásai | válasz erre | 2010.01.20 15:12:05 (37799)

Anelkul, hogy surgetesi listanak tunne, jo lenne egy publikus lista, amit a wiki-be feltennenek a javitok, s legalabb prioritasi es teljessegi listakent funkcionalnanak.

Pl Fuggo fejlesztesek es hibajavitasok

Ebbol lehetne latni, hogy mi az, amirol tud Andras es az a nehany ember, aki mar reszben hozza tud nyulni a dolgokhoz, jova is hagytak mint elvegzendo dolgot, csak meg nem volt ra idejuk.

Ugye, me'g nincs ilyen?

Felhasználónevedet és jelszavadat a geocaching.hu oldalon is használhatod!

[ kezdőlap ] [ térkép ] [ + felmérések ~ ] [ + útvonalak ~ ] [ + poi ~ ] [ belépés ] [ faq ] [fórum] [email]

A weboldal működése és tartalma folyamatos fejlesztés alatt áll, köszönettel vesszük az észrevételeket a fejlesztési ötletek oldalon.
A turistautak.hu-ra feltöltött track-eket és a letölthető térképeket, azaz térképi adatbázist az ODbL licencnek megfelelően bárki használhatja.
Minden egyéb anyag előzetes írásbeli engedély nélkül csak magáncélra használható fel. jogi tudnivalók