NetTopologySuite / NetTopologySuite.IO.GPX

GPX I/O for NetTopologySuite
BSD 3-Clause "New" or "Revised" License
10 stars 3 forks source link

GpxMainObject class #12

Closed HarelM closed 6 years ago

HarelM commented 6 years ago

I'm missing a class to hold all the information that I can pass in memory from place to place. Currently the writer is getting a metadata object and three list of features (among other stuff). It would be nice to have a interface call to the writer that receives an object that hold all the information. Some thing like:

public class GpxMainObject { 
    public GpxMetadata { get; }
    public GpxRoute[] {get;}
    ...

And the writer:

public void Write(..., GpxMainObject gpx, ...)
airbreather commented 6 years ago

It makes sense to give, e.g., GpxRoute[] to the consumer from Read, since we can always guarantee that it'll be an array, which gives the consumer maximum flexibility for what they can do with it right away, at no performance penalty. So yeah, it totally makes sense to have a Read kind of method that gives back a single object that encapsulates all the top-level gpx element content.

On the other hand, it doesn't make quite as much sense for Write to accept the same. The provider might want to pass in any number of different sequence types that implement IEnumerable<T>, and so if they have, e.g., IEnumerable<GpxRoute> that's being created by a LINQ query, then it would be wasteful to force it to go through a .ToArray() just to meet the demands of the API.

If you think it would help usability significantly, then I wouldn't mind doing something like this:

public static void Write(XmlWriter writer, GpxWriterSettings settings, GpxMainObject gpx)
{
    Write(writer, settings, gpx.Metadata, gpx.Waypoints, gpx.Routes, gpx.Tracks, gpx.Extensions);
}
HarelM commented 6 years ago

I never said anything about removing existing calls :-) The above suggesting is great IMO.