Child waypoints in gpx file

[giga]

Het volgende probleem treedt op bij export gpx vanuit GSAK. In de cache-omschrijving zijn de child WP's verdwenen en daarbij maakt het niet uit of je het vinkje aan of uit zet bij (including child WP's).

Als de gpx-file van geocaching.com rechtstreeks wordt gebruikt verschijnt wel het gedeelte van de child WP's onderaan de pagina, maar bij een export vanuit GSAK dus niet.

Heeft iemand hier al een oplossing voor?

[Kruimeldief]

export vanuit GSAK, waar naar toe? Naar o.a. HTML, zijn de childwaypoints immers niet nodig.

 

Nu heb ik niet alle vanuit Export geprobeerd natuurlijk, maar naar mapsource en TomTom blijven ze wel zichtbaar.

[Jurgen & Co]

Soms is deze export vand chilwp's wel nodig omdat hier aanwijzingen bij staan of vragen.

[Kruimeldief]

Soms is deze export vand chilwp's wel nodig omdat hier aanwijzingen bij staan of vragen.

Yes i know. Heb ik volgens mij ook niet ontkend. Ik gebruik ze dagelijks. Maar dat was volgens mij de vraag en mijn antwoord niet

 

Vrager krijgt ergens via export de childwaypoints niet ge-exporteerd. Mijn vraag was welke export en de opmerking dat bij HTML het niet nodig is en dat ik weet dat o.a. Mapsource en TomTom de childwaypoints wel ge-exporteerd krijgen

[LesMarten]

Het volgende probleem treedt op bij export gpx vanuit GSAK. In de cache-omschrijving zijn de child WP's verdwenen en daarbij maakt het niet uit of je het vinkje aan of uit zet bij (including child WP's).

Als de gpx-file van geocaching.com rechtstreeks wordt gebruikt verschijnt wel het gedeelte van de child WP's onderaan de pagina, maar bij een export vanuit GSAK dus niet.

Heeft iemand hier al een oplossing voor?

 

Wat zijn je settings als je de GPX/LOC binnenhaalt in GSAK ? In het import venster kun je ervoor kiezen om de additional waypoints niet te importeren (exclude), als een normaal waypoint (as normal waypoint), of als onderdeel van de cache (childwaypoint). Als je de laatste optie kiest en daarna vanuit GSAK de file weer als GPX exporteert (met de optie "include childpoints") dan zie je in de GPX file de extra waypoints onderaan elke cachebeschrijving staan (indien aanwezig).

[giga]

Ik wil idd exporteren naar een gpx file, die ik dan open met GPX-sonar. Vindt het echter zeer irritant als al die child WP's tussen de caches staan.

Nu heb ik weer eens geexporteerd met included child WP's en dan staan ze weer hinderlijk er tussen, maar niet onderaan de cache beschrijving.

 

De GPX-files haal ik altijd binnen via get data bij mail, maar kan nu even niet meer vinden waar ik dat heb ingesteld....

 

Dat laatste is gevonden. Ik heb aangevinkt dat de extra WP's als Child WP bij de caches moeten komen. De caches waar ze bijhoren zijn dan ook dik gedrukt.

 

 

Kan het ook aan de instellingen in gpx-sonar liggen? Heb namelijk nu een file van geocaching.com genomen en dan zie ik ze ook niet. En dat werkte bij Teph wel??

Begrijp er steeds minder van

[Jurgen & Co]

Misschien kun je wat plaatjes laten zien hoe het niet moet en hoe wel.

[LesMarten]

Kan het ook aan de instellingen in gpx-sonar liggen? Heb namelijk nu een file van geocaching.com genomen en dan zie ik ze ook niet. En dat werkte bij Teph wel??

Begrijp er steeds minder van

 

Net even gecontroleerd of er verschillen zijn tussen de manier waarop GPX-Sonar omgaat met child-waypoints en de manier waarop Cachemate ze importeert. GPX-Sonar zet ze er inderdaad als aparte caches tussen, zoals jij ook beschrijft. Bij Cachemate worden ze netjes in de bijbehorende "moedercache" gestopt. Ik kan zo snel ook geen settings vinden om ze bij GPX-Sonar wel goed te importeren. In mijn vorige bericht was ik er vanuit gegaan dat er geen verschillen zouden zijn tussen beide programma's. Dan blijkt het gezegde: assumption is the mother of all f*ckup's weer te gelden.... Ik zou zeggen, probeer het eens met Cachemate

24 oktober 2006 bewerkt door LesMarten

[de Roode Lantaarn]

Even de uitgebreide help van GSAK geraadpleegt en daar staat de oplossing kant en clear.

 

I suspect most users will want the new waypoints to show up in the GPSr "related" to the master Cache. The only way I see this happening is if the naming convention you use, has the first char_acters the same, and then something added to the end to differentiate the child waypoint.

 

For example, if your GPSr will accept a maximum of 8 char_acters for the waypoint name, it is very popular to use smart names with a length of 8. In this situation, if you want the child waypoints sorted correctly in your GPSr, change your smart name setting to 7 char_acters (via Tools=>Options=>General) then use the following tags in the "waypoint name":

 

%smart %children %smart%c_Code1

 

This will result in the parent cache getting the smart name, then the child waypoints having the smart name plus the one alpha code tacked on the end.

 

If your GPSr will accept more char_acters then perhaps a better solution is to set your smart name length to 2 less than you maximum length and use this setting

 

%smart %children %smart%c_Prefix

 

This will result in the parent cache getting the smart name, then the child waypoints having the smart name plus the 2 char_acter prefix tacked on the end.

 

If you prefer to see the Geocaching.com code in your GPSr and have the parent and child waypoints grouped together, try:

 

%drop2 %children %drop2%c_Prefix

 

This will drop the GC from the parent cache leaving just the XXXX part of GCXXXX. Child waypoints will then have the prefix appended to the XXXX code.

 

 

If you don't enter anything here GSAK will send down the Geocaching.com code to your GPSr. This effectively is the same as if you had added the following code to your waypoint name:

 

%children %c_Prefix%drop2

 

If you have an older GPSr that only supports 6 char_acters and would prefer to use the Geocaching.com code then the following tags will work and also bring the parent and child waypoints together

 

%drop2GC %children %drop2%c_Prefix

 

Nu zou het moeten lukken,

Succes.

[giga]

Dat is de oplossing om ze duidelijker in je GPS te krijgen. Het helpt niets voor GPX sonar. Heb via het forum van GSAK uitgevonden dat de GPX-file van 1 cache de child WP omschrijving wel bevat en de GPX-files uit PQ 's niet. Daar gaat het dus fout. GSAK exporteert ze blijkbaar ook niet duidelijk. Voorlopig nog geen oplossing dus.

[Xaa]

.

[de Roode Lantaarn]

Dat is de oplossing om ze duidelijker in je GPS te krijgen. Het helpt niets voor GPX sonar. Heb via het forum van GSAK uitgevonden dat de GPX-file van 1 cache de child WP omschrijving wel bevat en de GPX-files uit PQ 's niet. Daar gaat het dus fout. GSAK exporteert ze blijkbaar ook niet duidelijk. Voorlopig nog geen oplossing dus.

De childwaypoints worden wel degelijk meegenomen in een, door GSAK, geexporteerde file.

mits deze natuurlijk ook meegekomen zijn in de PQ. Zoals Xaa ook beschreef, de zipfile bevat dan twee GPX bestanden.

Als je nu GSAK het zip bestand laat inlezen neemt hij dus automatisch ook de childWP's mee.

In je lijst staan deze caches vetgedrukt ten teken dat het meer dan één coordinaat bevat.

Wanneer je nu weer een gpx export maakt (of wat dan ook) worden deze child's keurig meegenomen, indien de checkbox hiervoor is aangevinkt.

in mijn eerdere bericht staan de instellingen, en niet alleen voor een export naar je GPS maar deze ziojn geldig voor alle bestanden zoals ov2 wpt en gpx.

 

Succes.

[giga]

Maar waarom geeft GPX-sonar ze wel weer in de cachebeschrijving bij een losse GPX van geocaching.com en niet bij een GPX uit GSAK?

 

Het lijkt dus of het probleem in GPX-sonar zit of in ieder geval in de manier waarop deze de files uitleest...

29 oktober 2006 bewerkt door giga

[de Roode Lantaarn]

Ik heb eens de proef op de som genomen en eens de geëxporterde .gpx files van GSAK bekeken in Notepad. Alleen even het noodzakelijke eruit geknipt.

En eigenlijk zie ik gen verschil in opbouw.

 

Allereerst een .gpx van 2 'losse' caches.

 

version="1.0" creator="Groundspeak Pocket Query"

desc>Geocache file generated by GSAK (HasChildren)</desc>

 

<wpt lat="52.48" lon="6.081667">

<time>2005-04-14T00:00:00.0000000-08:00</time>

<name>GCNFM5</name>

<desc>Buys Ballot A - Met het veer of rond maar weer by Heirbaut Hunters (1/2,5)</desc>

 

<wpt lat="52.4795" lon="6.076167">

<time>2005-04-14T00:00:00.0000000-08:00</time>

<name>GCNFM4</name>

<desc>Buys Ballot A - Rond of met de Pont by Heirbaut Hunters (1/2,5)</desc>

 

Voor alle duidelijkheid, dezen zijn gearchiveerd.

 

De tweede is een cache met 7 'kinderen'.

Afhankelijk van de instellingen bepaalt hij dus de naam van deze childwaypoints.

 

<desc>Geocache file generated by GSAK (HasChildren)</desc>

 

<wpt lat="52.4744" lon="6.069967">

<time>2006-02-21T00:00:00.0000000-08:00</time>

<name>GCTD90</name>

<desc>Buys Ballot 8 - Hanzestad Hattem by Heirbaut Hunters (1/2)</desc>

<wpt lat="52.475167" lon="6.067617">

<time>2006-02-20T00:00:00.0000000-08:00</time>

<name>01TD90</name>

<wpt lat="52.473517" lon="6.069333">

<time>2006-02-20T00:00:00.0000000-08:00</time>

<name>02TD90</name>

<wpt lat="52.473483" lon="6.0703">

<time>2006-02-20T00:00:00.0000000-08:00</time>

<name>03TD90</name>

<wpt lat="52.475333" lon="6.066667">

<time>2006-02-20T00:00:00.0000000-08:00</time>

<name>04TD90</name>

<wpt lat="52.474" lon="6.07">

<time>2006-02-20T00:00:00.0000000-08:00</time>

<name>05TD90</name>

<wpt lat="52.474067" lon="6.07105">

<time>2006-02-20T00:00:00.0000000-08:00</time>

<name>06TD90</name>

<wpt lat="52.473333" lon="6.0706">

<time>2006-02-20T00:00:00.0000000-08:00</time>

<name>07TD90</name>

 

<gsak:Parent>GCTD90</gsak:Parent>

 

Duidelijk te zien dat de child Wp's meegenomen worden in de export van GSAK.

GPX sonar zal ze dus ook gewoon moeten bevatten. Ze staan misschien alleen ergens anders in de Wp lijst als waar je ze verwacht. (alfabetisch, direkt onder de ParentWP) Zoals gezegt is dit allemaal in te stellen binnen GSAK.

Nu staat het volgnummer voorop op de positie van de letters GC.

30 oktober 2006 bewerkt door de Roode Lantaarn

[De Roode Loper]

Ze staan misschien alleen ergens anders in de Wp lijst als waar je ze verwacht. (alfabetisch, direkt onder de ParentWP) Zoals gezegt is dit allemaal in te stellen binnen GSAK.

Nu staat het volgnummer voorop op de positie van de letters GC.

Dan is het misschien toch wel belangrijk (om de "boel" bij elkaar te houden) een éénduidige werkwijze te hebben/krijgen, zoals Kruimel al eens beschreef.