Attribute aus PQ einlesen

[greiol]

attribute befinden sich in einem

<groundspeak:attributes>
...
</groundspeak:attributes>

block

Jedes einzelne Attribut ist definiert als

<groundspeak:attribute id="X" inc="Y">text für X</groundspeak:attribute>

Y kann die werte 0 oder 1 haben. 0 = Attribut gesetzt ; 1 = Attribut verneint

Für X / Text für X konnte ich bisher folgende Kombinationen ermitteln:
1 Dogs
2 Access or parking fee
3 Climbing gear
4 Boat
5 Scuba gear
6 Recommended for kids
7 Takes less than an hour
8 Scenic view
9 Significant hike
10 Difficult climbing
11 May require wading
12 May require swimming
13 Available at all times
14 Recommended at night
15 Available during winter
17 Poison plants
18 Snakes
19 Ticks
20 Abandoned mines
21 Cliff / falling rocks
22 Hunting
23 Dangerous area
24 Wheelchair accessible
25 Parking available
26 Public transportation
27 Drinking water nearby
28 Public restrooms nearby
29 Telephone nearby
30 Picnic tables nearby
31 Camping available
32 Bicycles
33 Motorcycles
34 Quads
35 Off-road vehicles
36 Snowmobiles
37 Horses
38 Campfires
39 Thorns
40 Stealth required
41 Stroller accessible
42 Needs maintenance
43 Watch for livestock
44 Flashlight required

16 geht uns noch ab. Vielleicht kann das jemand beisteuern,. dann kann ggf. der GPX Import erweitert werden.

Nein, ich weiss auch nicht warum in den Zahlen mehr als eine Lücke ist. Vielleicht historisch Attribute oder welche die noch in Planung sind.

Edit: flopps infos eingebaut

 

[flopp]

Ich könnte noch anbieten:

<groundspeak:attributes>
<groundspeak:attribute id="3" inc="1">Climbing gear</groundspeak:attribute>
<groundspeak:attribute id="5" inc="1">Scuba gear</groundspeak:attribute>
<groundspeak:attribute id="18" inc="1">Snakes</groundspeak:attribute>
<groundspeak:attribute id="20" inc="1">Abandoned mines</groundspeak:attribute>
<groundspeak:attribute id="21" inc="1">Cliff / falling rocks</groundspeak:attribute>
<groundspeak:attribute id="43" inc="1">Watch for livestock</groundspeak:attribute>
</groundspeak:attributes>

Damit wären auch die Lücken erklärt...

 

[sonnyy]

id=16 wird derzeit von gc.com nicht verwendet, somit ist die bestehende Liste komplett

 

[arbor95]

gehe ich recht in der Annahme, dass da zur Zeit noch nichts importiert wird?

 

[MiK]

sieht so aus. Lange gab es die Attribute nicht in den PQs. Und auch jetzt bekommt man sie anscheinend nur, wenn man entsprechende Einstellungen trifft.

 

[greiol]

Und auch jetzt bekommt man sie anscheinend nur, wenn man entsprechende Einstellungen trifft.

ja, denn bedauerlicher weise haben einige programmierer auf die verwendung eines xml parsers verzichtet und das was sie ersatzweise einsetzen auch noch so dusselig zusammengebaut, dass die software aus dem tritt kommt, wenn ein unbekanntes tag auftaucht. im blauen forum gabs zum thema mehrere seiten.

 

[MiK]

Naja, das ist ja nichts neues. Merken wir ja ständig, wenn andere Programme unser GPX lesen wollen.

Ich sag ja nicht, dass unsere Software perfekt ist. Aber wenn es solche Probleme gäbe, würden wir sie lösen und nicht bei GC jammern, dass sie es nicht ändern sollen...

 

[arbor95]

Und auch jetzt bekommt man sie anscheinend nur, wenn man entsprechende Einstellungen trifft.

ja, denn bedauerlicher weise haben einige programmierer auf die verwendung eines xml parsers verzichtet und das was sie ersatzweise einsetzen auch noch so dusselig zusammengebaut, dass die software aus dem tritt kommt, wenn ein unbekanntes tag auftaucht. im blauen forum gabs zum thema mehrere seiten.

ich bin auch grad auf ein kleines Problem gestossen:
attributesYes bzw No hat ja "nur" 64 Bits, ich bin aber schon auf 74 Attribute, wenn ich Opencaching dazumische. (Mal abgesehen von dem Platz im Filter)!

 

[greiol]

könnte man evtl. beim cache ein flag mit speichern ob oc oder gc? wobei natürlich oc nicht immer gleich oc ist. hmmm

 

[pfeffer]

ich wäre dafür, dann halt mehrere ints zu verwenden, evtl. als array.

Gruß,
Pfeffer.

 

[arbor95]

ich wäre dafür, dann halt mehrere ints zu verwenden, evtl. als array.

Gruß,
Pfeffer.

mir stellt sich grad eh die Frage warum die att-Infos doppelt gespeichert werden. Einmal als long attributesYes/No und einmal in den Details als Klartext - Bildname.

Es werden ja auch nur maximal 12 Atts gespeichert, sprich 12 Bits von z.Zt 74 (Das ist wohl bei GC ein limit, aber bei OC?)

 

[MiK]

Es können bei GC derzeit nur 12 Attribute angegeben werden. Das ist aber nicht mit 12 Bits alleine darstellbar, weil diese 12 eine Auswahl aus einer größeren Menge sind. Beim Speichern in Bitfeldern ist auch zu beachten, dass ein Attribut drei Zustände haben kann: "nicht vorhanden", "aktiv" und "verneint". Oder man muss eben die aktive und die verneinte Form des Attributs einzeln aufführen und jeweils speichern, ob es gesetzt ist oder nicht.

 

[MiK]

Früher wurden die Attribute nur in den Cache-Details (in den Cache.xml) gespeichert. Um auch danach filtern zu können, wurde später die numerische Repräsentation in die index.xml aufgenommen.

Da die Zeile der index.xml auch zum Wiederaufbau des Index in der cache.xml gespeichert wird, befinden sich die Informationen über die Attribute dort nun doppelt.

Ich nehme an, dass das eine nur für die Anzeige und das andere nur für den Filter genutzt wird.

 

[pfeffer]

Du hast natürlich recht: 3 Zustände, dass ich das nicht gemerkt habe! - naja, habe auch noch nichts am Attribute-Teil gemacht. Keine Ahnung, wie das im Moment gelöst ist. Vielleicht mit jeweils 2 Bits, also für das Attrib und das Anti-Attrib eins? - Ist auch eine gute Lösung.

bei 3 Zuständen rechnet man logischerweise am besten im 3er-System (wenn man keine Bits verschenken will).
z.B. so:
0: Attrib nicht angegeben
1: Attrib angegeben
2: Attrib verneint

Wie setzt man ein int daraus zusammen?
int z = a[0]*3^0 + a[1]*3^1 + a[2]*3^2 ...

wie bekommt man aus dem int ein einzelnes Attrib?
a = z / (3^i) % 3

Mit dem 3er-System, das war mir nur grad so eingefallen, weiß nicht, ob es Vorteile hätte.

Gruß,
Pfeffer.

 

[Hälmchen]

Ich bin mir noch nicht ganz sicher warum es geht.
Sollen die Attribute möglichst komprimiert abgespeichert werden? Oder geht es um die Verwaltung in cw?

Unwissend werd ich mal meinen Senf dazu geben Mein Vorschlag wäre die Nutzung eines Bytes.

Die letzen 7 bit kann man verwenden um die id des Attributes zu codieren und das erste Bit als ist gesetzt (1) oder nicht gesetzt (0) verwenden. Damit lassen sich max 128 Attribute verwalten. Pro cache gibt es nen Byte array welches die vorhandenen Attribute enthält.

Filteren sollte recht gut mittels Bitmasken funktionieren.

Gruß Hälmchen

 

[greiol]

Sollen die Attribute möglichst komprimiert abgespeichert werden?

so mit das langsamste ist derzeit der file io. je weniger man lesen oder schreiben muss, desto schneller startet / stoppt cw.

Oder geht es um die Verwaltung in cw?

auch im cw speicher sollte es übersichtlich zugehen, da die (ausser beschreibungen und logs) im ram gehalten werden. gleichzeitig ist es vorteilhaft möglichst einfach auf die daten zugreifen zu können.

das ist immer ein kleiner spagat der mal besser und mal schlechter gelingt.

 

[pfeffer]

Wie man es am besten macht, hängt also davon ab, wieviele mögliche Attribute es gibt. Wenn es wenige sind, dann macht es meiner Meinung nach Sinn, für jedes eine Stelle im Dreiersystem vorzusehen.
Wenn es aber viele sind, dann sollte man lieber jedem Attrib eine Nummer geben und eine Liste mit den Attribnummern zu jedem Cache speichern.
Da Cachewolf Daten von GC und (zurzeit) 4 verschiedenen Opencaching-Servern holen kann, die alle unterschiedliche Attribute verwenden, scheint mir die Liste möglicher Attribute grundsätzlich ziemlich lang. Also jedem Attrib eine Nummer geben und als Vector für jeden Cache anlegen?

(wobei ich das niedrigstwertigste Bit nehmen würde, um "-yes" und "-no" zu unterscheiden, denn dann kann man leicht mehr als 1 Byte für die Attrib-Nummer nutzen, falls das später notwendig sein sollte)

Gruß,
Pfeffer.

 

[arbor95]

ich habs jetzt mal eingebaut, ohne Version 4 der Datenstruktur zu kreieren.

Vielleicht findet sich noch ein Designer, der sich mit den Icons der Atttribute beschäftigt. Habe grad alles zusammengemischt was mir vor die Finger kam. ach ja, attributes-big entfält, bzw ist zu attributes geworden.

War eh aufwändig genug..

 

[Chris Race]

Es gibt übrigens neue Attribute:

<groundspeak:attribute id=”48″ inc=”1″>UV Light required</groundspeak:attribute>
<groundspeak:attribute id=”49″ inc=”1″>Snowshoes</groundspeak:attribute>
<groundspeak:attribute id=”50″ inc=”1″>Cross Country Skis</groundspeak:attribute>
<groundspeak:attribute id=”51″ inc=”1″>Special Tool required</groundspeak:attribute>
<groundspeak:attribute id=”52″ inc=”1″>Night Cache</groundspeak:attribute>
<groundspeak:attribute id=”53″ inc=”1″>Park and grab</groundspeak:attribute>
<groundspeak:attribute id=”54″ inc=”1″>Abandoned structure</groundspeak:attribute>
<groundspeak:attribute id=”55″ inc=”1″>Short hike</groundspeak:attribute>
<groundspeak:attribute id=”56″ inc=”1″>Medium Hike</groundspeak:attribute>
<groundspeak:attribute id=”57″ inc=”1″>Long Hike</groundspeak:attribute>
<groundspeak:attribute id=”58″ inc=”1″>Fuel nearby</groundspeak:attribute>
<groundspeak:attribute id=”59″ inc=”1″>Food nearby</groundspeak:attribute>

 

[arbor95]

vielen Dank an GC. Ist das auch irgendwo dokumentiert?

Ich habe z.B. eben festgestellt, dass "alte" Attribute auf "neue" abgebildet werden.
z.B. "Significant hike" auf "Medium Hike".