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

A Turistautak.hu wikiből
(Áthozat a főlapról)
(Új lapra a sok szöveg)
1. sor: 1. sor:
== zacz (javaslat a megvalósításra) ==
+
== 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
+
lásd [[Javaslat a vonalreform megvalósítására]] oldalon
*1.1 Adatbáziskód és a hozzátartozó jelentés rögzítése
+
    lásd: [[Media:Turistautak-típuskészlet-vonalak-mind.png|mapedit-képernyőkép]]
+
    Új javaslatok: A közös kimenetek és a könnyebb rajzolás miatt alapnak érdemes lenne
+
    az [[Media:Omp-utak.jpg|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: [[Media:Turistautak-típuskészlet-vonalak-mind.png|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 ==
 
== 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.

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