turistautak.hu

Előzmények

hozzászólásai | válasz erre | 2010.01.21 21:41:13 (37866)

Szerintem az ID=394, ID=3240 felületeket simán törölni kell.

Ebbe a hibába estem bele én is, mert egyesítettem két hasonló felületet amiből létrejött egy harmadik ami feltöltéskor kapott egy új ID-t. Az adatbázis azt látta feltöltéskor, hogy létrehoztam egy harmadik felületet, de nem "bántottam" az eredeti kettőt, tehát megtartotta mindhármat. Ezért jött létre a wikiben a Külön ID-vel rendelkező felületek egyesítése fejezet.

[előzmény: (37864) Old Eye, 2010.01.21 21:22:36]

Old Eye

hozzászólásai | válasz erre | 2010.01.21 21:22:36 (37864)

Megnéztem... Faramuci dolog, nem is tudom hirtelenjében, hogy értelmezzem, mi a jelenség oka és hogyan kell javítani.
Mecsek tájegység; Hedrehely község - ez két, egymástól elkülönülten álló lakott terület, típusa 0x05 (falu), két hosszúkás, É-D irányultságú, nagyjából 100 m széles, 1800 m hosszú, egymástól úgy 500 m távolságban fekvô téglalap.
Az MP file-ban három [POLYGON] entitás írja le ezt a két felületet:
ID=394 a Ny-ra esô téglalapot,
ID=3240 a K-re esôt.
ID=61822 egyszerre mind a kettôt.
Az utóbbi [POLYGON] entitás két 'Data0=' paramétert tartalmaz, egy az egyben megfelelnek a másik két entitásban (ID=394 és ID=3240) található 'Data0='paramétereknek.
Úgy tûnik, elôször megrajzolták a Hedrehely polygonját két részben, nem egy idôben. Elôször csak egy polygon volt (ID=394), majd pontosították úgy hogy kettéosztották, az újabb felület kapta az ID=3240 azonosítószámot; ekkor nyerte el a két polygon jelenlegi, végleges alakját.
Aztán, ki tudja, mikor, valaki ezt a két polygont azzal a meggondolással, hogy egy közigazgatási egységet képviselnek, összevonta - ez kapta meg az ID=61822 azonosítószámot és a két polygon adatait - azonban vagy elfelejtette vagy nem tudta a régi kettôt törölni.
Nem tudom, mit lehet ilyenkor csinálni...

Errôl van szó:

Az MP file-ban pedig ez van:
[POLYGON]
Type=0xa5
Levels=4
Label=Hedrehely
Data0=(46.204787,17.644318),(46.204322,17.644548),(46.204143,17.644637),... stn
ID=394
Tipus=telepulesek
Tajegyseg=mecsek
Del=0
[END]

[POLYGON]
Type=0xa5
Levels=4
Label=Hedrehely
Data0=(46.205605,17.654113),(46.203841,17.654900),(46.203692,17.655124),.... stb
ID=3240
Tipus=telepulesek
Tajegyseg=mecsek
Del=0
[END]

[POLYGON]
Type=0xa5
Levels=4
Label=Hedrehely
Data0=(46.204787,17.644318),(46.204322,17.644548),... u.a. mint ID=394
Data0=(46.205605,17.654113),(46.203841,17.654900),... u.a. mint ID=3240
ID=61822
Tipus=telepulesek
Tajegyseg=mecsek
Del=0
[END]

Mi a teendô?

[előzmény: (37855) kovrob, 2010.01.21 12:42:37]

kovrob	hozzászólásai \| válasz erre \| 2010.01.21 12:42:37 (37855)
A mecsek pont kéznél volt: ID=394 ID=61822 [előzmény: (37853) kovrob, 2010.01.21 12:17:43]

kovrob	hozzászólásai \| válasz erre \| 2010.01.21 12:17:43 (37853)
Szerintem nem tudok olyat mondani amiben nincs. :) [előzmény: (37851) Old Eye, 2010.01.21 12:14:47]

Old Eye	hozzászólásai \| válasz erre \| 2010.01.21 12:14:47 (37851)
Ez kezd érdekelni... mondj egy olyan tájegységet, mely MP anyagában duplikált polygonok jelennek meg! Kösz! [előzmény: (37849) kovrob, 2010.01.21 11:59:20]

kovrob

hozzászólásai | válasz erre | 2010.01.21 11:59:20 (37849)

Nem tartom jó ötletnek több okból sem. Ha kilóg mégis a tájegység polygonból akkor mp-ben nem jön le, megint marad benn "szemét" illetve Megoldás lehet, ha valaki elválalja, hogy egyenként átnézi őket, de mivel ezek 2008 novembere óta nem hiányoznak seniknek, nem hiszem, hogy adatvesztés lenne. Amennyiben később valaki mégis rászánná magát akkor oda lehet neki adni a polygonokat, hogy csemegézze át...

[előzmény: (37845) pgyp, 2010.01.21 10:56:16]

pgyp	hozzászólásai \| válasz erre \| 2010.01.21 10:56:16 (37845)
Mivel BKK megye majdnem teljesen az alsó-tiszában van, tedd át őket oda szerintem [előzmény: (37841) urbalazs, 2010.01.21 10:33:25]

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