... the user friendly GPS tool


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Erweiterung Excel Import/Export für GPX V1.1 möglich?
#1
Hallo,
wäre es möglich den Import/Export (bzw. Öffnen / Speichern) für Excel- bzw. csv-Dateien um weitere wpt-tags von GPX 1.1 zu erweitern (so, wie es schon für den GPX Import/Export bzw Öffnen/Spechern funktioniert)?

Aktuell werden bei .xlx, .xlsx und .csv folgende Tags unterstützt: Description, Elevation, Heading, Latitude, Longitude, Pressure, Speed, Temperature, Time.
Nützlich wäre die Unterstützung weiterer GPX V1.1 Tags wie: name, type, cmt, extensions.

Dabei wäre es nützlich, wenn die aktuelle Editiermöglichkeit von "name" und "description", mittels "Name; Beschreibung" im RC Beschreibungsfeld, für das Importieren und Exportieren berücksichtigt würde. D.h., getrennt nach "name" und "desc" Tag.

Viele Grüße,
Uwe
----------
Uwe
Reply
#2
(06.05.2020, 08:59)Uwe BB Wrote: Nützlich wäre die Unterstützung weiterer GPX V1.1 Tags wie: name, type, cmt, extensions.

name wird bereits unterstützt. extensions ist ein generischer Container für beliebige Erweiterungen – das wird nicht funktionieren, das in Spalten in einem Excel-Sheet abzubilden.

Was steht bei Dir in type und cmt drin, dass Du es erhalten möchtest?

(06.05.2020, 08:59)Uwe BB Wrote: Dabei wäre es nützlich, wenn die aktuelle Editiermöglichkeit von "name" und "description", mittels "Name; Beschreibung" im RC Beschreibungsfeld, für das Importieren und Exportieren berücksichtigt würde. D.h., getrennt nach "name" und "desc" Tag.

Das heißt, Du stellst Dir eine weitere Spalte vor, die alles hinter dem Semikolon aufnimmt? In Excel kann man Zellen mit einem Trennzeichen mit nur 3 Klicks ziemlich fix aufteilen. Und ich hätte nicht das Problem, ein aufwändiges Mapping zu bauen Cool
--
Christian
Reply
#3
(06.05.2020, 10:41)routeconverter Wrote:
(06.05.2020, 08:59)Uwe BB Wrote: Nützlich wäre die Unterstützung weiterer GPX V1.1 Tags wie: name, type, cmt, extensions.

name wird bereits unterstützt. extensions ist ein generischer Container für beliebige Erweiterungen – das wird nicht funktionieren, das in Spalten in einem Excel-Sheet abzubilden.

Was steht bei Dir in type und cmt drin, dass Du es erhalten möchtest?
----------------------------------
Generell werden alle diese tags wohl Geräte spezifisch benutzt. OsmAnd benutzt sie wie folgt:
<type>Name der Wegpunktliste</type>                 -> Text
<extensions>Angabe der Iconfarbe</extensions>    -> Text: Wird so für z.B. grün kodiert: <extensions><color>#43a047</color></extensions>
<cmt>Eigener Kommentar zum Wpt</cmt>            -> Text: Nicht für OsmAnd, aber für interne Unterkategorie sehr nützlich.
 
Für Excel, csv kann man die Inhalte der tags immer als Textfeld lesen/schreiben.

(06.05.2020, 08:59)Uwe BB Wrote: Dabei wäre es nützlich, wenn die aktuelle Editiermöglichkeit von "name" und "description", mittels "Name; Beschreibung" im RC Beschreibungsfeld, für das Importieren und Exportieren berücksichtigt würde. D.h., getrennt nach "name" und "desc" Tag.

Das heißt, Du stellst Dir eine weitere Spalte vor, die alles hinter dem Semikolon aufnimmt? In Excel kann man Zellen mit einem Trennzeichen mit nur 3 Klicks ziemlich fix aufteilen. Und ich hätte nicht das Problem, ein aufwändiges Mapping zu bauen  Cool
------------------------------

Was ich meine ist:
- Im RC kann ich für GPX implizit die tags <name> und <desc> befüllen: Beschreibungsfeld, z.B. "Mein Name; Meine Beschreibung"
- In Exel, csv Export wird dann aber "Mein Name; Meine Beschreibung" in EINE Spalte "Description" geschrieben. Aus meiner Sicht wäre es gut daraus 2 Spalten zu generieren: "Name" und "Description" und dieses beim Import natürlich zu berücksichtigen. Ich denke die Spalte "Name" könnte man auch defaultmäßig anlegen und ggf. leer lassen?

Danke und viele Grüße,
Uwe
----------
Uwe
Reply
#4
(06.05.2020, 12:35)Uwe BB Wrote: Generell werden alle diese tags wohl Geräte spezifisch benutzt. OsmAnd benutzt sie wie folgt:
<type>Name der Wegpunktliste</type>                 -> Text
<extensions>Angabe der Iconfarbe</extensions>    -> Text: Wird so für z.B. grün kodiert: <extensions><color>#43a047</color></extensions>
<cmt>Eigener Kommentar zum Wpt</cmt>            -> Text: Nicht für OsmAnd, aber für interne Unterkategorie sehr nützlich.

Ich könnte möglicherweise die Felder aus GPX in CSV durchschleifen bis auf <extensions>. Nicht trivial aufgrund der Besonderheiten der Bibliothek für Excel-Dateien, die erst wissen möchte, welche Spalten es gibt ;-)

(06.05.2020, 12:35)Uwe BB Wrote: - In Exel, csv Export wird dann aber "Mein Name; Meine Beschreibung" in EINE Spalte "Description" geschrieben.

Wie in alle anderen Formate auch. Die Trennung per Semikolon ist eine GPX-Sonderlocke, da praktisch kein anderes Format mehr als ein Feld für die Beschreibung hat. Bei GPX müsste man auch noch <cmd> berücksichtigen, also sind es eigentlich 3 Felder.

(06.05.2020, 12:35)Uwe BB Wrote: Aus meiner Sicht wäre es gut daraus 2 Spalten zu generieren: "Name" und "Description" und dieses beim Import natürlich zu berücksichtigen. Ich denke die Spalte "Name" könnte man auch defaultmäßig anlegen und ggf. leer lassen?

Da wird's halt knifflig und deshalb sprach ich in meinem letzten Post von "aufwändiges Mapping": <name> ist das, was die meisten unter <description> erwarten. Ich kann <name> nicht leer lassen bei GPX ohne andere Probleme zu kreieren und das daher nicht 1:1 mappen.
--
Christian
Reply
#5
(06.05.2020, 14:03)routeconverter Wrote:
(06.05.2020, 12:35)Uwe BB Wrote: Generell werden alle diese tags wohl Geräte spezifisch benutzt. OsmAnd benutzt sie wie folgt:
<type>Name der Wegpunktliste</type>                 -> Text
<extensions>Angabe der Iconfarbe</extensions>    -> Text: Wird so für z.B. grün kodiert: <extensions><color>#43a047</color></extensions>
<cmt>Eigener Kommentar zum Wpt</cmt>            -> Text: Nicht für OsmAnd, aber für interne Unterkategorie sehr nützlich.

Quote:Ich könnte möglicherweise die Felder aus GPX in CSV durchschleifen bis auf <extensions>. Nicht trivial aufgrund der Besonderheiten der Bibliothek für Excel-Dateien, die erst wissen möchte, welche Spalten es gibt ;-)

Das würde aus meiner Sicht ausreichen, wenn <extensions> auch durchgeschleift werden würde.
Warum ist <extensions> ein Sonderfall? Kann man es nicht genauso wie <type> oder <cmt> als Textspalte behandeln?

(06.05.2020, 12:35)Uwe BB Wrote: - In Exel, csv Export wird dann aber "Mein Name; Meine Beschreibung" in EINE Spalte "Description" geschrieben.

Quote:Wie in alle anderen Formate auch. Die Trennung per Semikolon ist eine GPX-Sonderlocke, da praktisch kein anderes Format mehr als ein Feld für die Beschreibung hat. Bei GPX müsste man auch noch <cmd> berücksichtigen, also sind es eigentlich 3 Felder.

Verstehe.

(06.05.2020, 12:35)Uwe BB Wrote: Aus meiner Sicht wäre es gut daraus 2 Spalten zu generieren: "Name" und "Description" und dieses beim Import natürlich zu berücksichtigen. Ich denke die Spalte "Name" könnte man auch defaultmäßig anlegen und ggf. leer lassen?
Quote:Da wird's halt knifflig und deshalb sprach ich in meinem letzten Post von "aufwändiges Mapping": <name> ist das, was die meisten unter <description> erwarten. Ich kann <name> nicht leer lassen bei GPX ohne andere Probleme zu kreieren und das daher nicht 1:1 mappen.

Das ist ok so wie es ist, Christian, da nach Speichern als XLS und Öffnen der XLS, das RC "Beschreibungsfeld" mit "Mein Name; Meine Beschreibung" wieder genau so importiert wird. D.h., wenn ich es dann als GPX abspeichere, ist ja wieder <name> und <desc> getrennt. habe ich gerade probiert.


Zusammengefasst, würde also das Durchschleifen der anderen Felder aus meiner Sicht ausreichen. Das wäre eine echte Hilfe, vielleicht auch für andere.
Nur <extensions> müsste halt dabei sein Wink .

Danke und viele Grüße,
Uwe
----------
Uwe
Reply
#6
(06.05.2020, 17:05)Uwe BB Wrote: Warum ist <extensions> ein Sonderfall? Kann man es nicht genauso wie <type> oder <cmt> als Textspalte behandeln?

Weil das XML ist, das ein XML-Parser liest und in Programmobjekte überführt. Im Programm wird nicht Text verarbeitet (auch wenn viele Programmierer XML als Zeichenketten verarbeiten ;-) sondern Daten. Die <extensions> haben keinen XML Namespace und können daher nur mit der allgemeinen DOM-Schnittstelle bearbeitet werden. Ich habe Dir Links eingefügt fürs Schmökern ;-)

(06.05.2020, 12:35)Uwe BB Wrote: Aus meiner Sicht wäre es gut daraus 2 Spalten zu generieren: "Name" und "Description" und dieses beim Import natürlich zu berücksichtigen. Ich denke die Spalte "Name" könnte man auch defaultmäßig anlegen und ggf. leer lassen?

<name> ist in GPX aber das, was "Description" in CSV ist.

Da wird's halt knifflig und deshalb sprach ich in meinem letzten Post von "aufwändiges Mapping": <name> ist das, was die meisten unter <description> erwarten. Ich kann <name> nicht leer lassen bei GPX ohne andere Probleme zu kreieren und das daher nicht 1:1 mappen.
--
Christian
Reply
#7
Hallo Christian,
hier nochmal nach meinem Verständnis zusammengefasst:
1) Die aktuelle Implementierung beim Konvertieren zu/von XLS und csv bzgl. GPX <name> und <desc> ist ok und muss nicht angepasst werden.
2) Das "Durchschleifen" zu/von XLS und csv von GPX <type>, <cmt> wäre möglich?
3) Das "Durchschleifen" zu/von XLS und csv von GPX <extensions> ist nicht leicht machbar, weil wie du schreibst:
"... das XML ist, das ein XML-Parser liest und in Programmobjekte überführt. Im Programm wird nicht Text verarbeitet (auch wenn viele Programmierer XML als Zeichenketten verarbeiten ;-) sondern Daten. Die <extensions> haben keinen XML Namespace und können daher nur mit der allgemeinen DOM-Schnittstelle bearbeitet werden."

Um ehrlich zu sein, verstehe ich das Problem mit <extensions> nicht richtig. Dazu fehlt mir wohl auch zuviel Fachwissen.
Nach meinem Verständnis definiert doch GPX V1.1 den namespace: "http://www.topografix.com/GPX/1/1"
Oder liegt es daran, dass <extensions> ein complex-type ist und auch wieder in unterschiedlichen types auftauchen kann?
Ich rede jedenfalls vom type "wptType". Siehe: https://www.topografix.com/GPX/1/1/#type_wptType
<...
lat="latitudeType [1] ?"
lon="longitudeType [1] ?">
<ele> xsd:decimal </ele> [0..1] ?
<time> xsd:dateTime </time> [0..1] ?
<magvar> degreesType </magvar> [0..1] ?
<geoidheight> xsd:decimal </geoidheight> [0..1] ?
<name> xsd:string </name> [0..1] ?
<cmt> xsd:string </cmt> [0..1] ?
<desc> xsd:string </desc> [0..1] ?
<src> xsd:string </src> [0..1] ?
<link> linkType </link> [0..*] ?
<sym> xsd:string </sym> [0..1] ?
<type> xsd:string </type> [0..1] ?
<fix> fixType </fix> [0..1] ?
<sat> xsd:nonNegativeInteger </sat> [0..1] ?
<hdop> xsd:decimal </hdop> [0..1] ?
<vdop> xsd:decimal </vdop> [0..1] ?
<pdop> xsd:decimal </pdop> [0..1] ?
<ageofdgpsdata> xsd:decimal </ageofdgpsdata> [0..1] ?
<dgpsid> dgpsStationType </dgpsid> [0..1] ?
<extensions> extensionsType </extensions> [0..1] ?
</...>

Viele Grüße,
Uwe
----------
Uwe
Reply
#8
(07.05.2020, 10:29)Uwe BB Wrote: 2) Das "Durchschleifen" zu/von XLS und csv von GPX <type>, <cmt> wäre möglich?

Ja, das wäre möglich. Ich bin jedoch nicht überzeugt davon, dass es eine gute Idee ist, Daten ohne Sichtbarkeit in der Benutzungsschnittstelle hin- und her zu bewegen. Das erzeugt bei weniger geübten Benutzern für Verwirrung und letztlich den Wunsch, die Daten auch in der Benutzungsschnittstelle sehen und bearbeiten zu können. Und das geht wieder gegen das Ziel, ein einfaches, auch nach längerer Zeit schnell benutzbares Werkzeug zu bauen.

(07.05.2020, 10:29)Uwe BB Wrote: Nach meinem Verständnis definiert doch GPX V1.1 den namespace: "http://www.topografix.com/GPX/1/1"
Oder liegt es daran, dass <extensions> ein complex-type ist und auch wieder in unterschiedlichen types auftauchen kann?

Es erlaubt eigene Namespaces, die für Erweiterungen beliebig festgelegt werden können. Siehe https://www.topografix.com/GPX/1/1/#type_extensionsType

Quote:Allow any elements from a namespace other than this schema's namespace (lax validation). [0..*]
--
Christian
Reply
#9
Quote:2) Das "Durchschleifen" zu/von XLS und csv von GPX <type>, <cmt> wäre möglich?

Quote:Ja, das wäre möglich. Ich bin jedoch nicht überzeugt davon, dass es eine gute Idee ist, Daten ohne Sichtbarkeit in der Benutzungsschnittstelle hin- und her zu bewegen. Das erzeugt bei weniger geübten Benutzern für Verwirrung und letztlich den Wunsch, die Daten auch in der Benutzungsschnittstelle sehen und bearbeiten zu können. Und das geht wieder gegen das Ziel, ein einfaches, auch nach längerer Zeit schnell benutzbares Werkzeug zu bauen.


Ich verstehe, was du meinst. Aber beim Lesen und Schreiben von GPX Dateien ist das ja schon genau so implementiert.
Wenn ich z.B. eine gpx Datei, die Wegpunkte mit <type> tags beinhaltet, öffne, verändere und wieder speichere, sind die <type> tags immer noch da.
Nur wenn ich als XLS bzw. csv speichere sind sie weg.

Viele Grüße,
Uwe
----------
Uwe
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)