Přejít na obsah


Fotka
- - - - -

přenos waypointů označených jako "Nepřepisovat při importu"


  • Pokud chcete vložit odpověď, přihlašte se
87 odpovědí na toto téma

#61 mikeant

mikeant

    Advanced Member

  • Members
  • PipPipPip
  • 688 příspěvků(y)

Publikováno 01 říjen 2015 - 11:02

Nestačilo by dobastlit export přírůstku dat v programu za období a importní skript na straně GG ?

 

Export přírůstků dobastlený už je, Luděk byl tak hodný a na můj podnět přidal filtr "Naposledy upraveno". Jen nějak nechápu, proč se následně při exportu do GPX exportují i WP Original location (které jsou tak nějak k ničemu ;) ). Každopádně tímto způsobem lze aktualizovat GG z AD a mám již úspěšně odzkoušeno (a nepotřebuji ani připojení k PC - posílám si to změnové GPX mailem). Ovšem pořád to neřeší můj původní problém.

 

Myslím že bastlit HTTP server do AD je zbytečné.


  • 0

#62 gord

gord

    Advanced Member

  • Members
  • PipPipPip
  • 10 107 příspěvků(y)

Publikováno 01 říjen 2015 - 11:30

Co se vlastne exportuje? Jen polozky, ktere byly opravdu zmeneny nebo cela kes, u ktere doslo ke zmene?

 

Stale zustava problem v tom, ze importem prislusnych dat muzes prijit o data, ktera jsou v PC cerstvejsi. To je opravdu nutne resit skutecnou synchronizaci, jinak to nepujde.


  • 0

MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)

Stator - statistiky y GeoGetu (diskuse)

- Spoiler - uložení spoilerů do GPS jako POI (diskuse)

- Náhrada GJ legálními postupy

 


#63 mikeant

mikeant

    Advanced Member

  • Members
  • PipPipPip
  • 688 příspěvků(y)

Publikováno 01 říjen 2015 - 12:40

Co se vlastne exportuje? Jen polozky, ktere byly opravdu zmeneny nebo cela kes, u ktere doslo ke zmene?

 

Stale zustava problem v tom, ze importem prislusnych dat muzes prijit o data, ktera jsou v PC cerstvejsi. To je opravdu nutne resit skutecnou synchronizaci, jinak to nepujde.

 

Exportuje se samozřejmě celá keš. Trochu problém je, že se označí za změněnou i po pouhém otevření v AD. Čerstvost dat v GG je samozřejmě nutné ohlídat ručně, což pro mně není až takový problém (vždycky než něco zapíšu do GG, provedu import z AD). Nevyvracím, že skutečná synchronizace je do budoucna nutnost, ale za současné situace takovouto berličku vítám, protože než to někdo napíše, to mlže trvat i roky ;)

 

Každopádně si stále myslím, že implementace HTTP serveru do AD je vcelku zbytečná, synchronizace se může provádět s DB zkopírovanou do PC. Moje gigová DB se přes MTP kopíruje necelou minutu, přes FTP je to asi na 4 minuty. Zase na druhou stranu by to odstranilo nutno kopírování celé DB oběma směry. Otázkou je, jak dlouho by trvala synchronizace přes HTTP při změně celé DB (např. po importu APQ).


  • 0

#64 gord

gord

    Advanced Member

  • Members
  • PipPipPip
  • 10 107 příspěvků(y)

Publikováno 01 říjen 2015 - 12:59

Zmena = zobrazeni ... to jsou mi veci, to by me nenapadlo ;) Tim spis je nutne hlidat datum a cas zmeny jednotlivych hodnot.


  • 0

MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)

Stator - statistiky y GeoGetu (diskuse)

- Spoiler - uložení spoilerů do GPS jako POI (diskuse)

- Náhrada GJ legálními postupy

 


#65 kolombo

kolombo

    Advanced Member

  • Members
  • PipPipPip
  • 5 674 příspěvků(y)

Publikováno 01 říjen 2015 - 14:02

Já jsem si právě říkal, že kdyby byl nějaký systém záznamu změn v a:drake v mobilu, stačilo by jej vzít a aplikovat v GG.

 

Určitě by to bylo snažší, než web server a asi by se dalo více vypilovat co a jak má s daty dělat import v GG.

 

Ale samozřejmě, pokud by bylo a:drake API, kde by si GG, třeba podle logů na GC.COM, kontroloval změny v databázi přímo v mobilu a přenášel je do databáze GG, bylo by to báječné.

 

Jen si říkám, jestli to není zbytečně moc práce na to, kolik lidí to použije.


  • 0

Miroslav Kolombo, k.t.

Garmin Oregon 600

N50 45.701 E015 05.508

ICQ: 343-044-770

kolombo@kolombo.cz


#66 LudekV

LudekV

    Advanced Member

  • Members
  • PipPipPip
  • 2 166 příspěvků(y)

Publikováno 01 říjen 2015 - 14:24

Motivace pro moji úvahu byla několikerá:

1) řada lidí má problém s aDrakeSync přes MTP

2) hlavní práci by měl odvést plugin v GG

3) maximálně jednoduché pro BFU - ideálně tak, že si PC najde mobil atuomaticky (to nevím jak realizovat), v horším tak, že uživatel nastaví IP adresu telefonu (tu mu aD ukáže) v pluginu a pak už jen spustí synchronizaci

 

Pokud by a:Drake uměl pracovat jako server, pak plugin v GG může posílat jakékoli SQL dotazy a tím se otevře cesta k synchronizaci. Navíc by nebylo nutné přenášet celou databázi do PC.

Teď jde o to, zda se někdo ujme vývoje pluginu pro GG a jestli to celé není hloupost.

 

Jinak a:Drake zaznamenáva datum a čaas poslední změny a umí i export podle toho data. Jenže to je pro řadu uživatelů příliš složité a nedokážou to použít. Kolombo, byť uživatel poučený, to zřejmě ani nenašel :-).


  • 0

a : Drake - vše potřebné pro (offline) geocaching na Android * Stránka projektu na GitHubu - požadavky a reklamace

Hlavní kešovací zažízení: Samsung Galaxy A41


#67 kolombo

kolombo

    Advanced Member

  • Members
  • PipPipPip
  • 5 674 příspěvků(y)

Publikováno 01 říjen 2015 - 14:28

Kolombo, byť uživatel poučený, to zřejmě ani nenašel :-).

 

Kolombo to vůbec nehledal, protože mobil používá jako nouzovku, když někde je a má GPS doma. Nebo když potřebuje ověřit aktuální stav keše.

 

Automatické synchronizace ostrých a leckdy nezazálohovaných dat nemám tak úplně rád.


  • 0

Miroslav Kolombo, k.t.

Garmin Oregon 600

N50 45.701 E015 05.508

ICQ: 343-044-770

kolombo@kolombo.cz


#68 gord

gord

    Advanced Member

  • Members
  • PipPipPip
  • 10 107 příspěvků(y)

Publikováno 01 říjen 2015 - 14:58

Mne osobne pripada pripojeni pres HTTP server jako docela zajimava alternativa k MTP. K tomu, aby z PC bylo poslano nejake SQL, je treba vedet, co vlastne zadat. A to vi jedine aD. Jsem ochotny se na tom podilet. Asi by bylo dobre to napred prodiskutovat ze vsech pohledu treba v tom dokumentu o synchronizaci, co jsme si vyrikavali predchozi situaci.


  • 1

MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)

Stator - statistiky y GeoGetu (diskuse)

- Spoiler - uložení spoilerů do GPS jako POI (diskuse)

- Náhrada GJ legálními postupy

 


#69 HaLuMa

HaLuMa

    Autor Geogetu

  • Members
  • PipPipPip
  • 14 508 příspěvků(y)

Publikováno 01 říjen 2015 - 15:02

Aby to byla alternativa k MTP, nemel by tam fungovat i smer GG->AD ?


Tento příspěvek byl upraven od HaLuMa: 01 říjen 2015 - 15:03

  • 0

#70 gord

gord

    Advanced Member

  • Members
  • PipPipPip
  • 10 107 příspěvků(y)

Publikováno 01 říjen 2015 - 15:24

Synchronizaci chapu jako synchronizaci - tedy data obema smery.Je jasne, ze to je dost prace.


  • 0

MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)

Stator - statistiky y GeoGetu (diskuse)

- Spoiler - uložení spoilerů do GPS jako POI (diskuse)

- Náhrada GJ legálními postupy

 


#71 mikeant

mikeant

    Advanced Member

  • Members
  • PipPipPip
  • 688 příspěvků(y)

Publikováno 02 říjen 2015 - 9:20

Motivace pro moji úvahu byla několikerá:

1) řada lidí má problém s aDrakeSync přes MTP

2) hlavní práci by měl odvést plugin v GG

3) maximálně jednoduché pro BFU - ideálně tak, že si PC najde mobil atuomaticky (to nevím jak realizovat), v horším tak, že uživatel nastaví IP adresu telefonu (tu mu aD ukáže) v pluginu a pak už jen spustí synchronizaci

 

Pokud by a:Drake uměl pracovat jako server, pak plugin v GG může posílat jakékoli SQL dotazy a tím se otevře cesta k synchronizaci. Navíc by nebylo nutné přenášet celou databázi do PC.

Teď jde o to, zda se někdo ujme vývoje pluginu pro GG a jestli to celé není hloupost.

 

Jinak a:Drake zaznamenáva datum a čaas poslední změny a umí i export podle toho data. Jenže to je pro řadu uživatelů příliš složité a nedokážou to použít. Kolombo, byť uživatel poučený, to zřejmě ani nenašel :-).

 

1) On to není až tak problém synchronizace přes MTP, jako spíš problém to vůbec připojit, aby si adrakesync načetl potřebné. Já mu například (u připojení přes FTP) musel podvrhnout upravený adrake.ini, neboť adreakesync vyžaduje plné cesty.

 

2) souhlas

 

3) možná bych to doplnil o volby Nepřepisovat/přepsat pouze starší/přepsat vše či o možnost synchronizace pouze jedním směrem.

 

Přenášení celé databáze do PC by se dalo vyhnout, ovšem po celkové aktualizaci dat v GG by to na přenos celé db zpět do AD bylo. Otázkou je, o kolik by taková synchronizace byla pomalejší než zkopírování celé DB.

 

Nechápu, co je na vyfiltrování a exportu do GPX složité. Je to otázka pár kliknutí, vše je přehledné a jasné. Trošičku problém jsou výsledná vyexportovaná data (logy neobsahují údaje ze šablony, jsou exportovány i jen otevřené nezměněné keše, export obsahuje vcelku zbytečné WP "Original Location", ale to už se dá odladit při následném importu.


  • 0

#72 gord

gord

    Advanced Member

  • Members
  • PipPipPip
  • 10 107 příspěvků(y)

Publikováno 02 říjen 2015 - 9:45

Prenaseni cele databaze do PC je velmi vhodne se vyhnout. Databaze obsahuje prostorovy index, ktery zatim SQLIte na androidu nepodporuje. Po prenosu cele databaze z mobilu do PC je tedy tento index temer jiste poskozen. (Ano, jiste, lze jej po prenosu databaze vytvorit znovu.)


  • 0

MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)

Stator - statistiky y GeoGetu (diskuse)

- Spoiler - uložení spoilerů do GPS jako POI (diskuse)

- Náhrada GJ legálními postupy

 


#73 mikeant

mikeant

    Advanced Member

  • Members
  • PipPipPip
  • 688 příspěvků(y)

Publikováno 02 říjen 2015 - 10:28

Prenaseni cele databaze do PC je velmi vhodne se vyhnout. Databaze obsahuje prostorovy index, ktery zatim SQLIte na androidu nepodporuje. Po prenosu cele databaze z mobilu do PC je tedy tento index temer jiste poskozen. (Ano, jiste, lze jej po prenosu databaze vytvorit znovu.)

Nene, mám na mysli přenášení celé databáze z PC do mobilu... Přenos celé databáze do PC pouze pro účely rychlejší synchronizace, jako samostatné db, se kterou by se pracovalo odděleně. To by ovšem eliminoval webserver běžící v adrake


Tento příspěvek byl upraven od mikeant: 02 říjen 2015 - 10:30

  • 0

#74 LudekV

LudekV

    Advanced Member

  • Members
  • PipPipPip
  • 2 166 příspěvků(y)

Publikováno 02 říjen 2015 - 11:15

Přenos celé DB z PC do mobilu považuji za velmi vhodný, protože operace UPADE/INSERT v telefonu nejsou zrovna rychlé (pochopitelně záleží na výkonu telefonu a rychlosti SD karty) a nějaké masivnější změny je lepší udělat na PC s vyšším výkonem a nakopírovat pak jenom výsledek.


  • 0

a : Drake - vše potřebné pro (offline) geocaching na Android * Stránka projektu na GitHubu - požadavky a reklamace

Hlavní kešovací zažízení: Samsung Galaxy A41


#75 HaLuMa

HaLuMa

    Autor Geogetu

  • Members
  • PipPipPip
  • 14 508 příspěvků(y)

Publikováno 02 říjen 2015 - 11:26

Podle mne je tedy optimalni model pouzivani (alespon pro mne):

  • ziskani zmen spachanych Adrakem na databazi v mobilu
  • pokusit se je nekonfliktne promitnout do GG
  • vyslednou databazi naladovat do mobilu

  • 2

#76 mh.mail

mh.mail

    Advanced Member

  • Members
  • PipPipPip
  • 1 781 příspěvků(y)

Publikováno 02 říjen 2015 - 11:50

Já bych se tedy přimluvil za obousměrnou implementaci INSERT/UPDATE, protože to pro malé změny může být efektivnější (i přes pomalost) než kopírovat vždy celou databázi. Ale ten model, co popisuje HaLuMa, bych implementoval taky (pro větší změny).


  • 0
„Normální je nepodvádět.“
http://gc.i-mh.net/ | gc@i-mh.net

#77 mikeant

mikeant

    Advanced Member

  • Members
  • PipPipPip
  • 688 příspěvků(y)

Publikováno 02 říjen 2015 - 13:12

 

Podle mne je tedy optimalni model pouzivani (alespon pro mne):

  • ziskani zmen spachanych Adrakem na databazi v mobilu
  • pokusit se je nekonfliktne promitnout do GG
  • vyslednou databazi naladovat do mobilu

 

 

Pod to se podepíšu, přičemž v jakés-takés podobě jsou první a poslední krok vyřešeny (export GPX, ruční překopírování). Samozřejmě kdyby to proběhlo sofistikovaně v jediném kroku (alespoň tedy první a druhý bod), budu na vrcholu blaha.

 

PS: dnes jsem v GGP zvládnul "Hello world" :D


  • 0

#78 gord

gord

    Advanced Member

  • Members
  • PipPipPip
  • 10 107 příspěvků(y)

Publikováno 02 říjen 2015 - 13:16

V tom GPX z aD by musely byt navic doplneny jeho vlastni informace o tom, kdy byla ktera polozka v aD zmenena. Pak uz by bylo mozne alespon kontrolovat, zda nedochazi ke konfliktu - pokud o zmenu polozky zmenene v DB od posledni synchronizace.


  • 0

MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)

Stator - statistiky y GeoGetu (diskuse)

- Spoiler - uložení spoilerů do GPS jako POI (diskuse)

- Náhrada GJ legálními postupy

 


#79 HaLuMa

HaLuMa

    Autor Geogetu

  • Members
  • PipPipPip
  • 14 508 příspěvků(y)

Publikováno 02 říjen 2015 - 13:20

Tak on hlavne v GPX chybi ten timestamp z databaze o tom, kdy byl zaznam naposledy modifikovan. Coz je pro synchronizacni ulohu fatalni problem.


  • 0

#80 gord

gord

    Advanced Member

  • Members
  • PipPipPip
  • 10 107 příspěvků(y)

Publikováno 02 říjen 2015 - 13:31

Ano, to jsem mel na mysli temi doplnenymi informacemi. Muselo by to tedy byt podobne rozsireni GPX, jako mas ty pro GG, ale jeste o ty polozky s casem zmeny, aby to ten synchronizacni plugin mohl pouzit pro kontroly.


  • 0

MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)

Stator - statistiky y GeoGetu (diskuse)

- Spoiler - uložení spoilerů do GPS jako POI (diskuse)

- Náhrada GJ legálními postupy

 





0 uživatel(ů) prochází toto téma

0 uživatelů, 0 návštěvníků 0 anonymních uživatelů

Reklama