turbo87 / aerofiles Goto Github PK

The following igc file (renamed to txt for github upload), does not parse.

75V_GPS.txt

This writer should support writing waypoints and tasks. The specification is available at http://www.keepitsoaring.com/LKSC/Downloads/cup_format.pdf

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• Update dependency setuptools to v70

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency pytest to v7.4.4
• Update dependency coverage to v7.5.4
• Update dependency freezegun to v1.5.1
• Update dependency setuptools to v69.5.1
• Update dependency sphinx to v7.3.7
• Update dependency tox to v4.15.1
• Update pypa/gh-action-pypi-publish action to v1.9.0
• Update dependency flake8 to v7
• Update dependency pytest to v8
• Update dependency pytest-cov to v5
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Hello,

In documentation http://aerofiles.readthedocs.org/en/latest/api/xcsoar.html we can find

with writer.write_point(type=TaskType.TURN):
    writer.write_waypoint(...)
    writer.write_observation_zone(...)

but class TaskType has no attribute TURN

it should be PointType instead of TaskType

I also wonder why not using Eum34 for constants ?
https://docs.python.org/3/library/enum.html
https://pypi.python.org/pypi/enum34

Kind regards

AFAIK there is no written specification of the XML task file format, but it can be extracted from the source code at https://github.com/XCSoar/XCSoar

should be satellites instead

Hello,

maybe this's a bit out of the scope of your project but when you have a XCSoar task file (or any other PNA), it will be nice to be able to draw this task on a map with much more details.

A webpage using Google Maps API could be an interesting idea.
Maybe Aerofiles should be able to output such a HTML page (or a link to webpage).
pygmaps or pygmaps-extended might help https://code.google.com/p/pygmaps/ https://github.com/thearn/pygmaps-extended

Having this task displayed in Google Earth will be also interesting as we can have 3D view.
pyKML could help http://googlegeodevelopers.blogspot.fr/2012/01/introducing-pykml-python-library-for.html

Kind regards

Hello,

I own a GPS Bluetooth logger (Dual XGPS160).
Being able to create GPX file or IGC file (without declaration) from KML file (with gx:Track should probably be supported). See sample.kml

My first try was to use pykml but it doesn't seems to be maintained anymore .

Then I tried to use simplekml but that's only a KML generator not a KML parser (see code)

Then I tried to use fastkml... and found that gx:Track is not supported cleder/fastkml#37

So I wrote my own code using ElementTree cleder/fastkml#37 (comment)

Maybe adding support of KML files with gx:Track to aerofiles could be an interesting idea.

Kind regards

Hello,

OpenAIP exports files for Navaids (NDB, VORs...)
The Frequency field is set to the navaid's frequency, and currently aerofiles does not seem to like these:

./output/content/waypoint/country/CK-WPT-National-OpenAIP.cup
Traceback (most recent call last):
  File "/home/folken/git-xcsoar/xcsoar-data-content/./script/check/check_waypoints.py", line 9, in <module>
    cupfile.read(open(str(sys.argv[1])))
  File "/home/folken/git-xcsoar/xcsoar-data-content/lib/python3.11/site-packages/aerofiles/seeyou/reader.py", line 59, in read
    waypoint = self.decode_waypoint(fields)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/folken/git-xcsoar/xcsoar-data-content/lib/python3.11/site-packages/aerofiles/seeyou/reader.py", line 94, in decode_waypoint
    'frequency': self.decode_frequency(fields[self.headers.index('freq')]),
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/folken/git-xcsoar/xcsoar-data-content/lib/python3.11/site-packages/aerofiles/seeyou/reader.py", line 219, in decode_frequency
    raise ParserError('Reading frequency failed')

Sample File:

"AITUTAKI","AI",CK,1849.490S,15946.404W,8.0M,10,,,320.000,"NAVAID, ID AI, Frequency 320.000, , Magnetic declination 13.352, Aligned to true north FALSE"
"ATIU","AT",CK,2000.187S,15806.370W,67.0M,10,,,388.000,"NAVAID, ID AT, Frequency 388.000, , Magnetic declination 13.757, Aligned to true north FALSE"
"MANIHAKI","MH",CK,1022.789S,16100.073W,4.0M,10,,,380.000,"NAVAID, ID MH, Frequency 380.000, , Magnetic declination 11.049, Aligned to true north FALSE"

So the question is whether the check is too strict, or whether this is bending the standard.

SeeYou competition adds competition details in the L records (comments) of the IGC file. These records may exceed the maximum line length and are thus skipped in the parsing. This information is sometimes very useful and not indicative of a file error. For instance the task rules are presented like this. The TaskTime=03:30:00 tells that this task is an AAT, but this can never be recovered after parsing, because the line is left out:

LSEEYOU OZ=-1,Style=2,R1=5000m,A1=180,Line=1
LSEEYOU OZ=0,Style=1,R1=20000m,A1=180
LSEEYOU OZ=1,Style=1,R1=20000m,A1=180
LSEEYOU OZ=2,Style=1,R1=40000m,A1=180
LSEEYOU OZ=3,Style=1,R1=2000m,A1=180
LSEEYOU OZ=4,Style=3,R1=500m,A1=180,Move=1,Reduce=1,Line=1
LSEEYOU TSK,NoStart=13:29:00,TaskTime=03:30:00,WpDis=False,MinDis=True,NearDis=0.5km,NearAlt=200.0m,MinFinAlt=0.0km

Maybe it would be an idea to add a flag for relaxing the maximum line length requirement on L records?

Hello,

On https://aerofiles.readthedocs.io/en/latest/ we can read

This part of the documentation, which is mostly prose, begins with some background information about Flask, then focuses on step-by-step instructions for web development with Flask.

but it was fixed by #100

So I think latest (ie dev version or instable version) doc is not deployed on RTD.

Kind regards

The latest CI run shows an error during the deployment phase, because it tries to deploy on each entry in the test matrix (every version of python against which the tests are run). This deployment is successful for the python version which finishes testing first, but fails for the others: the package is already present on pypi.

This can be fixed in .travic.yml by adding that it should only deploy on the latest python version:

deploy:
  provider: pypi
  user: Tobias.Bieniek
  password:
    secure: 'encrypted password'
  on:
    tags: true
    python: latest
    repo: Turbo87/aerofiles

EDIT:
i am not certain whether python: latest works. the travis-ci doc only gives an example with a specific version number. thus: python: '3.6'

Sources:
https://docs.travis-ci.com/user/deployment/#Conditional-Releases-with-on%3A
https://stackoverflow.com/a/41543235/4629173

Hello,

After reading at http://www.ukiws.demon.co.uk/GFAC/documents/tech_spec_gnss.pdf p26 about C RECORD - TASK (Pre-flight Declaration), it seems to me that an IGC file can have several tasks declared and "a declaration continues to be valid until it is replaced by a new one".

So there's at a given instant only one active task but several tasks can exist in a whole IGC file.

Reading at

it seems that history of tasks in not kept in your implementation and maybe it should be considered.

An implementation could be to have

replaced by

task = [[], []]

and have

replaced by

 if task_item['subtype'] == 'task_info': 
     del task_item['subtype']
     task_item["waypoints"] = []
     task[1].append(task_item)
 elif task_item['subtype'] == 'waypoint_info': 
     del task_item['subtype'] 
     task[1]['waypoints'].append(task_item) 

I haven't tested it as I'm currently working on my Julia implementation but would be very pleased to have your opinion about my interpretation of this.

Kind regards

Hello,

it will be nice to have a aerofiles.xcsoar.ObservationZone object which could be passed to xcsoar.Writer.write_observation_zone. It will reduce my code https://github.com/scls19fr/pycondor/blob/master/pycondor/pycondor2xcsoar6.py
and improve it's readability

An implementation of this could be like this:

class ObservationZone:
    def __init__(self, **kw):
        assert 'type' in kw

        self.type = kw['type']

        if kw['type'] == ObservationZoneType.LINE:
            assert 'length' in kw
            self.length = kw['length']

        elif kw['type'] == ObservationZoneType.CYLINDER:
            assert 'radius' in kw
            self.radius = kw['radius']

        elif kw['type'] == ObservationZoneType.SECTOR:
            assert 'radius' in kw
            assert 'start_radial' in kw
            assert 'end_radial' in kw
            self.radius = kw['radius']
            self.start_radial = kw['start_radial']
            self.end_radial = kw['end_radial']

        elif kw['type'] == ObservationZoneType.SYMMETRIC_QUADRANT:
            assert 'radius' in kw
            self.radius = kw['radius']

        elif kw['type'] == ObservationZoneType.CUSTOM_KEYHOLE:
            assert 'radius' in kw
            assert 'inner_radius' in kw
            assert 'angle' in kw
            self.radius = kw['radius']
            self.inner_radius = kw['inner_radius']
            self.angle = kw['angle']

    def __str__(self):
        s = self.type + " "
        for key, val in self.__dict__.items():
            if key!="type":
                s += "%s: %s" % (key, val)
        return(s)

And
def write_observation_zone(self, **kw):

(in https://github.com/Turbo87/aerofiles/blob/master/aerofiles/xcsoar/writer.py )

should accept both either keyword args or an ObservationZone object.

so it could be

def write_observation_zone(self, obj=None, **kw):
    if obj is None:
        obj = ObservationZone(**kw)

    self.write_tag('ObservationZone', **obj.__dict__)

Kind regards

Some IGC file have an alternate syntax for the date: instead of HFDTE280709, it uses HFDTEDATE: 280709,01.
I have seen this in files generated with the XCTrack app.
In this situation, aerofiles fails to read the date, which is then missing from the header data.

Should the HGPS record be, HGPS:MANUFACTURERSNAME,MODEL,CHANNELS,MAXALT ie have a ":" after HGPS?
This is the example shown in http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/igc_format_2008.html#link_3.3 but the table below it says:

"HFGPS | HFGPSMANUFACTURER,MODEL,CHANNELS,MAXALT | HFGPSMarconi,SuperX,12ch,10000m | Manufacturer and model of the GPS receiver used in the logger. I think there's a TYPO in this section of the FAI document (2008), suggesting a colon is needed."

So there is a contradiction in the document and a potential error already noted. If there is an error and it should be HGPS: then line 301, "self.write_fr_header('GPS', gps_receiver)" should be:
"self.write_fr_header('GPS', gps_receiver, subtype_long="")" or something to get the colon added.

Basically there is something not right around HGPS and it might be the spec. Ideally whatever is wrong, where ever it is needs to be corrected (I'm not saying your code is wrong, just in total something is not right). If you believe your existing code is correct I'll contact the author of the spec and get them to change/clarify it.

the library has been updated with the following additions, which are currently not available pip:

• read the tasks from cup files
• read IGC files

See http://www.ftv-spandau.de/streckenfluege/flarm-informationen/flarmcfg.txt for an example

(Inspired by TobiasLohner/proSoar#3)

uses TZO as Two Letter Code but such TLC doesn't seems to exist in IGC specification http://www.ukiws.demon.co.uk/GFAC/documents/tech_spec_gnss.pdf

Implement AIXM parser

http://www.aixm.aero/sites/aixm.aero/files/imce/library/aicm_manual_4-5.pdf
http://www.aixm.aero/document/aixm-45-specification

http://www.aixm.aero/page/aixm-51-511

Just what I wanted to output IGC format files, excellent. One small point you don't say what units '*_alt" is in. I guess in the IGC format spec it says but it would make life easier for the user of aerofiles if it was stated in the documentation.

https://aerofiles.readthedocs.io/en/latest/api/seeyou.html

references the seeyou cup file specs here:
http://www.keepitsoaring.com/LKSC/Downloads/cup_format.pdf this one however 404s.

The document seems to have moved here:
http://download.naviter.com/docs/CUP-file-format-description.pdf

Hi,
I'm using your lib to read GAC files. GAC files are used by FAI General Aviation Commission and they are in fact regular IGC files (as stated in FAI Sporting code, Annex 4, Section 3.6). I have couple of GAC files generated by AFLOS flight recorder. They contain G record at its end, but it does not complain with IGC G record specification. It has four byte binary payload (ex. 0x7E 0x86 0xCE 0xE4) which causes exception when parsed by igc.Reader():

UnicodeDecodeError: 'utf-8' codec can't decode byte 0x86 in position 4868: invalid start byte

If I try to open GAC file in binary mode, igc reader doesn't recognize any fixes. So the file has to be opened in text mode.

Which codec is recommended to use with igc reader?

If I use codec ascii with error handler replace (maybe ignore?), I'm able to decode GAC files. But I'm not sure, if I don't lose anything else from another records too...

these old python versions are tripping up travis-ci test
i don't really feel like digging into this and put a lot of effort into the continuous support of these old versions.

@Turbo87: what do you think?

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.