Attendees
| IRC nick
|
Real name
|
| apmon |
Kai Krueger
|
| mvexel |
Martijn van Exel
|
| RichardF |
Richard Fairhurst
|
| tmcw |
Tom MacWright
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
Summary
- mvexel pointed out that there's no link to the TTTs from the rails port README, which was fixed during the meeting.
- There was discussion of apmon's routing branch (dev instance / code on github)
- Still needs some JS fixes - tmcw helping out.
- Design issue - probably better not to be adding new tabs for this.
- Deleted items API call.
- Work has not started yet, and may be quite involved.
- Problem is that the deleted items call as implemented for Potlatch 1 would make it difficult to add more integrity constraints to the database.
- OWL-powered history.
- zere needs to finish loading the new OWL server on zark. This is close to completion, but is likely not to be finished until after the license change.
- mvexel wanted to get involved, zere suggested that the front-end part of it could do with a lot of work and that the API is highly flexible at this point, if anyone wanted to expose new functionality.
IRC Log
18:04 < zere> minutes of the last meeting http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-03-05
18:04 < zere> please let me know if there's anything missing / wrong in there.
18:05 < zere> draft agenda for this meeting is to go through the other half of the TTTs we didn't get to last time. and hopefully in enough time to get through AoB too...
18:07 < mvexel> ok so I was confused then
18:10 < mvexel> It's my first time participating here so I can't really comment as to missing items in the minutes.
18:11 < mvexel> let me just say that I did not know of the TTT page
18:12 < mvexel> we might want to link there from the github readme.
18:13 < zere> yeah, that's a good idea :-)
18:14 < mvexel> OK let me take care of that
18:15 < tmcw> y, excellent
18:17 < zere> huh. i just tried that through the github fork&edit interface and now i'm getting a 404. :-(
18:17 * mvexel was just reviewing the git docs to see how he can sync his fork back up with master.
18:18 < mvexel> I am still at the point where git is holding me back more than it is helpting me.
18:19 < zere> well, yeah... i was hoping that fork&edit thing would do the job, but i think the fact that my existing forked repo is out-of-date is stopping it or something.
18:19 < mvexel> So the remaining TTT are Routing frontend, XML deleted items call, OWL-powered activity/history tab, Routing backend
18:19 < tmcw> mvexel: you can just add it as a remote, or your repo as a remote
18:19 < mvexel> If I am reading correctly
18:20 < mvexel> tmcw: I have that already
18:20 < TomH> then rebase (or reset if you just want to make your master equal to upstream master)
18:21 < mvexel> so something like git rebase upstream/master
18:21 < zere> mvexel: yup. if apmon is around, he can probably give us the latest on the routing frontend work.
18:22 < apmon> There is probably not that much to report on it.
18:22 < apmon> I guess the question is whether from a design perspective it is ok?
18:23 < apmon> RichardF said at some point one would have to get rid of the tabs?
18:23 < RichardF> apmon: where's the branch?
18:23 < RichardF> (is it running somewhere?)
18:24 < TomH> mvexel: if you've got local changes then that is the best plan, yes
18:24 < TomH> RichardF: routing.apis.dev.openstreetmap.org
18:24 < mvexel> apmon.dev.openstreetmap.org/routing/ is what I find on the wiki
18:24 < apmon> It hasn't been updated to the changes tmcw introduced yet
18:24 < apmon> mvexel: It is the same, just an alias
18:25 < mvexel> dev is really slow for me though
18:25 < mvexel> apmon: k
18:25 < RichardF> heh, yes, can't get anything from dev right now ;)
18:25 < mvexel> someone is using OWL, likely
18:25 < apmon> It finally loaded for me...
18:26 < tmcw> do people outside of the US call this routing?
18:26 < TomH> yes, we just pronounce it correctly
18:26 < apmon> tmcw: What else would you call it?
18:26 < mvexel> I'd say 'directions' probably
18:27 < RichardF> over here "rowting" (pronunciation-wise) is done with one of these: http://img.directindustry.com/images_di/photo-g/manual-router-469633.jpg
18:27 < mvexel> routing is too technical
18:27 < RichardF> but yes, "Get directions"
18:27 < tmcw> apmon: 'directions' is what this would be called, and is, on google, mapquest, etc.
18:27 < mvexel> It's getting my directions from Salt Lake to Denver now. What is the backend?
18:27 < RichardF> my general UI feeling is that we need to stop adding tabs, and in fact shouldn't have any tabs for things that aren't views on the current bbox (i.e. View/Edit/History)
18:27 < mvexel> OSRI?
18:28 < mvexel> RichardF: agreed
18:28 < tmcw> Where's the repo for this interface? Can it live in a branch of the rails port, or no?
18:28 < apmon> If someone can suggest a better layout let me know
18:29 < tmcw> apmon: I can do some style tweaks if I've got a git repo to clone
18:29 < apmon> tmcw: https://github.com/apmon/openstreetmap-website/tree/routing2
18:29 < tmcw> sweet, thx
18:30 < TomH> technicaly my memory is that the js code needs quite a lot of tidying up
18:30 < apmon> tmcw: If you are up for helping with that, that would be great
18:30 < TomH> it is I think all in the rails views when most of it is static js that would be better as an asset
18:31 < tmcw> Yeah, you see the js_cleanup changes?
18:31 < tmcw> there's a lot to do there, trying to take a first shot or two
18:32 < RichardF> \o/
18:32 < TomH> tmcw: yes - will post some comments later but mostly looks fine
18:32 < mvexel> Is there any way to logically divide that work up?
18:33 * mvexel would be happy to help out
18:33 < tmcw> mvexel: I think so - what I did was just removing dead code and fixing up a few bits.
18:33 < tmcw> See another task in updating to new OpenLayers and using its small api improvements to pare down the application code
18:34 < TomH> we're already on 2.11!
18:34 < TomH> and as soon as 2.12 is release I will update
18:34 < zere> ah, ok - finally got the fork&edit to work: https://github.com/openstreetmap/openstreetmap-website/pull/30
18:34 < tmcw> y, one issue left
18:34 < tmcw> for 2.12 that is
18:35 < TomH> I think 2.12 has all our patches in even
18:35 < mvexel> zere: nice, fast work :)
18:36 < mvexel> tmcw: let me have a look at your js commit and see what I can do to help
18:36 < zere> mvexel: it would have been even faster if i didn't keep my fork of openstreetmap-website shamefully out of date ;-)
18:36 < tmcw> It also might make sense to take a look at refactoring the createMap() function quite a bit, since it's used everywhere
18:39 < mvexel> tmcw: will do as soon as I win my fight with git (again)
18:41 < zere> next item on the TTTs is deleted items XML API call. i have to say i've made no progress on this, and i'm not aware of anyone else having started on it either.
18:42 < RichardF> P1 lives to fight another day then ;)
18:44 < zere> it looks that way. if i ever need to motivate myself on this, i'll remember you said that :-P
18:44 < mvexel> sounds extremely useful but that is over my head for now I believe
18:45 < zere> yes, it is extremely useful, not only in terms of adding this capability to editors (other than PL1), but also so that we can undertake some major refactoring on the API
18:45 < zere> sadly the impending license change is weighing heavier on my mind at the moment. but i'm very happy to help in any way i can if someone wants to take it on.
18:46 < mvexel> does the API require major refactoring then?
18:46 < mvexel> yea my main focus is on license change and its consequences for the data here in the US for now too...
18:47 < mvexel> zere: conceptually it's not a hard problem (the deleted items call)
18:47 < zere> yes, i have some crazy ideas for the API (e.g: support for JSON/AMF/PBF) which will mean pretty hefty refactoring.
18:47 < mvexel> it's just that the database may not be optimized for it, making it an expensive call
18:48 < zere> yeah. it's not hard if implemented in the way that P1's call currently works. unfortunately, supporting that makes it difficult for us to move to the next level of FK-integrity on the DB, which means removing deleted nodes from the current_nodes table so that the current_way_nodes table constraint can work.
18:50 < mvexel> that would clear the way for a history api as well, wouldn't it
18:50 < mvexel> for example a /map? call with a timestamp
18:51 < zere> although i was reading in the postgres docs that FKs can be against any unique key, so it's possible that we could just create a partial index on node_id where visible... but not sure that having that extra index is a good space trade-off...
18:52 < zere> tbh, i think a /map? call with a timestamp would be better pushed to a 3rd party service (or an API on a different machine) - but definitely worth having if someone writes it :-)
18:52 < apmon> I have to go now, see you later
18:52 < zere> apmon: cheers :-)
18:53 < mvexel> ltr apmon
18:54 < mvexel> zere: yes it is not exactly within the scope of the core API to have it. Let's focus on the TTT eh? ;)
18:54 < zere> just before we finish - OWL-powered history tab. also, i've not started on this and (afaik) no-one has yet.
18:54 < zere> mvexel: exactly :-)
18:54 < TomH> well I was waiting for OWL to be up and running first ;-)
18:55 < TomH> but somebody can work on it before that I guess
18:55 < zere> what's needed here is (on my part) to finish loading up OWL on zark, then the development work can really begin.
18:55 < zere> or what TomH sai.
18:55 < mvexel> I'm very excited about that functionality, but no clue really where to start
18:55 < zere> the major missing component is some better way of presenting the history information
18:56 < zere> so imagine you had an API which could give you back things like "select distinct user where area=bbox(NSEW) and time > '1 week ago'"
18:57 < zere> or disctinct changeset, or count(num_changes) or something like that
18:57 < zere> the bit that i have no clue about at all is getting good-looking presentation layer on top of that
18:58 < zere> if you've seen the OWL page at the moment with the blue/orange squares then you'll know the extent of my JS-sk1llz
18:58 < mvexel> right
18:58 < zere> and the OWL API is completely up for grabs at the moment - i can easily add new things to it, as long as the queries are roughly of the form above.
19:00 -!- apmon [~kai@ntct41-66-dhcp.resnet.colorado.edu] has quit [Ping timeout: 480 seconds]
19:01 < mvexel> Is there no simpler way to filter out potentially uninformative changesets from the history tab?
19:01 < TomH> not accurately no
19:01 < TomH> we've have endless people propose things based on bbo size etc
19:02 < zere> sorry guys, i have to go t a meeting. but i'll come back and read the scrollback when it's done.
19:02 < TomH> but the real test that people want is whether it touches anything in the bbox
19:02 < mvexel> something like maxx-minx * maxy-miny > THRESHOLD comes to mind but I guess that's been discussed to death
19:02 < zere> thanks for coming, everyone. maybe see you later :-)