IRC Logs March 6th

[07:06am] jgarnett: morning
[07:07am] jgarnett: emily_g ping? were you able to sort out where layer.refresh() goes?
[07:07am] emily_g: hello jody
[07:07am] emily_g: no
[07:07am] emily_g: I wasn't
[07:07am] emily_g: layer.refresh() doesn't fire any events
[07:09am] jgarnett: um it does something though right?
[07:10am] jgarnett: somehow it adds a bounding box to an area that needs to be repained for a layer
[07:10am] jgarnett: and queues up a RenderJob to handle it right?
[07:11am] emily_g: yes that sounds about right
[07:11am] emily_g: but there are no events there that I can listen for
[07:12am] jgarnett: um from the ui I can listen to the layer state changes; rendering, etc... I think I can listen for layer refresh as well
[07:12am] jgarnett: (I am sorry I am at home on funny mac thing and do not have the source code in front of me)
[07:13am] emily_g: funny mac thing eh? sounds like fun
[07:13am] jgarnett: so if there were no events RenderJob would of been called directly via layer.refresh?
[07:13am] emily_g: LayerImpl.refresh calls getRenderManager.refresh()
[07:14am] emily_g: now that I think somehow calls RenderJob
[07:14am] emily_g: but I guess I need to walk further into the code
[07:14am] emily_g: I kind of stopped there thinking I hit the wall
[07:14am] emily_g: but you have a point; I may need to go further and look at layer state events or render events
[07:15am] emily_g: I have a couple questions about the current udig graph module
[07:15am] jgarnett: sure
[07:15am] emily_g: 1 - it has very few to no comments; this really isn't cool if you are trying to understand what's going on
[07:16am] emily_g: 2 - it looks to me like you can only route on one dataset at a time
[07:16am] jgarnett: (although the news here is that if you need to change how graph works you can - it is not used much yet and has not seen public release)
[07:16am] emily_g: (the waypoints are stored on the map blackboard)
[07:16am] jgarnett: thinking ....
[07:16am] jgarnett: 1. you are correct about the comments; mostly that is because the graph functionality is document well on the geotools wiki
[07:17am] jgarnett: I should go through and add at least class level commens (ie meet the udig requirements for comments)
[07:17am] emily_g: ya; I think that would help
[07:17am] jgarnett: 2. this is something that can be changed I guess
[07:17am] emily_g: I'm not sure we need to change it
[07:17am] jgarnett: it depends on where you store the graph data structure
[07:17am] emily_g: I'm just trying to understand what is happening now
[07:17am] jgarnett: is routing actually making sense on more than one data set?
[07:17am] jgarnett: I could see a public transit one and a car one
[07:18am] emily_g: or trasit; car; walk & bike
[07:18am] emily_g: or maybe you want to test different dataset
[07:18am] jgarnett: but not both at the same time; you would set up what you need and then ask it to generate a route
[07:18am] emily_g: and see how the attributes give you different routes
[07:18am] jgarnett: yeah okay fair enough
[07:18am] emily_g: i'm sorry i'm making up use cases ... I don't actually have that use case ... yet
[07:19am] jgarnett: so the workflow for that package right now places a graph on the map blackboard; we would need it to change and place a graph on a layer blackboard; and make a single renderer to show way points and the route calcualted against that graph.
[07:19am] jgarnett: you guys are using pgRouting; and I am mostly interested in assuring you make use of the catalog api correctly
[07:20am] emily_g: I'm sure we are not
[07:20am] jgarnett: (ie it would be bad form to start doing data access connection stuff at the layer level)
[07:20am] jgarnett: did you get my origional message to Tim?
[07:20am] emily_g: yes I did
[07:20am] emily_g: but I'm still working on understanding it
[07:20am] jgarnett: I tried to think it through ... but I may of missed something. I assume he had gone through Service / Renderer / Style tutorials.
[07:20am] emily_g: You said somewhere that we should just use the postgis connection in the catalog - I don't think we can guarentee this is already a connection in the catalog
[07:21am] emily_g: our client also has some "weird" requirements that they want the connection stuff as a different bundle; so what we do for them will probably be a bit different from what we do for udig
[07:22am] jgarnett: um the requirements are fine
[07:22am] jgarnett: you can add functionality to the udig postgis from a different bundle
[07:22am] jgarnett: backing up to the larger picture
[07:22am] jgarnett: we want to make sure the postgis connection pool is managed stupidly well
[07:23am] jgarnett: and it would be good to share the connection between the postgis datastore and the pgRouting api
[07:23am] jgarnett: is that okay / understandable?
[07:23am] emily_g: yes - you want one connection
[07:23am] emily_g: makes sense to me
[07:24am] jgarnett: well one connection pool
[07:24am] jgarnett: so for your customer do you have access to the udig catalog?
[07:24am] emily_g: aren't connection pools managed by geotools datastores?
[07:25am] jgarnett: (this conversation kind of has two parts; one about how to manage the connection pool and another about how to intergrate with the graph tools)
[07:25am] jgarnett: not really; when you construct a geotools datastore you can hand in a connection pool
[07:25am] jgarnett: (or you can specifiy a bunch of optional parameters and ask it to create you one)
[07:26am] jgarnett: either way will work here; we need to get access to the connection pool for the PostGISserviceImpl
[07:26am] jgarnett: (I think there may already be a resolve target - for ConnectionPool or Connection)
[07:26am] jgarnett: I am not too worried about that ...
[07:26am] jgarnett: mostly about defining an API to access pgRouting; and then making sure you can get the connection pool in behind that api
[07:26am] emily_g: the thing is in the end our client may not want a direct connection to postgis anyways
[07:27am] emily_g: they may want it go to through some middleware connection
[07:27am] jgarnett: Do you have an API for pgRouting yet?
[07:27am] jgarnett: ah right - fair enough.
[07:27am] jgarnett: even more important to make an API then
[07:27am] jgarnett: (and consider spring remoting when implementing the api for your client - in order to reduce the cost of setting up the middleware)
[07:27am] emily_g: yes and no; I'm not really ready to answer that question
[07:27am] jgarnett: okay np
[07:27am] emily_g: i'm still working on it
[07:28am] jgarnett: at somepoint here will be some methods right?
[07:28am] jgarnett: hand in a start and end point and get back a route; or whatever other services pgrouting offers (I have only read about it)
[07:29am] emily_g: yes it is basically that
[07:29am] emily_g: pass in some points & route type and get back geometry
[07:29am] jgarnett: thinking
[07:30am] jgarnett: sorry for the distraction on the postgis front; going through some middleware thing is a bit different
[07:30am] jgarnett: I would probably handle it by defining that API
[07:30am] jgarnett: and sticking that object on the map or layer blackboard
[07:30am] jgarnett: and defining the graph tools against that object (or graph wizard or whatever)
[07:31am] jgarnett: and then I would implement using geotools graph
[07:31am] jgarnett: and implement using the middleware
[07:31am] jgarnett: and if we have call to talk to postgis directly I would go off and play that game.
[07:31am] emily_g: that's sort of what we are doing I think
[07:31am] jgarnett: in some sense that makes defining the api easier; since it comes down to what you need the tools to be able to call.
[07:31am] emily_g: without the geotools graph stuff because that is already handled for us by pg routing
[07:32am] emily_g: the problem I was having was want to do with our pgRouting API implementation; but you are correct - we can put it on the map blackboard
[07:32am] jgarnett: in anycase feel free to manipulate the graph module into that shape; it may even be a helpful move for your project since it would allow you to test prior to the create of the middleware bit
[07:33am] jgarnett: ah right - putting custom components on the map (or layer blackboard) is the way to go.
[07:33am] jgarnett: you may find that you need a bit more lifecucle control;
[07:33am] jgarnett: ie if the layer was deleted you may want to be told about it?
[07:33am] jgarnett: if that is the case we may need to look at making the blackboard a little smarter (ie more into a container)
[07:34am] jgarnett: but no sense causing trouble unless you have the need I figure.
[07:34am] jgarnett: um you did this approach for the birds demo; so I thought it would be fresh in your mind
[07:34am] jgarnett: (still want to write that demo up for others)
[07:34am] emily_g: ya; and I've used it for the mapgraphic rendering problem;
[07:34am] emily_g: just didn't clue into it; too many other things going on
[07:35am] emily_g: i have a meeting shortly and I need to eat so I'm going to run away
[07:35am] emily_g: thanks for the help
[07:35am] emily_g: is there an official irc meeting tommorrow?
[07:35am] jgarnett: okay; I will post these logs; and spend the rest of the meeting timeslot here on sorting jira bugs.
[07:35am] jgarnett: Today is friday for me; and this is the meeting timeslot.
[07:36am] emily_g: okay I'm confused between what day it is
[07:36am] jgarnett: Andrea wanted to go over Jira bugs (in prep for a code sprint) tomorrow
[07:36am] jgarnett: np
[07:36am] jgarnett: that is what weekends are for; to help you organize what day is where (or when?)
[07:36am] jgarnett:
[07:42am] jgarnett: thanks for the chat emily