turistautak.hu térképrészleteK+ jelzés GPS-szel
[ english
Előzmények

Andreashozzászólásai | válasz erre | 2013.07.10 00:01:16 (63429)
Sajnos nem értek a Garmin térkép-fájlok felépítéséhez, de szívesen meghallgatnák egy hozzáértőt az egyes nagyítási szintekhez köthető eltérő adattartalmú térképek létrehozásának lehetőségével kapcsolatban.

Amennyire én tudom, minden egyes ponthoz, vonalhoz és felülethez megadható, hogy milyen nagyítási szinteken jelenik meg. Viszont a TUHU jelenlegi rendszerében ezt nem változtathatjuk, András rendszere dönti el a Polish MP fájl generálásakor, hogy az adott objektum mikor jelenik meg.

Úgy tudom külön városrész nincs az IMG formátumban. Legalábbis a városrészeket a Naviguide-ban város POI-val hozták létre, így válnak kereshetővé a Where to/Cities menüben a GPS-en. A megye információ fixen be van írva a városok neve mögé, nem felületellenőrzéssel határozzák meg a megyét. A kereséshez a City Indexing képesség kell, ami a cGPSmapper Shareware változatában van meg. A TUHU térképeken úgy tudom nincsennek indexelve a városok, csak az Openmaps térképeken.

[előzmény: (63426) cseremoha, 2013.07.09 18:41:23]

cseremohahozzászólásai | válasz erre | 2013.07.09 18:41:23 (63426)
"miért lenne baj az, ha a térkép a valóság hű képi megfelelője lenne?" - Ezzel semmi probléma nincs, ez a minimum.

"olyan információt tárolni, amely a felhasználó számára semmi többlet ismeretet nem nyújt, teljesen felesleges" - Szerintem többlet ismeretet ad, ha - pl. Budapest esetében - a GPS-re nézve meg tudom mondani, hogy még Sashalmon vagyok-e, vagy már Mátyásföldön?

Sajnos nem értek a Garmin térkép-fájlok felépítéséhez, de szívesen meghallgatnák egy hozzáértőt az egyes nagyítási szintekhez köthető eltérő adattartalmú térképek létrehozásának lehetőségével kapcsolatban.

"Mert ugyan mi értelme volna például megkülönböztetni a POI-típusban az egyéb belterületi településrészeket az anyatelepüléshez viszonyított elhelyezkedésük alapján?" - Semmi.

De visszatérnék az alapkérdéshez - elfogadva az általad felállított rendszert - mi akadályoz abban, hogy a Budapest XXI. kerületében, Csepelen elhelyezkedő településrészek a hivatalos nevükön szerepeljenek az adatbázisban a felhasználók számára többlet ismeretet nyújtva?
[előzmény: (63424) alnibell, 2013.07.09 17:26:22]

alnibellhozzászólásai | válasz erre | 2013.07.09 17:26:22 (63424)
És a vázolt helyzetben az lenne a helyes állásfoglalás, hogy inkább nem csinálunk semmit, azt sem javítjuk ki, amihez nem kell semmiféle programozói tevékenység, amely legalább az egyik működő, rendszeresen frissülő kimeneten a felhasználók számára jobb tájékozódási, keresési lehetőséget nyújt, amely eközben a felépített adatbázisban adatvesztést, összeférhetetlenséget nem eredményez?

Egy szava nem lenne senkinek, ha a település POI, felület módosításokat csendben a háttérben végeztem volna el.
Elég ránézni Budapest területére, az összevissza kódolt területegység POI-kra, a szétszabdalt felületekre.
Régóta ismerjük a megoldandó feladatot? Igen. Akkor miért ne tennénk legalább annyit, hogy ami jobb a korábbinál, azt érvényre juttatjuk? Ráadásul annak tudatában, hogy a fejlesztés akadozik, illetve leállt.

Egy térképszerkesztőnek nem azon kell törnie a fejét, hogy a munkája során adatbázist tölt-e meg tartalommal, hogy abból hogyan lesz térkép? Mert a cél - szerintem - nagyon is egyértelmű: a felhasználók számára minél több formátumban előállítani egy jól használható térképet. De ehhez információkkal fel kell tölteni az adatbázist és csak azt követeően lehet az abban tárolt adatokból térképet generálni. (Azt csak az értetlenségem kérdezi: miért lenne baj az, ha a térkép a valóság hű képi megfelelője lenne?)
És ott igenis egyszerűsíteni kell, ahol az adatok ismétlése tapasztalható, ahol a rendszer olyan választéklistát kínál, amelyből néhány vagy több soha nem kerül kijelölésre, ahol teljesen fölöslegesen kötünk le erőforrásokat tartalom nélküli adatbázis mezőkre. Továbbá az egyszerűsítés és a rendszerezés nem egymást kizáró fogalmak. De olyan információt tárolni, amely a felhasználó számára semmi többlet ismeretet nem nyújt, teljesen felesleges, csak erőforrást köt le, rossz esetben más hasznos dolog elől. Mert ugyan mi értelme volna például megkülönböztetni a POI-típusban az egyéb belterületi településrészeket az anyatelepüléshez viszonyított elhelyezkedésük alapján?

Lehet általánosan kifogásolni valamit, lehet a meglévőnél jobb megoldáson gondolkodni, általa egy jobban használható terméket elképzelni, de ez nem jelenthet tíz percen túl is zárva tartható sorompót egy már létező rendszer hibáinak javítása előtt! Pató Pál ráért, én nem. Éppen ezért szíves figyelmébe ajánlom ismét a jogosztóknak a #63402 sorszámú hozzászólásom 7. pontjának kiemelt gondolatát. Döntsenek a legjobb belátásuk szerint. De ne majd, most és határozottan!
De azért előtte nem ártana valahogy igazolni, hogy a TuHu-ra és az OMP-re nézve hibás eredményre vezetett a csepeli területen elvégzett szerkesztés, átkódolás, hogy pl. fölösleges volt a kereshetőség megteremtése! Mert szerintem jobb, használhatóbb lett általuk az adatbázisból generált térkép.

[előzmény: (63417) cseremoha, 2013.07.09 16:17:17]

cseremohahozzászólásai | válasz erre | 2013.07.09 16:17:17 (63417)
Végigolvasva Trackman és alibnell hozzászólásait, és az azokat kiváltó levelezést (csak az egy óra volt míg a széttördelt szöveget emészthető formába hoztam) sajnos meg kellett állapítanom, hogy egyik koncepció mellé sem tudnék teljes meggyőződéssel odaállni. :-(

Mivel nem akarom hasonló betűtengerrel elárasztani a fórumot, ezért most nem állok neki pontokba szedni támogató és marasztaló véleményeket az adott javaslatokról.

Egy kicsit messzebbről indítanék. A TuHu-n tapasztalható demokratikus anarchia a TuHu kezdeti időszakától folyamatosan kódolódott bele a működésbe. Egy ilyen, hosszú évekig részletes szabályok nélkül működő rendszert utólag nagyon nehéz komoly érdeksérelmek nélkül keretek közé szorítani.

Alapvető problémának látom, hogy már a projekt céljaiban sincs egyetértés: - adatbázisból csinálunk térképeket, vagy egy térképet tárolunk adatbázisban?
Tehát GPS-re feltölthető (és ez mellett természetesen máshol is megjeleníthető) térképre gyúrunk, vagy egy rendszerezett, részletes adatbázisra (amelyből természetesen minden kimenet kiveheti azt, amire szüksége van).
...hogy érthetőbben fogalmazzak egyszerűsíteni kell, vagy rendszerezni, másoljuk a valóságot, vagy tudunk (és akarunk) valami pluszt is hozzáadni?

Amíg ez a kérdés nem tisztázódik megnyugtatóan, addig teljesen felesleges bármilyen aktuális témát felhozni, mert a háttérben ez a probléma húzódik meg.
[előzmény: (63402) alnibell, 2013.07.08 21:53:01]

alnibellhozzászólásai | válasz erre | 2013.07.08 21:53:01 (63402)
Jó estét!
Ha azt mondom, hogy Trackman hivatkozott hozzászólása elkésett, akkor egyrészt teljesen az igazat írom, másrészt pedig a tálalása, a levelezés tartalmának közreadása semmi más célt nem szolgál, mint egy folyamatban lévő kódolási metódus alkakmazásának a megakadályozása, csak éppen az érdemi indoklás hiányzik mellőle. De úgy is fogalmazhatnék, a leírt óhaj ellenére, hogy ez egyfajta hátbatámadás, Már csak azért is, mert módom sem volt reagálni a legutóbbi levélre, máris ide került. A legfinomabban is inkorrekt dolog ez így.
S hogy ne csak általánosságban írogassak, megpróbálom összeszedni, miért is érzem kétségbeesett tiltakozásnak a szerkesztőknek szóló felhívást.
1.) Május eleje már elég régen volt, az azóta eltelt alatt bőven lett volna mód a világosan megfogalmazott egyszerűsítési, egységesítési elképzelések észrevételezésére, a kifogások, észrevételek megtételére, már csak azért is, mert az információm szerint az egyik kollégánk közvetlenül elküldte az anyagot az OMP prominenseinek is.
2.) Az egész lényege az egyszerűsítés volt. Részben az, hogy teljesen fölösleges a felületeket ugyanolyan szempont szerint típusokra bontani, mint a felületen elhelyezett település jellegű POI-kat. Másrészt pedig az, hogy az eddig egyértelműen besorolhatatlan egyéb belterület, illetve külterület jellegű településrészek jelölésére használjuk fel a MapEdit-ben rendelkezésre álló 7 db település jellegű POI-ból kettőt, az egyiknek új nevet (külterület) adva.
Az első levél szerint jónak ítéltetett mind az, hogy elég kétféle település felületet megtartani, és az is, hogy a meglévő 7 db település jellegű POI elégséges a települések jogállás szerinti kódolására.
3.) A meglévő 7-hez hozzáadni még akárhányat, az nem egyszerűsítés, az annak az ellenkezője, s ha valakit nem érdekel a KSH szerinti jogállás besorolás, akkor meg végképp érthetetlen a típusbővítés. Ugyan milyen lehet az úgymond egyéb településtípus, amely nem vonható be a pdf-ben olvasható hét típus valamelyikébe? Ehhez még hozzávenni a tanyát, amely önmagában sehol nem önálló település vagy akármilyen településrész, legalább akkora hiba, mint teljesen feleslegesen cipelni egy olyan választék lehetőséget, amelynek egyetlen objektum sem felel meg.
4.) A legerőteljesebben kritizált dolog a javaslataim közül a névrajz POI-k használata a nem hivatalos, de a köznyelvben használatos nevű, településen belüli területrészek jelölésére. Ezzel kapcsolatban jeleztem, nincs ellenvetésem az ellen, hogy ezeket egy új POI-típussal jelöljük, hogy ne egy csoportban legyenek pl. a hegycsúcsokkal és a hasonlóakkal. (Szóval így van ez, hogy másoktól nem fogadok el semmit.)
Ha megvan az a lehetőség, hogy a személyes kapcsolat által egy új POI-típus felvételre kerüljön, akár már meg is történhetett volna a névrajz POI helyett ezen újjal jelölni a nevesített területrészeket. (Azt is vállaltam, hogy akár egyenként is átkódolom a területrészek POI-jait.)
5.) A meglévő kimenetek legkisebb mértékű javítása is előrelépés a korábbi állapothoz képest. Győr esetében úgy nagyjából egy éve, míg Csepel esetében a múlt hónapban kódoltam át a POI-kat, módosítottam a lakott területek felületeit. Mindkettőt többször jeleztem itt a fórumon, és igencsak elfogultnak kell lennie annak, aki azt állítja, hogy pl. a Budapest XXI. kerületének, de még a nevesített területrészei kereshetőségének megteremtése az OMP Garmin-kimenetén hibás lépés volt, hogy az visszalépés a korábbi állapothoz képest.
Bőven hagytam időt a módosítás megkezdése előtt az észrevételek, kifogásolások megtételére. Nem történt semmi, leginkább úgy tűnt, hogy nem az a lényeg, hogy mit, hanem, hogy azt ki írja, mondja.
6.) Elég gyakran szorgalmaztam, hogy a használt fogalmakat mindenki egyformán értelmezze. Hogy ez a törekvésem (is) hatástalan volt, mi sem bizonyítja jobban, mint az ide bemásolt levélváltás. (Például nagyon nem összekeverendő a településrész és a nevesített területegység. Az utóbbiak közül az olyanonkról meg külön szó se essen, amelyek területe két kerületet érint.)
7.) A magam keretei, lehetőségei között megpróbáltam gondolkodva megoldást keresni a kimenetek nyilvánvaló hiányosságainak javítására úgy, hogy az ne igényeljen bizonytalan kimenetelű fejlesztési tevékenységet, ne okozzon adatvesztést sem az adatbázisban, sem a felhasználónál.
Állítom, hogy a most kívülről nyíltan (jelentős késéssel) elutasított részleges megoldási javaslatom minden kitűzött célt teljesíti, az OMP Garmin-kimeneten előrelépést hozott.
Lehet felszólítani, meg sürgetni. De eddig miért nem nem keresték a megoldást, miért lett a tagadás most ennyire égető?
És ha azt akarja elérni az arra jogosult, hogy a meggyőződésem szerint helyes eljárást ne folytathassam, akkor - bár ugyan kívülről jött az alkalmazás tiltására történt felszólítás - vegye vissza a jogosítványaimat, hogy ne okozhassak "kárt" az adatbázisban, a generált kimeneteken! De azt elvárom, hogy erről haladéktalanul értesítsen, és azt se bánom, sőt inkább kérem, hogy itt a fórumon!
8.) Trackman, ha sikerül(ne) a nevesített területrészek jelölésére az új POI-típust felvetetni K.A-val, akkor milyen érdemi, példával alátámasztott kifogásod maradna? Milyen kárt okoztam az eddigi tevékenységemmel az OMP-nek, akár a korábbi, akár a Csepel területén végzett szerkesztésemmel?
[előzmény: (63398) Trackman, 2013.07.08 00:12:59]

Trackmanhozzászólásai | válasz erre | 2013.07.08 00:12:59 (63398)
Kedves rajzolók!

Nemrég Alnibell kollégával email váltásba keveredtem, mert felmerült a települések és településrészek ábrázolásának kérdése.
Megkaptam tőle az általa készített pdf-et, amelyben szándékai szerint összefoglalta a témával kapcsolatos szerkesztési szabályokat. Sajnos magának a pdf-nek az eredeti helyét nem ismerem, így feltöltöttem egy kamu trackhoz, ott megtekinthető.
Az összefoglaló pdf-et Alnibell így kommentálta:
...megküldöm azt az anyagot, amelyet a tárggyal kapcsolatban véleményezésre előterjesztettem, és amelyre - sajnos - érdemi állásfoglalás gyakorlatilag senkitől sem érkezett...

Áttekintettem a szabályrendszert, és több - legalábbis általam vélt - problémát találtam benne. Úgy véltem a pdf-et olvasván, hogy alapvető nehézséget jelentett az anyag összeállításakor a jelenlegi poi típuskészletben található elemek minősége (pl. nincs olyan típus, ami kellene, ld. "külterület"), esetleg mennyisége (többfélét kellene ábrázolni, pl. köznyelvben használt, de ksh által nem ismert területi egységek).
Fentiek miatt felajánlottam, hogy amennyiben sikerül egy olyan szabályrendszert alkotni, amely mindkettőnk számára "jónak tűnik", és azt itt a fórumon a tuhu közösség is elfogadja, akkor személyesen megkeresem Kolesár Andrást, jelezve a típuskészlet módosítási igényét, és felajánlva, hogy átvezetem a mapeditben (és a szükséges egyéb helyeken) a módosításokat/bővítéseket (neki ne kelljen vele időt töltenie).

Sajnos idáig nem jutottunk el, mert az általam leírt szabály-kezdeménnyel (amely egyelőre csak a poi típusokra terjed ki, felülettípusok még nem kerültek bele) Alnibell maximálisan nem értett egyet.

Ezzel meghiúsult az, hogy a problémát kezelő, kész szabályrendszer tervezettel tudjunk a tisztelt rajzolói közönség, illetve a tuhu kapcsán tenni képes kollégák elé állni, így maradt az, hogy magával a problémával álljak elő.
A probléma maga - remélem - kiolvasható az alábbi levelezésből. A neveket, email címeket kitöröltem belőle, illetőleg az érthetőség kedvéért nicknévre változtattam.

A "magam részéről" itt kettős jelentőséggel bír: mind tuhu rajzolói, mind az openmaps fejlesztői minőség ide értendő. (Utóbbira reményeim szerint alapot ad, hogy sokan az omp kimeneteket [is] használják Mo vonatkozásában.)

Természetesen a javaslatom, hogy induljunk el a típusbővítés kapcsán abba az irányba, amit körvonalazok alább a "0xa000" típuskód megjelenésétől a "Ez 5 új típus, ha a tanyát is beleértjük." szövegrészig. Itt megtalálhatóak az indokaim is a bővítésre.
Nem állítom, hogy az általam leírtak készek és jók, de úgy vélem, kiindulási alapként szolgálhatnak, az irány megfelelő lenne.

Összességében magam részéről
- kérek minden rajzolót, hogy a pdf-ben leírtakat a jelenlegi formában NE ALKALMAZZA, különös tekintettel a névrajz poik kapcsán,
- felhívom mindenki figyelmét, hogy tartózkodjon az olyan gyakorlattól, amely során saját maga által létrehozott szabályok alapján rajzol objektumokat, módosít/állít be adatokat a tuhu adatbázisában,
- sürgetem, hogy a szóbanforgó témában mielőbb megnyugtató megoldás szülessen.

Üdv,
Trackman

-------------

Az Alnibellel folytatott levelezés:
---


-------- Eredeti üzenet --------
Tárgy: Re: Települések felület POI megfeleltetés a TuHu-n
Dátum: Sun, 07 Jul 2013 22:52:33 +0200
Feladó: Trackman
Címzett: Alnibell

Szia,

elnézésedet kérem a kései válaszért.

Azt írod, a "jogállást tekintve semmi érdemi különbség nincs két vagy
több, a KSH terminológiában egyéb belterületként meghatározott
településrész között".
Ezt én sosem vitattam.
Viszont sajnálom, hogy hiába leveleztünk hosszasan, nem sikerült
érthetően megfogalmaznom, hogy egy térinformatikai adatbázisnak nem csak
a ksh jogállást kellene figyelembe vennie. Sőt, ha csak a saját
véleményemet nézzük, akkor konkrétan nem érdekel a ksh. De el tudom
fogadni, hogy ez is egy szempont, tehát a rendszerbe kerüljenek be azok
az információk, amiből a ksh nézőpontja, adatai előállíthatóak.

Azt is sajnálom, hogy ugyanez az elfogadás részedről mások szempontjai
felé nem működik.

Összességében tehát nem jutottunk előre.
Így viszont - megismerve a pdf-ben általad leírtakat -, azokat
kifejezetten károsnak tartom, főképp a névrajz poi félrehasználata
miatt, de véleményem szerint az alább olvasható egyéb kérdések is
problémásak a rendszeredben.
Kifejezetten helytelennek tartom azt is, hogy készítettél egy
szabályrendszert, amire bár reakció nem jött, de magad mégis elkezdted
alkalmazni. Természetesen nem akarom a te hibádnak beállítani, hogy
nincs a tuhun jelenleg működő megoldás a rajzolási szabályok
rendszerszintű módosítására.

Belementem, hogy magánlevelezést folytassunk e témáról - kizárólag
azért, hogy hátha sikerül *gyorsabban* előrelépni egy szabálytervezet
összeállításában.
Mivel ez nem sikerült, nem a tervezetet, hanem a vakvágányra futásunkat
osztom meg a tuhu közönségével: az alább olvasható teljes levelezést
bemásolom a fórumra.
Nem szeretném, ha úgy vélnéd, hogy hátba támadlak, ezért külön felhívom
a figyelmed arra, hogy hozzászólásomban kifejezetten ellenjavallani
fogom a pdf-ben olvashatóak alkalmazását, különös tekintettel a névrajz
poikra.
Szorgalmazni fogom azt is, hogy mielőbb kerüljenek megoldásra azok a
problémák, amelyekről értekeztünk.

Üdv,
Trackman

> 2013.07.01. 17:43 keltezéssel, Alnibell írta:
> *Szép napot, Trackman!*
> Kérlek, ne haragudj meg rám, hogy kertelés, finomkodás nélkül írom az
> alábbiakat!
> Azon túl, hogy a korábbi álláspontodat feladva, netán feledve,
> ellentmondásba keveredtél önmagaddal, már ami a település jellegű POI-k
> darabszámát illeti, a leveledben leírt bővítés szöges ellentétben van az
> egyszerűsítési, egységesítési törekvésemmel, és mint ilyen, alapból nem
> tudom támogatni a legkisebb mértékben sem.
> De nem csak a típuson belüli - szerintem teljesen indokolatlan -
> bővítéssel szemben van elvi kifogásom, hanem a bővítés indoklásával is.
> A jogállást tekintve semmi érdemi különbség nincs két vagy több, a KSH
> terminológiában egyéb belterületként meghatározott településrész között.
> Ezért nincs érdemi indok arra, hogy - úgymond a turisták jobb
> eligazodását segítendő - kétféle POI-val jelöljük az azonos jogállású
> területeket, azok anyatelepüléshez viszonyított elhelyezkedése alapján.
> Semmi hibát nem követünk el akkor, ha egy-egy nagyobb település
> kerületeinek POI megfeleltetésére a város POI-t használjuk fel.
> Leginkább azért nem , mert gyakorlatilag csak egy városnál égetően
> fontos a kerületenkénti azonosíthatóság, és ennek megfelelően a
> kivételből nem csinálhatunk általános szabályt. (Nézd meg az OMP réteges
> Garmin kimenetét, ott lehet keresni már a Budapest XXI. kerületét, de a
> többit nem, továbbá még a névrajz POI-ként felvitt városrész nevek is
> kereshetők a /Földrajzi helyek/Szárazföld /kategórián belül.)
> Ez utóbbival kapcsolatban már írtam: nincs kifogásom az ellen, hogy a
> városrészek jelölésére egy új POI típus kerüljön bevezetésre, de csak
> akkor, ha a kerehetőségük, a célpontként történő alkalmazhatóságuk
> biztosított és legalább olyan módon jelennek meg a térképünkön, mint a
> névrajz POI-k. Ezt tartom, de csak azért, hogy a városrészek ne
> ugyanabban a kategóriában legyenek, mint pl. a hegycsúcsok, nevesített
> rétek, árkok, stb.
> Én pedig véglegesen költerület-nek tekintem a jelenleg még település
> nevű 0xa000 POI-t . Nem tudok olyan település jellegű földrajzi egységet
> elképzelni, amely ne férne bele az általam javasolt kategóriák egyikébe.
> Magyarán nem látom indokát egy speciális település POI típus fenntartására.
> Üdv.: /alnibell/
>


>> Trackman írta:
>>
>> Szia,
>>
>> sajnos nem volt annyi időm, mint szerettem volna, ezért lehet, hogy
>> valami elkerülte a figyelmemet, de azért remélem, továbblépés lesz, amit
>>
>> írok.
>> Egyelőre csak a poitípusokra koncentrálok, tkp a modelledet bővítem.
>> Aztán folytassuk a többivel, ha van még kérdés.
>>
>> A "(most is az)" szöveggel jeleztem, ha az adott kód már most is létezik
>>
>> és jelentésében nincs változás.
>> [] jelek között egy-egy példa olvasható.
>>
>> 0xa000 - település (most is az) -- ez megmarad, de nem üzemszerű
>> használatra, csak ha felmerül olyan típus-szerűség, ami nem fér a
>> kurrens rendszerbe. Ezt lehet ideiglenesen használni, míg konkrét új
>> típus nem születik, vagy egyeztetés alapján mégiscsak be nem fér egy már
>> létező típusba.
>> 0xa001 - megyeszékhely (most is az) [Miskolc]
>> 0xa002 - megyei jogú város (most is az) -- ami nem megyeszékhely
>> [Dunaújváros]
>> 0xa003 - város (most is az) [Érd]
>> 0xa004 - nagyközség (most is az) [Szirmabesenyő]
>> 0xa005 - község (most is az) [Bükkszentkereszt]
>> 0xa006 - településrész -- azon KSH szerinti 'egyéb belterület' jellegű
>> egységek, amelyek az adott település központi belterületével határosak,
>> azzal összetartozóak, vagy más ugyanilyen belterületi egység által
>> "közvetítetten" alkotnak egy területi egységet a központi belterülettel
>> (tulajdonképp városrészek) [Pereces]
>> 0xa007 - külső településrész -- azon KSH szerinti 'egyéb belterület'
>> jellegű egységek, amelyek földrajzi értelemben nem alkotnak egységet a
>> településsel (jellemzően nemrégen külön települések voltak) [Ómassa]
>> 0xa008 - külterület -- a KSH adatbázisa alapján külterületként
>> nyilvántartott egységek [Jávorkút]
>> 0xa009 - kerület [XXI]
>> 0xa00a - városrész -- a köznyelvben használt, de a KSH által nem ismert,
>>
>> településen belüli területi egységek elnevezései [Csepel] [Királyerdő]
>>
>> Utolsónál kompromisszumosan összemostam nem egy szinten levő egységeket is.
>> A 0xa007 és 0x00a típusok nevét nem feltétlen gondolom "véglegesnek",
>> találjunk rövid, de a fentieknél találóbbat, ha van ilyen.
>>
>> És nem látom megoldottnak a tanyákat. Az omp-n pl. van külön tanya
>> típus. Az omp-s átvételkor bénázunk, pl. a "tanya" szót is keresgéljük a
>>
>> névben, hogy a mi tanya típusunkat be tudjuk állítani - ez így igen
>> gázos megoldás. Hasznos lenne egy tanya típus a tuhun is.
>>
>> Ez 5 új típus, ha a tanyát is beleértjük.
>> ?
>> Üdv,
>> Trackman


>>> Alnibell wrote:
>>> Szervusz Trackman!
>>> Igyekszem gyorsan reagálni, mert egyrészt türelmetlen vagyok,
>>> másrészt tartok tőle, hogy kifutok az időből.
>>> Rögtön az elején leszögezem, hogy csak a meglévő eszközöket,
>>> lehetőséget vettem figyelembe a javaslatom kidolgozásakor, amelyet
>>> végülis senki nem észrevételezett a TuHu közreműködői közül. Így
>>> kellett cselekednem, mert arra már több esetben rá kellett jönnöm,
>>> nem az számít, hogy mit, hanem hogy azt ki mondja. Esélyem se lett
>>> volna egy újabb POI-típust bevezettetni, volt korábban próbálkozásom
>>> ilyesmivel, amikor azt javasoltam, hogy a települések fontos
>>> közösségi létesítményei (sport- és multifunkcionális csarnokok)
>>> kapjanak a súlyuknak, a látogatottságuknak megfelelően szembetűnő
>>> POI-t. Számtalanszor jeleztem, eredménytelenül.
>>> Tehát, ha úgy érzed, hogy el tudod érni K.A-nál egy új, egyéb
>>> kategóriájú, mondjuk *0xae07* kóddal és *városrész* névvel egy új
>>> POI felvételét a választék listába, nincs semmi kifogásom az ellen,
>>> hogy ne a *névrajz* POI-val jelöljük a nevesített városrészeket,
>>> hanem ezen újjal, de úgy, hogy a megjelenítéskor - eksősorban a
>>> Garmin kimeneteken - a névrajz POI-khoz hasonlóan jelenjenek meg.
>>> De ehhez még később fűzök hozzá mást is a vonatkozó pontnál.
>>> Továbbá fontosnak tartanám, hogy a Budapest területén a jelenleg
>>> található összevisszaságot valahogy megszüntessük, és ehhez a
>>> javasolt, de írhatnám azt is, hogy a TuHu közössége által
>>> hallgatólagosan jóváhagyott megoldás elfogadható eredménnyel
>>> kecsegtet. Azt sem tartom lehetetlennek, hogy a városon belüli,
>>> városrészeket jelölő névrajz POI-k gyorsan, pár billentyűleütésre
>>> átkerüljenek a fentebb javasolt városrész POI-k közé. De akár
>>> személyesen is átpakolom egyenként azokat, ha nincs más lehetőség,
>>> van már gyakorlatom az ilyesmiben.
>>> A legfőbb ellenérv ezzel - szerintem - kilőve.
>>> ad. #1. és #2.)
>>> Örülök, hogy végre van valami, amivel egy hozzáértő is egyetért!
>>> ad. #3.)
>>> A KSH lakóhely nyilvántartása szerint mindkettő, azaz
>>> Miskolc-Pereces és Miskolc-Ómassa egyéb belterület kategóriájú.
>>> Az, hogy az egyik, nevezetesen Pereces területeileg határos a
>>> központi belterülettel nem jelenti azt, hogy ne lehetne önálló
>>> felülettel és POI-val azonosítani. A javaslatom részben pont arra
>>> irányult, hogy valamelyest kifejezésre juttassuk a térképünkön az
>>> ábrázolt települések és részeik jogállását. (Azt csak mellékesen
>>> említem, hogy Pereces, mint Diósgyőr hajdani városrésze Diósgyőrrel
>>> együtt 1950-ben került Miskolc közigazgatása alá, azaz a kérdés
>>> szempontjából semmi különbség nincs Pereces és Ómassa között.)
>>> A keresés lehetősége az egyéb belterületi egységeket jelölő
>>> településrész POI-kra könnyen megteremthető lenne, némi kitérővel
>>> most is megoldható.
>>> Adatvesztést egyáltalán nem okoz, a polygonok nevesítése csupán a
>>> településrész POI név átadási funkcióval való ellátását követelné
>>> meg. (Ezt az OMP saját hatáskörben rendezni tudja.)
>>> ad. #4.)
>>> Soha nem gondoltam arra, hogy egy-egy önálló épület polygonnal
>>> legyen ábrázolva. Ezért aztán a különálló őrházak, stb csak POI-t
>>> kapnának. Viszont problémamentesen kitölthető ezek Telepules=
>>> paramétere, amennyiben a KSH adatbázisában külterületi
>>> lakóegységként szerepelnek.
>>> Amennyiben viszont relatív nagy kiterjedésű a nevesített külterület,
>>> akkor a hozzárendelt felület szerkesztésekor el kell (tudni)
>>> dönteni, hogy az adott külterületi területegységnek mi az elsődleges
>>> funkciója, és annak megfelelő kódú fülettel kell(ene) ábrázolni.
>>> Hogy ez szubjektív lenne? Részben nyilván, de a helyismerettel bíró
>>> meg tudja állapítani, hogy pl. a területen lévő, mondjuk 4-5
>>> lakásnak/lakóháznak vagy az állattartó vagy egyéb telepnek van-e
>>> nagyobb súlya a funkciók sorrendiségében.
>>> A tanyák kérdése korábban már rendeződött. Azok nem egyedileg, hanem
>>> csoportosan vannak egy-egy külterületi egységbe vonva, de jelölve
>>> mindegyik csak egy épülettel van.
>>> ad. #5.)
>>> Ha akarom, a típusleírás végén szereplő stb-be minden további nélkül
>>> beleérthető lenne a városrészek neve is.
>>> Az, hogy összevisszaság van e téren, nem lehet vitatni. A keresés
>>> ezekre közvetlenül most sem lehetséges, de megoldható. A városrész
>>> névrajz POI-k szétválasztása a többitől nem lehetetlen, hisz' ezek
>>> érvényes Telepules= paraméterrel rendelkezhetnek.
>>> És csak emlékeztetőül:
>>> településrész POI-t az egyéb belterületi területegységekkapnának,
>>> önálló felülettel,
>>> névrajz POI-t pedig a köznyelvben használatos nevű városrészek
>>> kapnának, de a területük kiterjedésének jelölése nélkül.
>>> ad #6.)
>>> Az alapvetésből kiindulva jelenleg nincs mód arra, hogy egy
>>> összefüggő felület jelölje Budapest egészét, fölötte a kerületek
>>> területeivel, majd azokon felül még a nevesített városrészek
>>> területeivel. (Az utóbbiak kapcsán: egyrészt nem ismert a pontos
>>> határvonaluk, másrészt néhány két kerületet is érint, ráfedve azok
>>> határvonalára.)
>>> Ezért sokkal egyszerűbbnek és járhatóbbanak tűnik, többek között a
>>> keresés szempontjából is, ha mindegyik kerület kap egy város POI-t
>>> és a hozzátartozó egy- vagy többelemes felületet. (És itt álljunk
>>> meg egy kicsit. Egy másik alapvetés szerint nem a közigazgatási
>>> határ által körbevett területet, hanem a beépített területet
>>> ábrázoljuk. Ezért léteznek az üres foltok. Ezek megszüntetése
>>> gyakorlatilag csak igen nagy ráfordítással lenne lehetséges. Az
>>> iparterület viszont minden további nélkül beleérthető a beépített
>>> területbe. Az viszont más kérdés, hogy ezt hogyan jelöljük? Ha
>>> ugyanis az iparterületen belül, az üzemek között van egy közterület
>>> jellegű utca, akkor ott bizony meg kell(ene) szakítani az
>>> iparterület polygonját, hogy az adott utca a település-polygonra
>>> essen, hogy ezáltal kereshető legyen.)
>>> Tekintettel arra, hogy összesen 23 kerületről van szó, semmi nem
>>> indokolja, hogy ezen néhány egyedért több település POI is
>>> kényszerűen cipelje az érvényes adattartalom nélküli paramétert.
>>> Legyen visszafelé érvényes a szabály, amely szerint itt a 23 kerület
>>> a kivétel, amelyek város POI-jai több jellemzőt együtt hordoznak a
>>> nevükben.
>>> ad. #7.)
>>> A jelenlegi eszközkészlet következetes alkalmazásával csak
>>> javítanánk a jelenlegi állapoton. A kivétel jelleg miatt megint csak
>>> nem látom értelmét egy új alá-fölérendeltségi szint kialakítását.
>>> Bőven megfelel a névrajz vagy a városrész POI-k megnevezéséhez a
>>> hivatalos városrész lista szerinti név. Ez Budapest vonatkozásában
>>> rendelkezésre áll.
>>> A TuHu fórumán jeleztem, hogy a XXI. kerületet, azaz Csepelt a
>>> javasolt megoldás szerint átalakítom.
>>> Ez azt fogja eredményezni, hogy a jelenlegi felületek összevonásával
>>> lesz két jelenlegi megyeszékhely típusú felület, de valójában ezek
>>> lakó- és/vagy intézményterület felületek. Az egyik az ún központ
>>> belterületet, a másik a Belsőháros nevű külterületet fogja jelölni,
>>> amelynek alapvetően lakóhely funkciója van. Továbbá szerepelni fog
>>> rajta összesen 13 db névrajz POI a hivatalos városrész nevekkel.
>>> Üdv.: alnibell


>>>> Trackman írta:
>>>> Szervusz Alnibell,
>>>> átnéztem pontról pontra a leírást, és mindegyikhez hozzáfűztem, hogy
>>>> mind omp-s, mind tuhu rajzolói szemszögből hogyan látom az adott kérdést
>>>> (lásd a levél végén). Annyi időt sajnos jelenleg nem sikerült
>>>> ráfordítanom, hogy ahol nem értettem egyet a leírásoddal, ott konkrét
>>>> megoldást javasoljak, ez egy további lépés lehet.
>>>> Hadd fejezzem ki előre sajnálatom, hogy több ponton nem értek egyet a
>>>> leírással, mint igen. Az egyet nem értésemnek koncepcionális oka van: a
>>>> leírtakban rendszerezni próbálod a "településszerű" objektumokat, de
>>>> csak a *meglevő eszközökkel*. Pedig azokkal nem lehet ezt megoldani,
>>>> csak másvalaminek a rovására, a pdf-ben a névrajz poik használata
>>>> szenvedi el a legnagyobb kárt.
>>>> Összességében tehát nem tartom jónak, omp-s szempontból nem tartom
>>>> elfogadhatónak a leírást ebben a formában.
>>>> De hadd próbáljak konstruktív lenni:
>>>> Az alap probléma, hogy kevés a típus (némelyiknek meg rossz a neve), és
>>>> ezen nem tudunk változtatni. Azt mondom, próbáljunk meg ezen mégiscsak
>>>> változtatni. Gondolkodjunk szabadabban, készítsünk egy olyan leírást,
>>>> ami használ még nem létező típusokat is, és megoldást ad azokra a
>>>> problémákra, amelyket lentebb kifejtek.
>>>> Ha ez megvan, akkor abból kiderül, milyen új típusokra, stb van szükség.
>>>> Ezzel megkeresem Kolesár Andrást, hogy árulja el, hogyan tudok a
>>>> mapeditbe (és a db-be még szükséges helyekre) új típust tenni. Látok
>>>> esélyt rá, hogy nem áll ellent, hisz pl. a mapeditet én is
>>>> keresztül-kasul átírtam már, nem egy ördöngősség új típust tenni bele.
>>>> Várom véleményed,
>>>> üdv,
>>>> Trackman
>>>> U.I.: a pdf egyes pontjai:
>>>> 1) ok
>>>> 2) ok
>>>> 3) nem ok: "Miskolc Ómassa egyéb belterület" és "Miskolc Pereces
>>>> egyéb
>>>> belterület" nem összemosandóak egy típusba. Előbbi külön település
>>>> (volt), földrajzilag különálló egység, utóbbi egy városrész önálló
>>>> névvel, fizikailag a központi belterülettel határos. Ezek összemosása 1)
>>>> adatvesztés (nem ksh, hanem földrajzi, térképadatbázis 'nézetből'), 2) a
>>>> "keresés jellegű" funkciókat zavarják (nem lehet pl. városrészre
>>>> keresni), 3) a polygonelnevezést gátolja, de legalább nehezíti
>>>> (előbbinél szükséges a felületelnevezés, utóbbinál nem).
>>>> 4) nem ok:
>>>> -"jellegüknek megfelelő felülettel és POI-val" : szubjektív és / vagy
>>>> nem/nehezen érthető. "Miskolc Vasúti őrházak
>>>> külterület" - ez ház poit
>>>> kap, mert őrházak?
>>>> -"kivéve azok, amelyek alapvetően lakóhelyül szolgálnak" : szubjektív:
>>>> alapvető lakhely egy motel egy gondnokkal? Egy erdész? Egy tanya egy
>>>> házzal? Egy tanya több házzal? ....?
>>>> 5) nem ok: a névrajz poi szerepe egész más, a mapedit magyarázat szerint
>>>> "nevesített elágazás/csomópont, rét, nyereg, stb.", nagyrészt így is
>>>> használják (egy gyors rápillantás alapján) . Ezzel a területi egységek
>>>> összemosódnának pl. a rétekkel, ami 3. pontban említett problémákat
>>>> okozza, csak itt a 3)-as pontál még sokkal különbözőbb dolgokat mosnánk
>>>> össze.
>>>> 6) teljesen pontosan lefektetésre kellene kerüljön, hogy egy Budapest
>>>> jellegű városnál pontosan milyen egységeket milyen polygonokkal
>>>> ábrázolunk (Bp egy plygon v. egy kerület egy polygon, v. egy kerület
>>>> tovább osztható?), utána lehetne ezt a 6)-os pontot korrektül megírni.
>>>> A "beépített területeihez" kitétel pontosításra és/vagy javításra
>>>> szorul. Mert pl. lehet egy iparterület (nem beépítettnek minősülő)
>>>> polygonban is egy utca, és ha ez nem kap a ponttól nevet, akkor ez az
>>>> utca nem lesz kereshető (illetve a megfelelő helyen megtalálható).
>>>> "Budapest, XY kerület" - nem szerencsés több tulajdonságtípus egy mezőbe
>>>> (név) való összefűzése. A település neve Budapest, a kerületnek
>>>> valószínűleg külön mező kellene.
>>>> 7) nem ok: ugyanazért probléma, mint az 5) pont. Ha ponttípusokban
>>>> gondolkodunk, akkor az ilyen neveknek külön típus kellene, sőt vszeg
>>>> több is (hierarchia: Csepel -> [Királyerdő,Csillagtelep,...])


Bejelentkezés név:  jelszó:   tárolás [regisztráció]

Felhasználónevedet és jelszavadat a geocaching.hu oldalon is használhatod!

[ kezdőlap ] [ térkép ] [ + felmérések ~ ] [ + útvonalak ~ ] [ + poi ~ ] [ belépés ] [ faq ] [fórum] [email]

A weboldal működése és tartalma folyamatos fejlesztés alatt áll, köszönettel vesszük az észrevételeket a fejlesztési ötletek oldalon.
A turistautak.hu-ra feltöltött track-eket és a letölthető térképeket, azaz térképi adatbázist az ODbL licencnek megfelelően bárki használhatja.
Minden egyéb anyag előzetes írásbeli engedély nélkül csak magáncélra használható fel. jogi tudnivalók