Difference between revisions of "Working Group Minutes/EWG 2012-10-15"
Line 48: | Line 48: | ||
<pre class="forcewrap"> |
<pre class="forcewrap"> |
||
+ | 18:03:34 <zere> #startmeeting |
||
+ | 18:03:34 <ewg-meetbot> Meeting started Mon Oct 15 18:03:34 2012 UTC. The chair is zere. Information about MeetBot at http://wiki.debian.org/MeetBot. |
||
+ | 18:03:34 <ewg-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic. |
||
+ | 18:04:10 <zere> last meetings minutes: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-10-08 |
||
+ | 18:04:55 <zere> #info we had actions on TomH to push his branch live, which has been done: http://lists.openstreetmap.org/pipermail/rails-dev/2012-October/001080.html |
||
+ | 18:05:43 <zere> #info and an action on ppawel to look at OSQA migration possibilities: http://lists.openstreetmap.org/pipermail/dev/2012-October/025799.html |
||
+ | 18:05:58 <zere> anything we need to discuss on either of those topics? |
||
+ | 18:06:19 <apmon_> TomH: Through what channels would you prefer feedback on the notes branch? |
||
+ | 18:06:23 <ppawel> I guess next action for help.osm.org |
||
+ | 18:06:35 <apmon_> I have noticed a couple of minor issues |
||
+ | 18:07:12 <TomH> apmon_: whatever - email to the list, or open issues/pulls against my github |
||
+ | 18:07:57 <zere> well... weren't you saying before that github issues isn't the right place to discuss feature enhancements? |
||
+ | 18:08:21 <zere> so i guess bugs -> github issues, feature discussions -> mailing list? |
||
+ | 18:08:38 <apmon_> They are pretty minor like e.g. ( http://notes.apis.dev.openstreetmap.org/user/apmon-test ) not working as it links to note=>mine rather than notes => mine. So I guess issues agains github would be easiest |
||
+ | 18:08:49 <TomH> well I assumed apmon_ was talking about bugs in the notes code |
||
+ | 18:09:17 <zere> especially if they have patches attached :-) |
||
+ | 18:09:50 <zere> ppawel: what do you think the next move is? are the data models of OSQA / shapado close enough that a migration is possible? |
||
+ | 18:09:59 <TomH> I mean I don't think it's at all perfect so I hope people will offer improvements |
||
+ | 18:10:08 <zere> e.g: does it have the same concept of karma, etc... |
||
+ | 18:10:21 <ppawel> yes, feature-wise they are close |
||
+ | 18:10:30 <ppawel> except that shapado has better i18n of course |
||
+ | 18:10:44 <ppawel> one thing is |
||
+ | 18:11:06 <ppawel> specific "badges" - whether it would be possible to migrate every badge type |
||
+ | 18:11:30 <apmon_> Does anyone care enough about badges to worry about that? |
||
+ | 18:11:47 <ppawel> I don't know, my guess is that i18n trumps badges |
||
+ | 18:12:01 <zere> hmm... and i wonder whether that would go wrong if shapado has a different way of calculating such things... we might migrate a badge to have it taken away by the new instance ;-) |
||
+ | 18:12:16 <zere> personally, i think i18n definitely trumps badges |
||
+ | 18:12:26 <ppawel> yes these badges are very specific sometimes.. |
||
+ | 18:12:51 <ppawel> in any case I think technically migration is feasible - either through export/import or lower level database migration |
||
+ | 18:13:01 <zere> is there enough interest to start prototyping some migration code? |
||
+ | 18:13:04 <apmon_> http://ask.debian.net/ nicely shows how you can select different languages for questions and filter by language |
||
+ | 18:13:15 <ppawel> on #shapado they said that hosting on shapado.com is free for open source projects |
||
+ | 18:13:22 <zere> whether import/export or direct-to-database |
||
+ | 18:14:04 <ppawel> import/export is a matter of checking the dump format and import to shapado capability (it does have one but how effective it is?) |
||
+ | 18:14:29 <ppawel> and checking whether osqa can export to the 'stackexchange format' |
||
+ | 18:14:36 <zere> do you want to investigate that? |
||
+ | 18:14:42 <ppawel> but this potentially is a lot faster than direct database migration |
||
+ | 18:15:04 <zere> yes, re-using existing import pathways would be more appropriate |
||
+ | 18:15:32 <ppawel> I am interested in other top ten tasks as well so perhaps we should go through the list and volunteer at the end? |
||
+ | 18:15:43 <zere> fair enough :-) |
||
+ | 18:16:03 <zere> moving on, then, to: |
||
+ | 18:16:14 <zere> #topic clickabke POIs on the frontpage |
||
+ | 18:16:29 <zere> this one's had a lot of discussion, but so far not much actual code |
||
+ | 18:16:45 <ppawel> yeah I would be eager to learn current status |
||
+ | 18:17:00 <apmon_> What was the purpose of that? Could it be achieved better in other ways? |
||
+ | 18:17:05 <zere> as far as actual implementation - i'm not aware of any |
||
+ | 18:17:18 <drol> I suggest to use now the Overpass Popup feature, because it is ready to use. |
||
+ | 18:17:43 <zere> previous discussions had centered around ways of doing it such that the click was related to features rendered by mapnik |
||
+ | 18:18:06 <ppawel> well for me WFS comes to mind |
||
+ | 18:18:08 <zere> but, as drol suggests, there's already working code for doing this by click interception and db query |
||
+ | 18:18:11 <ppawel> which does exactly that |
||
+ | 18:18:27 <ppawel> the question is whether infrastructure could handle WFS server serving the whole planet |
||
+ | 18:18:30 <ppawel> TomH? |
||
+ | 18:18:31 <apmon_> Imho, it would be more useful to provide vector tiles that can then be used in e.g. KothicJS style layers |
||
+ | 18:18:52 <ppawel> WFS can serve vectors as well |
||
+ | 18:19:00 <ppawel> and it's already supported in openlayers |
||
+ | 18:19:22 <TomH> how am I supposed to know? |
||
+ | 18:19:25 <zere> i thought WFS was a bbox-style query, and highly non-cacheable? |
||
+ | 18:19:43 <apmon_> It needs to be tiled and "static" for performance reasons |
||
+ | 18:20:08 <ppawel> WFS has a GetFeatureInfo API that returns a vector feature with its associated data (tags) |
||
+ | 18:20:12 <zere> effectively the "data browser" is already a kind of WFS overlay, and it gets kind of slow |
||
+ | 18:20:23 <ppawel> yes |
||
+ | 18:21:26 <apmon_> More of a question would imho be, should the vector tiles be "rendering optimized" i.e. derived from an osm2pgsql style db, or vector tiles in .osm format? |
||
+ | 18:21:43 <zere> and, iirc, kothicjs (while awesome and amazing) is still pretty slow on low-powered machines. i haven't used it on my phone yet, but i fear for how it would perform |
||
+ | 18:22:29 <shaunmcdonald> I'd say they should be optimised so that you get the best user experience of showing things that the user expects rather than just a pile of garbage |
||
+ | 18:23:10 <drol> To what system do you refer, Shaun? |
||
+ | 18:23:13 <zere> i think the question facing us is - is perfect the enemy of good enough? drol's suggestion of a click-query approach could be implemented relatively quickly. a vector-tile approach seems much more work... |
||
+ | 18:23:46 <shaunmcdonald> drol: the general principle behind clickable POIs |
||
+ | 18:23:53 <apmon_> I haven't looked at it, but wasn't there a GSoC project that did the vector tiles? So it might be reasonably easy as well |
||
+ | 18:23:59 <ppawel> zere, but woduln't using overpass on osm.org tie those two systems together? |
||
+ | 18:24:10 <apmon_> and imho much more general purpose useful that just clickable POIs |
||
+ | 18:24:30 <jfire> hello from PDX |
||
+ | 18:24:34 <zere> ppawel: only in the same sense that nominatim is used, or mod_tile/renderd/mapnik is used... |
||
+ | 18:25:01 <ppawel> zere, ah so it would be an instance of overpass hosted at osm.org |
||
+ | 18:25:07 <shaunmcdonald> For what it's worth the ITO Map clickable feature uses a round trip to the server to let the server decide based on the style shown as to what to show rather than pre downloading all the vectors with the information. |
||
+ | 18:25:19 <zere> apmon_: sure, but what i'm looking for is someone to volunteer to try and do it ;-0 |
||
+ | 18:25:48 <ppawel> I think the scope of this needs clarification |
||
+ | 18:25:58 <ppawel> 1) do we want to serve geometry? |
||
+ | 18:26:03 <ppawel> 2) do we want clickable pois? |
||
+ | 18:26:13 <ppawel> (1) includes (2) but not the other way around |
||
+ | 18:26:24 <zere> ppawel: maybe. initially it could use the external instance and we could create an osm.org hosted instance if the load was onerous, or we wanted to admin it wiithin osm.org... |
||
+ | 18:26:26 <ppawel> clicable pois can be a tailored solution just for this use case |
||
+ | 18:26:27 <drol> I see these "clickable POIs" as a reward to mapping features not rendered. |
||
+ | 18:26:37 <drol> It's neither 1) or 2) of ppawel |
||
+ | 18:26:52 <ppawel> drol, oh? |
||
+ | 18:27:34 <shaunmcdonald> Or may so that you can have a row of shops with icons but no names rendered on the map, then when you click them you get the name. |
||
+ | 18:27:49 <drol> The geometry is already rendered by Mapnik, so this it not that urgent. |
||
+ | 18:28:06 <drol> "Clickable POIs" is a notion to discuss. |
||
+ | 18:28:21 <zere> the task description makes reference to surfacing more metadata. i'm guessing that the original idea here was that the map is just 2-dimensional. it has an icon and maybe a name. we have much more (e.g: on the browse/ pages) that we could be showing. |
||
+ | 18:28:49 <ppawel> zere, exactly what I meant with "serving geometry" - sorry for misleading name |
||
+ | 18:28:56 <ppawel> geometry + metadata |
||
+ | 18:29:06 <ppawel> OGC calls it "features" |
||
+ | 18:30:28 <ppawel> if no one else wants it then I can gladly volunteer to at least sort out the current state of affairs (whether there is any code) and possible ways forward |
||
+ | 18:31:20 <drol> I think the question is rather, do we want to have something really now and not in weeks or months? That's why the Overpass solution is there. |
||
+ | 18:31:21 <zere> anecdotally, the use of information drives it being recorded. so people tend to map things that will show up on the map tiles. allowing stuff like wikipedia links, opening hours, etc... to be more easily viewable (rather than going to the data browser, waiting, clicking a node, clicking "details"...) |
||
+ | 18:32:25 <ppawel> zere, +1 ... I think this is a very prominent feature missing from osm.org |
||
+ | 18:32:37 <ppawel> drol, can you link to some code or live demo? |
||
+ | 18:32:51 <drol> http://overpass-api.de/open_layers_popup.html |
||
+ | 18:33:45 <drol> Installation means: just copy the JavaScript code. You can configure the categories there. I also voluteer to configure it in the way the community wants. |
||
+ | 18:33:46 <zere> ok. let's put it to a poll. the question is: should we try for the overpass-style approach (hopefully quickly)? (the alternative being to go the vector-tiles route) +1 / -1, please. |
||
+ | 18:33:47 <ppawel> I see that the API responds with HTML |
||
+ | 18:34:09 <drol> +1 :) |
||
+ | 18:34:28 <apmon_> -1 |
||
+ | 18:34:33 <ppawel> -1 |
||
+ | 18:34:40 <ppawel> (at least until I know more) |
||
+ | 18:35:04 <shaunmcdonald> +1 |
||
+ | 18:35:43 <zere> anyone else want to add their opinion? Firefishy, TomH, jfire? |
||
+ | 18:35:59 <TomH> I have no useful knowledge here... |
||
+ | 18:36:07 <jfire> I'll abstain, not knowledgable enough |
||
+ | 18:36:43 <Firefishy> Click to fire SQL nearest search isn't my ideal. |
||
+ | 18:36:52 <zere> ok. the general consensus seems split... |
||
+ | 18:37:10 <zere> ppawel: you mentioned you'd be happy to take an action to look into this more? |
||
+ | 18:37:12 <ppawel> Firefishy, +1 |
||
+ | 18:37:51 <ppawel> zere, yes. I don't mean to hijack this task - I just would like to go through the alternatives |
||
+ | 18:38:18 <apmon_> I can probably look into the feasibility of the vector tiles |
||
+ | 18:38:18 <zere> #action ppawel to look into the various alternatives on the clickable POIs task |
||
+ | 18:38:30 <zere> #action apmon_ to look into the feasibility of the vector tiles |
||
+ | 18:38:31 <ppawel> overpass solution is there and is not going anywhere so I think one week delay of research is not going to matter in the large scheme |
||
+ | 18:39:02 <zere> yup. hopefully next week we will have more information to form a consensus :-) |
||
+ | 18:39:16 <Firefishy> apmon_: interesting things can be done with html imagemaps + js, day job hacked this up: http://www.redsands.wwood.co.uk/html/what-we-do/ (map at top) |
||
+ | 18:39:29 <zere> time is moving on, so shall we discuss the routing frontend? |
||
+ | 18:39:50 <zere> i know dennis luxen recently did something regarding this... anyone know any more? |
||
+ | 18:40:38 <ppawel> wasn't there a fully working osm.org routing frontend implemented somewhere? |
||
+ | 18:40:47 <zere> #topic routing frontend |
||
+ | 18:41:02 <ppawel> http://apmon.dev.openstreetmap.org/routing/ :) |
||
+ | 18:41:18 <TomH> there is something yes - the code is not the neatest though |
||
+ | 18:41:39 <zere> so it needs a little cleanup / refactor? |
||
+ | 18:41:49 <TomH> I think I got part way through trying to tidy it up and never even started realy trying to understand it in detail |
||
+ | 18:41:50 <zere> are there notes anywhere on what needs to be done? |
||
+ | 18:42:04 <apmon_> I tried to merge in the latest set of re-arranging of the javascript code that has gone on, but ran into too many conflicts for the moment |
||
+ | 18:42:11 <TomH> well the big issues is that it's a ton of javascript embedded in html.erb |
||
+ | 18:42:13 <apmon_> They shouldn't be too difficult to solve though |
||
+ | 18:42:31 <TomH> and split over several files and the logic behind the split is not entirely clear |
||
+ | 18:42:42 <jfire> where is the repo/branch for this? |
||
+ | 18:42:43 <apmon_> But I am not familiar with all these fancy magic frameworks / templates. So I don't think I can help with that atm |
||
+ | 18:42:47 <TomH> at least as I remmeber it, but I havent looked for ages |
||
+ | 18:43:05 <zere> ok, so the main part of the work is separating the routing-specific stuff out into its own files |
||
+ | 18:43:11 <Firefishy> jfire: handy guide: http://apis.dev.openstreetmap.org/ |
||
+ | 18:43:19 <apmon_> jfire: https://github.com/apmon/openstreetmap-website/tree/routing2 |
||
+ | 18:43:23 <zere> decrease the coupling between that code and the rest of it? |
||
+ | 18:43:36 <TomH> jfire: https://github.com/tomhughes/openstreetmap-website/tree/routing is where I left it I think |
||
+ | 18:43:58 <zere> #info code at https://github.com/apmon/openstreetmap-website/tree/routing2 and https://github.com/tomhughes/openstreetmap-website/tree/routing |
||
+ | 18:44:27 <apmon_> For someone who is aquanted with the fancy technology of the frameworks, it imho shouldn't be to much work to clean it up |
||
+ | 18:44:56 <jfire> I can take a look at it later this week |
||
+ | 18:45:14 <zere> jfire: awesome :-) |
||
+ | 18:45:50 <zere> if it's time to move on...? |
||
+ | 18:45:58 <zere> #topic XML deleted items call |
||
+ | 18:46:21 <zere> this one has had no progress whatsoever - it's still basically entirely on the drawing board |
||
+ | 18:47:12 <zere> the main point of this item is to provide an API call which will give deleted nodes/ways/relations within a given bounding box |
||
+ | 18:47:26 <shaunmcdonald> It's been asked for again since the removal of Potlatch 1 from the edit menu. |
||
+ | 18:47:41 <zere> there's an existing implementation of this for the AMF (non)API, but there's no need to use that as a template |
||
+ | 18:47:58 <zere> in fact, it might be better not to, as iirc the query wasn't exactly efficient |
||
+ | 18:49:03 <jfire> Do we know of a more efficient way? Or is figuring that out part of the task? |
||
+ | 18:49:23 <shaunmcdonald> figuring out is part of the task |
||
+ | 18:49:49 <zere> there's some interaction here with other proposed changes too |
||
+ | 18:50:28 <zere> for a while, i've been wanting to delete deleted items from the current_* tables, so that we can check the integrity of current_ways/relations with an FK constraint |
||
+ | 18:51:07 <zere> but, the implementation in the AMF controller relies on visible=false items in the current_* tables (iirc) |
||
+ | 18:51:50 <zere> ideally, there'd be some way to do this efficiently without touching the current_* tables, but i have a feeling that's not going to be easy, or even possible. |
||
+ | 18:52:33 <apmon_> TomH: Slightly off topic, but I have to go in a minute. Could you have a brief look at the volume of code of the "login with facebook" feature and tell me if that would be an unacceptable amount of "special case code" |
||
+ | 18:53:01 <apmon_> Imho it is small enough to not be worth the effort for now to have to rewrite the entire authentication code to move over to something like devise |
||
+ | 18:54:12 <zere> doesn't sound like there's a lot of interest in the deleted items call... |
||
+ | 18:54:40 <zere> would everyone prefer to go on to OWL powered activity / history, or AoB and finish on time? ;-) |
||
+ | 18:54:51 <shaunmcdonald> It's cos it's a hard problem ;-) |
||
+ | 18:54:56 <apmon_> zere: I guess that is squarly in your court for now... ;-) |
||
+ | 18:55:46 <ppawel> I would propose rephrasing this TTT so it is maybe not OWL specific |
||
+ | 18:56:05 <zere> yup. i'll have to make an attack on it after i've done with cgimap... i'm on a self-imposed single-task status until i've got cgimap's "replicated postgres" backend done & tested. |
||
+ | 18:56:26 <ppawel> I have started a demo instance of activity server integrated with osm.org today - http://lists.openstreetmap.org/pipermail/talk/2012-October/064823.html |
||
+ | 18:56:59 <ppawel> this could be alternative solution to this task |
||
+ | 18:57:44 <zere> yup. but is it an alternative, or are they doing different tasks? |
||
+ | 18:58:14 <ppawel> well the task is 'OWL-powered activity/history tab' and what I'm doing is not OWL-powered (at least not now/yet) |
||
+ | 18:58:16 <apmon_> zere: cgimap does seem like a good topic to focus on |
||
+ | 18:58:40 <zere> for example, OWL doesn't do activity streams. its purpose is just to provide more accurate footprints for changesets. |
||
+ | 18:58:41 <ppawel> so it's kind of a different task but it means to provide activity tab/stream/whatever you call it |
||
+ | 18:58:47 <zere> yup |
||
+ | 18:58:56 <zere> ok, i'll re-word that |
||
+ | 18:59:08 <zere> #topic OWL-powered activity/history tab |
||
+ | 18:59:26 <zere> #action zere re-word this item - doesn't need to be OWL-specific |
||
+ | 18:59:31 <ppawel> right now it's kind of on the border |
||
+ | 18:59:46 <ppawel> so I suggest that it's either completely about OWL or not OWL specific at all |
||
+ | 18:59:52 <zere> yeah, OWL is potentially part of the solution, but it doesn't need to be |
||
+ | 19:00:16 <ppawel> i.e. what I'm working on will not provide what OWL provides |
||
+ | 19:00:27 <ppawel> and vice versa as you said |
||
+ | 19:01:10 <zere> ah, but if i pull my finger out then what you're working on could use OWL... but first i need to get OWL working again... |
||
+ | 19:01:29 <zere> so much to do, so little time :-) |
||
+ | 19:01:52 <ppawel> yeah that would greatly simplify some parts of my solution... |
||
+ | 19:01:57 <zere> since we're at the proposed end of the meeting... does anyone have any (quick) other business? |
||
+ | 19:02:00 <zere> #topic AoB |
||
+ | 19:02:31 <ppawel> going back to help.osm.org - I can volunteer once again to maybe do more in-depth research |
||
+ | 19:02:38 <ppawel> specifically on migration to shapado |
||
+ | 19:02:47 <zere> absolutely :-) we love volunteers! |
||
+ | 19:02:53 <ppawel> he he |
||
+ | 19:03:21 <zere> #action ppawel to do more in-depth research into migration of help.osm.org to shapado |
||
+ | 19:04:23 <zere> if there's nothing else, then i'd like to thank everyone for coming, and hope to see you again next monday :-) |
||
+ | 19:05:10 <zere> #endmeeting |
||
</pre> |
</pre> |
Latest revision as of 12:38, 16 October 2012
Attendees
IRC nick | Real name |
---|---|
apmon_ | Kai Krueger |
drol | Roland Olbricht |
Firefishy | Grant Slater |
jfire | John Firebaugh |
ppawel | Paweł Paprota |
shaunmcdonald | Shaun McDonald |
TomH | Tom Hughes |
zere | Matt Amos |
Summary
- Matters arising:
- Clickable POIs on the frontpage
- See Overpass API pop-ups: [4]
- ACTION: ppawel to look into the various alternatives on the clickable POIs task
- ACTION: apmon_ to look into the feasibility of the vector tiles idea
- Routing frontend
- XML deleted items call
- Current status is still drawing board. This was set out, but didn't attract interest.
- OWL-powered activity/history tab
- ACTION: zere re-word this item - doesn't need to be OWL-specific
- Seems to be a lot of interest in activity streams, see [8] for a demo from ppawel.
- AoB
- ACTION: ppawel to do more in-depth research into migration of help.osm.org to shapado
IRC Log
18:03:34 <zere> #startmeeting 18:03:34 <ewg-meetbot> Meeting started Mon Oct 15 18:03:34 2012 UTC. The chair is zere. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:34 <ewg-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 18:04:10 <zere> last meetings minutes: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-10-08 18:04:55 <zere> #info we had actions on TomH to push his branch live, which has been done: http://lists.openstreetmap.org/pipermail/rails-dev/2012-October/001080.html 18:05:43 <zere> #info and an action on ppawel to look at OSQA migration possibilities: http://lists.openstreetmap.org/pipermail/dev/2012-October/025799.html 18:05:58 <zere> anything we need to discuss on either of those topics? 18:06:19 <apmon_> TomH: Through what channels would you prefer feedback on the notes branch? 18:06:23 <ppawel> I guess next action for help.osm.org 18:06:35 <apmon_> I have noticed a couple of minor issues 18:07:12 <TomH> apmon_: whatever - email to the list, or open issues/pulls against my github 18:07:57 <zere> well... weren't you saying before that github issues isn't the right place to discuss feature enhancements? 18:08:21 <zere> so i guess bugs -> github issues, feature discussions -> mailing list? 18:08:38 <apmon_> They are pretty minor like e.g. ( http://notes.apis.dev.openstreetmap.org/user/apmon-test ) not working as it links to note=>mine rather than notes => mine. So I guess issues agains github would be easiest 18:08:49 <TomH> well I assumed apmon_ was talking about bugs in the notes code 18:09:17 <zere> especially if they have patches attached :-) 18:09:50 <zere> ppawel: what do you think the next move is? are the data models of OSQA / shapado close enough that a migration is possible? 18:09:59 <TomH> I mean I don't think it's at all perfect so I hope people will offer improvements 18:10:08 <zere> e.g: does it have the same concept of karma, etc... 18:10:21 <ppawel> yes, feature-wise they are close 18:10:30 <ppawel> except that shapado has better i18n of course 18:10:44 <ppawel> one thing is 18:11:06 <ppawel> specific "badges" - whether it would be possible to migrate every badge type 18:11:30 <apmon_> Does anyone care enough about badges to worry about that? 18:11:47 <ppawel> I don't know, my guess is that i18n trumps badges 18:12:01 <zere> hmm... and i wonder whether that would go wrong if shapado has a different way of calculating such things... we might migrate a badge to have it taken away by the new instance ;-) 18:12:16 <zere> personally, i think i18n definitely trumps badges 18:12:26 <ppawel> yes these badges are very specific sometimes.. 18:12:51 <ppawel> in any case I think technically migration is feasible - either through export/import or lower level database migration 18:13:01 <zere> is there enough interest to start prototyping some migration code? 18:13:04 <apmon_> http://ask.debian.net/ nicely shows how you can select different languages for questions and filter by language 18:13:15 <ppawel> on #shapado they said that hosting on shapado.com is free for open source projects 18:13:22 <zere> whether import/export or direct-to-database 18:14:04 <ppawel> import/export is a matter of checking the dump format and import to shapado capability (it does have one but how effective it is?) 18:14:29 <ppawel> and checking whether osqa can export to the 'stackexchange format' 18:14:36 <zere> do you want to investigate that? 18:14:42 <ppawel> but this potentially is a lot faster than direct database migration 18:15:04 <zere> yes, re-using existing import pathways would be more appropriate 18:15:32 <ppawel> I am interested in other top ten tasks as well so perhaps we should go through the list and volunteer at the end? 18:15:43 <zere> fair enough :-) 18:16:03 <zere> moving on, then, to: 18:16:14 <zere> #topic clickabke POIs on the frontpage 18:16:29 <zere> this one's had a lot of discussion, but so far not much actual code 18:16:45 <ppawel> yeah I would be eager to learn current status 18:17:00 <apmon_> What was the purpose of that? Could it be achieved better in other ways? 18:17:05 <zere> as far as actual implementation - i'm not aware of any 18:17:18 <drol> I suggest to use now the Overpass Popup feature, because it is ready to use. 18:17:43 <zere> previous discussions had centered around ways of doing it such that the click was related to features rendered by mapnik 18:18:06 <ppawel> well for me WFS comes to mind 18:18:08 <zere> but, as drol suggests, there's already working code for doing this by click interception and db query 18:18:11 <ppawel> which does exactly that 18:18:27 <ppawel> the question is whether infrastructure could handle WFS server serving the whole planet 18:18:30 <ppawel> TomH? 18:18:31 <apmon_> Imho, it would be more useful to provide vector tiles that can then be used in e.g. KothicJS style layers 18:18:52 <ppawel> WFS can serve vectors as well 18:19:00 <ppawel> and it's already supported in openlayers 18:19:22 <TomH> how am I supposed to know? 18:19:25 <zere> i thought WFS was a bbox-style query, and highly non-cacheable? 18:19:43 <apmon_> It needs to be tiled and "static" for performance reasons 18:20:08 <ppawel> WFS has a GetFeatureInfo API that returns a vector feature with its associated data (tags) 18:20:12 <zere> effectively the "data browser" is already a kind of WFS overlay, and it gets kind of slow 18:20:23 <ppawel> yes 18:21:26 <apmon_> More of a question would imho be, should the vector tiles be "rendering optimized" i.e. derived from an osm2pgsql style db, or vector tiles in .osm format? 18:21:43 <zere> and, iirc, kothicjs (while awesome and amazing) is still pretty slow on low-powered machines. i haven't used it on my phone yet, but i fear for how it would perform 18:22:29 <shaunmcdonald> I'd say they should be optimised so that you get the best user experience of showing things that the user expects rather than just a pile of garbage 18:23:10 <drol> To what system do you refer, Shaun? 18:23:13 <zere> i think the question facing us is - is perfect the enemy of good enough? drol's suggestion of a click-query approach could be implemented relatively quickly. a vector-tile approach seems much more work... 18:23:46 <shaunmcdonald> drol: the general principle behind clickable POIs 18:23:53 <apmon_> I haven't looked at it, but wasn't there a GSoC project that did the vector tiles? So it might be reasonably easy as well 18:23:59 <ppawel> zere, but woduln't using overpass on osm.org tie those two systems together? 18:24:10 <apmon_> and imho much more general purpose useful that just clickable POIs 18:24:30 <jfire> hello from PDX 18:24:34 <zere> ppawel: only in the same sense that nominatim is used, or mod_tile/renderd/mapnik is used... 18:25:01 <ppawel> zere, ah so it would be an instance of overpass hosted at osm.org 18:25:07 <shaunmcdonald> For what it's worth the ITO Map clickable feature uses a round trip to the server to let the server decide based on the style shown as to what to show rather than pre downloading all the vectors with the information. 18:25:19 <zere> apmon_: sure, but what i'm looking for is someone to volunteer to try and do it ;-0 18:25:48 <ppawel> I think the scope of this needs clarification 18:25:58 <ppawel> 1) do we want to serve geometry? 18:26:03 <ppawel> 2) do we want clickable pois? 18:26:13 <ppawel> (1) includes (2) but not the other way around 18:26:24 <zere> ppawel: maybe. initially it could use the external instance and we could create an osm.org hosted instance if the load was onerous, or we wanted to admin it wiithin osm.org... 18:26:26 <ppawel> clicable pois can be a tailored solution just for this use case 18:26:27 <drol> I see these "clickable POIs" as a reward to mapping features not rendered. 18:26:37 <drol> It's neither 1) or 2) of ppawel 18:26:52 <ppawel> drol, oh? 18:27:34 <shaunmcdonald> Or may so that you can have a row of shops with icons but no names rendered on the map, then when you click them you get the name. 18:27:49 <drol> The geometry is already rendered by Mapnik, so this it not that urgent. 18:28:06 <drol> "Clickable POIs" is a notion to discuss. 18:28:21 <zere> the task description makes reference to surfacing more metadata. i'm guessing that the original idea here was that the map is just 2-dimensional. it has an icon and maybe a name. we have much more (e.g: on the browse/ pages) that we could be showing. 18:28:49 <ppawel> zere, exactly what I meant with "serving geometry" - sorry for misleading name 18:28:56 <ppawel> geometry + metadata 18:29:06 <ppawel> OGC calls it "features" 18:30:28 <ppawel> if no one else wants it then I can gladly volunteer to at least sort out the current state of affairs (whether there is any code) and possible ways forward 18:31:20 <drol> I think the question is rather, do we want to have something really now and not in weeks or months? That's why the Overpass solution is there. 18:31:21 <zere> anecdotally, the use of information drives it being recorded. so people tend to map things that will show up on the map tiles. allowing stuff like wikipedia links, opening hours, etc... to be more easily viewable (rather than going to the data browser, waiting, clicking a node, clicking "details"...) 18:32:25 <ppawel> zere, +1 ... I think this is a very prominent feature missing from osm.org 18:32:37 <ppawel> drol, can you link to some code or live demo? 18:32:51 <drol> http://overpass-api.de/open_layers_popup.html 18:33:45 <drol> Installation means: just copy the JavaScript code. You can configure the categories there. I also voluteer to configure it in the way the community wants. 18:33:46 <zere> ok. let's put it to a poll. the question is: should we try for the overpass-style approach (hopefully quickly)? (the alternative being to go the vector-tiles route) +1 / -1, please. 18:33:47 <ppawel> I see that the API responds with HTML 18:34:09 <drol> +1 :) 18:34:28 <apmon_> -1 18:34:33 <ppawel> -1 18:34:40 <ppawel> (at least until I know more) 18:35:04 <shaunmcdonald> +1 18:35:43 <zere> anyone else want to add their opinion? Firefishy, TomH, jfire? 18:35:59 <TomH> I have no useful knowledge here... 18:36:07 <jfire> I'll abstain, not knowledgable enough 18:36:43 <Firefishy> Click to fire SQL nearest search isn't my ideal. 18:36:52 <zere> ok. the general consensus seems split... 18:37:10 <zere> ppawel: you mentioned you'd be happy to take an action to look into this more? 18:37:12 <ppawel> Firefishy, +1 18:37:51 <ppawel> zere, yes. I don't mean to hijack this task - I just would like to go through the alternatives 18:38:18 <apmon_> I can probably look into the feasibility of the vector tiles 18:38:18 <zere> #action ppawel to look into the various alternatives on the clickable POIs task 18:38:30 <zere> #action apmon_ to look into the feasibility of the vector tiles 18:38:31 <ppawel> overpass solution is there and is not going anywhere so I think one week delay of research is not going to matter in the large scheme 18:39:02 <zere> yup. hopefully next week we will have more information to form a consensus :-) 18:39:16 <Firefishy> apmon_: interesting things can be done with html imagemaps + js, day job hacked this up: http://www.redsands.wwood.co.uk/html/what-we-do/ (map at top) 18:39:29 <zere> time is moving on, so shall we discuss the routing frontend? 18:39:50 <zere> i know dennis luxen recently did something regarding this... anyone know any more? 18:40:38 <ppawel> wasn't there a fully working osm.org routing frontend implemented somewhere? 18:40:47 <zere> #topic routing frontend 18:41:02 <ppawel> http://apmon.dev.openstreetmap.org/routing/ :) 18:41:18 <TomH> there is something yes - the code is not the neatest though 18:41:39 <zere> so it needs a little cleanup / refactor? 18:41:49 <TomH> I think I got part way through trying to tidy it up and never even started realy trying to understand it in detail 18:41:50 <zere> are there notes anywhere on what needs to be done? 18:42:04 <apmon_> I tried to merge in the latest set of re-arranging of the javascript code that has gone on, but ran into too many conflicts for the moment 18:42:11 <TomH> well the big issues is that it's a ton of javascript embedded in html.erb 18:42:13 <apmon_> They shouldn't be too difficult to solve though 18:42:31 <TomH> and split over several files and the logic behind the split is not entirely clear 18:42:42 <jfire> where is the repo/branch for this? 18:42:43 <apmon_> But I am not familiar with all these fancy magic frameworks / templates. So I don't think I can help with that atm 18:42:47 <TomH> at least as I remmeber it, but I havent looked for ages 18:43:05 <zere> ok, so the main part of the work is separating the routing-specific stuff out into its own files 18:43:11 <Firefishy> jfire: handy guide: http://apis.dev.openstreetmap.org/ 18:43:19 <apmon_> jfire: https://github.com/apmon/openstreetmap-website/tree/routing2 18:43:23 <zere> decrease the coupling between that code and the rest of it? 18:43:36 <TomH> jfire: https://github.com/tomhughes/openstreetmap-website/tree/routing is where I left it I think 18:43:58 <zere> #info code at https://github.com/apmon/openstreetmap-website/tree/routing2 and https://github.com/tomhughes/openstreetmap-website/tree/routing 18:44:27 <apmon_> For someone who is aquanted with the fancy technology of the frameworks, it imho shouldn't be to much work to clean it up 18:44:56 <jfire> I can take a look at it later this week 18:45:14 <zere> jfire: awesome :-) 18:45:50 <zere> if it's time to move on...? 18:45:58 <zere> #topic XML deleted items call 18:46:21 <zere> this one has had no progress whatsoever - it's still basically entirely on the drawing board 18:47:12 <zere> the main point of this item is to provide an API call which will give deleted nodes/ways/relations within a given bounding box 18:47:26 <shaunmcdonald> It's been asked for again since the removal of Potlatch 1 from the edit menu. 18:47:41 <zere> there's an existing implementation of this for the AMF (non)API, but there's no need to use that as a template 18:47:58 <zere> in fact, it might be better not to, as iirc the query wasn't exactly efficient 18:49:03 <jfire> Do we know of a more efficient way? Or is figuring that out part of the task? 18:49:23 <shaunmcdonald> figuring out is part of the task 18:49:49 <zere> there's some interaction here with other proposed changes too 18:50:28 <zere> for a while, i've been wanting to delete deleted items from the current_* tables, so that we can check the integrity of current_ways/relations with an FK constraint 18:51:07 <zere> but, the implementation in the AMF controller relies on visible=false items in the current_* tables (iirc) 18:51:50 <zere> ideally, there'd be some way to do this efficiently without touching the current_* tables, but i have a feeling that's not going to be easy, or even possible. 18:52:33 <apmon_> TomH: Slightly off topic, but I have to go in a minute. Could you have a brief look at the volume of code of the "login with facebook" feature and tell me if that would be an unacceptable amount of "special case code" 18:53:01 <apmon_> Imho it is small enough to not be worth the effort for now to have to rewrite the entire authentication code to move over to something like devise 18:54:12 <zere> doesn't sound like there's a lot of interest in the deleted items call... 18:54:40 <zere> would everyone prefer to go on to OWL powered activity / history, or AoB and finish on time? ;-) 18:54:51 <shaunmcdonald> It's cos it's a hard problem ;-) 18:54:56 <apmon_> zere: I guess that is squarly in your court for now... ;-) 18:55:46 <ppawel> I would propose rephrasing this TTT so it is maybe not OWL specific 18:56:05 <zere> yup. i'll have to make an attack on it after i've done with cgimap... i'm on a self-imposed single-task status until i've got cgimap's "replicated postgres" backend done & tested. 18:56:26 <ppawel> I have started a demo instance of activity server integrated with osm.org today - http://lists.openstreetmap.org/pipermail/talk/2012-October/064823.html 18:56:59 <ppawel> this could be alternative solution to this task 18:57:44 <zere> yup. but is it an alternative, or are they doing different tasks? 18:58:14 <ppawel> well the task is 'OWL-powered activity/history tab' and what I'm doing is not OWL-powered (at least not now/yet) 18:58:16 <apmon_> zere: cgimap does seem like a good topic to focus on 18:58:40 <zere> for example, OWL doesn't do activity streams. its purpose is just to provide more accurate footprints for changesets. 18:58:41 <ppawel> so it's kind of a different task but it means to provide activity tab/stream/whatever you call it 18:58:47 <zere> yup 18:58:56 <zere> ok, i'll re-word that 18:59:08 <zere> #topic OWL-powered activity/history tab 18:59:26 <zere> #action zere re-word this item - doesn't need to be OWL-specific 18:59:31 <ppawel> right now it's kind of on the border 18:59:46 <ppawel> so I suggest that it's either completely about OWL or not OWL specific at all 18:59:52 <zere> yeah, OWL is potentially part of the solution, but it doesn't need to be 19:00:16 <ppawel> i.e. what I'm working on will not provide what OWL provides 19:00:27 <ppawel> and vice versa as you said 19:01:10 <zere> ah, but if i pull my finger out then what you're working on could use OWL... but first i need to get OWL working again... 19:01:29 <zere> so much to do, so little time :-) 19:01:52 <ppawel> yeah that would greatly simplify some parts of my solution... 19:01:57 <zere> since we're at the proposed end of the meeting... does anyone have any (quick) other business? 19:02:00 <zere> #topic AoB 19:02:31 <ppawel> going back to help.osm.org - I can volunteer once again to maybe do more in-depth research 19:02:38 <ppawel> specifically on migration to shapado 19:02:47 <zere> absolutely :-) we love volunteers! 19:02:53 <ppawel> he he 19:03:21 <zere> #action ppawel to do more in-depth research into migration of help.osm.org to shapado 19:04:23 <zere> if there's nothing else, then i'd like to thank everyone for coming, and hope to see you again next monday :-) 19:05:10 <zere> #endmeeting