Vita:Vonalreform

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

Nem szintbeni kereszteződések ábrázolása

A térképen többnyire nem látszik, ha két vonal nem szintben keresztezi egymást (híd vagy alagút esetén), ill. hogy melyik van felül, melyik alatta. Ld. pl. Budai Vár Alagút

Javaslom egy új vonalparaméter bevezetését ("Szint" vagy "Z koordináta") néven, ami relatív magasságot jelöl, azaz arra szolgál, hogy ha egy adott pontban nem szintbeni kereszteződés van (nincs közös node), akkor el tudjuk dönteni, mit kell "felülre" rajzolni. Többszintű csomópontoknál ez még inkább jelentős. Az értéke tetszőleges egész szám lehet, nem a konkrét érték számít, hanem hogy ha keresztezi egymást két vonal, akkor melyiknek van nagyobb értéke.

Ennek továbbfejlesztése is lehetséges lenne, ha az alagút jelölését meg akarjuk különböztetni a híd/viadukt jelölésétől: a negatív számok alagutat jelölhetnének, a pozitívak hidat, így az alagutat lehetne a térképeken szokásos módon, szaggatottal vagy halványan, esetleg csak a két bejáratot feltüntetve kirajzolni (miközben maga az út teljes értékű térképi elem marad az útvonaltervezéskor), a hidak két oldalára pedig fel lehetne tüntetni a szokásos térképjelet. Persze csak azokon a kimeneteken, amelyek erre képesek, vagy képessé tehetők.

Az új paraméter bevezetésével a valóságot hűbben tudnánk leképezni az adatbázisban. Kérdés persze, hogy mely kimeneteken hogyan lehetne ezt jól kihasználni...

Hajo: Jó ötlet!

Erről jut eszembe: Jó volna még két vonaltípus: híd. Ezt pl viaduktok és/vagy hosszabb hidak esetében a mapeditben az út vonalára rárajzolva rajzolnánk meg híd típussala híd/viadukt hosszának megfelelően. A kimeneteken pedig az út jobb és bal oldalán a szokásos jelet látnánk. (Lehet, hogy ilyet láttam az OMP Ausztria térképén?)

baggio: Nagyon jó ötlet!

Már én is gondolkodtam rajta. A hidakat, alagutakat, töltésen haladó utakat (pl. gátakon), mélyutakat akár egy labelben lévő kapcsolóval is meg lehetne különböztetni, de az extraparaméter se rossz ötlet. A hidak megjelenése a kimeneteken lehetne a vonalak két oldalán futó vékony folyamatos vonal a hidak végén egy kis szakaszon a vonaltól 45fokban távolítva. Az alagutaknak a vonalak két oldalán folyamatos szaggatott vonal. A töltéseknél, és a mélyutaknál szintén két oldalon futó vékony vonal más-más sraffozással. A hidaknál/alagutaknál felmerül még az hogy útvonaltervezésnél ne illessze a szintvonalakra az utat, hanem a híd/alagút kezdete és vége közötti magasság közé egy folyamatos átmenetet interpoláljon. Így a magasság diagramon egy viaduktnál nem az látszódna, hogy lemész a völgybe, majd vissza, hanem a viadukt eleje és a vége közötti egyenes szakasz. Töltések és mélyutaknál lehetne alkalmazni egy (akár egy fix) magasságot/mélységet amit az aktuális szinthez hozzáad/kivon tervezéskor/megjelenéskor. A másik kérdés a két vagy többszintes kereszteződések (vasúti felül/aluljárok, nagyobb utak/autópályák csomópontjai). Ezt is labelben vagy extraparaméterrel kéne megoldani. Lenne egy szint szám aminél +/- előjelekkel kéne megadni, hogy földfelszín felett, vagy alatt halad a vonal. A szintek közötti távolság egy fix magasság lenne. Pl. ha ez 6m akkor a szintek magassága "szint" x 6m lenne. A felszín a 0 szint. Tudom, hogy ennek megvalósítása egy összetett feladat, de most, hogy meg lesz osztva a munka, remélhetőleg lesz rá kapacitás. Igazi csemege lenne, ha laszloistvan T3D-jében át lehetne nézni egy viadukt alatt ami árnyékot vet, vagy bele lehetne nézni egy többszintes kereszteződés utjai közé! :-)

modras : Nagyon jó! Itt tényleg többről van szó, mint amit elsőre gondoltam. :) Szóval akkor pontosan mi és hogyan legyen? Hangosan gondolkozom tovább...:

• az út térképjele lehet
  • alagút
  • viadukt
  • mélyút
  • töltésen vezető út
  • ... +lehet-e ezek kombinációja? Kell-e megadnunk oldalt? (pl. meredek hegy oldalában vagy rakparton az egyik oldal mintha töltés/viadukt lenne, a másik oldal meg mélyút (pl. sziklafal), meg lehet olyan is, hogy nyitott alagút egyik oldalon) - ezt szerintem még gondoljuk tovább, hogy akarjuk-e modellezni, s mennyire (pl. lehet hogy elég egy "fal balra, szakadék jobbra" / "fal jobbra, szakadék balra" nevű 2 további érték?)
• az út magassága lehet
  • 3D-ben és magassági profilon rajzolva (kérdés, hogy mit milyen mélységben akarunk modellezni):
    • a felszínhez illeszkedő,
    • a felszíntől elrugaszkodott (azaz a végpont és a kezdőpont közt átlós - de 3D-ben a közbülső pontok abszolút Z koordinátáját ki kell számolni ehhhez!),
    • a felszíntől +/- m-ben vagy szinttel megadott érték, de itt probléma lehet az eleje/vége kezelése... Lehet, hogy pontonként kellene X,Y,Z koordinátát tárolni ilyen esetekben, ha akarjuk ezt jól ábrázolni? Csak ez eléggé nagy belenyúlás lenne az adatmodellbe... A GPS track fájl tárol Z koordinátát? Szerintem igen...
  • a térképen rajzolva a relatív sorrend számít, amit elvileg ki is lehetne számítani, de lehet, hogy jobb lenne letárolni a relatív Z koordinátát vonalanként, amit a felhasználó megadhat a MapEditben is...?

S ha megvannak a válaszok, akkor javasoljunk konkrét megvalósítást (hogy minél jobban fogjuk meg az adatbázis szintjén a dolgot: milyen mező/kapcsoló kombináció a legjobban érthető és a legkevésbé redundáns és nem igényel túl nagy számítási kapacitást a rajzolás pillanatában)...

baggio: Kérdés még, hogy milyen szinten akarjuk ezt megvalósítani. Ha csak az a cél, hogy 2D-ben megjelenítsük a hidat, alagutat, töltést, mélyutat, és a többszintes kereszteződéseket, akkor egy új extraparaméter öt lehetséges érték akár elég is lehet, már ami a rajzolókat érintené. Viszont ha a 3D-s megjelenítés a cél akkor jóval több kell hozzá, és jelenleg csak laszloistvan T3D-jén lehetne valamit kezdeni vele és kérdés, hogy szeretne-e egyáltalán foglalkozni ezzel?

Hajo: Én csak a 2D-ben gondolkoznék. Ennél több túl nagy változás lenne. Azt kellene elödnteni, hogy extra paraméterrel jelöljük (relatív magasság, sorrend, vagy típus), vagy spec (rátét) vonaltípussal jelöljük a hidat/alagutat stb-t?.

baggio: ne bonyolítsuk újabb vonallal, az extra paraméter szerintem jó lesz, vagy mint az OMP-nél kapcsolóval.

modras: OK, akkor szerintem vonalanként legyen egy relatív Z koordináta (a 2D rajzolási sorrend végett) és egy útextra (alagút, híd, ... - térképjelekhez) paraméter. Azt még azért belevenném, hogy a felszínhez igazodó vagy attól "elrugaszkodott"-e a vonalvezetés, pusztán az útvonal itiner magassági profilja miatt ("2,5D"). Ezt viszont ha jól érzem, el lehet dönteni az útextra alapján: ha alagút vagy híd akkor csak a két végpont magassága számít, közte egyenletes (bár tudom hogy vannak spec. esetek, ez csak közelítő megoldás), a többi esetben meg - szintén közelítőleg - a felszínt vehetjük. Nem? Vagy tudunk ebben a modellben jobbat mondani?

így akkor két plusz paraméter kell, kérdés milyen nevet adjunk nekik és mik legyenek a lehetséges értékek (a rel. koordináta egész szám, az előjel végül is nem számít; a másiknak meg szöveges értékek vagy kódok)?