„Vita:Vonalreform” változatai közötti eltérés
zacz (vitalap | szerkesztései) (Áthozat a főlapról) |
zacz (vitalap | szerkesztései) (Új lapra a sok szöveg) |
||
1. sor: | 1. sor: | ||
− | == zacz ( | + | == zacz (Javaslat a megvalósításra) == |
− | + | ||
− | + | ||
− | + | lásd [[Javaslat a vonalreform megvalósítására]] oldalon | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Kolesár == | == 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. | 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 lap 2008. november 12., 10:39-kori változata
Tartalomjegyzék |
zacz (Javaslat a megvalósításra)
lásd Javaslat a vonalreform megvalósítására oldalon
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ő).