Weekly check in 2012.02.02

• 13:30 <novalis_dt> Good afternoon, everyone.
• 13:30 <demory> good morning/afternoon/evening everyone
• 13:31 <mattwigway> Morning
• 13:31 <mele> Hi everybody
• 13:31 <andrewbyrd> Hi
• 13:31 -!- pj_______ [465a8742@gateway/web/freenode/ip.70.90.135.66] has joined #opentripplanner
• 13:31 <grant_h> hey guys
• 13:31 <demory> are we expecting Frank to join? should we give him another minute?
• 13:32 <novalis_dt> I've got to run a bit early for a doctor's appointment, so if there's anything you want to ask me specifically, please do it early.
• 13:32 <demory> ok
• 13:32 <demory> well let's get started then
• 13:32 <demory> let's do quick check ins first
• 13:32 <demory> I've been feeling a little under the weather this week, so not as much progress as I'd like, but I have been working on a couple things. On OTPSetup, I'm working w/ Evan at OP on getting the network architecture to a point where public addressing can be done consistently.
• 13:33 <demory> Also, have uploaded some initial work on a leaflet based front end for visualizing the graph internals: https://github.com/demory/otp-visualizer
• 13:33 <demory> that's it from me, for now
• 13:34 <novalis_dt> I've been working on trying to merge geometries for the system map view. Unfortunately, it's going a bit slow.
• 13:34 <novalis_dt> I may try another approach if this fails.
• 13:36 <pj_______> grant finished a first version of the accessibility presentation
• 13:36 <pj_______> it's going through a revision but maybe he can send it to you guys once he's done.
• 13:36 <novalis_dt> I actually read that first version
• 13:36 <pj_______> nice
• 13:36 <novalis_dt> I wanted to discuss it, if you guys are interested
• 13:36 <demory> yeah we saw the one you sent yesterday
• 13:36 <mele> yeah please
• 13:36 <mattwigway> Very nice.
• 13:36 <pj_______> way to include me on that email grant. ;-P
• 13:37 <pj_______> input?
• 13:37 <novalis_dt> So, I think if you're going to do all the research on station accessibility, you should individually tag each feature, if that's possible
• 13:37 <novalis_dt> Rather than simply giving a number
• 13:37 <pj_______> we already have the station data
• 13:37 <pj_______> it's in our own database
• 13:37 <pj_______> not osm
• 13:37 <mele> yeah well the problem is TriMet doesn't want to have to maintain it in OSM
• 13:37 <mele> right
• 13:38 <mele> so the number will be automatically generated from the TM database
• 13:38 <novalis_dt> Would we be able to get access to the raw data instead?
• 13:38 <novalis_dt> Here's the reasoning
• 13:38 <grant_h> right, the ratings won't actually be in osm
• 13:38 <pj_______> who's we?
• 13:38 <novalis_dt> A bus shelter only helps when you are waiting for a bus
• 13:38 <pj_______> the developers?
• 13:38 <pj_______> or the users?
• 13:38 <novalis_dt> Well, the graph builder process
• 13:39 <pj_______> aw, ok
• 13:39 <mele> could the graph builder maybe read it from GTFS?
• 13:39 <novalis_dt> Sure.
• 13:39 <pj_______> but is that info in GTFS?
• 13:39 <mattwigway> Depending on the user, other things may be more or less important as well, for instance a wheelchair user doesn't need seating at the stop.
• 13:39 <pj_______> or just at Trimet?
• 13:39 <mele> ok we may be able to do it that way. I think it is to some extent
• 13:39 <novalis_dt> So, we want to prefer stops with landing pads for both boarding and alighting, but we want to only prefer stops with shelters for boarding.
• 13:40 <pj_______> that's a good point
• 13:40 <pj_______> yeah, if otp can consider that stuff... it might be better
• 13:40 <novalis_dt> Yeah, since we're already generating highly individualized trip plans, we might as well have all the bells and whistles
• 13:40 <pj_______> ha, ok
• 13:41 <pj_______> and as for osm data, that part has the ability to expand
• 13:41 <pj_______> when users start adding in crossings
• 13:41 <pj_______> and stuff
• 13:41 <novalis_dt> So far, we're not really sure how to deal with crossing and curb cut data.
• 13:41 <pj_______> was that in the presentation much? otp reading crossings with wheelchar=yes
• 13:41 <pj_______> well, we were thinking of making the tag wheelchair=yes applying to crosswalks that have curb cuts on both ends
• 13:41 <novalis_dt> The presentation mentioned that as a more time-intensive approach
• 13:41 <pj_______> and then also tagging the nodes
• 13:41 <pj_______> but not requiring otp to read the nodes
• 13:41 <novalis_dt> But said that you would be focused on stations/stops for now
• 13:41 <mele> well we would be doing it only around the stops, yes
• 13:42 <pj_______> yes
• 13:42 <pj_______> and if users add in crosswalks with wheelchair=yes/no, then great
• 13:42 <pj_______> otp could hopefully read that too
• 13:42 <novalis_dt> Do you have any wheelchair=no crosswalks?
• 13:42 <pj_______> not yet
• 13:42 <mele> we have none of either yet
• 13:42 <pj_______> but that will be the next setep
• 13:42 <pj_______> we just started this project funding
• 13:42 <novalis_dt> Do you know of any areas in the system that are not accessible?
• 13:42 <mele> ... too many :)
• 13:43 <pj_______> ha, yes. mostly outside portland city limits
• 13:43 <novalis_dt> I think I would like to see a bunch of examples to get a better handle on things.
• 13:43 <pj_______> i bet grant has a bunch of pictures
• 13:43 <pj_______> you mean, in terms of amenities listed in the trimet database, right?
• 13:43 <pj_______> cuz osm doesn't have much data
• 13:43 <novalis_dt> Well, whatever you expect the code to handle
• 13:44 <grant_h> I have a few others that we're in the presentation, but i think the pictures in there give a pretty good idea of the range of stop conditions
• 13:44 <demory> one thing we discussed earlier was setting up a wiki page on accessibility issues -- would be a good place to compile pics, examples, etc
• 13:44 <pj_______> even though supposedly, all our stops are ada accessible...
• 13:44 <pj_______> on github?
• 13:44 <demory> yeah
• 13:44 -!- FrankP [d819d21d@gateway/web/freenode/ip.216.25.210.29] has joined #opentripplanner
• 13:44 <pj_______> ok
• 13:45 <pj_______> i bet grant would love to do that
• 13:45 <pj_______> :0
• 13:45 <pj_______> i mean, :)
• 13:45 <demory> there is some other work on the topic we could include, like Sean Barbeau's earlier work on crosswalk encoding
• 13:45 <novalis_dt> grant_h, so, just to be clear, we're not expecting to handle curb cuts or more generally sidewalks/crossing streets in the code yet?
• 13:45 <demory> i am happy to set up the page
• 13:46 <grant_h> yes, no curb cuts for right now
• 13:46 <demory> but if you have local examples you can add (or send to me) that would be great
• 13:46 <pj_______> what about crosswalks?
• 13:46 <pj_______> i feel like we were on the fence about that
• 13:46 <mele> no i think we do want to do that, but we don't need it right this second
• 13:46 <grant_h> the idea behind adding footways/crosswalks to osm around stops is just to make the itinerary a little more detailed in those areas
• 13:46 <mele> right
• 13:46 <pj_______> ok
• 13:47 <novalis_dt> Well, crosswalks are ordinary ways, so they'll be handled
• 13:47 <mele> yeah we'd try to put all of the info as tags in ways
• 13:47 <novalis_dt> And we already handle wheelchair=no
• 13:47 <pj_______> sweet
• 13:47 <mele> what does wheelchair=no do currently?
• 13:47 <novalis_dt> It marks the street segment as not accessible
• 13:47 <mele> ah ok
• 13:47 <novalis_dt> And so if you're planning a wheelchair trip, it will not use that segment
• 13:47 <mele> we wouldn't want to prohibit but put some penalty
• 13:48 <novalis_dt> I assumed that wheelchair=no meant that there was a step or something
• 13:48 <novalis_dt> Maybe wheelchair=caution for a penalty?
• 13:48 <grant_h> we were thinking it could mean no curbcut in some caes
• 13:48 <pj_______> we should research more on tags
• 13:48 <pj_______> that could be sustainable
• 13:48 <mele> right, the problem is sometimes there's no other way but a nearby driveway or something like that
• 13:48 <mele> yeah
• 13:48 <pj_______> and then let you know
• 13:49 <novalis_dt> Yeah, that sounds like wheelchair=caution to me.
• 13:49 <pj_______> we don't want to start adding tags that aren't used b/c users will change it
• 13:49 <novalis_dt> Or something like that
• 13:49 <mele> yeah we definitely need to do more tag research
• 13:49 <pj_______> "subjective" tags are contradictory
• 13:49 <grant_h> and we don't want to completely cuts users off from a stop with the wheelchair=no tag, just guide them to a better footpath if there is one
• 13:49 <pj_______> before dt leaves, we have a question about elevation and bridges i think.
• 13:50 <pj_______> i mean, once we're done with accessibility
• 13:50 <novalis_dt> There's "limited"
• 13:50 <novalis_dt> (on the wiki)
• 13:50 <mele> oh right, yes there is a bridge question
• 13:51 <pj_______> oo, limited. yeah, we'll look at that.
• 13:51 <pj_______> mele, you ask it, you were in contact with alexis
• 13:51 <novalis_dt> There's also the possibility of adding wheelchair:description to the warnings
• 13:51 <novalis_dt> Does that sound useful?
• 13:51 <mele> yeah so we need a refresher for how elevation is calculated over bridges
• 13:52 <mele> i remember you guys saying before that the same elevation was assumed from the start to the end of a bridge
• 13:52 <novalis_dt> I think that's what we do.
• 13:52 <novalis_dt> Well
• 13:52 <novalis_dt> The slope is assumed to be zero.
• 13:52 <mele> Ah, I see
• 13:52 <mele> the issue is we have a few bridges made out of several segments
• 13:53 <mele> some of them definitely have higher high-points than others
• 13:53 <mele> I'm wondering if there's some way we can better capture that, whether that's some change to OSM or the graph
• 13:53 <pj_______> is there a bridge elevation dataset?
• 13:53 <pj_______> anywhere?
• 13:53 <mattwigway> An OSM level map would let you do that.
• 13:54 <mele> but they're all at the same OSM "level"
• 13:54 <mele> generally
• 13:54 <mele> the thing is "flattest" routes seem to go on the Morrison bridge too often
• 13:54 <pj_______> you mean, using layers?
• 13:54 <novalis_dt> Ah, and the Morrison bridge has a big hump?
• 13:54 <mele> yes in that it starts a lot lower and then it's assumed to not have a slope when it does do some climbing
• 13:55 <novalis_dt> Ok, yeah, that's bad.
• 13:55 <mattwigway> Layers <> levels <> level_maps in OSM. A level map could be used, but the bump in the middle would mean a new level (not necessarily a new layer)
• 13:55 <mele> so yeah i'd just like us to start thinking about some solutions to this
• 13:55 <pj_______> you think the counties have bridge elevations?
• 13:55 <pj_______> could we make a tag?
• 13:55 <mele> oh yeah bridge elevation info probably exists somewhere
• 13:55 <novalis_dt> So, OSM has an elevation tag already.
• 13:55 <pj_______> ok
• 13:55 <mattwigway> That's better than a level map, then.
• 13:55 <pj_______> we should get the data and put it in
• 13:55 <pj_______> and then get otp to read it
• 13:55 <pj_______> and wa la
• 13:56 <novalis_dt> OK.
• 13:56 <pj_______> MAGIC
• 13:56 <novalis_dt> I guess the tag needs to be on the nodes
• 13:56 <pj_______> but otp doesn't read nodes
• 13:56 <novalis_dt> Yet.
• 13:56 <mele> Would it? or could it work on the middle segment?
• 13:56 <pj_______> we could put it on the nodes and middle segment at first
• 13:56 <pj_______> until otp jumps to the next level of NODE READING
• 13:57 <novalis_dt> This set of changes will be a bit complex, but definitely doable
• 13:57 <mattwigway> Unified node reading would be great. I read nodes for levels in my elevators-new branch now.
• 13:58 <mele> ok, great well keep us up to date and we'll wrangle that data together
• 13:58 <novalis_dt> Oh, then I'll definitely wait for matt's branch to hit.
• 13:58 <mattwigway> But it'd be prettier if there was a standard way to do it.
• 13:58 <pj_______> the elevation tags look like propsed
• 13:58 <andrewbyrd> There were also problems elsewhere, where the segment marked as a bridge begins and ends in a trench or drop-off.
• 13:58 <pj_______> *proposed
• 13:58 <andrewbyrd> This does affect "flattest" search results.
• 13:59 <mele> could we assume a steady slope from bridge start spot to highest elev segment generally? hmm... yeah, we all still need to think about this a bit more
• 13:59 <novalis_dt> Ah, there's http://wiki.openstreetmap.org/wiki/Key:ele
• 13:59 <mattwigway> Generally I think it's a kind of arc, maybe a parabola or an inverted catenary?
• 13:59 <pj_______> ah ok
• 14:00 <mele> right, yeah that would be more correct
• 14:00 <novalis_dt> Anything that involves multiple edges gets complex
• 14:00 <novalis_dt> My ideal would be to find a simple approximation
• 14:00 <novalis_dt> So, use the OSM ele tags to override the NED.
• 14:01 <mele> right
• 14:01 <novalis_dt> Which would give straight slopes rather than catenaries.
• 14:01 <mattwigway> Probably linear is good enough, maybe linear*1.33 or something to approximate max slope.
• 14:01 <novalis_dt> Flattest is a total hack anyway.
• 14:01 <mele> haha shhhh :)
• 14:01 <novalis_dt> I mean, we're already approximating all the slopes of roads as straight
• 14:01 <mele> as long as it ends up generally intuitively true i'm fine with it
• 14:02 <novalis_dt> That's my view too
• 14:02 <mattwigway> If there's a significant difference, linear is going to be fine. If there's not it doesn't matter.
• 14:03 <novalis_dt> Great. Anything else on elevation?
• 14:03 <demory> so would we be overriding ned w/ osm ele values anywhere they appear, or only on bridge edges?
• 14:03 <novalis_dt> demory, I would say anywhere
• 14:04 <novalis_dt> On the theory that people would not have tagged the OSM unless they knew what they were doing
• 14:04 <pj_______> ha
• 14:04 <mele> ok sounds like there's kind of a plan now, so that's great. let us know when some changes are made and how to go about tagging them.
• 14:04 <pj_______> we'll find out
• 14:04 <mele> haha yep pj
• 14:04 <demory> ok. maybe at least throw a graph builder warning if there is a significant difference
• 14:04 <novalis_dt> demory, there will be on bridges, tho, correctly
• 14:04 <demory> w/ non-bridge/tunnel edges
• 14:05 <novalis_dt> demory, that is hard, because the OSM tags are processed at a completely different time than the elevation
• 14:05 <demory> hmm
• 14:06 <demory> ok, never mind about the warnings
• 14:06 <novalis_dt> FrankP, let me know which of these features I should actually be working on.
• 14:07 <andrewbyrd> we could keep the osm tags in the graph's debug info, associated with the edges, at least through the building process. serializing that could then be optional.
• 14:07 <novalis_dt> Oh, yeah.
• 14:07 <novalis_dt> Good call.
• 14:07 <FrankP> Okay...I'll get back to you (it's up to Bibi ... I'm just a coal shoveller)
• 14:08 <mele> ha then what are we shoveling, FrankP ? :)
• 14:08 <FrankP> BTW, novalis_dt, about issue https://github.com/openplans/OpenTripPlanner/issues/595 ... does the OBA gtfs parser allow extra columns that are not in the gtfs spec?
• 14:09 <novalis_dt> Yes.
• 14:09 <novalis_dt> But I think this is caused by a comma inside a field
• 14:09 <novalis_dt> It's quoted, but maybe OBA-GTFS doesn't handle that?
• 14:09 <FrankP> right...
• 14:09 <novalis_dt> right, meaning you have noticed that it doesn't handle it?
• 14:10 <andrewbyrd> novalis_dt: I noticed some really specific problem with commas in the CSV parser
• 14:10 <novalis_dt> Looks like the spec allows quoted items
• 14:10 <andrewbyrd> trying to remember what it was
• 14:10 <FrankP> no...that I understand what the problem might (or might not) be...
• 14:10 <andrewbyrd> I even submitted a bug report at one time I think
• 14:10 <novalis_dt> Hm.
• 14:11 <novalis_dt> There were some bugs about trailing commas, but this is different
• 14:13 <andrewbyrd> Ah, it wasn't a bug in the parser, it was a bug in the feed. RFC 4180 doesn't allow spaces after commas.
• 14:13 <novalis_dt> This one is a bug in the parser, I'm pretty sure
• 14:13 <novalis_dt> oh, wait, no it's not
• 14:13 <novalis_dt> That's exactly what's going on here!
• 14:14 <andrewbyrd> Patch: when in state DATA either ignore spaces when (token.length() == 0), or (again when when in state DATA) issue a warning when (token.length() != 0) and the next character is a quote.
• 14:15 <novalis_dt> I think that's a reasonable thing to do.
• 14:15 <andrewbyrd> That will handle the broken CSV, but technically the grammar does not allow spaces after commas.
• 14:15 <novalis_dt> andrewbyrd, are you looking at the code now?
• 14:16 <andrewbyrd> no, I just pulled up the email I wrote at the time
• 14:16 <novalis_dt> Ah.
• 14:17 <andrewbyrd> Well, now I'm looking at it.
• 14:17 <novalis_dt> OK, so we never patched it. But we know that Google's validator accepts it
• 14:17 <novalis_dt> That is, their internal tool and the public one.
• 14:17 <novalis_dt> So we should patch it.
• 14:18 <novalis_dt> I will do that later today.
• 14:19 <novalis_dt> Ok, gotta run.
• 14:19 <andrewbyrd> But the CSV reader is in OBA, that's why I didn't change it before.
• 14:20 <demory> ok thanks novalis_dt
• 14:21 <demory> anyone have anything else? (re my email, let's defer the time-based restriction issue to another chat, it's not urgent)
• 14:21 <mattwigway> I've done a bit with analyst this week, it seems very useful.
• 14:21 <andrewbyrd> My update: I've added colormap and analysis type selection to Analyst, using the layers and styles WMS parameters.
• 14:22 <mattwigway> andrewbyrd's changes to allow grayscale wms allow some heavy duty GIS-based analysis.
• 14:22 <andrewbyrd> The backend can now draw a linear combination of 2 rasters, with methods for subtraction and potential path area built on top.
• 14:22 <mattwigway> I'll share my maps when I'm happy with them.
• 14:22 <andrewbyrd> So two layers other then basic travel time are available, using a destination time/place.
• 14:22 <andrewbyrd> Added draggable origin/destination markers to the client -- the way it's set up now makes for a good demo. Assuming 90 minutes to get from point A to point B, it alpha-masks the map according to how much time you have to perform an activity along the way, at each point.
• 14:23 <mele> ooo fancy
• 14:23 <andrewbyrd> Also finished cleaning up my branch, fixing a couple of bugs. I would like to cut a release first in case someone is depending on the current version.
• 14:23 <mele> can we take a look at that in our test version soon, Frank?
• 14:23 <mattwigway> your branch of OTP, or of analyst, andrew?
• 14:23 <mele> oh nm that's analyst, sorry
• 14:23 <andrewbyrd> branch of OTP.
• 14:24 <andrewbyrd> mele: you can throw an analyst layer into an OTP client with no problem
• 14:24 <mattwigway> Cool, don't let my elevator work hold you up on that-my schedule has veritably exploded this week.
• 14:24 <andrewbyrd> You just need two servers.
• 14:24 <mele> oh great, awesome
• 14:24 <mattwigway> Out of curiosity, can OTP and analyst share the same in-memory graph? I still only have 3GB of RAM and can't run both at once.
• 14:25 <andrewbyrd> mattwigway: nope
• 14:25 <mattwigway> Fair enough.
• 14:25 <mattwigway> Not worth the time to work on it, I should just get more memory.
• 14:25 <demory> andrewbyrd so you've confirmed that for sure?
• 14:26 <andrewbyrd> I looked into that this week. Webapps each have their own classloader, and cannot share objects. It's intentionally designed that way.
• 14:26 <demory> ok
• 14:26 <demory> well good to know
• 14:26 <mattwigway> Has there been any talk of arrive-by tiles for analyst?
• 14:26 <andrewbyrd> You can get around it, but it means defeating what is basically a security feature, and asking other people to do so.
• 14:28 <andrewbyrd> mattwigway: yes, we also need arrive-by to do the potential path area correctly. I need to rework a couple of components to get that working.
• 14:29 <demory> also is there a way to specify banned routes in analyst?
• 14:29 <demory> i'd like to recreate the purple line demo at analyst.otp.org using the new code
• 14:30 <demory> (i suppose i could have two separate instances running at once w/ different graphs, but that seems rather wasteful)
• 14:30 <andrewbyrd> mattwigway: I do think it's questionable to have two copies of the graph in memory to run analyst and OTP together... will keep thinking about how to address modular server functionality.
• 14:31 <andrewbyrd> demory: I would like to just allow tacking full OTP route planner query strings on raster requests.
• 14:32 <demory> ok
• 14:32 <andrewbyrd> but I would like to share code between OTP and analyst to handle turning those queries into TraverseOptions and initial states.
• 14:32 <andrewbyrd> so need to do a little refactoring.
• 14:33 <demory> well for the time being I may just replace the demo w/ the current version of analyst, it still is a big step up visually
• 14:33 <andrewbyrd> if you want to do a demo soon I can just hack something in for proof of concept.
• 14:34 <andrewbyrd> demory: out of the box it gives ever higher resolution at increasing zoom level, so it takes a while for the tile cache to warm up.
• 14:35 <andrewbyrd> if you prefer to trade off resolution for fast response, I can show you how to stick a cache in front of the sample generator that will do so.
• 14:36 <demory> ok, that would be good, but maybe let's put this off until next week? I want to knock out this OTPsetup stuff first
• 14:36 <FrankP> One thing from me: Multiple agencies in a single Graph has caused me problems every time I've tried (the latest being this week) https://github.com/openplans/OpenTripPlanner/issues/594. It's not a priority here (e.g., I don't have the time to even debug). But I hate having a conversation with other agencies about how we could do a regional site, and then we can't. I'm just wondering if we have a larger problem here (or is
• 14:37 <andrewbyrd> demory: sure no problem
• 14:39 <demory> FrankP, what are the specific routing issues you're running into?
• 14:40 <andrewbyrd> FrankP: i saw that ticket and was also wondering what specific problems you were having.
• 14:40 <demory> on the deployed site now, is there a particular trip I should try?
• 14:40 <mattwigway> I've done multi-agency graphs before (Muni and BART) without incident.
• 14:40 <FrankP> Sorry about that...let me get a few example trips in that ticket.
• 14:41 <FrankP> Basically, the routing has many obvious errors when planning trips from one agency to the next.
• 14:41 <mattwigway> Hmmm... don't know if I tried trips with both muni and bart - let me go in the back room and start up the other server to try it.
• 14:42 <FrankP> Like showing trips that on TriMet routes, but with Salem/Cherriots times and stops, etc...
• 14:43 <FrankP> mattwigway...knowing that you have success would be good to know (and feel free to email me your graph-builder.xml if you can)
• 14:43 <demory> yeah i'm noticing some weirdness w/ trips from portland to salem
• 14:43 <demory> we did try a 3-agency deployment in Chicago when testing OTPsetup, and it seemed to work OK
• 14:43 <demory> though I didn't test extensively
• 14:44 <demory> i can actually fire that back up pretty quickly
• 14:44 <andrewbyrd> FrankP - maybe has to do with agency name collisions.
• 14:44 <andrewbyrd> since it's likely that there are routes with the same name at several agencies.
• 14:44 <FrankP> Yeah, I don't know. Here's a simple trip is having problems: http://maps5.trimet.org/otp?submit&purl=/or&fromPlace=45.522429562221,-122.67574920654&toPlace=44.941194005302,-122.99503936761
• 14:45 <FrankP> In that one, Andrew, it's just saying take the TriMet 44 down to Salem (but no other transfer, etc... And no other agency has a line 44, I believe.
• 14:46 <mele> yeah, that's no good
• 14:47 <andrewbyrd> FrankP, I'll need to build the graph and take a look in detail, but I an idea what might be happening, will look into it later.
• 14:48 <demory> fyi, here is that chicago one: http://ec2-174-129-44-94.compute-1.amazonaws.com:8080/opentripplanner-webapp/
• 14:48 <demory> multi-agency (e.g. metra to cta) trips seem to be working ok
• 14:48 <mattwigway> Mine is starting up now, I'll give a screenshot in a moment.
• 14:48 <andrewbyrd> I had similar problems with New York -- stops getting mixed between agencies.
• 14:51 <FrankP> Thanks Guys...good knowing that others have had some success. And again, it's not a priority for us now (but I'm happy to put the bug in your ears on this one ... I'm happy to help debug). Finally, it could be a data issue, since none of these GTFSs (except for TriMet) have been tested with OTP.
• 14:51 <demory> i may also use Portland/Salem as a test case for otpsetup, see if I get the same thing
• 14:51 <demory> since i'm doing testing w/ that now anyway
• 14:52 <demory> ok anything else for the chat?
• 14:53 <FrankP> Thanks David...yeah, please let me know... Nothing else from me.
• 14:53 <demory> will do
• 14:53 <mattwigway> Here's my graph-builder: https://gist.github.com/f65aa9faecf6747fbc78
• 14:54 <FrankP> (thanks Matt ... happy to see default agency id works multiple times...that was failing for me, and might be one issue)
• 14:57 <demory> ok if there's nothing else I think we're done for today. thanks everyone!
• 14:58 <andrewbyrd> OK, bye everyone.
• 14:58 <mele> thanks guys!