Narazil jsem na problém s tagy u bodů. Jedná se konkrétně o FN přes tagy. Ale platí to obecně.
Když potřebuji uložit do tagu víceřádkový text, tak musím založit více tagů stejné kategorie a do každého zapsat jako hodnotu jeden řádek textu.
Když mám tag, který obsahuje víceřádkový text (dostal jsem ho tam jiným způsobem - např. z PocketDrake), tak při exportu pomocí gpxgeoget2 se jeden víceřádkový tag rozseká na více jednořádkových tagů, tedy po importu z tohoto souboru do GG se u bodu založí několik tagů stejné kategorie s jednotlivými řádky textu.
Potíže s tím mám tyto:
tag obsahující víceřádkový text se nedá dobře editovat a špatně se zobrazuje (v jednom řádku) - v editoru tagů
rozsekaný text do více tagů stejné kategorie zase působí problémy, protože při zpracování ve skriptu se řádky složí v opačném (nebo nedefinovaném) pořadí než byly původně.
Čili řeším problém jak k tomu přistoupit. Buď si upravím exportní skript aby tag nerozsekal, ale nevím zda v GG nenastane někde problém se zpracováním takové hodnoty tagu (v zobrazení a editaci tagů mi to moc nevadí, protože to v tomto případě nepoužívám).
Nebo bych potřeboval prokouknout jakým způsobem se více tagů stejné kategorie chová při čtení skriptem - jak se spojují za sebe. Zda bych to nedokázal ovlivnit aby nedocházelo k přeházení řádků.
Neřešil někdo podobný problém, případně nedokáže mi někdo poradit jak na to?
Předem díky.
Tak trochu jsi smisil dve veci dohromady. Jedna vec je ulozeni TAGu, tam se normalne ulozit zalomeni radku da. Druha vec je manipulace s novym radkem v tagu - a tam je trochu problem. Pascal ma stringlist implementovany jako seznam stringu, z nichz kazdy je ukonce prave koncem radku. Pri nacteni takoveho tagu se tedy kazdy novy radek chape jako dalsi hodnota TAGu.
Jedine reseni, ktere me napada, je vlastni obsluha TAGu primym nacitanim/ukladanim z/do databaze. Obecne reseni na urovni GeoGetu asi bude znamenat prepracovani uplne vseho (vcetne mnoha scriptu) a to asi nebude akceptovatelne nikym.
Zkusil jsem pracovat ve skriptu s tagy, které obsahují i zalomení a zdá se, že to ničemu nevadí a dělá to co má. žádný stringlisty při tom používat nemusím, čili to mi nevadí.
Když tedy nepotřebuju editovat tagy v editoru GG, pak to asi tak můžu normálně používat, jenom musím upravit exportní makro (potřebuji tagy vyexportovat z jedný databáze do druhý) aby mi to nerozsekalo, což je jednoduchý.
Vlastně moc nechápu, proč exportní makro gpxgeoget2 ty tagy rozsekává, vždyť by je mohlo vyexportovat tak jak jsou a nezasahovat do toho. Možná to nějaký důvod má, jenom ho neznám
Taky jsem to tak pochopil, teď mi ale vadí, že se těžko definuje pořadí více stejných tagů a tedy nedokážu jednoduše zpět složit text s definovaným pořadím řádků.
Zkusím to risknout a pracovat s víceřádkovým textem, snad kromě editoru nikde nenarazím.
Hlavne se ti ted nemuzu podivat, kde vsude to muze narazit, a proc se to dela tak ci tak. To proto, ze si podobne speky vymyslite zasadne v dobe, kdy jsem nekde v trapu.
Teď mi to chodí, ale když mi příležitostně dáš vědět, jestli můžu někde narazit, budu určitě rád, abych měl alespoň trochu jistotu, že nedělám úplnou blbost.
FN nejsou pro tagy určitě to ideální místo, už jenom proto, že kdybychom jich chtěli mít pro jednu keš víc, tak už to vůbec bude hrozný.
Možná by bylo dobrý zapřemýšlet jestli by FN nešly řešit úplně jinak. Třeba jenom přes nějaký texťák a do tagů je netahat. Nebo pro ně založit samostatnou tabulku.
Moc tomu nerozumím, ale vidím asi dvě možnosti. Buď to udělat mimo pomocí nějakého jednoduchého xml nebo ini texťáku. Něco s čím se dá dobře pracovat.
A nebo to integrovat do databáze GG jako další jednoduchou tabulku, něco jako WP.
Jde o to aby se s tím dalo dobře pracovat jak v GG tak v PDA (PocketDrake) a dalo se to snadno přenášet.
V podstatě by to už mělo jít teď. Sice pro to třeba není přímá podpora v GG, ale číst a zapisovat do databáze jde asi cokoliv, včetně založení nové tabulky.
Přímá podpora pro to je: viz http://geoget.ararat.cz/help/index.html a SQLiteWrap. Vyžaduje to alespoň trochu rozumět SQL. V řadě GG skriptů se to používá, podívej se.
Presne to jsem mel na mysli tou vlastni databazi. Pripada mi to rozumnejsi, nez doplnit do stavajici databaze tabulku. To by mohlo nekde narazit, zejmena bych se obaval udrzbovych rutin GG, ale to urcite poreferuje HaLuMa. Zatimco nova databaze je zcela v rezii toho, co ji bude obsluhovat - at uz ve scritpu GG nebo uplne mimo.
To je pravda. Jde ale o to, jestli to pojmout jako obecnou vlastnost i pro ostatní uživatele GG nebo jestli si to budu dělat pouze pro sebe. Nedokážu odhadnout nakolik je takováto práce s FN potřebná i pro ostaní uživatele, kteří nepoužívají PocketDrake. Pak by totiž bylo lepší mít pro to podporu přímo v GG a nehrát si na vlastním písečku.
Samostatná databáze by na druhou stranu měla i další výhody, protože by se do ní třeba mohly ukládat i další informace z PocketDrake (trasa, atp.) a nepletlo by se to do databáze hlavní. To mi ale nepřísluší řešit, to musí LudekV a HaLuMa, já se pak pouze přizpůsobím.
No, dalsi napad je pouzit na ukladani do tagu knihovnu StructString, ktera je presne k tomu urcena.
Pomoci knihovny jde pekne pracovat se stringy a vytvaret stringy strukturovane, podobne jako s XML parserem.
Do jednoho dlouheho jednoradkoveho tagu tak muzes jednoduse ulozit treba datum, typ logu, poznamku, zda uz byl FN exportovany, odkud pochazi, kam smeruje, blabla…
Presne tuto knihovnu pouziva CWGlist pro ukladani informaci o pouzitych CWG do databaze GG. Do tagu. A presne tuto knihovnu planuju na fieldnotes pouzivat i ja
Pokud bys potreboval priklad pouziti ci nejakou jinou pomoc, tak se mi ozvi. Knihovnu jsem psal ja, takze bych snad mel byt schopen resit pripadne problemy.
To je nakonec pravda. Já pořád myslel na to aby to šlo v editoru tagů alespoň trochu editovat, ale vždyť to vlastně není vůbec potřeba a když už, tak ten str.text se při troše snahy dá celkem v pohodě. Na komfortní editaci pak v budoucnu snad bude i to makro od tebe
V tuto chvíli už ani tak neřeším víceřádkový text v tagu, ale spíš více FN k jedné keši, tedy aby nevznikalo příliš moc nepřehledných tagů. Což by ale i ten str.text řešil, protože jeden tag pro jednu FN zas není tak moc.
Chtělo by to co nejdříve stanovit přesnou strukturu toho tagu abychom to každý neměli jinak. Nemáš to už promyšlený?
Jelikož já to řeším v souvislosti s PD, tak mě bude ještě zajímat jak se k tomu postavi LudekV s přímou podporou v PD.
