Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

GPX metadata proposal #128

Open
jaybo opened this issue Nov 19, 2024 · 5 comments
Open

GPX metadata proposal #128

jaybo opened this issue Nov 19, 2024 · 5 comments

Comments

@jaybo
Copy link

jaybo commented Nov 19, 2024 •
edited
Loading

Here's an alternative approach for handling the many vagaries of GPX metadata (vs #111).

Option 1

Instead of adding something like getMetadata(), add an extended implementation of gpxGen() which includes the xml node being processed.
So the iterator would return something like:

{
    done: boolean;
    value: {
        xml: domNode,  // XML text fragment
        geojson: {
            type: "feature",
            properties:  {
                _gpxType : 'rte',
                name : 'Day 1'
                time : '2024-12-06T10:30'
            },
            coordinates ...,
        }
    }
}

This shifts all of most of the implementation work onto clients, but at least gets them halfway there. Otherwise, everybody is stuck writing a full parser just to extract the stupid bloody custom metadata.

Option 2

Alternatively, return the metadata instead:

{
    done: boolean;
    value: {
        extensions: {
            foo: "bar"
        },
        geojson: {
            type: "feature",
            properties:  {
                _gpxType : 'rte',
                name : 'Day 1'
                time : '2024-12-06T10:30'
            },
            coordinates ...,
        }
    }
}

Option 3

Or, perhaps optionally just include the metadata in properties.

{
    done: boolean;
    value: {
        type: "feature",
        properties:  {
            _gpxType : 'rte',
            name : 'Day 1'
            time : '2024-12-06T10:30',
            extensions: {
                bar: "foo"
            }
        },
        coordinates ...,
    }
}

Of these, Option 1 is the most flexible, since it gives full access to the DOM node in case non-standard properties were added.
@tmcw
Copy link
Collaborator

tmcw commented Nov 19, 2024

I don't want to be too stubborn about the initial getMetadata() proposal, but I don't fully understand why it wouldn't be the clearest solution: it would work well for people who have both gpx() and gpxGen() based parsing strategies, wouldn't introduce any confusion about what's feature vs what's a metadata object, would also allow nice, informative TypeScript types for what metadata values are possible.

The only downsides that I can think of are that it'd be an extra method to call. Any performance difference is probably extremely minimal because the bulk of the time spent is going to be in the initial parsing of XML into a DOM, which happens once.

@jaybo
Copy link
Author

jaybo commented Nov 19, 2024

I don't know the details of the proposed getMetadata() solution, but I see that nothing has happened on this front for over a year, so I'm throwing out alternatives. I just need something soonish or I need to write my own parser.

What are the parameters to the proposed getMetadata() option?

@tmcw
Copy link
Collaborator

tmcw commented Nov 19, 2024

The API would be like:

gpxMetadata(node: Document): GpxMetadata

And GpxMetadata would be an interface like

interface GpxMetadata {
  name: string;
  desc: string;
}

So if you're parsing a gpx file and getting metadata, you parse out the features as usual with gpx(doc) or gpxGen(doc) and then call gpxMetadata(doc) which returns the metadata object.

I think the gist is, this extra method perfectly belongs with the rest of the togeojson functionality, but trying to emit metadata from the gpx() or gpxGen() methods is more trouble than it's worth. It should probably be a separate function that returns a metadata object.

@jaybo
Copy link
Author

jaybo commented Nov 19, 2024

Looks like I was just confused about the support for extensions. In the attached file, there are extensions on each route which don't show up after parsing, yet I now see the source code apparently does support extensions. How do I extract

      <opencpn:planned_speed>6.00</opencpn:planned_speed>
      <opencpn:planned_departure>2022-01-01T23:27:53Z</opencpn:planned_departure>

from this file? (rename to .gpx)
OpenCpnAroundOrcas.txt

tmcw added a commit that referenced this issue Nov 19, 2024
@tmcw
Look for opencpn extensions to GPX
d074b21 
- Refs #128
@tmcw tmcw mentioned this issue Nov 19, 2024
Open
@tmcw
Copy link
Collaborator

tmcw commented Nov 19, 2024 •
edited
Loading

Ah, yes - that's a different issue. #111 is about metadata for the whole GPX file, which doesn't have an obvious place for storage within GeoJSON. This is a more straightforward issue, see #129

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tmcw @jaybo