Vita:Vonalreform

A Turistautak.hu wikiből
A lap korábbi változatát látod, amilyen zacz (vitalap | szerkesztései) 2008. november 12., 10:23-kor történt szerkesztése után volt.

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.

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