Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/dkm/gpsbabel-python-filter

Adds an output filter that uses python as backend.
https://github.com/dkm/gpsbabel-python-filter

Last synced: 8 days ago
JSON representation

Adds an output filter that uses python as backend.

Awesome Lists containing this project

README 

        
If you're interested in contributing to this program, here are some

guidelines.  Mail patches to [email protected] for

consideration and integration.



Rules to Live By

----------------



Standards are good.   ISO C and POSIX are greatly preferred.



Reuse is good, if doing so is not onerous.  For example, using the expat

libraries vastly simplifies the XML parsers while increasing their

robustness plus those libraries are ubiquitous.  So I consider it OK to

require expat.



You may find format_skeleton.c and filter_skeleton.c in the source tree

to be helpful examples. Just add meat!



Compilers complain for a reason.   Code shouldn't emit warnings.



The entire world doesn't run .  I've tested this code on

at least five different OSes.  If you find yourself wanting to insert

compiler or OS specific magic, please resist.



Coding consistency is encouraged. The reality is we have a lot of code

that was written by different authors. Some code from other projects is

included. We don't have immutable rules about code style (indention,

curly location, whitespace rules, etc.) but we do ask that you try to

match what is around any code you modify.  "When in Rome..."  



If writing new code, we'd prefer a style like:



	int

	mumble(int whatever)

	{

	if (whatevever) {

	return blah;

	}

	}



...but if you're submitting a new source file that you intend to

maintain and are convinced that two space indents will make the world a

better place, knock yourself out.  But if you need to add a line of code

to the above before "return blah" and do it with spaces instead of hard

tabs, that would be bad.



Submitting Patches

------------------



If you are creating a new target you should submit patches (use 

"cvs diff -uN" to create patches) to the following files:

* Yourcode.c and/or Yourcode.h - this is the code required to do your

  conversions and any support files that your code requires.

* vecs.c - an updated vecs.c file implementing your conversion code into

  GPSBabel.

* Makefile - an updated Makefile telling the compiler how to build and link

  your conversion into GPSBabel

* testo - an updated script that tests your conversion (this should produce

  no output if all is good, see the current testo script for examples)

* YourOutput - a sample file of code produced by your function (used in testo

  and lives in a directory called "reference").

* Documentation - see below.



Please ensure that you are building and testing against the latest code

from the top of the CVS tree and that any code you modify is the latest

version from the CVS - Note: code changes sometimes occur frequently!



Documentation

-------------



HTML and text documentation are generated automatically from DocBook 

source located in the "xmldoc" directory.  That directory contains 

two subdirectories of interest: "formats" and "filters".  If your

contribution adds or affects a format, you'll want to be in the "formats"

directory.  Otherwise, you'll want to be in the "filters" directory.



You should contribute a file called "yourname.xml", where "yourname" is the

name you would give on the command-line to invoke your new format or filter.  

For example, the arc filter is documented in "filters/arc.xml".



This file contains a general description of your format or filter, any 

limitations in your support for it, and anything else the end user should 

know.  For file formats, links to manufacturers' websites are encouraged.  

The contents of this file are not valid or even well-formed XML on their own; 

they are included into a larger framework.  If you know DocBook, you should 

ensure that the contents of this file will validate if included in a .

If you do not know DocBook, see the other files in this directory for examples 

or see http://docbook.org/tdg/en/html/docbook.html for the gory details.  Tags 

of interest will almost certainly include  for paragraphs, 

 for web links, and  for 

example command lines.



For each option supported by your format or filter, you should also contribute

a file in the "options" subdirectory called "yourname-youroption.xml", again

using the names you would use on the command line to invoke your format or 

filter with that particular option.  For example, the "distance" option to the

"arc" filter is documented in "filters/options/arc-distance.xml".  These 

files are similar to the general description above, and should meet the same

validation requirements.



As of this writing, there are two formats that violate this rule: Magellan 

serial and Microsoft Streets & Trips.  Because those formats have the same

names as other formats, their descriptions are located in "magellan1.xml" and

"msroute1.xml" respectively.  These are special cases, and you should do your

best to ensure that they remain the only special cases.



Note that the automated framework already includes the name and description of

your format and its options as described in vecs.c and yourcode.c, so there is

no need to repeat that information in your documentation.



Enjoy!



Robert Lipe,

[email protected]