„Vita:Vonalreform” változatai közötti eltérés

A lap 2008. november 12., 11:23-kori változata

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.

1. 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
2. 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ő).