Difference between revisions of "Working Group Minutes/EWG 2012-10-15"

From OpenStreetMap Foundation
 
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:
    • we had actions on TomH to push his branch live, which has been done: [1]
    • and an action on ppawel to look at OSQA migration possibilities: [2]
    • (re: Shapado i18n support) [3] nicely shows how you can select different languages for questions and filter by language
  • 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
Retrieved from "https://wiki.osmfoundation.org/w/index.php?title=Working_Group_Minutes/EWG_2012-10-15&oldid=1890"