Vita:Vonalreform
Tartalomjegyzék |
zacz (javaslat a megvalósításra)
A vonalreform megvalósításának lépései. 2008.11.09 és 2008.12.31 között
1.Uj típusok meghatározása
- 1.1 Adatbáziskód és a hozzátartozó jelentés rögzítése
lásd: mapedit-képernyőkép Új javaslatok: A közös kimenetek és a könnyebb rajzolás miatt alapnak érdemes lenne az OMP útjait figyelembe venni.
- 1.2 Bővíthetőség biztosítása
Rendben
- 1.3 Adatbázis struktúra
Néhány szó, hogy miként érinti a struktúrát.
- 1.4 Vita további menete
fölösleges
- 1.5 Lezárás
(felelős: , Határidő:2008.11.09)
2. Adatbázis átkonvertálása
- 2.1. Konvertálási szabályok
Régi típus és/vagy paraméterek alapján
A kimaradók, nehezen kezelhetők, ellentmondók == Ismeretlen
a régi típus paraméter lehet)
Akár rögtön SQL-ben megfogalmazni
- 2.1.1 Vita további menete
xy vitaindítót készít 2008.11.17.re
- 2.1.2 Lezárás (felelős: , Határidő:2008.11.21)
- 2.2 Konvertálás
- 2.2.1 Gépi menet
(Az SQL megírása kiadható, András átveszi)
(felelősök : , Határidő:2008.12.10)
- 2.2.2 Kézi menet
A vitás esetek kigyűjtése, konzultálni a terepet ismerőkkel
(felelősök tájegységenként : , Határidő: 2008.12.10 után folyamatos)
3. Adatbázis és térképkészítők kapcsolatának biztosítása
- 3.0 Mapedit megjelenítés
lásd: mapedit-képernyőkép KÉsz??? (felelősök : , Határidő: 2008.11.09 )
- 3.1 új mp állományt generáláló program karbantartása
(A megírása kiadható?, András átveszi)
(felelősök : , Határidő: 2008.12.10 )
- 3.2 Mapedit új verzió kiadása
(A megírása kiadható?, András átveszi)
(felelősök : , Határidő:2008.12.10 )
- 3.3 új mp állományokat bedolgozó program karbantartása
(A megírása kiadható?, András átveszi)
(felelősök : , Határidő:2008.12.10 )
- 3.4 WEBes program karbantartása
(A megírása kiadható?, András átveszi)
(felelősök : , Határidő: )
- 3.5 WEBes program fejlesztése
(szükséges-e, mikor, hogyan)
4. Egyéb kimenetek biztosítása
- 4.1 Raszterkép
(Mapedit megjelenés?!)
(A megírása kiadható?, András átveszi)
(felelősök : , Határidő:2008.12.10 )
- 4.2 Garmin
- 4.2.1 Konvertálási szabályok
(kódkapcsolat)
(felelősök : , Határidő: )
- 4.2.2 Konvertálási szabályok helye
(Adatbázis, generáló program)
(felelősök : , Határidő: )
- 4.2.3 A generáló program karbantartása
(A megírása kiadható?, András átveszi)
felelősök : , Határidő:2008.12.10
- 4.3 Russa
- 4.4 Java
- 4.5 3D
- 4.6 Magellán
- 4.7 SVG
- ...
- 4.x
POI-reform hasonló alapelvekkel indul 2009.01.01.
Kolesár
Nem értek egyet az időzítés rendszerével, mert a három típuslistát (pont, vonal, felület) egyszerre kell bevezetni, mégpedig akkor, amikor a szerkesztők által használt mapeditben már benne van a teljes típuskészlet.
A feladatok sorrendje sem jó, mert például nem lehet előbb lezárni a típuskészletet és utána nekiállni a konvertáló algoritmus megírásának, hiszen a konverzió során eszünkbe juthat kimaradt típus, mint ahogyan már meg is történt.
A konvertálás nem tiszta SQL, hanem PHP program végzi. Ennek az az oka, hogy többféle paramétert kell figyelembe venni az új típus meghatározásánál.
Szóba került az OMP-hez való alkalmazkodás. Szükség van egy olyan emberre, aki benne él az OMP-ben, így össze tudja párosítani a típusokat, majd tud javaslatot tenni változtatásokra annak érdekében, hogy oda-vissza jól átjárható legyen a típuskészlet.
A lépcsőkben való bevezetést amiatt ellenzem, mert beleőrülnénk, hogy mikor melyiket is kell használni. Kellene egy Turistautak-átmenetileg-csak-vonalak típuskészlet, aztán egy Turistautak-átmenetileg-csak-vonalak-és-felületek, majd egy végleges Turistautak is, vagyis egy helyett háromszor kellene átállni.
Összeírtam a típuskészlet-váltás ütemtervét, lásd a Típusreform oldalán.
zacz
A típusok együttes bevezetése lehet, hogy bizonyos feladatok elvégzését megkönnyíti, de továbbra is úgy gondolom, hogy lehetséges a szakaszos bevezetés is. Szerintem a vonalreform előkészítése jó, szombaton véglegesen lezárható. Az időzítés rendszerét én nem tudnám az együttes bevezetéshez megfogalmazni.
A feladatok sorrendje variálható és párhuzamosítható, de ezek azok a feladatok, amit meg kell csinálni vagy rögzíteni azt, hogy készen vannak.
A kimaradtak Ismeretlen típussal kerülhetnek konverzióra, s kézzel korrigálható.
A javaslatom lényege, hogy kiderüljön mik azok a (programozási és egyéb) (rész)feladatok, amelyeket András át tud adni másoknak, s időben is látható és meghatározható legyen a folyamat menete, vége.
Jelzésfestők, új turistaút-tervezők számára:
modras: a Jelzésfestési és táblázási támogatás-ban leírt lehetséges jövőbeni funkciókhoz (meg már most is) szükség lenne az alábbiakra, ezért javaslom a megvitatásukat:
- privát vonal/POI lehetősége (Del=user)? v. tervezett vonal/POI lehetősége?... ÉS/VAGY:
- új vonaltípus szükséges: „ez az út nem út” névvel – tervezett/megszűnt nyomvonal, de még/már nem járható, mert pl. lekerített, nagyon bozótos, beszántott, nem kitaposott, stb... (ilyenre számos példát láttunk már!)
- gyalogos járhatóság bővítése: D – bakancsban is igen nehezen járható, úthibákkal terhelt, veszélyes szakasz, esős időben nem ajánlott...
Irányítás kétféle értelmezése
(ld. még Útvonalkezelés fejlesztése)
modras: Sok gondot okoz az irány megfordításának művelete az útvonalak kezelésekor, ezt jó lenne elkerülni: a szakasz iránya az egyirányúságnál és a szakaszra való hivatkozásnál egyaránt megjelenik, ezeket függetlelíteni kellene egymástól.
- megoldási javaslat: 0-1-2 értékű egyirányúsági paraméterrel [ahol a 2 azt jelenti, hogy a tárolt irányhoz képest visszafelé egyirányú], vagy
- megoldási javaslat: a hivatkozás default irányára vonatkozó „reversed” flag-gel [ez akkor kapcsolódna be, ha valaki a megfordítás műveletet hajtotta végre]).
Akármelyiket is választanánk, stabil lenne a szakaszra való közvetlen hivatkozás az id-vel és annak negáltjával (pl. 112 odafelé és -112 visszafelé értendő).
