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

Kolesárhozzászólásai | válasz erre | 2014.06.06 11:10:07 (68451)
"A megnyitott állományban annyi illesztési hibát láttam, hogy azok eleve elvették a kedvem a rendbetételüktől. Az igaz, hogy mindegyik "félkész" minősítésű."

Inkább kérdezz vagy fogalmazz óvatosabban, mert téves kijelentéseiddel magadról állítasz ki bizonyítványt.

A "félkész" kifejezés (eredetiben: "incomplete") nem félbehagyott szerkesztést vagy illesztési hibát jelent, hanem azt, hogy a kapcsolat tagjai közül nincs mindegyik letöltve. A kapcsolatok lehetnek felületek, jelzett túraútvonalak vagy akár a közösségi közlekedés járatai. A tagjai többnyire vonalak, de lehetnek pontok is (pecsételőhely, megállóhely).

Példa Győrből: a Rába vízfelülete 12 elemből áll (körülbelül a Marcal torkolatáig), 11 vonal határolja kívülről, egy zárt vonal pedig a Radó-sziget körvonala, ami lyuk a felületben.

Rába
http://www.openstreetmap.org/relation/1477817

Amikor letöltöd mondjuk a Radó-szigetet, akkor lejön a körvonala, meg egy-két további határvonal-darab is, viszont nem jönnek le azok a vonalak, amelyek egyáltalán nem esnek bele a letöltött területbe. Kérheted ezeknek a letöltését is: kattints a kapcsolatra és válaszd a "Tagok letöltése" pontot, ekkor lejön az összes tag, kirajzolódik a teljes felület és eltűnik a "félkész" jelölés. Ezt akár az összes kapcsolatra egyszerre is megteheted: jelöld ki az összeset a kapcsolatok listájában és így kérd a letöltést.

Az elsőre furcsának tűnő jelenség tehát nem hiba, sem a szerkesztőprogramban, sem az adattartalomban. Azért alkották meg így, hogy a rendszer képes legyen nagy elemszámú, hosszan vagy nagy területen húzódó kapcsolatok kezelésére. A mapedit éppen ott botlik meg, hogy mindenképpen egyben akarja kezelni az objektumokat.

Remélem, hogy sikerült érthetően bemutatnom a kapcsolatok kezelését. Ha nem sikerült, kérlek mutass rá a vélt hibára képernyőképpel, osm azonosítóval vagy más módon azonosítva a helyszínt.
[előzmény: (68449) alnibell, 2014.06.06 10:31:12]

alnibellhozzászólásai | válasz erre | 2014.06.06 10:31:12 (68449)
Nem olvasom át újra, nincs szükség rá, most már számomra tiszta a kép. Éppen ezért nyilatkoztam határozottan arról, hogy nem kívánom használni a JOSM-ot szerkesztő ezközként.

Azt a megoldást még el tudnám fogadni, hogy a jelenlegi adatbázis struktúra változatlanul hagyása mellett, egy köztes applikáció szerkesztő interfész használatával, a JOSM-ot használni kívánók hozzáférhessenek az adatbázisokban tárolt adatokhoz. De ezt is csak akkor, ha bármikor bárki módosíthat bármit lehetőség ki van zárva és a feltöltsét követően a MapEdit alatti szerkesztés és feltöltés a megszokott módon végezhető.

Ellenkező esetben legfeljebb bekövetkezik az az állapot, hogy végleg kiszorulok - többek megelégedésére - a szerkesztői körből és így fórumoznom végképp nem lesz értelme - szintén örömmel töltve el néhányakat -, csupán ismét felajánlhatom licitre a 60CSx-emet.
És csak egy megjegyzés Győr vonatkozásában. A megnyitott állományban annyi illesztési hibát láttam, hogy azok eleve elvették a kedvem a rendbetételüktől. Az igaz, hogy mindegyik "félkész" minősítésű.
[előzmény: (68448) Kolesár, 2014.06.06 09:57:50]

Kolesárhozzászólásai | válasz erre | 2014.06.06 09:57:50 (68448)
"a JOSM pl. nem tudja letölteni Győr város területének egészét"

A JOSM le tudja tölteni Győr egészét, csak az osm szervere a magas adatsűrűség miatt visszautasítja a nagy területű lekérést. Több részletben letölthető, ezek a JOSM-ben egyesülnek.

Egy egész megyeszékhely egyben szerkesztésére általában nincs szükség. Hosszú nyomvonal szerkesztésekor van lehetőség arra is, hogy a vonal mentén töltse le az adatokat valamilyen távolságig, magától kiszámolja a téglalapokat és letölti az adatokat. Mindez átívelhet az osm esetén országhatáron is, vagy a turistautak.hu esetében a tájegységek határán is.

Egymástól elszigetelt területek egyidejű szerkesztésénél, mondjuk hegycsúcsok magasságának rendbetételénél nincs szükség a teljes terület letöltésére, csak a szerkesztések szűkebb környezetére. Próbáld ki magad is: töltsd le Dobogókőt, a Zengőt, Írott-kőt egymás után ugyanarra az adatrétegre. Ilyet a turistautak.hu jelenleg nem tud.

Ha a turistautak.hu saját osm adatbázisszervert üzemeltet, akkor a letöltési korlátokat maga szabhatja meg, úgy letölthetsz sokkal többet is.

"Továbbá azt kellett megállapítanom, hogy a mozgatás, nagyítás határozottabban jobban akadozott, mint a MapEdit alá behívott teljes tájegység estében."

Elővettem az a gépemet, amit a legelső geocaching versenyen használtam 12 évvel ezelőtt: http://www.geocaching.hu/versenykepek/05110064.jpg

Windows XP van rajta, akkori telepítés, tehát nagyon nem friss rendszer. Pentium III processzor 733 MHz-el, 384 MB memóriával. A mapedit pöccre indul, de Zalát 105 másodperc alatt nyitotta meg a nyomvonalakkal együtt. A JOSM 15 másodperc alatt indul, az 50 négyzetkilométeres szerkesztési területet 10 másodperc alatt nyitja meg nyomvonalakkal együtt.

Annak ellenére, hogy ez egy szélsőségesen régi gép, gyorsabban el lehet vele kezdeni a szerkesztést és egyáltalán nem lassú. Szívesen megmutatom bárkinek élőben is.

"a két szerkesztő alkalmazás (JOSM, MApEdit) valamelyikének eltérő helyeken történő futtatása megengedhető-e, képesek-e külön-külön az adatbázis tartalmak bővítésére, módosítására?"

Akár a turistautak.hu jelenlegi adatbázisához is készíthető osm api, amivel váltás nélkül használható szerkesztésre a JOSM a mapedit mellett, az adatbázis és a kimenetek változatlanul hagyásával. Ez még kisebb lépcső a tegnap említett köztes megoldásnál, szerintem ez is gazdaságtalan, de lehetséges.

"az ugyanúgyra vonatkozó kérdés akkor is, most is megválaszolatlan maradt"

Kétértelmű az "ugyanúgy" szó. Ha azt mondom, hogy a BKK bérletemmel ugyanúgy tudok utazni a metrón és a buszon, akkor arra értem, hogy mindkettőre érvényes. Ennek ellenére másképpen szállok fel a metróra mint a buszra, másképpen ellenőrzik a bérlet érvényességét, más sebességgel jutok el a célhoz.

A szerkesztőprogramnak ráadásul nincs közvetlen kapcsolata a kimenetekkel, ezt megírtam az imént, olvasd el kérlek újra azt a hozzászólást, amire válaszoltál.
[előzmény: (68447) alnibell, 2014.06.06 08:21:34]

alnibellhozzászólásai | válasz erre | 2014.06.06 08:21:34 (68447)
Megtettem a próbát, a 7-es verziójú Java-t nem igénylő JOSM elindult a gépemen. Nem 10 percig, egy kicsit tovább próbálkoztam vele, és arra a következtetésre jutottam, hogy nem fogom használni.

Sebesség adatok:
A JOSM szerkesztői felület felépítése nálam ~23 sec, ugyanez a MaPEdit estében ~2-3 sec.
A MapEdit képes fogadni pl. a Bakony tájegység egészét, a mellékleteivel együtt, míg a JOSM pl. nem tudja letölteni Győr város területének egészét vagy Tapolcát a Haláppal, Szent György-heggyel és a Badacsonnyal határolt területtel együtt. (A tapasztalatom szerint ~1,5 MB-nál kisebb adatmennyiség letöltése engedélyezett, efölött - hiába írja ki a területválasztó képernyő alján azt az üzenetet, hogy "Letöltési terület mérete rendben, a szerver számára elfogadható, a letöltési próbálkozás a következő hibaüzenettel megszakad: "The OSM server 'https://api.openstreetmap.org/api/0.6/' reported a bad request. The area you tried to download is too big or your request was too large. Either request a smaller area or use an export file provided by the OSM community.
Azaz minél sűrűbbé válik az adattartalom egy térségben, annál kisebb terület választható ki belőle a feldolgozás alapjaként. (Ez ugyan logikus, de valószínűleg sokszor lehet a folyamatos szerkesztést akadályozó tényező.
Ezek így együtt, a feldolgozásra le- majd a szerkesztőbe betölthető adatmennyiség 2 nagyságrendű eltérése miatt, nem összemérhetővé minősítik a korábban jelzett mért időadatokat.

Továbbá azt kellett megállapítanom, hogy a mozgatás, nagyítás határozottabban jobban akadozott, mint a MapEdit alá behívott teljes tájegység estében.

De ezek csak kezelési gondként jelentkeznek, alapvetően nem ezek a részemről történő elutasítás okai.

A kérdéseim veleje az volt, hogy a JOSM-ra történő átállást követően ugyanúgy létre lehet-e hozni ugyanazokat a térkép kimeneteket, mint eddig? Majd kiegészítésül az, hogy a két szerkesztő alkalmazás (JOSM, MApEdit) valamelyikének eltérő helyeken történő futtatása megengedhető-e, képesek-e külön-külön az adatbázis tartalmak bővítésére, módosítására?

Az eredeti 1.) kérdésemre egy rövid igenválaszt kaptam. Azaz azt, hogy elő lehet állítani a JOSM-ból közvetlenül az adtbázisba feltöltött adatokból ugyanolyan állományokat, mint eddig, de az ugyanúgyra vonatkozó kérdés akkor is, most is megválaszolatlan maradt.
Aztán átgondolva a vázolt adatkezelési metódusokat és a két szerkesztő alkalmazásnál használható be- és kimeneti fájltípusokat, arra következtetésre kellett jutnom, hogy az azonos kimenetek előállításának metódusa nem lehet egyforma. Alapvetően azért nem, mert a két adatbázis-hármas eltérő felépítésű, a külön, illetve közvetlenül feltöltésre kerülő adatok más-más szerkezetű adattáblákat követelnek meg.

Ebből kiindulva, teljesen jogos a korábbi 2-es és 3-as kérdéscsokor is.

Végül, nagyon nincs ínyemre, hogy a szerintem legfontosabbnak tartott kérdések figyelmen kívül hagyásával, immár többedszerre is félrevezettél. Az utolsó bekezdésben jelzett lehetséges - egyelőre csak esetleges - megoldások már csak amolyan kármentő jellegűek, mindenestre a lényegre rámutatnak.

[előzmény: (68446) Kolesár, 2014.06.06 07:16:59]

Kolesárhozzászólásai | válasz erre | 2014.06.06 07:16:59 (68446)
"Ellenőrzési lehetőség nélkül tudomásul veszem azt az állítást"

Kérdeztél, megválaszoltam. Ha ellenőrizni tudnád magad is, nem kellett volna megkérdezned. Ha bizonyítékot szeretnél az állítás igazolására, az egyesület megkérhet engem vagy bárki mást tesztkörnyezet kialakítására, amelyen bemutatható a tervezett működés és a változatlan hardverigény.

"A kérdés jogos, ugyanis tudtommal a JOSM legalább a Java 7-es vagy annál magasabb fokú változatát igényli, és nekem pl. a 6-os verzió frissítéseinek egy részét is törölnöm kellett korábban, hogy egyáltalán használni tudjam a MapEdit-et."

JOSM-et akartál írni, ugye? Amint Báthory Peti azóta megírta, ha gondod van a Java verzióváltással, akkor használhatod a Java 6 alatt működő kicsivel korábbi 7000-es változatot. Ezt tettem Mac OS X 10.6 alatt én is.

"nem érvényes belépési pont, meg hiányzó dll"

Ezek tipikus windows hibaüzenetek, miközben itt Java környezetről beszélünk. A JOSM Java alatt fut. Nem szeretném lesöpörni az asztalról a Java telepítésének és futtatásának problémáit, de fontosnak tartom megjegyezni, hogy a hibákat nem a JOSM okozza.

Ugyanez igaz a mapeditre is. Ha olyan állapotban van a windowsod, hogy nem indul el rajta, akkor nem a mapedit javítandó, hanem a futtatókörnyezet. A JOSM ebből a szempontból nem szűk keresztmetszet, sőt jelentősen tágabb környezetben futtatható. Amint már többször elhangzott, mindenhol működik, ahol van Java: mac és linux rendszereken is.

Személyes tapasztalatom az, hogy a gépek 80%-án a friss jar csont nélkül elindul. Néhol nincs Java, gyors letöltés és telepítés megoldja. Egy egyetemi gépen küzdöttem a legtovább, ahol nem volt Java, telepítés után a JOSM elindult, de nem töltött le és fel, mert azt mondta, hogy az SSL tanúsítvány még nem érvényes. A rendszerdátum ugyanis 2010 volt, amit csak a rendszergazda volt jogosult beállítani.

A fórumon meghirdetett turistautak.mapcss letöltéseinek naplójából készítettem egy kivonatot: grep turistautak\.hu\.mapcss | grep -o '"\(JOSM.\+\)"' | sort -u

"JOSM/1.5 (4878 en) Java/1.6.0_31"
"JOSM/1.5 (7000 en) Mac OS X 10.6.8 Java/1.6.0_65"
"JOSM/1.5 (7000 hu) Linux Ubuntu 12.04.4 LTS Java/1.7.0_55"
"JOSM/1.5 (7182 en) Windows Vista 32-Bit Java/1.7.0_55"
"JOSM/1.5 (7182 hu) Windows 7 32-Bit Java/1.7.0_51"
"JOSM/1.5 (7182 hu) Windows 7 32-Bit Java/1.7.0_55"
"JOSM/1.5 (7182 hu) Windows 7 32-Bit Java/1.7.0_60"
"JOSM/1.5 (7182 hu) Windows 7 64-Bit Java/1.7.0_55"
"JOSM/1.5 (7182 hu) Windows XP 32-Bit Java/1.7.0_60"

Amint láthatod, kilenc különböző konfiguráción működött a JOSM, két kivétellel Java 7 volt rajtuk. Egyedül te jelezted hogy problémád van vele. Hol akadtál el, volt hibaüzenet?

Ha továbbra is gondod van a Java környezet telepítésével, több megoldás közül választhatsz. Megkérhetsz valakit környezetedben, például szomszédot, számítógépboltos ismerőst, informatikust, rendszergazdát. A geocachinges csapatból is bizonyára találsz valakit. Hozzám is elhozhatod a gépedet.

"ahol szoftver oldali problémák miatt akadályokba ütközik a JOSM használata, ott a MapEdit alatti szerkesztés továbbra is mehet, szerkesztőként bármelyik használata megengedett"

Lehetséges írni apit osm adatbázishoz mp formátumú adatcserére, akár php-ben is. Szintén lehetséges kiegészíteni a mapeditet az osm formátumú fel- és letöltéssel. Véleményem szerint mindkettő gazdaságtalan megoldás lenne, mivel nagy fejlesztői kapacitást köt le, az eredményét pedig kevesen használnák.

Felhasználható viszont az iD webes szerkesztőfelület, ez is az osm eszközkészlet része. http://wiki.openstreetmap.org/wiki/ID
[előzmény: (68444) alnibell, 2014.06.05 23:09:59]

alnibellhozzászólásai | válasz erre | 2014.06.05 23:09:59 (68444)
Igazán nem értem, mi szükség volt erre?
Ha legalább az előző üzenetem utolsó mondata megmaradt volna az emlékezetdben a "billentyűkoptatás" megkezdése előtt, akkor nem szólítasz föl semmire. (Azt írtam ugyanis, hogy nem sikerült a telepítés.)
Fogadd el, hogy engem mindaddig abszulót nem érdekel a használatra felkínált alkalmazás egyetlen sajátossága sem, amíg nincs határozott és próbákkal igazolt válasz arra vonatkozóan, hogy a TuHu működése változatlan kimenetekkel ugyanúgy mehet tovább, valahol JOSM, másutt MapEdit alatt végzett szerkesztés esetében is, mint eddig.
[előzmény: (68442) BáthoryPéter, 2014.06.05 22:50:53]

BáthoryPéterhozzászólásai | válasz erre | 2014.06.05 22:50:53 (68442)
JOSM sebesség kérdést András elég alaposan kielemezte, én egy gyakorlati tapasztalatot fűznék hozzá. A nyúzós laptopom több, mint 10 éves, egymagos, 1GB RAM, valami piszok lassú HDD és Ubuntu. Az OSM meetupokon elég gyakran dugjuk rá kivetítőre, általában több órás JOSM szerkesztés után sem tűnik fel a hallgatóságnak, hogy bármi is lassú lenne (kivéve amikor a Chrome bekajálja a világ minden memóriáját).
Ismét csak azt tudom mondani, hogy billentyűzetkoptatás helyett szánj 10 percet a JOSM kipróbálására. Nem mondom, hogy legyél OSM szerkesztő, ehhez nincs közöm, de ha szakmai vitát szeretnél folytatni, a szoftver alapszintű ismerete elengedhetetlen.
[előzmény: (68439) alnibell, 2014.06.05 20:32:34]

alnibellhozzászólásai | válasz erre | 2014.06.05 20:32:34 (68439)
Elindult a terelés.
Nem vagyok kíváncsi, hogy kinek mi a véleménye a képességeimről. Feltettem a magyar nyelv szabályai szerint - sajnos egy "az" fölösleggel - megfogalmazva, egyelőre csak 3 kérdést, hozzájuk kapcsolódó alpontokkal. Akinek van valami fogalma az itteni adatfeldolgozásról, a felhasználóknak szánt térképek előállításának módjáról, annak nem lehet ómagyar nyelvezetű ez a pár kérdés.
Legközelebb akkor jelentkezz, ha a feltett kérdéseket a részetekről bárki is egyértelműen megválaszolta!

Maradjunk a legegyszerűbbnél. Mi kell a JOSM-hoz, hogy egyáltalán telepíthető és legalább olyan sebességgel futtatható legyen, mint a MapEdit most egy szerkesztő gépén? Ugyan, mi ebben a megfejthetetlen?

És hogyan lehet leragadni egy csupán példaként felhozott sajátosságnál, nem a működésére voltam kíváncsi?

Szóval, a kérdésekre várom a választ, nem a terelő szövegelést!
[előzmény: (68438) BáthoryPéter, 2014.06.05 17:55:28]

BáthoryPéterhozzászólásai | válasz erre | 2014.06.05 17:55:28 (68438)
András biztos megfejti az irományod, de én háromszori átolvasás után is csak azt látom, hogy fogalmad sincs azokról, amikről írsz. Nagyságrendekkel egyszerűbb lenne az élet, ha letöltenéd a JOSM-et, szánnál 10 percet arra, hogy betöltesz egy területet, kimented .osm fájlba, és megnézed szövegszerkesztővel, hogy mit hozott létre. Így még mindig elég messze vagyunk attól, hogy átlásd az egész folyamatot, de ebből már el lehet indulni.

Egy kérdés volt, amire egyértelmű választ tudok: az egykattintásos törlés egy eszköz, ha kiválasztod, tudsz vele törölni. Nekem még soha sem volt rá szükségem, nem éreztem hátrányát, hogy van valahol a menüben egy számomra fölösleges gomb. Tehát ne úgy képzel el, hogy ha rossz egérgombot nyomsz, letöröl random dolgokat.
[előzmény: (68437) alnibell, 2014.06.05 16:29:21]

alnibellhozzászólásai | válasz erre | 2014.06.05 16:29:21 (68437)
(De mennyivel könnyebb keverni ... Igen, azt is.)

Íme egy rövid kivonat a május 26-án indult eseményekről.
A közléseket nem én írtam, nem szó szerint jelzem azokat, de a lényeg bennük van.

- Hahó, régen találkoztunk, gyertek el egy érdekes találkozóra, van még hely!
Aztán a meghívás igazi indítékát firtató posztokat követően:
- Nincs szükségünk sem a TuHu adataira, sem a szerkesztőire, már most többen vagyunk itthon is.
Nem sok idő elteltével a nyilatkozat egyik fele devalválódott, ugyanis:
- Hiányzik a terepi felméréseket feldolgozó kapacitás, ehhez kellenének az itteni szerkesztők.
Majd egy újabb poszt-sorozat után:
- A kutyának nem kell a TuHu eddig munkája, hisz' megbízhatatlan, ellenőrzés nélkül nem lehet felhasználni.

És ugyan már kétszer tudtunkra adták, hogy itt minden úgy rossz, ahogy van, mégis megy tovább az agitálás az adatok újrafeldolgozásáért, meg a korábbi, állítólag pontatlan, szerkesztést végzők bevonásáért a munkába.

Mindezeket nem feledve, mégis hajlandó vagyok visszamenni a kályhához, mint ha csak most dobták volna be a reklámanyagot.

Tehát álljon itt, egy elsősorban a felhasználók érdekeit szem előtt tartó pár kérdés. Nem lesz teljeskörű, de ahhoz talán elég, hogy eldöntsük, az induló lépések megtételébe belevághatunk-e?

1.) Képes-e a JOSM a felmérési adatok szerkesztését követő olyan munkaközi állományt előállítani, amelyet felhasználva a jelenleg használt kimenet generáló applikáció ugyanazokat a kimeneti formátumokat elő tudja állítani, mint amelyek most készülnek?
1/a.) Ha nem - a sorrend nem az eleve elutasítást fejezi ki -, akkor
Van-e olyan közbülső megoldás, amellyel az a változatlan kimenet gyártás megvalósítható?
1/b.) Ha igen vagy van elérhető közbülső megoldás, akkor mi az a minimálisan szükséges hardver kiépítettség, amely biztosítja legalább azt a szerkesztési sebességet, mint a MApEdit alatti munkánál eddig megszokhatott a szerkesztő? Továbbá, az eddigi futtató szoftver környezet milyen módosítást, kiegészítést igényel a telepítéshez és persze az akadály- ill. váratlan kilépés mentes futtatáshoz?

2,) Amennyiben a JOSM állomány nem teszi lehetővé a megszokott kimenetek változatlan formájú előállítását, akkor
mi módon, milyen eszközökkel lehet megoldani a TuHu-nál már meglévő adatok újrafeldolgozását a korábbival legalább azonos színvonalon?
2/a.) Ehhez elégséges-e az 1./b.) pont kapcsán meghatározott hardver és szoftver konfiguráció?

3.) Mi lehet az újrafeldolgozás módja?
3/a.) Az újrafeldolgozásnak, a mostani állapotot figyelembe véve, mennyi a kalkulált átfutási ideje?

Egyelőre ennyi.
Ahhoz mindenképpen elégnek tűnik, hogy a rájuk adott reális, az esetleges problémákat nem elfedő válaszok alapján egyáltalán nekifogjunk a váltás előkészítéséhez.

Mert pl. az olyan sajátosság, mint pl. az egy kattintásos törlés amennyire előny, olykor meg éppen hátrány lehet. Ezzel csak azt akarom mondani, hogy csupán a sajátosságok bővebb volta nem indok a váltásra.

Szóval, most én visszamentem a kályhához, eközben nem szólítottam fel senkit semmire, nem küldtem el még kiegészítő megjegyzés formájában se máshová.

Nos?

[előzmény: (68436) Kolesár, 2014.06.05 12:49:02]

Kolesárhozzászólásai | válasz erre | 2014.06.05 12:49:02 (68436)
Bryan, látod így hígul fel a szakmai vita értelmetlen személyeskedő hozzászólásokkal.
[előzmény: (68435) alnibell, 2014.06.05 12:37:19]

alnibellhozzászólásai | válasz erre | 2014.06.05 12:37:19 (68435)
Nem cáfoltál Te semmit, egy jó hete erőlteted a hívek toborzását.
[előzmény: (68434) Kolesár, 2014.06.05 12:23:17]

Kolesárhozzászólásai | válasz erre | 2014.06.05 12:23:17 (68434)
Bocs, hogy zavartunk. Éppen azért van itt a legjobb helye, mert elsősorban a térképszerkesztőket érinti. Azt a döntést készítjük elő, hogy a turistautak.hu milyen eszközzel és milyen adatot szerkesszen a jövőben. Téged is érint a téma. Sajnálom, hogy ilyen terjedelmes lett, sok tévedésen alapuló hozzászólás érkezett, ezeket cáfoltam többnyire.
[előzmény: (68433) Bryan, 2014.06.05 12:10:34]

Bryanhozzászólásai | válasz erre | 2014.06.05 12:10:34 (68433)
Mi lenne, ha ennek az OSM-es vitának valaki illetékes létrehozna egy külön fórumot?!?
Az elmúlt közel egy hétben született közel 6-700 olyan hozzászólás, aminek szvsz vajmi kevés köze van ennek a topikhoz....
[előzmény: (68432) Bryan, 2014.06.05 12:10:02]

Bryanhozzászólásai | válasz erre | 2014.06.05 12:10:02 (68432)
Mi lenne, ha ennek az OSM-es vitának valaki illetékes létrehozna az külön fórumot?!?
Az elmúlt közel egy hétben született közel 6-700 olyan hozzászólás, aminek szvsz vajmi kevés köze van ennek a topikhoz....


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