Giters

OneBusAway / onebusaway-gtfs-modules

A Java-based library for reading, writing, and transforming public transit data in the GTFS format, including database support.

Home Page:https://github.com/OneBusAway/onebusaway-gtfs-modules/wiki

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Where should transformer strategies live?

laidig opened this issue · comments

commented

Summary:

Currently, there are transformer strategies in both org.onebusaway.gtfs_transformer.updates and org.onebusaway.gtfs_transformer.impl. This caused me some confusion (as not all transformations are documented), and I wrote a duplicate transform.

Is there a reason why they are split?

I propose that they be all moved together into one of the following org.onebusaway.gtfs_transformer packages:

updates
impl (as they implement a strategy)
strategies (a new package)

If someone else opines, I'd be happy to refactor this, test, and submit a PR.
Expected behavior:

They should be in one package.

commented

We've been rushing some changes for the latest project, and this repo could use some cleanup in general. Some things that should happen:

  1. Document some of the hidden gems, like support for s// and m//
  2. Create a plugin convention and pull out some of the agency specific transforms, and start refactoring
  3. Investigate, document, and if necessary implement the ability to commit, apply, or flatten the dao from within a transform. Either that or document that multi-part transforms are not recommended
  4. General cleanup as suggested above
commented

I spoke with the rest of my team and they agree with your proposed changes. We are happy to accept any contributions you are willing to make...

commented

Any thoughts on transform strategies that live outside the onebusaway-gtfs-modules tree? Right now I'm just including onebusaway-gtfs-transformer-cli as a dependency and building a shaded JAR whose main class is org.onebusaway.gtfs_transformer.GtfsTransformerMain, so as to avoid having to tinker with the classpath, but that's not a particularly clean solution.

commented

We've been doing a similar pattern for other modules recently for code not appropriate for the generic/open source repo. So no, no better ideas here so far.