Skip to content

Weekly check in 2012.03.22

Andrew Byrd edited this page Dec 17, 2014 · 1 revision
  • 13:31 <demory> hello everyone
  • 13:31 <grant_h> hi
  • 13:31 <andrewbyrd> hi, what's up?
  • 13:32 <andrewbyrd> ah, meeting time. DST mismatch caught me again.
  • 13:32 <demory> oh, sorry!
  • 13:33 <demory> yeah, it's check in time
  • 13:33 <demory> i had my own DST mishap earlier this week..
  • 13:33 <demory> did you know Arizona does not recognize DST? fun fact of the day
  • 13:34 <demory> anyway let's get started, i think this is everyone (David T won't be joining us today)
  • 13:34 <andrewbyrd> not your fault! google calendar keeps track nicely, but the local time of the meeting is starting to be etched into my mind, and only changes for a couple of weeks at a time due to the offset
  • 13:34 <andrewbyrd> I think david turner is right about fighting to abolish DST.
  • 13:34 <mele> neither does Hawaii :)
  • 13:35 <mattwigway> I was getting used to leaving for school in the light :)
  • 13:35 <demory> yeah, thankfully my confusion w/ AZ meant I was an hour early -- better than the other way around!
  • 13:35 <demory> anyway, my update: still mostly focused on OTPSetup, working out some bugs and workflow/interface issues before we do an official announcement to the lists. Would like to do that by the weekend though!
  • 13:35 <demory> Also, I presented via web conference to the national RTAP (rural transit assistance program) conference in Scottsdale Tuesday.. they have an excel-based GTFS builder tool targeted a small tribal systems and the like. Lots of interest in OTP, though a common question had to do w/ support for deviated-route services and demand-response. Just something to be thinking aboug long term..
  • 13:36 <demory> that's it for me this week
  • 13:38 <andrewbyrd> I've also been helping with testing out these large multi-feed cases, resolving or at least annotating some data quality issues that have come up (eg repeated stop times, a bug in JTS).
  • 13:38 <andrewbyrd> we changed the default OTP map tile set
  • 13:38 <demory> yeah it looks a lot nicer
  • 13:39 <demory> see http://req-30.deployer.opentripplanner.org/ (an nyc area graph)
  • 13:39 <andrewbyrd> working on the reusable spt request objects and seeing if that plays well with Guice servlet (<-- analyst)
  • 13:39 <demory> so is that a free tileset? (or free to a certain usage limit?)
  • 13:39 <kpw> free to a usage limit
  • 13:40 <kpw> but i think we can include it in the default build, as folks won't be hitting the limit with their local apps
  • 13:40 <mele> I <3 MapBox streets
  • 13:40 <kpw> plus there's no api key
  • 13:40 <kpw> mele, yeah! it's pretty great
  • 13:41 <andrewbyrd> they just provided the urls for their tile server in a howto on the site, and those URLs have no app key...
  • 13:41 <andrewbyrd> so basically each individual user's client is seen as a separate user I suppose
  • 13:41 <kpw> yep
  • 13:41 <kpw> that's my take
  • 13:41 <kpw> i think they'll figure the usage stuff out later
  • 13:41 <demory> i like the mapbox light tileset too -- could be very useful for analyst and system-map overlay apps
  • 13:42 <kpw> yeah, light is really good for overlays
  • 13:42 <mele> yeah it would be perfect for that
  • 13:42 <andrewbyrd> demory: good point. though I think their basic tileset is understated enough to look good with overlays
  • 13:43 -!- EvanCC [~EvanCC2@cpe-98-14-235-6.nyc.res.rr.com] has joined #opentripplanner
  • 13:43 <demory> yeah, it's certainly an improvement over the OSM default
  • 13:43 <kpw> yep! thanks for making the swithc.
  • 13:45 <demory> so any other check-ins / news?
  • 13:46 <FrankP> found a pretty bad bug yesterday - https://github.com/openplans/OpenTripPlanner/issues/647
  • 13:47 <FrankP> (bad, in that it makes for a confusing itinerary when the start icons on the map are in the wrong place)
  • 13:47 <kpw> FrankP: yeah i've been noticing that too
  • 13:47 <kpw> thanks for pining it down
  • 13:48 <demory> hmm. I wonder if that's related to how the elev graph sometimes doesn't get drawn at the very beginning
  • 13:48 <demory> i've noticed that from time to time
  • 13:49 <FrankP> kpw, no problem. demory, it seems pretty consistent with begin walk/bike legs. I did release a new graph yesterday with that problem. also using Dave's map builder stuff -- org.opentripplanner.graph_builder.impl.map.MapBuilder
  • 13:50 <kpw> frankp: what are you doing with the map builder?
  • 13:50 <andrewbyrd> yes, we should fix that soon since it's so visible, probably just a small tweak in the plan generator method
  • 13:50 <FrankP> (btw, problem seems unrelated to MapBuilder)
  • 13:51 <FrankP> kpw, there were points that snapped to parking lot isles, etc... MapBuilder post prcessing snaps better to street point.
  • 13:51 <mattwigway> How do you enable MapBuilder?
  • 13:51 <andrewbyrd> mattwigway: it's a graphbuilder module
  • 13:52 <andrewbyrd> on a totally unrelated subject, I was noticing that on a smallish screen, the elevation graph seems to crowd the map visually. this is just an esthetic detail, but I was thinking it would look nice if the graph background was transparent and the map continued behind it.
  • 13:53 <demory> yeah, the graphbuilder docs on the wiki should be updated to include the mapbuilder.. I'll try to get around to that later
  • 13:53 <mattwigway> demory: thanks
  • 13:53 <demory> actually, is MapBuilder part of the core release now? Last I was using it, it was still in an experimental branch
  • 13:54 <grant_h> andrewbyrd: I've noticed that too, it'd be nice if you could resize the elevation window
  • 13:54 <mele> or have a hide/show button or something
  • 13:55 <mattwigway> There is a hide/show button: the little triangle above the graph.
  • 13:55 <mele> ah, well then
  • 13:55 <demory> the elevation profile code can accept an arbitrary height, so having it be resizable should be pretty doable
  • 13:56 <demory> it would just need to listen for an EXT resize event on that component, i think
  • 13:56 <demory> and then redraw itself
  • 13:56 <FrankP> mattwigway, <bean id="mapBuilder" class="org.opentripplanner.​graph_builder.impl.map.​MapBuilder"/> Here's the bean -- put it after you load the OSM and GTFS but before linking.
  • 13:57 <mele> hmm... seems to be bugging out with our version a bit
  • 13:57 <demory> btw I answered my own question, MapBuilder is in 0.5
  • 13:58 <demory> mele, you mean showing/hiding the elev graph?
  • 13:59 <mele> yep
  • 13:59 <mele> it may just be with our version, checking yours now that you linked to earlier
  • 14:00 <andrewbyrd> demory: is it feasible to alpha-overlay the graph onto the map rather than putting it in a separate box?
  • 14:00 <demory> yeah, i see -- hiding it (so that the map takes up all the vertical space) then showing it again fails to scale the map back down
  • 14:00 <mele> demory: yeah you actually have same problem. The background of the mini-graph below goes transparent too
  • 14:01 <demory> mele, I think it's always transparent, it just expects a white bg behind it
  • 14:01 <mele> ah
  • 14:02 <demory> andrewbyrd, what you describe is basically the behavior we're seeing if you hide then show that lower elev panel
  • 14:03 <demory> it looks a little strange
  • 14:04 <andrewbyrd> ah ok. I imagine the colors and layout logic would have to be changed a little for it to look good. just an idea, I might try it out someday since the behavior is already there, if by accident :)
  • 14:05 <demory> yeah, if you go to the trip in https://github.com/openplans/OpenTripPlanner/issues/647 (since we were just talking about that), minimize the elev graph, then show it again, you'll see what we mean
  • 14:08 <demory> btw, I've been thinking about a "next generation" front-end where there are no panels, i.e. the map takes up the whole screen and things like the graph, itinerary, etc. would be resizable, draggable windows in the foreground
  • 14:08 <demory> kpw I think you had started on something like that for dc using leaflet
  • 14:08 <kpw> demory: +1
  • 14:08 <kpw> yep, i've got a basic Leaflet client going
  • 14:08 <kpw> that does exactly that
  • 14:08 <kpw> need to finish it and make use of the new JSONP api
  • 14:09 <demory> yeah that's a longer term project, but something to keep in mind as we talk about general UI stuff
  • 14:09 <kpw> I haven't implemented anything like the bike graph yet but want to follow andrewbyrd's recommendation with making those kind of things not reduce the map area
  • 14:11 <demory> you could reuse most of the elev graph drawing code, it's just the container that would change
  • 14:11 <demory> it'
  • 14:11 <demory> s design to be scalable to arbitrary spaces
  • 14:12 <andrewbyrd> kpw: of course the graph will still eat into the map, but people usually keep a lot of non-itinerary map around the edges for context... this gives them a bit more context
  • 14:15 <demory> alright, anything else for the chat today?
  • 14:16 <andrewbyrd> nothing else here
  • 14:16 <mele> nope, putting in some more elevators for mattwigway to play with though :)
  • 14:16 <FrankP> demory, I have it on my todo for this year to replace the text trip planner and other related tools (about 20 web endpoints). Desire is to write a single interface that works on any device / desktop. http://foundation.zurb.com/case-foundation.php
  • 14:18 <FrankP> ideally, a next generation front-end will solve a need for a mobile planner ui.
  • 14:19 <demory> FrankP, very interesting. I'll have to read up on Foundation, I wasn't familiar w/ that
  • 14:19 <andrewbyrd> FrankP: I think a text frontend could be useful in many cases. screen reader, sms service, etc.
  • 14:20 <FrankP> Yeah, we need a text frontend for the screen reader folks out there, and also the few (many) with IE 6.0 / web tv browsers / etc..
  • 14:23 <demory> Ah, Web TV
  • 14:23 <FrankP> (And in general, all the web apps that we build at TriMet ... both internal & external ... are going to have a mobile device component to them -- so again, the ideal solution would be to write it once and have it work on whatever device ... even if that means the ui is a bit more basic than it could be if we just targeted desktops)
  • 14:24 <FrankP> (demory, we've had (within the past three years) folks that complained that our site no longer ran on their web tv boxes :-)
  • 14:25 <demory> Yeah, I'm not surprised
  • 14:26 <mattwigway> Regarding visually-impaired users, I've thought for a while that it would be cool to generate printable tactile maps a la http://www.tandfonline.com/doi/abs/10.1080/00330124.2011.595619
  • 14:26 <demory> anwway we should continue this unified UI discussion going forward -- we have a couple of related efforts going on (analyst, the graph visualizer, etc.) that should be pulled together
  • 14:29 <demory> mattwigway, thanks for sharing, that looks promising too
  • 14:30 <mattwigway> Something that could probably be done fairly easily iwith Mapnik.
  • 14:30 <mattwigway> It was published in the AAG Professional Geographer which is where I found it, I don't know if you have access to that. It may also be available directly from the university.
  • 14:32 <demory> ok. once the Deployer work settles down and I get through some other tasks (like the long-awaited new otp.com) I'd like to look more at the UI stuff in general
  • 14:33 <demory> well speaking of which, i should get back to work on OTPSetup. anything else for today?
  • 14:35 <demory> i think that's it then. thanks everyone!
  • 14:35 <kpw> thanks!
  • 14:35 <andrewbyrd> bye
  • 14:36 <mele> bye

The documentation on this wiki is outdated and should not be used

unless you are intentionally working with legacy versions of OpenTripPlanner. Please consult the current documentation at readthedocs

Clone this wiki locally