turistautak.hu térképrészleteK+ jelzés GPS-szel
[ english
, petrot81 hozzászólásai
Online és letölthető térképek, Windows, Android és iPhone alkalmazások

új hozzászólás | témák listája

Összesen: 389 db hozzászólás

Lapozás: előző | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | következő


petrot81hozzászólásai | válasz erre | 2017.12.20 22:19:19 (1278)
A geoládák alkalmazásomban van útvonaltervező, bár ott a ládák közti utat a tervező adja és nem lehet módosítani. De távolságot pontosan kiír.
[előzmény: (1275) Frentzen, 2017.12.20 21:33:46]

petrot81hozzászólásai | válasz erre | 2017.12.20 15:29:51 (1273)
Az új API éles oldalra való másolása mikorra várható? A legutóbbi logos hibán kívül én más hibát nem találtam, bár nem is használom az összes végpontot. Amiket korábban használtam a régi API-ból, azok mind működnek szépen az újban is.

petrot81hozzászólásai | válasz erre | 2017.12.20 15:24:29 (1272)
Ki is próbáltam, működik, köszönöm! :)
[előzmény: (1271) gusty, 2017.12.20 15:12:08]

petrot81hozzászólásai | válasz erre | 2017.12.20 08:51:25 (1268)
Nálam továbbra is rossz. Kitöröltem minden logot (több egyéb log is volt tesztként), de továbbra is hozza.

Amit küldök:

userid: 97337
apikey: S43vf1nKTtAYNn1k (ez még él, nem kértem újat)
cacheid: 1732
cachepass: a helyes jelszó
logtype: 1
notes: blabla
logdate: 2017-08-21 12:34:56


Egyéb loggal működik, 1-es type-al jön az említett hiba.

A 1732-981 összetett index miből jön? Mi a 981? Ez lehet a probléma kulcsa. Valami benne maradhat a DB-ben log törlés után is.
[előzmény: (1267) gusty, 2017.12.19 22:42:30]

petrot81hozzászólásai | válasz erre | 2017.12.19 09:33:26 (1266)
Most néztem, hogy a korábbi működő postmanes tesztben is elhasal a log mentés, az említett hibával:
"SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1732-981' for key 'PRIMARY'"
[előzmény: (1262) petrot81, 2017.12.18 09:24:52]

petrot81hozzászólásai | válasz erre | 2017.12.18 09:24:52 (1262)
Az nem baj, csak lényeg, hogy pontosan a rekord struktúra legyen :)

Viszont találtam egy újabb apró bugot: az említett PUT-os visszítérési értékben a logtype szöveges, nem id.

UPD:
Másik bug:
"SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2005-11672' for key 'PRIMARY'"

2005-ös láda (pusztaszeri emlékmű), a jelszó jó mert már megtaláltam pár hete. Viszont ez az összetett index gyanús, a 11672 a userid lenne? mert én nem ezt küldtem.
[előzmény: (1261) gusty, 2017.12.18 08:46:48]

petrot81hozzászólásai | válasz erre | 2017.12.18 08:17:21 (1260)
Igen, működik, köszönöm!!

Még 1 apróság :)

1) lehetne, hogy a log POST is visszaadja a teljes rekordot, mint a PUT? Most post után külön kérem le az új log adatait, ezt meg lehetne spórolni, ha rögtön visszakapjuk (most csak az id-t küldi vissza az api)
[előzmény: (1259) gusty, 2017.12.17 21:56:00]

petrot81hozzászólásai | válasz erre | 2017.12.17 21:19:00 (1258)
Csináltam egy egyszerű tesztoldalt: http://tamaspetro.com/download/direct/gctest/

userid-t és apikey-t kell megadni, a többi ki van töltve. A log beszúrás gombra kattintva elküldi a logot, a válasz vissza is jön. Ezután lehet kattintani a módosításra, ott pedig visszajön a hiba.
[előzmény: (1256) gusty, 2017.12.17 17:43:50]

petrot81hozzászólásai | válasz erre | 2017.12.17 18:56:55 (1257)
Nem jó, ugyanazt kapom :(
[előzmény: (1256) gusty, 2017.12.17 17:43:50]

petrot81hozzászólásai | válasz erre | 2017.12.17 17:20:08 (1255)
Továbbra sem jó :(

Úgy olvastam, hogy az option method-ra is kell egy üres végpont, ami 20x-el tér vissza, hogy lefusson a kérés. Most az jön vissza hibaként is, hogy "Érvénytelen művelet"
[előzmény: (1254) gusty, 2017.12.17 12:18:58]

petrot81hozzászólásai | válasz erre | 2017.12.17 01:01:30 (1253)
Ismét API..

A logoknál a PUT és DELETE előtt a böngésző küld egy OPTIONS kérést is, ez viszont rendszeresen lehal. Swaggerben és postmanben jó, de fejlesztésnél a böngészőben a cross-domain miatt megy az említett metódus és kilövi a tényleges kérést.

Request URL:https://api.geolada.hu/userlog
Request Method:OPTIONS
Status Code:405 Method Not Allowed
Remote Address:217.13.101.139:443
Referrer Policy:no-referrer-when-downgrade

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests

Elviekben szerver beállítás orvosolná:
Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Origin: *

petrot81hozzászólásai | válasz erre | 2017.12.11 08:46:51 (1252)
Ill. még egy nagyon fontos dolog, bár ez inkább szerver config, mint api..

Ha van rá mód, nem lehetne beállítani, hogy a szerver dobja el a hívásokat x idő után? Esténként mikor nagyon belassul az oldal, percekig csak pörög a töltés és várja a választ. Én terveztem egy timer-t az alkalmazáson belüli abortolásra, de ezt szerver oldalon is lehetne valahogy kezelni. pl. max 30mp.

(Volt már olyan userem, aki azért pontozta le 1-es értékelésre az alkalmazást, mert azt hitte, hogy indulásnál lefagyott, közben meg csak pont kifogott egy szerver lassulást az alaplista letöltésénél.)

petrot81hozzászólásai | válasz erre | 2017.12.11 08:42:45 (1251)
Én jelenleg nem szűrök log típusra a lekéréseknél, de jó tudni, hogy ilyen szabály is van :) Köszönöm az infót :)
[előzmény: (1249) Old Eye, 2017.12.11 08:36:46]

petrot81hozzászólásai | válasz erre | 2017.12.11 08:41:19 (1250)
Szerintem a 404 megmaradhatna a hibáknak, az üres tömbös visszatérések helyes válaszok, csak épp üres az eredmény.

Én tegnap este befejeztem a régi api hívások átírását, egyelőre a 404-es üres eredményeket is lekezelve, de ha jól sejtem, a többieknek is jobban kezelhető a válasz, ha az üres tömb is sikeres válasz. Ráadásul ahogy lentebb írtam, az üres loggal rendelkező ládainfó nem is nagyon tesztelhető, mert nem tudunk olyan ládaid-t, ahol nincs még log.

A láda adatoknál viszont eléggé el lett aprózva a sok lekérés, nem tudom, hogy mennyire lesz kevésbé leterhelt a szerver így.
Pl. régen egy lekérésből megkaptuk 1) a láda adatait, 2) segéd- és multipontokat, 3) logokat a képeikkel (limitálva), 4) képeket, 5) megtalálás állapotát. Ez most a felsoroltak alapján 5 külön api hívás.

Részemről maradhat így is, nem akarnálak további refactorral terhelni, csak nem tudom, hogy az erőforrás-kímélés célja megvalósul-e így.
[előzmény: (1248) gusty, 2017.12.11 08:22:51]

petrot81hozzászólásai | válasz erre | 2017.12.10 22:33:51 (1247)
Egy újabb kérdésem volna, amit sajnos nem tudok tesztelni: a logsbycache végpont mit ad vissza, ha létezik a láda, de még nincsenek logjai? Üres tömböt 200-as sikeres válasszal, vagy 401-et?
[előzmény: (1245) gusty, 2017.12.10 21:15:35]

petrot81hozzászólásai | válasz erre | 2017.12.10 21:30:07 (1246)
Nagyon köszönöm! :)
[előzmény: (1245) gusty, 2017.12.10 21:15:35]

petrot81hozzászólásai | válasz erre | 2017.12.07 12:32:24 (1244)
1) köszönöm!


2) A képeknél esetleg egy GROUP_CONCAT segíthetne, ez kigyűjti a joinolt képeket és stringként összefűzi egy mezőbe.

A régi apiban hogy volt megoldva?
[előzmény: (1243) gusty, 2017.12.07 09:52:51]

petrot81hozzászólásai | válasz erre | 2017.12.06 23:18:27 (1242)
Újabb kérdésem volna:

Ha letöltöm egy láda minden adatát, hogyan tudom hozzáfűzni legegyszerűbben a saját megtalálásaimat (ami régen a found mezőben jött külön értékként)? A cache végpont nem ad vissza ilyen jellegű infót, hiába küldök userid-t is. A logsbycache végpontnál viszont nem tudok a saját userid-mra szűrni, csak a láda id-ra, így minden log visszajön.

Ill. a logsbyuser végpont esetén nem lehetne megoldani, hogy rögtön jöjjenek a képek is, ha vannak? Most ha lekérem a log listát, egyesével kell a képes logokhoz hívogatni a logimages végpontot.
[előzmény: (1240) gusty, 2017.12.03 23:24:46]

petrot81hozzászólásai | válasz erre | 2017.12.04 01:07:56 (1241)
Köszönöm a gyors javítást! :)
[előzmény: (1240) gusty, 2017.12.03 23:24:46]

petrot81hozzászólásai | válasz erre | 2017.12.03 01:28:52 (1239)
Akkor jó munkát mindkettőtöknek a bejgli mellé :)

Gusty-hoz lenne újabb api kérdésem/észrevételem:

1. A cachesbyarea végpont most az alábbi paraméterekkel fut le (csak a lényegi paramétert írom):

cachesbyarea?lat1=40&lat2=59&lon1=-180&lon2=180&fields=...

Ezzel szemben a szabályzatban az alábbi szöveg szerepel:
A geocaching.hu oldalra a piros téglalappal jelölt területen belülre rejtett geoládát lehet bejelenteni:
A pontos szélességi és hosszúsági körök: N51°04' - N41°50' - E09°31' - E29°44'

A lekérdezésben a "lon" paraméterek maxra vannak húzva, a "lat"-ok pedig 39.99999-nél ill 60-nál már elszállnak, tehát 40 ... 59.99999-ig fogadja el helyes értékként. Benézek valamit, vagy valóban zavar van az erőben?

p.s. ha mégis lenne majd a "sima" /cache végponton listázási lehetőség, akkor a magam részéről szívesen elhagynám ezt a furfangos cachesbyarea-s megoldást az összes láda lekérésére :)

2. A pointsbyarea végpontnál nálam a type üres:
pointsbyarea?lat1=40&lat2=59&lon1=-180&lon2=180&fields=id,no,type,name,description,lat,lon,alt

Itt van egyébként olyan lehetőség, hogy csak adott típusú pontot kérjünk le? pl. csak multipont adatokat, segédpont nélkül (vagy a wp paraméter ezeket szűrné?).
[előzmény: (1238) ocsike78, 2017.12.02 16:19:17]

petrot81hozzászólásai | válasz erre | 2017.11.30 13:52:43 (1236)
A magam részéről a hétvégén tervezem az új api integrálásának befejezését (kicsit megcsúsztam a melók miatt..). Lehet tudni, hogy a többiek hogy állnak és kb mikor lesz élesben is elérhető az új api is?

petrot81hozzászólásai | válasz erre | 2017.11.16 18:37:36 (1194)
Megint a szerver vacakolhat :(

[előzmény: (1192) Norbee97, 2017.11.16 17:22:20]

petrot81hozzászólásai | válasz erre | 2017.11.16 12:27:10 (1187)
Ebbe majd én is beszállok postman tesztekkel, úgyis abban próbálgattam eddig is az új apit. Elég könnyű konfigolni és teljesen automatizálható a tesztek futtatása.

https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop
[előzmény: (1183) gusty, 2017.11.16 11:47:02]

petrot81hozzászólásai | válasz erre | 2017.11.16 11:43:47 (1182)
Design alatt azt értettem, hogy a menüben én kiírom a bejelentkezett user felhasználónevét. Ez alá terveztem a nevét is kiírni, de mivel ez hiányos lehet, valóban elhagyható. Nem bonyolítom az életünket, elég lesz a felhasználónév :)
[előzmény: (1181) gusty, 2017.11.16 11:38:03]

petrot81hozzászólásai | válasz erre | 2017.11.16 10:35:59 (1180)
Köszi, a token így tökéletes lesz :)

Ahogy írtam, a user adatoknál a név csak "design" miatt kéne, csak a publikus kapcsoló miatt ugye nem mindig jön le a saját neve se.. Bár az sem lenne rossz, ha a saját adatai esetén mindent le lehetne kérni :)
[előzmény: (1178) gusty, 2017.11.16 08:55:16]

petrot81hozzászólásai | válasz erre | 2017.11.16 08:41:46 (1177)
A token generálással kapcsolatban volna egy kérdésem:

Ha valaki még sosem kért kulcsot, és renew paraméter nélkül küldöm el az auth kérést, akkor nem létező kulcs hiányában generál egy újat, vagy üres értékkel tér vissza?

A problémám az, hogy eddig úgy teszteltem, hogy fixen küldtem a renew=true paramétert is. Viszont így minden új eszköz, amin újonnan bejelentkezik, új kulcsot fog kérni és a korábbi eszközökön tárolt kulcsok elavulnak. Így mindig csak a legfrissebb eszközön lesz bejelentkezve. Lényegében tehát a renew-t csak akkor kéne küldeni, ha alapos indokból akarok kulcsot frissíteni.
Sajnos már nem tudom kipróbálni, hogy milyen az, ha nincs api kulcs még a userhez..

Ill. két ehhez kapcsolódó kérdés:
1) esetleg néha hasznos lenne egy külön token törlő végpont. Bár erre nagyon ritkán lehet szükség (kb a fenti eset tesztelésére vagy ha paranoiás az illető)..
2) a user végpont csak a publikus adatokat adja vissza. Lehetne-e, hogy az auth végpont is visszaadjon néhány plusz user infót, pl. user név, esetleg email. Ez kicsit önös kérés, én a megújult designban a felhasználónév alá terveztem kiírni a teljes nevet is, de ezt a user végpont nem mindig adhatja vissza.
[előzmény: (1176) gusty, 2017.11.14 22:53:35]

petrot81hozzászólásai | válasz erre | 2017.11.13 22:12:46 (1169)
Köszönjük! :)
[előzmény: (1168) gusty, 2017.11.13 15:52:48]

petrot81hozzászólásai | válasz erre | 2017.11.08 22:37:20 (1166)
Köszönet! :)
[előzmény: (1164) gusty, 2017.11.08 22:31:42]

petrot81hozzászólásai | válasz erre | 2017.11.08 22:37:10 (1165)
ah, köszi, jogos :D
[előzmény: (1163) gusty, 2017.11.08 22:27:39]

petrot81hozzászólásai | válasz erre | 2017.11.08 22:15:35 (1162)
A found-ra visszatérve:

Ez most lekéri a megtalált ládákat, és a found mezőben a találat számát szépen hozza is (mozgóknál ez a régiben és gondolom most is - nagyobb is lehet, mint 1).

https://api.geolada.hu/cachesbydist?userid=97337&radius=20&lat=46.253&lon=20.14824&status=1&found=true&fields=id,dateid,waypoint,nickname,found

Viszont én terület alapján kérném majd le (max. terület, hogy minden láda lejöjjön, minimális mezőlistával) és ott a found mezőt nem tölti ki, sőt a found, mint paraméter sem él:

https://api.geolada.hu/cachesbyarea?userid=97337&lat1=40&lat2=59&lon1=-180&lon2=180&foud=true&fields=id,nickname,found

Ezt be lehetne majd ide is kötni?

Csak, hogy tisztább legyen a nézőpontom: a régi apiban én úgy kértem le a ládalistát, hogy a térkép kirajzolásához minimálisan szükséges mezőlistával kértem le minden ládát, és mivel a username is meg van adva, a found mezőt is megkaptam, így jelölni tudtam, hogy melyik láda van már megtalálva. Aztán mikor megnyitja egy láda oldalát, akkor kérek le minden adatot (és cachelem lokálban)
[előzmény: (1158) gusty, 2017.11.08 12:51:28]

petrot81hozzászólásai | válasz erre | 2017.11.08 15:00:56 (1161)
Köszönöm mindkettőtöknek! :)

A leglényegesebb a találat lekérdezés volt, a multi ládákat én egységesen kezelem, nem jelölöm külön, hogy milyen (a leírásban úgyis ott van).

köszi még egyszer :)
[előzmény: (1158) gusty, 2017.11.08 12:51:28]

petrot81hozzászólásai | válasz erre | 2017.11.07 22:43:56 (1156)
Ismét API v2, szép nagy csokorban:

1. Korábban ocsike78 is említette, hogy nem lehetne-e a type mezőt numerikusan visszakapni, mint régen. Ennek én is nagyo hasznát venném.

2. Hasonlóan a status is, ha lehetne újra id-s.

3. A needs_maintenance mező mit tartalmaz, ha van benne érték? Pl. 70.es id-vel: "needs_maintenance": ";1649368;"

4. a régi api "found" mezőjét hogyan lehet most a legegyszerűbben lekérni? Van rá mód, hogy listákban való szűrés nélkül egyérelműen megkapjuk, hogy egy ládát megtalált-e a user?

5. Cache adatoknál a db_f mit takar?

6. Láda pontok lekérésénél (pl. points?id_list=2100) a type 3 különböző értéket vesz fel. Itt ha jól sejtem:
"type": "V" - multi pont
"type": "W", - segédpont
"type": "H", - "fő" pont

Ezek helytállóak? Lehet még más értéke a type-nak?

7. Említett 2100-as ládánál mit jelentenek pontosan az értékek?
"multi": "4", ??
"egyeb": "2", ??
"multi_h": "1", - ennyi H típus van - lehet több is?
"multi_v": "3", - ennyi V típusú pont van

petrot81hozzászólásai | válasz erre | 2017.11.06 09:56:09 (1152)
Akkor ezt nagyon benéztem, köszönöm :)
[előzmény: (1151) gusty, 2017.11.06 08:29:25]

petrot81hozzászólásai | válasz erre | 2017.11.05 22:10:18 (1150)
Egy újabb kérdés/kérés:

Ha láda kóddal szeretném megadni a logot, mi a teendő? A küldéshez láda id-kell, olyan végpont viszont nincs, amivel a láda kód alapján lekérhetném az id-t. Így viszont (nagyon-nagyon) extrém esetben előfordulhat, hogy a lokális DB-ben még nem létezik a láda, viszont bejelentésnél meg nem tudja, hogy milyen id-vel kéne küldenie, mert csak a rövid nevet tudja.

Összefoglalva:
- vagy a log mentés támogathatná láda Id helyett a láda rövid nevet is
- vagy jól jönne egy végpont, amivel rövid név alapján kereshető vissza egy láda.
[előzmény: (1148) gusty, 2017.11.05 16:58:22]

petrot81hozzászólásai | válasz erre | 2017.11.05 18:21:21 (1149)
Köszönjük! :)
[előzmény: (1148) gusty, 2017.11.05 16:58:22]

petrot81hozzászólásai | válasz erre | 2017.11.05 14:52:48 (1147)
Találtam egy újabb bugot az apiban:

https://api.geolada.hu/cachesbyowner?owner=97337&fields=id

{
"error": "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'c.datemodified' in 'field list'"
}

ill kérdés:

https://api.geolada.hu/ignored?userid=97337 - nekem nincs ignorált ládám, de üres tömb helyett egy "false" érték jön vissza. Ilyenkor nem lehetne egy [] (üres tömb) a válasz?
[előzmény: (1143) gusty, 2017.11.01 23:51:32]

petrot81hozzászólásai | válasz erre | 2017.11.03 22:44:10 (1144)
Fut most valami generálás? A régi api nálam most borzasztóan lassú :(

petrot81hozzászólásai | válasz erre | 2017.11.01 20:53:17 (1142)
ok, köszönjük!
[előzmény: (1141) gusty, 2017.11.01 20:12:35]

petrot81hozzászólásai | válasz erre | 2017.11.01 18:24:39 (1139)
{{apiBase}}/points?cacheid=1356

[előzmény: (1135) gusty, 2017.11.01 17:35:50]

petrot81hozzászólásai | válasz erre | 2017.11.01 17:29:32 (1134)
továbbra is :(
[előzmény: (1133) gusty, 2017.11.01 17:24:36]

petrot81hozzászólásai | válasz erre | 2017.11.01 17:12:38 (1132)
Most viszont ez jön:

"error": "SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY p.id,p.no,p.type' at line 1"

A type milyen értékeket vehet majd fel?
[előzmény: (1130) gusty, 2017.11.01 16:22:35]

petrot81hozzászólásai | válasz erre | 2017.11.01 15:56:38 (1129)
Köszi az infót :)

Újabb kérdés mertült fel: a multi és segédpontokat lekérésénél van egy furcsaság:

points?cacheid=1356


example value:

{
"id": 0,
"no": 0,
"ctype": 0,
"ptype": 0,
"name": "string",
"description": "string",
"icon": 0,
"lat": 0,
"lon": 0,
"alt": 0,
"distance": 0
}

kapott érték:

"id": "1356",
"no": "5",
"type": "V",
"name": "HmvH:M5",
"description": " Az épület falán található egészalakos szobrok száma! Nem csak szemmagasságban!!!)",
"icon": "32",
"lat": "46.414600",
"lon": "20.325083",
"alt": "89"

Főként a típus érdekelne, ctype és ptype nincs, de van "type": "V".
[előzmény: (1124) gusty, 2017.11.01 13:08:34]

petrot81hozzászólásai | válasz erre | 2017.11.01 09:05:43 (1120)
A régi name és code mezők hogyhogy nem jönnek vissza? A mezőlista nem kompatibilis a régi api-val?

ill. pl. a type régen csak egy integer volt, én használom is több helyen szűrésre. Most konkrétan a szöveges értéket adja vissza.

UPDATE: /cache?cacheid=70

Így visszajön minden mező, látszik, hogy milyen adatok vannak. A régi code waypoint(?) néven jön.

Egyébként ez érdekes, hogy POSTMAN-ben tesztelve működik az {{apiBase}}/cache?cacheid=70 lekérdezés. Az api.geolada.hu-n a swagger a kötelező fields mezők hiányában nem futtatja le a lekérést.
[előzmény: (1119) ocsike78, 2017.11.01 08:56:35]

petrot81hozzászólásai | válasz erre | 2017.10.27 22:35:19 (1113)
Én Ionic/Cordova-val fejlesztem a Geoládákat, ott androidnál 4.4 a minimum. Attól lefelé csak a betöltő képernyő jelenik meg. Nálad mi az "alja"?
[előzmény: (1109) bigmick, 2017.10.27 21:27:10]

petrot81hozzászólásai | válasz erre | 2017.10.27 19:19:33 (1108)
Ez így nagyon jól hangzik :)

Ami a távoli funkciók kapcsán felmerült bennem (és Fazék néhány napja írt posztja, miszerint a weboldalt is tervezitek frissíteni): a távoli cél, hogy a frontend/backend teljesen külön váljon és minden funkció az apit használja majd, vagy egyelőre csak a külsős alkalmazások kiszolgálása a cél?
[előzmény: (1107) gusty, 2017.10.27 18:25:47]

petrot81hozzászólásai | válasz erre | 2017.10.26 22:19:52 (1103)
Valóban, nálam is 500-as hiba jön :(
[előzmény: (1100) ocsike78, 2017.10.26 21:14:17]

petrot81hozzászólásai | válasz erre | 2017.10.26 21:07:31 (1099)
/ getkey
[előzmény: (1097) ocsike78, 2017.10.26 21:04:29]

petrot81hozzászólásai | válasz erre | 2017.10.26 21:06:52 (1098)
"Ajax, Javascript" helyett angular 2/4 alapokon tudnék segíteni. Lényegesen hatékonyabb és modernebb.
[előzmény: (1096) Fazék, 2017.10.26 21:00:08]

petrot81hozzászólásai | válasz erre | 2017.10.26 20:30:01 (1095)
Hogy még picit megkavarjalak:

http://waymarkedtrails.org/

Ez ua. mint az OSM turistautak, csak nincs levágva a határon :)
[előzmény: (1094) Travis, 2017.10.26 20:20:48]

petrot81hozzászólásai | válasz erre | 2017.10.25 14:21:19 (1082)
A tokennek lesz valami lejárati ideje, vagy addig él, amíg nem generálunk újat?
[előzmény: (1081) gusty, 2017.10.25 13:53:48]

Lapozás: előző | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | következő

Egy lapon megjelenő sorok száma:

új hozzászólás | témák listája


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