Attendees
| IRC nick
|
Real name
|
| apmon |
Kai Krueger
|
| migurski |
Michal Migurski
|
| pnorman |
Paul Norman
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
Summary
- Clickable POIs
- Various methods of implementation were discussed, with their various advantages and drawbacks, including:
- Mapnik's "grid" renderer
- Mapnik's "metawriters" features
- Komzpa's PostGIS query system
- Making stuff clickable on the main style still leaves a need for the data layer or something similar to examine all items, not just those which are renderable and have been rendered.
- OpenLayers vs. Leaflet
- There was a lot of discussion on this, but it basically reduced to two items:
- Ensuring functionality like the data layer isn't lost.
- Concerns that Leaflet may not have as broad browser support as OL.
- Moving away from OL would have to show some clear benefit.
- Data layer / raw OSM layer
- migurski offered to have a look at what a "raw vector" raster layer could be, as a potential replacement for the data layer.
- Data timeliness?
- Print stylesheet. pnorman had had some issues, but it wasn't clear if they had already been fixed.
IRC Log
18:02 < zere> minutes of the last 2 meetings: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2011-12-19 and http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-01-02
18:02 < zere> please have a look and let me know if there's anything objectionable in there?
18:04 -!- migurski [~migurski@173-164-158-185-SFBA.hfc.comcastbusiness.net] has joined #osm-ewg
18:05 < migurski> howdy folks
18:05 < migurski> is there an EWG meeting happening here?
18:06 < zere> yes, there is.
18:06 < zere> but at the moment, it's just you and me
18:06 < migurski> heh
18:06 < migurski> well hello!
18:06 < TomH> and me
18:07 < zere> aha! a lurker :-)
18:07 < migurski> I'm new here, but I'm interested in what's going on and thought I'd see if my participation was welcome
18:07 < zere> absolutely, it's welcome.
18:07 < zere> what's going on is that we've just finished doing some planning exercises for 2012 and are following up from that.
18:08 < migurski> related to the Top Ten Tasks?
18:08 < zere> last meeting we talked a little about feedback we'd received from the "top ten tasks" announcements and the "2012 plan" - http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-01-02
18:09 < zere> so if you have some feedback, or suggestions, about the top ten tasks (or anything else) we'd love to hear about it.
18:09 < migurski> yeah - I'm interested in the clickable POIs one
18:10 < migurski> because I'm new, I have ideas about how to get it done by tearing a bunch of stuff down
18:10 < migurski> and I'm at least aware that's not always welcome =)
18:11 < zere> what's your idea? (for full disclosure, i've implemented it in an as-yet closed-source app for MQ) i'd be interested to hear how your ideas differ from mine. :-)
18:12 * pnorman waves
18:12 < zere> hi pnorman :-)
18:12 < migurski> I think it would be worth our time to completely replace the OpenLayers-based map on the front page
18:13 < migurski> and use something more in the spirit of Leaflet, Wax, or Modest Maps
18:13 < migurski> specifically, the grid support that Dane has been adding to Mapnik
18:13 < migurski> which will allow for interactivity and support both clickable POIs and a data layer
18:13 < pnorman> Komzpa had clickable POIs on osm.be, right?
18:13 < migurski> it will place new demands on OSM's tile rendering
18:14 < zere> many have suggested it, but the stumbling point seems to be the data layer. how would that work? is it already implemented in Leaflet?
18:14 < migurski> pnorman: I don't know, actually
18:14 < migurski> data layer would need to be rewritten, is the short story
18:14 < migurski> so that's a big risk.
18:14 < TomH> and the export tool
18:15 < zere> yeah, but Komzpa's implementation draws POI information directly from the database (iirc) and so doesn't know about whether POIs were visible or not as a result of mapnik's placement rules.
18:15 < migurski> and that, yeah - though it really only interacts via a bbox right?
18:16 < pnorman> zere: Last I checked, you were able to click on a building and get a list of the shops inside it, as well as their levels
18:16 < migurski> export tool takes an area and turns it into an XML or PDF link, without necessarily interacting with the deeper portions of the map, IIRC
18:16 < TomH> what is the benefit of switching to leaflet? I can understand that it may be easier to use, and hence good if starting from scratch
18:16 < TomH> but we already have a work OL deployment
18:16 < zere> yeah, that's point-poly intersection, which is pretty cool. but again, it goes to the database, so it wins points for simplicity and loses them for scalability.
18:17 < TomH> migurski: well does leaflet have a control for drawing a box?
18:17 < migurski> don't know the answer to that
18:17 < TomH> not AFAIK
18:17 < migurski> we've written them for MMaps before, so I know it's a minor feature
18:18 < migurski> that's the main thing, though, isn't it? drawing a box, getting a set of numbers, then shipping that off to export?
18:18 < zere> leaflet seems to have some vector drawing methods, so it's not as basic as "just tiles" http://leaflet.cloudmade.com/reference.html
18:19 < TomH> migurski: sure, that's all it is
18:19 < migurski> so a control would have to be written and added
18:19 < pnorman> zere: is the database load that serious from the clicking on buildings? It's not the type of feature that I would expect to be scraped by phone apps
18:19 < migurski> how's the relationship between Cloudmade and OSM these days? Could we ask Vladimir to add that?
18:20 < zere> pnorman: yeah, it only takes one guy who wants to pre-download the info for his app making a request for every pixel at z18...
18:21 < migurski> the grid technique may be a way around that
18:21 < zere> or a news article about OSM and the number of people clicking goes through the roof. i think a better solution here is something like the grid renderer or just the bboxes in a json file and then that can be more effectively cached.
18:21 < TomH> migurski: don't think there is a relationship to talk of
18:21 < TomH> but that's not to say we couldn't add something
18:21 < migurski> right
18:21 < zere> but if we asked vladimir he might do it - the guy loves a challenge
18:22 < migurski> Mapnik also has the Metawriters feature, which I believe is a simple output of bboxes for all the labels and POIs it placed in a tile
18:22 < zere> yep - that's what i used for clickable POIs
18:22 < zere> the inmem metawriter and some python to serialise it to geoJSON for each tile.
18:22 < migurski> my understanding is that the metawriters approach creates a secondary output from a single rendering pass
18:22 < migurski> which sounds like it would place less stress on the tile server
18:23 < zere> the inmem one collects it in memory and it's available from the Map object after rendering.
18:23 < zere> yes, it seems to scale well.
18:23 < migurski> and I understand the grid approach well enough to turn the meta output into tiles
18:24 < TomH> trying to figure out what rendering technologies leaflet supports for vectors - it can clearly do canvas but not sure about anything else
18:24 < zere> can't speak for that vs the grid renderer, as i haven't tried that. but the grid renderer seems like it would be better for doing mouseovers/clicks for arbitrary-shaped stuff
18:24 < migurski> into grid tiles, I mean.
18:24 < zere> whereas my approach was only good for box-shaped stuff (like text and icons)
18:24 < migurski> ah I see
18:24 < pnorman> fwiw, I found zooming slower in leaflet than OL when looking at the two osm bugs implementations
18:24 < migurski> the grid render would, I think, get us a usable data layer
18:26 < zere> depends what you want from a data layer - i often use it to view the data that's invisible due to overcrowding in the rendered layer
18:26 < zere> but then it's possible that's not what the majority of people use it for,
18:26 < pnorman> Or data that is mis-tagged and therefore not rendered
18:26 < zere> pnorman: indeed.
18:26 < migurski> so two tile sets: 0. the current mapnik tiles, 1. a new clickable grid layer built in the same pass as the mapnik tiles to allow for clickable POIs
18:26 < TomH> ah looks like it can do SVG and VML as well
18:26 -!- apmon [~kai@ucb-np2-100.colorado.edu] has joined #osm-ewg
18:26 < zere> hi apmon :-)
18:26 < migurski> I use the data overlay primarily to find the OSM IDs of thing
18:26 < apmon> hi
18:26 < migurski> *things
18:26 < zere> we're discussing clickabke POIs
18:27 < apmon> nice
18:27 < apmon> I am not sure how much I can respond, as I need to take pictures of brains inbetween...
18:27 < migurski> heh
18:27 < pnorman> even if the grid layer is built in the same pass of mapnik, wouldn't it add some load to the server for writing it out and storing it?
18:27 < zere> migurski: so is it still useful for you if the data layer only shows things which have been rendered?
18:27 < migurski> so I can see two additional tile sets for the data layer: 2. a new data-like vector layer designed to show as much information as possible and 3. a new grid layer to make that vector layer clickable
18:28 < apmon> btw, I think I am nearly done with getting a KothicJS backend for tirex
18:28 < zere> for example, i'd go here and switch on the data layer to find the OSM ID for the san francisco city node: http://osm.org/go/TZHvTF_sQ--
18:29 < zere> but that node isn't visible at z18
18:29 < zere> although i guess i could click it at a lower zoom level if the layer was clickable...
18:29 < pnorman> The data layer loses most of its value to me if it only shows rendered objects
18:30 < migurski> pnorman: what if it made a best-effort to show *everything*?
18:30 < pnorman> If it's only best-effort than I'd just download the area in JOSM
18:30 < migurski> alternatively: what if the grid layer included everything, i.e. you click on a point and can get a list of every OSM ID intersecting that point?
18:31 < migurski> that's something the current data layer doesn't do very well.
18:31 < migurski> overlaps, etc. remain annoying
18:31 < zere> are we looking at 2 different things, then? an "inspection" layer, clickable, for casual use. and the full "data" layer which isn't expected to look nice, but shows everything?
18:31 < migurski> zere: I think so, yeah - the "inspection" layer addresses the Top Ten Task
18:31 < pnorman> overlaps suck in the current data layer. they're not great in any of the editors either
18:31 < migurski> the "data" layer is something I think would improve on the current vectors + openlayers approach
18:31 < zere> migurski: being able to click a point isn't as useful as being able to see what's there (imho).
18:32 < migurski> I agree
18:32 < migurski> I think the data pixels would make a best effort to show everything
18:32 < migurski> e.g. label buffers would be turned off in mapnik
18:32 < migurski> that kind of thing
18:32 < apmon> zere: I think two layers would be better
18:32 < zere> i guess there are two problems - one is clickable features on a map - mapnik + gridrenderer/metawriter seems to cover this pretty well. the other is how to view "raw" OSM data in a browser.
18:33 < migurski> yeah
18:33 < migurski> I can mock these up so we have something to point at when discussing it
18:33 < pnorman> Is a better print function on the top 10?
18:33 < zere> the data layer tries to do both at the moment. and, for level 7 jedi OSMers, succeeds. but i'd hate to see what happens when someone new to OSM clicks the data layer on...
18:34 < migurski> not sure how far I can get with actually making it all work, but we can at least see what a "raw vector" raster layer would look like. I'm interested partially because many people have asked for this in Walking Papers.
18:34 < zere> i know some people have gone back to printing out the wireframe render from JOSM for walking around and annotating. much of it is probably personal preference.
18:34 < migurski> interesting
18:34 < TomH> pnorman: if you can find a way to improve the print stylesheet then please be my guest
18:35 < TomH> I've torn enough of my hair out over it
18:35 < pnorman> Mainly a writing CSS issue? I might be able to handle that
18:36 < zere> isn't the problem the interaction between OL's JS resizing and the print rendering of browsers? i might be talking rubbish, here.
18:37 < zere> migurski: if you want to take the lead on this clickable thing, that would be fantastic. i'm sure you're the man to make the mess of raw OSM data look beautiful ;-)
18:37 < migurski> I'm staring down the barrel of a busy springtime, but it's something I'm very interested in
18:38 < migurski> if I came back with something that replaced OpenLayers, would that be a no-go for anybody?
18:38 < TomH> pnorman: well it rather depends what you think is wrong with it ;-) but yes it's all about writing CSS unless you know something I don't about what is possible
18:38 < zere> i think as long as we don't lose useful functionality then we can consider any (open source) technology
18:39 < pnorman> TomH: Well, what I think is wrong with it is I can't just hit print and get something usable in most browsers
18:39 < TomH> pnorman: seems to work for me
18:39 < TomH> have you tried it recently? it had got a bit broken but I fixed it up again I think
18:39 < migurski> zere: any functionality I'm missing, beyond data layer and bbox for export?
18:39 < pnorman> Not recently
18:39 < zere> seems like pnorman might be using a different browser? pnorman: if you could check again, that would be great. :-)
18:40 < zere> migurski: basic stuff like drawing markers over the top, but that shouldn't be a problem for anything... i'm trying to think if there's anything else.
18:41 < pnorman> It's only using part of the page in chrome and ie9. I'll give it some thought and muck around with the CSS
18:42 < zere> nope - i can't think of anything else we use maps for at the moment: on the frontpage, to put markers in for nearby users, to highlight vectors in the browse view, and the data layer.
18:44 < migurski> I expect it to be a long slow burn for me, but I'll work in public and try to get help
18:45 < zere> thanks :-) if you need anything - to throw ideas around, or see if someone wants to help out, that's what we're (supposed to be) here for :-)
18:46 < migurski> heh, okay - I'll be back next week, need to dive off of IRC now
18:46 < migurski> *off
18:47 < migurski> talk to you guys later!
18:47 -!- migurski [~migurski@173-164-158-185-SFBA.hfc.comcastbusiness.net] has left #osm-ewg []
18:49 < zere> thanks to pnorman for volunteering to take a look at the printing stuff :-)
18:49 < zere> does anyone have anything else they'd like to discuss in the remainder of the meeting? (~10mins)
18:56 < zere> ok, i guess that's a 'no'. thankyou to everyone for coming, particularly pnorman and migurski.
18:57 < zere> i hope to see you all next week :-)