See uploaded document for the review

This paper describes Trackmatcher, software for computing the intersections between computer trajectories and satellite observations. The paper describes the software construction and design as well as providing a few example cases demonstrating the use of the software. The paper can be a bit technical in some areas, particularly for people not familiar with Julia, but the supplementary information is very useful in this case.

This paper covers a tool to help with a common task. Although this task is not particularly complicated, it is good to see the algorithm described in detail. It would benefit from a clearer statement of where TrackMatcher improves over previous work (or what makes it necessary). Given this is a common task, is there something that previous studies were missing?

This work is within scope for GMD and I would support publication after a few corrections.

L49 - Although the package is described in more general terms, it is clearly designed for matching calculated trajectories with CALIPSO data. It might be good to put this description of primary and secondary first (which the terms are defined). I would have found this helpful for remembering which type of data the primary and secondary values are.

L70 - It might be nice to distribute some very simple test data with the package, so that contributors can be sure that any changes they make don't break the base functionality of the package.

L71 - While I understand the necessity of using Matlab to read in the hdf files, it does detract slightly from the free (as in both freedom and beer) nature of the whole package. I know in python, if the netcdf library is built correctly, it can be used to read hdf4 files too. You may not want to include this now, but if the same capability exists in julia, perhaps it is useful for a future version?

L75 - The package versions could probably be in the supplementary information.

L95 - Please define ESM when it is first used

L124 - Is there any reason not to use the haversine distance here? It is slightly slower, but might provide an improvement in the accuracy (especially near the poles).

L179 - acceptable

Figure 2 - the coloured dots at the intersections are very small on my screen.

L255 - 'If MATLAB is not installed at ...'?

L361 - There are a very large number of extra matches in this study. I am not really clear how this has happened and I think this really requires some more discussion. This comparison to previous studies is the main way of assessing the accuracy of TrackMatcher, rather than the accuracy metric (which is more testing simplifications in the matching process). Was there a deficiency in Tesche et al, 2016 (or is TrackMatcher overdoing the matches here, or missing in some cases?).

L388 - Is this for the 4-core run, or a single core run of TrackMatcher?

L404 - Given the satellite travels much faster, 8min is thousands of kilometers - is this plausible?

L411 - I think this accuracy value doesn't really cover much about the accuracy of trackmatcher itself, more about the accuracy of using either lat or lon for finding an intersection. Hence this value is more related to the shape/curve of the trajectories. Perhaps it could be referred to as something else, maybe the 'interpolation accuracy' or 'mathcing accuracy'?

Fig. 5 - Some of these tracks appear to have no intersections. Is that intentional?

L469 - Is this really a conclusion about PCHIP? There is no comparison to any other source of data. Perhaps removing some intermediate flight points the testing the reconstruction could test the accuracy of PCHIP (although I don't think the accuracy of PCHIP needs to be shown in much detail for this work).