Weekly check in 2012.01.19

• 13:30 <novalis_dt> Hello, everyone.
• 13:30 -!- grant_h [d819d2e1@gateway/web/freenode/ip.216.25.210.225] has joined #opentripplanner
• 13:30 <andrewbyrd> Hi
• 13:30 <mattwigway> Hi
• 13:31 <grant_h> hey
• 13:31 <FrankP> h
• 13:31 <demory> hello
• 13:31 <demory> looks like we have everyone
• 13:32 <demory> i'll check in first
• 13:32 <demory> Still working mainly on OTPsetup -- further fine-tuning of the AWS configuration, some misc. debugging, plus some architectural documentation for show on Saturday. Also doing some work on the web-based visualizer to show Saturday as well.
• 13:33 <FrankP> What's on Saturday, David?
• 13:33 <demory> oh, sorry. TranspoCamp DC!
• 13:33 <novalis_dt> So, I did some work on osmsplit yesterday and the day before
• 13:34 <mattwigway> I'm not totally clear on how OSMSplit integrates with OTP?
• 13:35 <mele> Thanks for that by the way novalis, excited about checking out the fixes as soon as I get the chance
• 13:35 <novalis_dt> mattwigway, it doesn't.
• 13:35 <mele> It's kind of a side thing, matt
• 13:35 <mattwigway> Ah, ok thanks.
• 13:36 <demory> FrankP, we'll probably have some sort of "OTP Progress" session on Sat where we'll talk about the TriMet launch in addition to showing this new work. Anything in particular you'd want us to mention?
• 13:36 <novalis_dt> I'm actually still not 100% clear on what it's used for :)
• 13:36 <mele> It's for helping TriMet translate the OSM basemap data into data it can use for operations
• 13:38 <novalis_dt> I would love to see some of that operations software at some point
• 13:38 <novalis_dt> Just so that I have an idea of what I'm working with :)
• 13:38 <PJ______> the secretive operations software?
• 13:38 <FrankP> demory, I can't think of anything in particular to point out. We're looking to replace ride.trimet.org (running proprietary planner) with rtp.trimet.org by June. GeoCoder we're currently using for both is ATIS...but I'm working on a better geosearch tool using Apache SOLR as a replacment.
• 13:39 <novalis_dt> Ah, secretive :)
• 13:39 <andrewbyrd> I'm working on WMS tiling / caching for analytics. Having some difficulty properly matching CRS between layers in OpenLayers. I may move over to Leaflet -- that's what you're using, right David E?
• 13:39 <demory> that's correct
• 13:41 <andrewbyrd> Which day do you want to do the isochrone demo, Saturday?
• 13:41 <demory> yeah though no worries if it's not ready then. we have plenty of other OTP stuff to show
• 13:42 <demory> i'm not worried about filling that hour!
• 13:42 <mattwigway> I wish DC was closer to SF, sounds really interesting, wish I could be there.
• 13:42 <demory> but if anything with the isochrones is ready we will certainly work it in
• 13:42 <andrewbyrd> There's a San Francisco transportation camp as well, right?
• 13:43 <demory> mattwigway we did one of these in SF last year, i'm sure there will be another at some point
• 13:43 <mattwigway> I was at the one last year (a volunteer in fact), can't wait for another one. Hopefully it comes before I move in August/Spetember.
• 13:44 <demory> yeah there's no set schedule beyond this but there's certainly a lot of interest. so stay tuned..
• 13:45 <demory> so any other OTP business? TriMet folks, anything in particular?
• 13:45 <novalis_dt> Yeah, July is about the right time to visit SF.
• 13:45 <mattwigway> Nice and foggy :)
• 13:45 <PJ______> we're talking about accessibility stuff, but not ready to present anythig yet, i think? unless mele & grant know more.
• 13:45 <novalis_dt> Less freezing, less rain :)
• 13:46 <FrankP> Not from me, but I'm curious...why Leaflet over OpenLayers? Mobile? Simple? (Won't you be pissing off the OpenGeo folks?)
• 13:46 <kpw> accessibility for ped routes?
• 13:46 <PJ______> yes
• 13:46 <PJ______> and to get to a bus stop
• 13:46 <kpw> awesome--i'd love to follow the progress there
• 13:46 <mele> Yeah we should have a plan of action in the next couple of weeks
• 13:46 <kpw> i've been talking with folks in other cities about how best to encode that
• 13:46 <kpw> are you following the CUTR OSM encoding approach?
• 13:46 <mele> Great kpw we should probably chat about what we have in mind
• 13:46 <PJ______> data seems to be the big limit
• 13:47 <kpw> with paths for the sidewalks/crossings?
• 13:47 <mele> Not exactly
• 13:47 <mele> But very close
• 13:47 <kpw> ah ok, love to know the approach
• 13:47 <kpw> re: Leaflet vs openlayers
• 13:47 <mele> Yeah we still have to nail it all down but should know soon
• 13:47 <PJ______> yeah, our area has a lot of sidewalks, so...
• 13:47 <andrewbyrd> FrankP: on my end it's just because I know demory is using it, and I want to see how it behaves with the travel time layer
• 13:47 <kpw> openalayers hasn't kept up in terms of UX for public facing apps
• 13:47 <kpw> it's much more focused on GIS applications
• 13:48 <kpw> and does a great job there
• 13:48 <mattwigway> I've been working on elevator support, initially for a campus on a hill, but maybe for indoor mapping in future.
• 13:49 <mattwigway> It could probably also be used for micromapped stations.
• 13:49 <kpw> we'll use whatever is best for the task.. hopefully that will encourage the openlayers team to innovate, but honestly i don't think public facing stuff like ours is in their target market
• 13:49 <kpw> PJ______: cool, let me know if you all get to the point where you can demo your approach
• 13:49 <PJ______> we will
• 13:49 <novalis_dt> mattwigway, I'm excited to merge those changes
• 13:49 <demory> i've found leaflet to be both simpler to use and still very good performance-wise -- e.g. for the graph visualizer it can display tens of thousands of vertices w/ no problem
• 13:50 <novalis_dt> FrankP, did you have a chance to look at my question on #583?
• 13:50 <mattwigway> novalis, I'll probably need to back off a bit in the next few weeks because of deadlines in other projects (and a ramp up of schoolwork :)
• 13:51 <FrankP> looking now...novalis_dt
• 13:51 <mattwigway> But I'll definitely have more time in early Feb, hopefully a bit before that too.
• 13:51 <novalis_dt> mattwigway, cool. We'll still be here :)
• 13:51 <mattwigway> It turned out to be a bit of a can of worms, especially the data stuff
• 13:51 <mattwigway> Incidentally, mele, thanks for the properly tagged elevators in Portland.
• 13:52 <grant_h> w/r/t to accessability features I'm working on a presentation that explains what we're looking to implement, which I can pass along to anyone who's interested
• 13:52 <novalis_dt> grant_h, I'm definitely interested. But if you prefer, I can wait until you're done.
• 13:52 <mattwigway> grant_h, me too.
• 13:53 <grant_h> novalis_dt: sounds good, should have it done some time next week
• 13:53 <mele> Haha you're welcome, there are a lot more to do :)
• 13:53 <andrewbyrd> mattwigway: thanks for your contributions. There are going to be some conflicts between your branch and mine - I could take care of that, just let me know when your elevator code is stable.
• 13:53 <novalis_dt> Speaking of which, kpw, what would it be useful for me to do for the remainder of the week?
• 13:53 <mattwigway> I trust you've seen my branch, or no?
• 13:54 <mattwigway> If we want to see how to work around some issues, we can probably do a pull request between the two branches, not for merging but just to see conflicts.
• 13:55 <andrewbyrd> mattwigway: just looked at it quickly but I've been following your emails, so I know there will be some changes to make in the graphbuilder.
• 13:55 <kpw> novalis_dt & andrewbyrd: any value in you two collaborating on the analytics changes?
• 13:55 <kpw> andrewbyrd: not sure if you're at a point where you can use help
• 13:55 <kpw> but just curious
• 13:55 <novalis_dt> I would be happy to jump in.
• 13:56 <mattwigway> andrewbyrd, which branch is yours?
• 13:56 <kpw> novalis_dt: otherwise, i've got another small project i'd like to run by your (mostly for feb) but we should connect up on that tomorrow in dc
• 13:56 <andrewbyrd> if novalis_dt is interested in working on it, sure.
• 13:56 <novalis_dt> andrewbyrd, absolutely. Drop me and email or find me here. Or, even better, ticket some tasks.
• 13:58 <mattwigway> One other thing I've been bouncing around in my head is area routing. It's not something I'll implement in the short term, but I have some ideas.
• 13:58 <andrewbyrd> though this week I just want to see the tiling work right and evaluate the performance. it's all planned out but I need to implement. Once I push that code I'll ticket some tasks.
• 13:58 <novalis_dt> mattwigway, that's definitely something we would like to have.
• 13:59 <kpw> area rputing as in "free space" routing?
• 13:59 <mattwigway> I think it consists of building a visibility graph, basically turning areas to (lots and lots of) edges.
• 13:59 <mattwigway> kpw, yes
• 13:59 <mattwigway> across plazas, parking lots, etc.
• 13:59 <andrewbyrd> So kpw & novalis_dt, if you have another project to work on maybe we can start collaborating on analytics after this weekend
• 13:59 <kpw> some folks sent me some articles about this over the holidays drawing from video games
• 14:00 <mattwigway> Neat. I'd love to see them
• 14:00 <novalis_dt> It might be possible to dynamically generate those regions
• 14:00 <novalis_dt> kpw, I think I saw that one, actually. They're generally grid-based, right?
• 14:00 <mattwigway> If you want this implemented in the short term, I can write an email or wiki page with what I've been thinking.
• 14:00 <mattwigway> and someone else could implement it
• 14:00 <kpw> http://www.ai-blog.net/archives/000152.html
• 14:01 <mattwigway> some of my thoughts are at https://github.com/openplans/OpenTripPlanner/wiki/Indoor-Mapping but that page is a little outdated with what I've been thinking about lately.
• 14:01 <novalis_dt> Oh, hm, I was thinking of a different article.
• 14:01 <andrewbyrd> mattwigway: vertexEdgeTypes is my branch. I need to clean it up and merge to master. Actually that's a priority since it would facilitate others working on analytics.
• 14:02 <kpw> i also know that the military applications use a 10m triangular grid
• 14:02 <kpw> what's the application you have in mind?
• 14:03 <novalis_dt> Yes, the visibility graph was what I had in mind, although pregenerating a complete graph (n^2 edges) seems excessive if we could instead generate the list of edges on the fly.
• 14:03 <mattwigway> Maybe so.
• 14:03 <novalis_dt> Maybe we would end up generating n^2 edges anyway, or maybe we could find some way to limit it.
• 14:04 <kpw> so the primary application is indoor?
• 14:04 <mattwigway> You could use a directed search to only generate edges that are needed, i.e. start by generating edges from one node, then follow edges from that node towards the goal and so on.
• 14:04 <kpw> the question i have, is how do you communicate the route?
• 14:04 <mattwigway> I think indoor is primary.
• 14:05 <kpw> what degree specificity is required?
• 14:05 <mattwigway> As in narrative, probably "across" or "around" depending on the angle.
• 14:05 <mattwigway> the map is essential, as is what path they're connecting to.
• 14:06 <mattwigway> The other thought I had that's much simpler but only works for convex non-donut polygons is to store the whole polygon as a vertex.
• 14:06 <mattwigway> and let the vertex worry about traversal
• 14:06 <mattwigway> but that quickly makes no sense when you have a concave polygon
• 14:06 <mattwigway> Imagine a horseshoe plaza with a path closing the open end. That's an edge connecting a vertex to itself.
• 14:07 <novalis_dt> Yeah, that would definitely be wrong
• 14:07 <kpw> ok--i'm just trying to think about applications where it's really free space and not just a network
• 14:07 <novalis_dt> I think it might still be complicated to figure out costs if a convex polygon were treated as a single vertex.
• 14:08 <kpw> it seems like in most buildings it could be reduced down to a network of corridors, unless you're trying to do obstacle avoidance (as the game folks are )
• 14:08 <kpw> or are navigating over large open areas (like the military)
• 14:08 <novalis_dt> Yeah, in most cities, outdoor areas are relatively small
• 14:09 <mattwigway> Even in a large area, the shortest path is always along straight lines connecting a varying number of vertices.
• 14:09 <novalis_dt> But still, it's annoying to see directions to go around rather than through a park
• 14:10 <mattwigway> Well, they'll go straight across where they can, otherwise snap to the edge going around things.
• 14:10 <mattwigway> If I could draw you a picture it'd be a lot clearer, just a sec.
• 14:10 <kpw> yeah, i guess the park routing makes sense, though there are usually paths in urban parks
• 14:10 <kpw> no need to draft anything up right now
• 14:10 <kpw> but i'd love to keep thinking about this
• 14:10 <kpw> a couple other folks have brought it up recently
• 14:10 <mattwigway> I think plazas make more sense than parks, parks you usually stick to the paths though.
• 14:11 <kpw> i'm just trying to understand where it's most useful
• 14:12 <mattwigway> novalis, here's what I was thinking of: https://docs.google.com/drawings/d/1Zl2vbKuHGjn5KauUuimEOu9jt_Sc9tPX0aD1Gr_pSeg/edit
• 14:13 <mattwigway> kpw, good in large rooms and, say, quad of universities, public squares, &c.
• 14:13 <novalis_dt> Yeah, that's definitely a complicated case.
• 14:13 <mattwigway> It's perfect for a visibility graph solution though; edges connecting all nodes that can have straight lines drawn between them.
• 14:15 <novalis_dt> You may need to introduce nodes in otherwise non-routable areas of the graph (for instance, if the area to the south of your drawing were water)
• 14:15 <mattwigway> There need to be nodes along the edges of the water at least.
• 14:15 <novalis_dt> yeah
• 14:16 <mattwigway> The trick is I imagine a pond in a park is modeled as exactly that in OSM, so we need to also avoid paths that pass through other non-routable areas.
• 14:16 <novalis_dt> Right.
• 14:16 <mattwigway> sorry to monopolize the conversation, if folks want to move on that's fine.
• 14:17 <demory> no it's an interesting problem
• 14:17 <mattwigway> agreed :) that's why I like to think about it.
• 14:17 <demory> so we should definitely keep thinking about it
• 14:18 <demory> though in the meantime, anyone have anything else for this week?
• 14:18 <andrewbyrd> demory, do you have a leaflet-based client already built somewhere?
• 14:18 <demory> otherwise i should get back to preparations for friday
• 14:19 <demory> andrewbyrd, not online, though I can upload what I have for the visualizer
• 14:20 <demory> should I put that in the opentripplanner-analyst repo?
• 14:20 <andrewbyrd> if you're in a good place to do so, sure. It's probably better for me to fork your client than build yet another one.
• 14:22 <andrewbyrd> though I guess it will interact primarily with core OTP, not the analytics server
• 14:22 <demory> yeah right now it interacts entirely w/ OTP
• 14:23 <demory> so maybe it should be a new module in the main OTP repo?
• 14:23 <FrankP> I'd like to see the code too, if possible. I'm interested in the library in action, but haven't really seen anything built with Leaflet that is all that complex (so feel free to send this and other sites along).
• 14:23 <demory> i kind of see this becoming an replacement, or at least alternative to, the standalone java visualizer
• 14:24 <demory> which is currently a module within the core OTP repo
• 14:25 <novalis_dt> I would be excited to see a workable replacement to the current visualizer
• 14:25 <andrewbyrd> It's not really clear to me whether these two functions should be handled in the same client. I suppose even if there is a separate analytics client, your debug/visualization client could benefit from interacting with the analytics server.
• 14:25 <novalis_dt> But the A* visualizer is pretty indespensable
• 14:26 <demory> andrewbyrd yes i could see it interacting with both
• 14:27 <demory> maybe i'll just put what I have on my personal github for now so you all can see it
• 14:28 <mattwigway> Can someone reopen #582 for me, looks like someone's commit closed it by mistake.
• 14:28 <andrewbyrd> It wouldn't bother me to have both the standalone java visualizer and the more polished leaflet admin/debug visualizer. That way there is no harm in the standalone visualizer being arcane.
• 14:28 <mattwigway> Agreed. more tools == better in this case
• 14:28 <demory> it's not really polished enough to go into one of the project repos anyway (not mavenized, etc)
• 14:30 <demory> so yeah, i'll follow up when there's something online to see
• 14:30 <demory> anything else?
• 14:30 <novalis_dt> Not here.
• 14:30 <andrewbyrd> Sure, if you can just put it in its own repo for now, we can move it over to core OTP after a while. In the mean time it will serve as an example.
• 14:30 <andrewbyrd> demory: nothing else here.
• 14:31 <andrewbyrd> mattwigway: unless you want to talk about this merge
• 14:31 <andrewbyrd> mattwigway: does your elevatorized otp pass all the tests etc?
• 14:32 <mattwigway> Haven't run the tests in a while, so I'll re-run them. I can't run the full graph-builder integration test, I don't have enough RAM.
• 14:33 <mattwigway> I also know my code has some indentation problems, evidently I still don't have Emacs set up correctly.
• 14:34 <mattwigway> Here's a dummy pull request of my current code against your branch as base: https://github.com/mattwigway/OpenTripPlanner/pull/2
• 14:38 <andrewbyrd> OK thanks. At first glance it doesn't look like we'll have too many problems. I have to get going but will check it out later.
• 14:38 <mattwigway> Ok, see you around.
• 14:38 <novalis_dt> See you!
• 14:38 -!- mattwigway [~matthewc@adsl-75-36-157-173.dsl.pltn13.sbcglobal.net] has left #opentripplanner
• 14:40 <novalis_dt> I look forward to seeing some of you at tcamp, and talking to the rest of you next week (or whenever you email!)
• 14:46 <andrewbyrd> talk to you later, bye.
• 14:46 -!- andrewbyrd [c3ddc10f@gateway/web/freenode/ip.195.221.193.15] has quit [Quit: Page closed]
• 14:48 <demory> ok thanks everyone!