columbus3 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (49) hide show
  1. checksums.yaml +7 -0
  2. data/.gitignore +9 -0
  3. data/.travis.yml +4 -0
  4. data/Gemfile +4 -0
  5. data/LICENSE.txt +21 -0
  6. data/README.md +41 -0
  7. data/Rakefile +10 -0
  8. data/bin/console +14 -0
  9. data/bin/setup +7 -0
  10. data/bower_components/leaflet/.bower.json +34 -0
  11. data/bower_components/leaflet/CHANGELOG.md +929 -0
  12. data/bower_components/leaflet/CONTRIBUTING.md +155 -0
  13. data/bower_components/leaflet/Jakefile.js +48 -0
  14. data/bower_components/leaflet/LICENSE +23 -0
  15. data/bower_components/leaflet/PLUGIN-GUIDE.md +127 -0
  16. data/bower_components/leaflet/README.md +34 -0
  17. data/bower_components/leaflet/bower.json +24 -0
  18. data/bower_components/leaflet/component.json +20 -0
  19. data/bower_components/leaflet/dist/images/layers-2x.png +0 -0
  20. data/bower_components/leaflet/dist/images/layers.png +0 -0
  21. data/bower_components/leaflet/dist/images/marker-icon-2x.png +0 -0
  22. data/bower_components/leaflet/dist/images/marker-icon.png +0 -0
  23. data/bower_components/leaflet/dist/images/marker-shadow.png +0 -0
  24. data/bower_components/leaflet/dist/leaflet-src.js +9180 -0
  25. data/bower_components/leaflet/dist/leaflet.css +478 -0
  26. data/bower_components/leaflet/dist/leaflet.js +9 -0
  27. data/bower_components/leaflet/package.json +33 -0
  28. data/bower_components/leaflet-providers/.bower.json +35 -0
  29. data/bower_components/leaflet-providers/CONTRIBUTING.md +10 -0
  30. data/bower_components/leaflet-providers/README.md +54 -0
  31. data/bower_components/leaflet-providers/bower.json +25 -0
  32. data/bower_components/leaflet-providers/css/gh-fork-ribbon.css +127 -0
  33. data/bower_components/leaflet-providers/css/gh-fork-ribbon.ie.css +68 -0
  34. data/bower_components/leaflet-providers/leaflet-providers.js +630 -0
  35. data/bower_components/leaflet-providers/license.md +9 -0
  36. data/bower_components/leaflet-providers/package.json +38 -0
  37. data/columbus3.gemspec +28 -0
  38. data/exe/columbus3 +144 -0
  39. data/lib/columbus3/metadata/query_parser.racc +160 -0
  40. data/lib/columbus3/metadata/query_parser.tab.rb +349 -0
  41. data/lib/columbus3/metadata/sidecar.rb +48 -0
  42. data/lib/columbus3/renderer/renderer.rb +73 -0
  43. data/lib/columbus3/v900track/v900track.rb +157 -0
  44. data/lib/columbus3/v900track/v900waypoint.rb +51 -0
  45. data/lib/columbus3/version.rb +3 -0
  46. data/lib/columbus3.rb +6 -0
  47. data/lib/html/show.html.erb +84 -0
  48. data/lib/html/track.js.erb +15 -0
  49. metadata +164 -0
@@ -0,0 +1,155 @@
1
+ Contributing to Leaflet
2
+ =======================
3
+
4
+ 1. [Getting Involved](#getting-involved)
5
+ 2. [Reporting Bugs](#reporting-bugs)
6
+ 3. [Contributing Code](#contributing-code)
7
+ 4. [Improving Documentation](#improving-documentation)
8
+
9
+ ## Getting Involved
10
+
11
+ Third-party patches are absolutely essential on our quest to create the best mapping library that will ever exist.
12
+ However, they're not the only way to get involved with the development of Leaflet.
13
+ You can help the project tremendously by discovering and [reporting bugs](#reporting-bugs),
14
+ [improving documentation](#improving-documentation),
15
+ helping others on the [Leaflet forum](https://groups.google.com/forum/#!forum/leaflet-js)
16
+ and [GitHub issues](https://github.com/Leaflet/Leaflet/issues),
17
+ showing your support for your favorite feature suggestions on [Leaflet UserVoice page](http://leaflet.uservoice.com),
18
+ tweeting to [@LeafletJS](http://twitter.com/LeafletJS)
19
+ and spreading the word about Leaflet among your colleagues and friends.
20
+
21
+ ## Reporting Bugs
22
+
23
+ Before reporting a bug on the project's [issues page](https://github.com/Leaflet/Leaflet/issues),
24
+ first make sure that your issue is caused by Leaflet, not your application code
25
+ (e.g. passing incorrect arguments to methods, etc.).
26
+ Second, search the already reported issues for similar cases,
27
+ and if it's already reported, just add any additional details in the comments.
28
+
29
+ After you made sure that you've found a new Leaflet bug,
30
+ here are some tips for creating a helpful report that will make fixing it much easier and quicker:
31
+
32
+ * Write a **descriptive, specific title**. Bad: *Problem with polylines*. Good: *Doing X in IE9 causes Z*.
33
+ * Include **browser, OS and Leaflet version** info in the description.
34
+ * Create a **simple test case** that demonstrates the bug (e.g. using [JSFiddle](http://jsfiddle.net/)).
35
+ * Check whether the bug can be reproduced in **other browsers**.
36
+ * Check if the bug occurs in the stable version, master, or both.
37
+ * *Bonus tip:* if the bug only appears in the master version but the stable version is fine,
38
+ use `git bisect` to find the exact commit that introduced the bug.
39
+
40
+ If you just want some help with your project,
41
+ try asking [on the Leaflet forum](https://groups.google.com/forum/#!forum/leaflet-js) instead.
42
+
43
+ ## Contributing Code
44
+
45
+ ### Considerations for Accepting Patches
46
+
47
+ While we happily accept patches, we're also commited to keeping Leaflet simple, lightweight and blazingly fast.
48
+ So bugfixes, performance optimizations and small improvements that don't add a lot of code
49
+ are much more likely to get accepted quickly.
50
+
51
+ Before sending a pull request with a new feature, first check if it's been discussed before already
52
+ (either on [GitHub issues](https://github.com/Leaflet/Leaflet/issues)
53
+ or [Leaflet UserVoice](http://leaflet.uservoice.com/)),
54
+ and then ask yourself two questions:
55
+
56
+ 1. Are you sure that this new feature is important enough to justify its presense in the Leaflet core?
57
+ Or will it look better as a plugin in a separate repository?
58
+ 2. Is it written in a simple, concise way that doesn't add bulk to the codebase?
59
+
60
+ If your feature or API improvement did get merged into master,
61
+ please consider submitting another pull request with the corresponding [documentation update](#improving-documentation).
62
+
63
+ ### Setting up the Build System
64
+
65
+ To set up the Leaflet build system, install [Node](http://nodejs.org/),
66
+ then run the following commands in the project root:
67
+
68
+ ```
69
+ npm install -g jake
70
+ npm install
71
+ ```
72
+
73
+ You can build minified Leaflet by running `jake` (it will be built from source in the `dist` folder).
74
+ For a custom build with selected components, open `build/build.html` in the browser and follow the instructions from there.
75
+
76
+ ### Making Changes to Leaflet Source
77
+
78
+ If you're not yet familiar with the way GitHub works (forking, pull requests, etc.),
79
+ be sure to check out the awesome [article about forking](https://help.github.com/articles/fork-a-repo)
80
+ on the GitHub Help website — it will get you started quickly.
81
+
82
+ You should always write each batch of changes (feature, bugfix, etc.) in **its own topic branch**.
83
+ Please do not commit to the `master` branch, or your unrelated changes will go into the same pull request.
84
+
85
+ You should also follow the code style and whitespace conventions of the original codebase.
86
+ In particular, use tabs for indentation and spaces for alignment.
87
+
88
+ Before commiting your changes, run `jake lint` to catch any JS errors in the code and fix them.
89
+ If you add any new files to the Leaflet source, make sure to also add them to `build/deps.js`
90
+ so that the build system knows about them.
91
+
92
+ Also, please make sure that you have [line endings configured properly](https://help.github.com/articles/dealing-with-line-endings) in Git! Otherwise the diff will show that all lines of a file were changed even if you touched only one.
93
+
94
+ Happy coding!
95
+
96
+ ## Running the Tests
97
+
98
+ To run the tests from the command line,
99
+ install [PhantomJS](http://phantomjs.org/) (and make sure it's in your `PATH`),
100
+ then run:
101
+
102
+ ```
103
+ jake test
104
+ ```
105
+
106
+ To run all the tests in actual browsers at the same time, you can do:
107
+
108
+ ```
109
+ jake test --ff --chrome --safari --ie
110
+ ```
111
+
112
+ To run the tests in a browser manually, open `spec/index.html`.
113
+
114
+ ## Code Coverage
115
+
116
+ To generate a detailed report about test coverage (which helps tremendously when working on test improvements), run:
117
+
118
+ ```
119
+ jake test --cov
120
+ ```
121
+
122
+ After that, open `spec/coverage/<environment>/index.html` in a browser to see the report.
123
+ From there you can click through folders/files to get details on their individual coverage.
124
+
125
+ ## Improving Documentation
126
+
127
+ The code of the live Leaflet website that contains all documentation and examples is located in the `gh-pages` branch
128
+ and is automatically generated from a set of HTML and Markdown files by [Jekyll](https://github.com/mojombo/jekyll).
129
+
130
+ The easiest way to make little improvements such as fixing typos without even leaving the browser
131
+ is by editing one of the files with the online GitHub editor:
132
+ browse the [gh-pages branch](https://github.com/Leaflet/Leaflet/tree/gh-pages),
133
+ choose a certain file for editing (e.g. `reference.html` for API reference),
134
+ click the Edit button, make changes and follow instructions from there.
135
+ Once it gets merged, the changes will immediately appear on the website.
136
+
137
+ If you need to make edits in a local repository to see how it looks in the process, do the following:
138
+
139
+ 1. [Install Ruby](http://www.ruby-lang.org/en/) if don't have it yet.
140
+ 2. Run `gem install jekyll`.
141
+ 3. Run `jekyll serve --watch` in the root `Leaflet` folder.
142
+ 4. Open `localhost:4000` in your browser.
143
+
144
+ Now any file changes will be updated when you reload pages automatically.
145
+ After commiting the changes, just send a pull request.
146
+
147
+ If you need to update documentation according to a new feature that only appeared in the master version (not stable one),
148
+ you need to make changes to `gh-pages-master` branch instead of `gh-pages`.
149
+ It will get merged into the latter when released as stable.
150
+
151
+ ## Thank You
152
+
153
+ Not only are we grateful for any contributions, &mdash; helping Leaflet and its community actually makes you AWESOME.
154
+ Join [this approved list of awesome people](https://github.com/Leaflet/Leaflet/graphs/contributors)
155
+ and help us push the limits of what's possible with online maps!
@@ -0,0 +1,48 @@
1
+ /*
2
+ Leaflet building, testing and linting scripts.
3
+
4
+ To use, install Node, then run the following commands in the project root:
5
+
6
+ npm install -g jake
7
+ npm install
8
+
9
+ To check the code for errors and build Leaflet from source, run "jake".
10
+ To run the tests, run "jake test".
11
+
12
+ For a custom build, open build/build.html in the browser and follow the instructions.
13
+ */
14
+
15
+ var build = require('./build/build.js');
16
+
17
+ function hint(msg, paths) {
18
+ return function () {
19
+ console.log(msg);
20
+ jake.exec('node node_modules/jshint/bin/jshint -c ' + paths,
21
+ {printStdout: true}, function () {
22
+ console.log('\tCheck passed.\n');
23
+ complete();
24
+ });
25
+ }
26
+ }
27
+
28
+ desc('Check Leaflet source for errors with JSHint');
29
+ task('lint', {async: true}, hint('Checking for JS errors...', 'build/hintrc.js src'));
30
+
31
+ desc('Check Leaflet specs source for errors with JSHint');
32
+ task('lintspec', {async: true}, hint('Checking for specs JS errors...', 'spec/spec.hintrc.js spec/suites'));
33
+
34
+ desc('Combine and compress Leaflet source files');
35
+ task('build', {async: true}, function () {
36
+ build.build(complete);
37
+ });
38
+
39
+ desc('Run PhantomJS tests');
40
+ task('test', ['lint', 'lintspec'], {async: true}, function () {
41
+ build.test(complete);
42
+ });
43
+
44
+ task('default', ['test', 'build']);
45
+
46
+ jake.addListener('complete', function () {
47
+ process.exit();
48
+ });
@@ -0,0 +1,23 @@
1
+ Copyright (c) 2010-2013, Vladimir Agafonkin
2
+ Copyright (c) 2010-2011, CloudMade
3
+ All rights reserved.
4
+
5
+ Redistribution and use in source and binary forms, with or without modification, are
6
+ permitted provided that the following conditions are met:
7
+
8
+ 1. Redistributions of source code must retain the above copyright notice, this list of
9
+ conditions and the following disclaimer.
10
+
11
+ 2. Redistributions in binary form must reproduce the above copyright notice, this list
12
+ of conditions and the following disclaimer in the documentation and/or other materials
13
+ provided with the distribution.
14
+
15
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
16
+ EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
17
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
18
+ COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
19
+ EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
20
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
21
+ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
22
+ TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
23
+ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
@@ -0,0 +1,127 @@
1
+ # Leaflet Plugin Authoring Guide
2
+
3
+ One of the greatest things about Leaflet is its powerful plugin ecosystem.
4
+ The [Leaflet plugins page](http://leafletjs.com/plugins.html) lists dozens of awesome plugins, and more are being added every week.
5
+
6
+ This guide lists a number of best practices for publishing a Leaflet plugin that meets the quality standards of Leaflet itself.
7
+
8
+ 1. [Presentation](#presentation)
9
+ - [Repository](#repository)
10
+ - [Name](#name)
11
+ - [Demo](#demo)
12
+ - [Readme](#readme)
13
+ - [License](#license)
14
+ 2. [Code](#code)
15
+ - [File Structure](#file-structure)
16
+ - [Code Conventions](#code-conventions)
17
+ - [Plugin API](#plugin-api)
18
+
19
+ ## Presentation
20
+
21
+ ### Repository
22
+
23
+ The best place to put your Leaflet plugin to is a separate [GitHub](http://github.com) repository.
24
+ If you create a collection of plugins for different uses,
25
+ don't put them in one repo &mdash;
26
+ it's usually easier to work with small, self-contained plugins in individual repositories.
27
+
28
+ ### Name
29
+
30
+ Most existing plugins follow the convention of naming plugins (and repos) like this: `Leaflet.MyPluginName`.
31
+ You can use other forms (e.g. "leaflet-my-plugin-name"),
32
+ just make sure to include the word "Leaflet" in the name so that it's obvious that it's a Leaflet plugin.
33
+
34
+ ### Demo
35
+
36
+ The most essential thing to do when publishing a plugin is to include a demo that showcases what the plugin does &mdash;
37
+ it's usually the first thing people will look for.
38
+
39
+ The easiest way to put up a demo is using [GitHub Pages](http://pages.github.com/).
40
+ A good [starting point](https://help.github.com/articles/creating-project-pages-manually) is creating a `gh-pages` branch in your repo and adding an `index.html` page to it &mdash;
41
+ after pushing, it'll be published as `http://<user>.github.io/<repo>`.
42
+
43
+ ### Readme
44
+
45
+ The next thing you need to have is a descriptive `README.md` in the root of the repo (or a link to a website with a similar content).
46
+ At a minimum it should contain the following items:
47
+
48
+ - name of the plugin
49
+ - a simple, concise description of what it does
50
+ - requirements
51
+ - Leaflet version
52
+ - other external dependencies (if any)
53
+ - browser / device compatibility
54
+ - links to demos
55
+ - instructions for including the plugin
56
+ - simple usage code example
57
+ - API reference (methods, options, events)
58
+
59
+ ### License
60
+
61
+ Every open source repository should include a license.
62
+ If you don't know what open source license to choose for your code,
63
+ [MIT License](http://opensource.org/licenses/MIT) and [BSD 2-Clause License](http://opensource.org/licenses/BSD-2-Clause) are both good choices.
64
+ You can either put it in the repo as a `LICENSE` file or just link to the license from the Readme.
65
+
66
+ ## Code
67
+
68
+ ### File Structure
69
+
70
+ Keep the file structure clean and simple,
71
+ don't pile up lots of files in one place &mdash;
72
+ make it easy for a new person to find their way in your repo.
73
+
74
+ A barebones repo for a simple plugin would look like this:
75
+
76
+ ```
77
+ my-plugin.js
78
+ README.md
79
+ ```
80
+
81
+ An example of a more sophisticated plugin file structure:
82
+
83
+ ```
84
+ /src - JS source files
85
+ /dist - minified plugin JS, CSS, images
86
+ /spec - test files
87
+ /lib - any external libraries/plugins if necessary
88
+ /examples - HTML examples of plugin usage
89
+ README.md
90
+ LICENSE
91
+ package.json
92
+ ```
93
+
94
+ ### Code Conventions
95
+
96
+ Everyone's tastes are different, but it's important to be consistent with whatever conventions you choose for your plugin.
97
+
98
+ For a good starting point, check out [Airbnb JavaScript Guide](https://github.com/airbnb/javascript).
99
+ Leaflet follows pretty much the same conventions
100
+ except for using smart tabs (hard tabs for indentation, spaces for alignment)
101
+ and putting a space after the `function` keyword.
102
+
103
+ ### Plugin API
104
+
105
+ Never expose global variables in your plugin.<br>
106
+ If you have a new class, put it directly in the `L` namespace (`L.MyPlugin`).<br>
107
+ If you inherit one of the existing classes, make it a sub-property (`L.TileLayer.Banana`).<br>
108
+ If you want to add new methods to existing Leaflet classes, you can do it like this: `L.Marker.include({myPlugin: …})`.
109
+
110
+ Function, method and property names should be in `camelCase`.<br>
111
+ Class names should be in `CapitalizedCamelCase`.
112
+
113
+ If you have a lot of arguments in your function, consider accepting an options object instead
114
+ (putting default values where possible so that users don't need specify all of them):
115
+
116
+ ```js
117
+ // bad
118
+ marker.myPlugin('bla', 'foo', null, {}, 5, 0);
119
+
120
+ // good
121
+ marker.myPlugin('bla', {
122
+ optionOne: 'foo',
123
+ optionThree: 5
124
+ });
125
+ ```
126
+
127
+ And most importantly, keep it simple. Leaflet is all about *simplicity*.
@@ -0,0 +1,34 @@
1
+ <img src="http://leafletjs.com/docs/images/logo.png" alt="Leaflet" />
2
+
3
+ Leaflet is an open source JavaScript library for **mobile-friendly interactive maps**.
4
+ It is developed by [Vladimir Agafonkin][] of [MapBox][] with a team of dedicated [contributors][].
5
+ Weighing just about 30 KB of gzipped JS code, it has all the [features][] most developers ever need for online maps.
6
+
7
+ Leaflet is designed with *simplicity*, *performance* and *usability* in mind.
8
+ It works efficiently across all major desktop and mobile platforms out of the box,
9
+ taking advantage of HTML5 and CSS3 on modern browsers while being accessible on older ones too.
10
+ It can be extended with a huge amount of [plugins][],
11
+ has a beautiful, easy to use and [well-documented][] API
12
+ and a simple, readable [source code][] that is a joy to [contribute][] to.
13
+
14
+ For more info, docs and tutorials, check out the [official website][].<br>
15
+ For **Leaflet downloads** (including the built master version), check out the [download page][].
16
+
17
+ We're happy to meet new contributors.
18
+ If you want to **get involved** with Leaflet development, check out the [contribution guide][contribute].
19
+ Let's make the best mapping library that will ever exist,
20
+ and push the limits of what's possible with online maps!
21
+
22
+ [![Build Status](https://travis-ci.org/Leaflet/Leaflet.png?branch=master)](https://travis-ci.org/Leaflet/Leaflet)
23
+
24
+ [Vladimir Agafonkin]: http://agafonkin.com/en
25
+ [contributors]: https://github.com/Leaflet/Leaflet/graphs/contributors
26
+ [features]: http://leafletjs.com/features.html
27
+ [plugins]: http://leafletjs.com/plugins.html
28
+ [well-documented]: http://leafletjs.com/reference.html "Leaflet API reference"
29
+ [source code]: https://github.com/Leaflet/Leaflet "Leaflet GitHub repository"
30
+ [hosted on GitHub]: http://github.com/Leaflet/Leaflet
31
+ [contribute]: https://github.com/Leaflet/Leaflet/blob/master/CONTRIBUTING.md "A guide to contributing to Leaflet"
32
+ [official website]: http://leafletjs.com
33
+ [download page]: http://leafletjs.com/download.html
34
+ [MapBox]: https://mapbox.com
@@ -0,0 +1,24 @@
1
+ {
2
+ "name": "leaflet",
3
+ "version": "0.7.3",
4
+ "description": "JavaScript library for mobile-friendly interactive maps",
5
+ "main": [
6
+ "dist/leaflet.js",
7
+ "dist/leaflet.css",
8
+ "dist/leaflet-src.js",
9
+ "dist/images/layers-2x.png",
10
+ "dist/images/layers.png",
11
+ "dist/images/marker-icon-2x.png",
12
+ "dist/images/marker-icon.png",
13
+ "dist/images/marker-shadow.png"
14
+ ],
15
+ "ignore": [
16
+ ".*",
17
+ "CHANGELOG.json",
18
+ "FAQ.md",
19
+ "debug",
20
+ "spec",
21
+ "src",
22
+ "build"
23
+ ]
24
+ }
@@ -0,0 +1,20 @@
1
+ {
2
+ "name": "leaflet",
3
+ "version": "0.7.3",
4
+ "description": "JavaScript library for mobile-friendly interactive maps",
5
+ "scripts": [
6
+ "dist/leaflet.js",
7
+ "dist/leaflet-src.js"
8
+ ],
9
+ "images": [
10
+ "dist/images/layers-2x.png",
11
+ "dist/images/layers.png",
12
+ "dist/images/marker-icon-2x.png",
13
+ "dist/images/marker-icon.png",
14
+ "dist/images/marker-shadow.png"
15
+ ],
16
+ "styles": [
17
+ "dist/leaflet.css"
18
+ ],
19
+ "main": "dist/leaflet-src.js"
20
+ }