Skip to content

2012.03.22 Weekly Check In

demory edited this page Mar 29, 2012 · 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 [~[email protected]] 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
Clone this wiki locally