rochaporto / ezgliding Goto Github PK

Something looking like:
https://storage.googleapis.com/maps-devrel/google.json

This should make it easy to have google maps data layers such as:
https://developers.google.com/maps/documentation/javascript/examples/layer-data-dynamic?hl=en-en

Full documentation of the data layer is here:
https://developers.google.com/maps/documentation/javascript/datalayer?hl=en-en

For reference, another option to achieve something similar would be to rely on google maps engine:
https://developers.google.com/maps/documentation/javascript/mapsenginelayers?hl=en-en

but it would tie the visualization to a specific backend for data retrieval. Having generated geojson and a caching layer should achieve the same goal. In the future we could add the maps engine layer with the same data anyway though.

http://dominik.honnef.co/posts/2014/12/an_incomplete_list_of_go_tools/#govet

At least have a look at how / if it could be useful.

Idea is to build a decision based on the parameters we'll use for identifying and activating thermal triggers. This would give us a good image of which parameters are the most relevant when identifying thermal triggers - pressure, humidity, wind, cloud coverage, etc.

Not sure how it could be used, but would be a nice way to determine how relevant each parameter is.

Idea taken from chapter 7 'Modeling with decision trees' of Programming Collective Intelligence.

Refactor the code in both airfield and waypoint information to match the new code structure in airspace. Package should own a struct which exports the required methods. The struct implements common.Plugin, which for now only has an Init() method.

Idea is to follow the google plus ui button design:
http://code.brucegalpin.com/google-plus-ui-buttons/

and to have a layout which resembles the current google keep interface:
http://keep.google.com

Minimalistic as much as possible.

This is still far away, but it's a good place to collect links with useful info:
http://jimblackhurst.com/wp/2011/05/17/heatmaps-point-clouds-and-big-data-in-processing/

Really nice visualization tool in javascript:
http://d3js.org/

Command line tool should be able to push information upstream.

This should be done by passing both a source and destination for each of the information types. As an example:

ezgliding airfield-put welt2000 datahub

There's too much stuff in the common package (airspace, flight, airfield, ...). It gets complicated to manage and triggers too many cycles.

Goal is to move each of the areas to their own package, introducing airspace, airfield, waypoint, flight packages.

Requires output geojson, to be implemented in #45.

In some flight logs the header records will include a label in the value, as in:

HFPLTPilotincharge:Ricardo.Rocha

It happens for other fields as well. We should strip the <...>: part (all preceding and the semicolon).

All here:
http://soaringweb.org/Airspace

but not evident how to check for updates (will need to parse the html apparently).

Needs a parser for openair format.
http://www.winpilot.com/UsersGuide/UserAirspace.asp

And given we'll have multiple implementations, probably worth integrating these tools:
http://dominik.honnef.co/posts/2014/12/an_incomplete_list_of_go_tools/#benchcmp

to get a nice comparison of different algorithms and their evolutiokn.

It might be we don't have to handle the RectangleSet as we do now, just put all data into a kd tree or similar.

Example of netcoupe.net parsing failure (Name, Category, Club, Region).

Happening when name/club/region/etc have accents.

./ezgliding flight-get -id=666
09/03/2015,PRAT Helene,Arcus M,D-KRHP
    netcoupe: {SourceID: Name: Category: Club: Region: Country:France Date:2015-03-09 00:00:00 +0000 UTC Takeoff:Saint Gaudens Distance:471.67 Points:328.12 Type: CircuitType:Libre Speed:98.61 Start: Turnpoints:[{Time:0001-01-01 00:00:00 +0000 UTC Latitude:0 Longitude:0 FixValidity:0 PressureAltitude:0 GNSSAltitude:0 IData:map[] NumSatellites:0 Description:} {Time:0001-01-01 00:00:00 +0000 UTC Latitude:0 Longitude:0 FixValidity:0 PressureAltitude:0 GNSSAltitude:0 IData:map[] NumSatellites:0 Description:} {Time:0001-01-01 00:00:00 +0000 UTC Latitude:0 Longitude:0 FixValidity:0 PressureAltitude:0 GNSSAltitude:0 IData:map[] NumSatellites:0 Description:}] Finish: Comment:Petite onde de Nord Est DownloadURL:/Download/DownloadIGC.aspx?FileID=930}

After refactoring common we can move the cli tools to their own specific packages, getting rid of the cli pkg too (which is too global and causes cycles/dependency issues).

In this case we need to be able to both get and put information.

Add a way to tell the system (command line, website, ...) which plugins to be using, any metadata required for those plugins, preferred formats for output and input, etc.

There are several candidate libraries, including goconfig, goconf, gcfg for ini files, go-yaml if yaml is chosen, or simply using the json parser if we go with json.

Start is when motorized (or tow) flight stopped. End is when motor restarted.

add a flight optimizer based on montecarlo.

igc shows lat/lon as DDmmsss, with sss being decimals of minutes, no seconds.

Probably using glog.

we are now parsing the region value, but getairfield/getwaypoint are not taking the param into account.

• show arrows pointing to the closest landing points when animating a flight. With colors according to the distance... Maybe show the closest three or so

For fun or maybe not only if it works well.

The gpligc library seems to use it, although the code is pretty messy. There's decent documentation on the approach in books such as The Algorithm Design Manual.

Example here:
https://travis-ci.org/rochaporto/ezgliding/builds/42454099

http://blog.christianperone.com/2015/08/googles-s2-geometry-on-the-sphere-cells-and-hilbert-curve/

probably useful for mapping thermals to cells.

tracked here for simplicity, but the issue is in the vim usage (as goimports gets called on save).

issue is that goimports, which mainly adds import management to gofmt (and wraps the rest), is not exposing the -s flag:
https://golang.org/cmd/gofmt/

looking around code seems to be here:
https://github.com/golang/tools/blob/master/cmd/goimports/goimports.go

should be trivial to add.

discovered while trying this out.
http://goreportcard.com/report/rochaporto/ezgliding

It seemed trivial but it's not easy to run docker from inside travis.

This is though the best way to get the build deliverables pushed to dockerhub, as we can make use of the generated binary directly. The alternative of using dockerhub automated build has the drawback of a rebuild, and the generation of much larger container images, as all the golang build tools get included and are not necessary at runtime.

See #55 for additional details on what was tried.

add a last update field to airfield, airspace, waypoint.

this is to be used later when doing airfield-put,etc so that we only add when the new data is more recent.

From netcoupe.net.

This is a really good description:
http://natureofcode.com/book/chapter-9-the-evolution-of-code/

And as a summary...

Population. Start with a variable number of random candidates

Fitness. Function evaluating the gene's fitness. Distance, prob squared or 2^distance so that we get an exponential increase for better solutions

Selection. Based on fitness. Should be a roulette wheel with the fittest candidates having a higher selection probability

Reproduction. Crossover between 1, 2 or even more parents. Take random position and take each side from a different parent.

Mutation. For each point mutate based on a probability, which should be low. Guarantees randomness when start population was bad

Play with population number and mutation rate to evaluate best results.

Genotype is the internal representation of a candidate. Phenotype the visual one

Add a frontend to query data based on open shift online. Required gears should be go, memcache and cron.

The same functionality as what would be achieved with appengine should be possible, but based on open source components.

Ideally it should focused on everything being containers so that we can easily migrate to open shift v3.

Using this instead:
https://github.com/codegangsta/cli

It includes much better support for subcommands (and subsubcommands if needed), and allows passing a context object to the action functions.

Parsing of flights stored in the IGC format, as defined in:
https://github.com/rochaporto/ezgliding/blob/master/doc/igc-flight-specification.pdf

It should include parsing of all basic elements of flight metadata and fixes. That means records A, H for flight metadata; record B for fixes.

This is enough to properly optimize and catalog the flights. All extra information is left for later (if ever needed).

ezgliding airspace-get, as a first example.

As defined here:
http://www.winpilot.com/UsersGuide/UserAirspace.asp

This is the format we'll use for the soaringweb airspace information.

This document:
https://github.com/rochaporto/ezgliding/blob/master/doc/palkovsky-optimization.pdf

has a good overview of a branch and bound strategy to perform both broken line and triangle optimization. It should give much more obvious code than the hard small optimizations over a brute force approach of things like maxcc or the other available open source optimizers.

Performance is said to be fraction of second, shouldn't be too different in JAVA.

https://blog.golang.org/profiling-go-programs

Needs to have some Bench* tests added, and then something like:

go test net/http -cpuprofile httpcpu.prof
go tool pprof http.test httpcpu.prof

in travis. For memory too.

All there to be taken.

Home at:
http://www.segelflug.de/vereine/welt2000/

Format description at:
http://www.segelflug.de/vereine/welt2000/download/WELT2000-SPEC.TXT

Sample file at:
http://www.segelflug.de/vereine/welt2000/download/WELT2000.TXT

There are periodic releases, and in principle a RSS feed to follow it:
http://www.segelflug.de/vereine/welt2000/index.html.en

Animate the flight log along the path, probably using a google maps polyline and animation on top:

Other ideas include:

• using a rounded glider/plane for representation (later we can make it configurable with several models, but for now make it funny... there was a cool one in one of the android apps for air traffic control)
• color the glider/plane according to one of the stats (or its borders)
• allow multiple gliders/planes in you single map
• if possible, also color the flight path line (this might not be possible with google maps though)
• look at adding extra info around the glider/plane, something radar like

Example when fetching netcoupe flight:

./ezgliding flight-get -id=666

failed to get flight :: unknown record :: HFTZNTIMEZONE:0 :: {Header:{Manufacturer:LXV UniqueID:740 AdditionalData:FLIGHT:1 Date:2015-03-09 00:00:00 +0000 UTC FixAccuracy:15 Pilot:PRAT Helene Crew: GliderType:Arcus M GliderID:D-KRHP GPSDatum:WGS-1984 FirmwareVersion:4.00 HardwareVersion:2 FlightRecorder:LXNAV,LX9000F GPS::uBLOX LEA-4S-2,16,max9000m PressureSensor:INTERSEMA,MS5561C,max16000m CompetitionID:PR CompetitionClass:Doubleseater} Points:[] K:map[] Events:map[] Satellites:map[] Logbook:[] Task:{DeclarationDate:0001-01-01 00:00:00 +0000 UTC FlightDate:0001-01-01 00:00:00 +0000 UTC Number:0 Takeoff:{Time:0001-01-01 00:00:00 +0000 UTC Latitude:0 Longitude:0 FixValidity:0 PressureAltitude:0 GNSSAltitude:0 IData:map[] NumSatellites:0 Description:} Start:{Time:0001-01-01 00:00:00 +0000 UTC Latitude:0 Longitude:0 FixValidity:0 PressureAltitude:0 GNSSAltitude:0 IData:map[] NumSatellites:0 Description:} Turnpoints:[] Finish:{Time:0001-01-01 00:00:00 +0000 UTC Latitude:0 Longitude:0 FixValidity:0 PressureAltitude:0 GNSSAltitude:0 IData:map[] NumSatellites:0 Description:} Landing:{Time:0001-01-01 00:00:00 +0000 UTC Latitude:0 Longitude:0 FixValidity:0 PressureAltitude:0 GNSSAltitude:0 IData:map[] NumSatellites:0 Description:} Description:} DGPSStationID: Signature: Sources:map[]}t