Options for importing dive sites from XML into Subsurface

Berthold Stoeger bstoeger at mail.tuwien.ac.at
Sun Apr 14 10:11:30 PDT 2019


On Sonntag, 14. April 2019 18:43:33 CEST Doug Junkins wrote:
> I’ve been looking at the code to try to figure out the best way to add the
> capability to import an XML file of dive sites to the Subsurface dive site
> table. Looking at the existing dive log import code, it may be possible to
> simply modify the dive log import code to be able to process an XML file
> that only includes dive sites.
> This would involve modifying the ‘process_imported_dives’ function in
> core/divelist.c to not filter sites that are not used by the imported dives
> and to process files even if the number of imported dives is zero. This
> would keep the XML import code consolidated in one place, but it would blur
> the separation of dive processing and dive site processing that we are
> trying to create.
> The other alternative is to replicate the ‘process_imported_dives’ function
> as something like ‘process_imported_divesites’ in core/divesites.c and add
> a new, separate menu option to import dive site XML files, but then there a
> lot of duplicate code to maintain.

I think I would prefer the second option. Conceptually, these are different 
things and we are more flexible that way. We might present the user different 
merging options (determine duplicates by name, by distance), prefer data from 
old or imported dive sites, etc. The whole process_imported_divesites logic is 
only a few lines. I wonder if we need such a function at all. Checking for 
duplicates could be done in the UndoCommand. If you give me a day or two I 
will write such a command. The only thing to do then is to get the parser to 
return a dive_site_table.


More information about the subsurface mailing list