Attendees
| IRC nick
|
Real name
|
| alexbarth |
Alex Barth
|
| apmon_ |
Kai Krueger
|
| ppawel |
Paweł Paprota
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
Summary
- Matters arising:
- zere contacted LWG about the anonymous notes concerns, and will relay back the response
- zere updated the TTTs page to defer the routing backend task and split the clickable task [1]
- Vector tiles
- there was a discussion about existing implementations, including the result of a GSoC project called "Cover", which is being used in the KothicJS javascript renderer.
- apmon pointed out [2] is what a tile looks like
- and [3] is what the style looks like
- There was general enthusiasm for trying this out and seeing whether it could be brought up somewhere as a development service / worldwide demo.
IRC Log
18:05:19 <zere> #startmeeting
18:05:19 <ewg-meetbot> Meeting started Mon Nov 5 18:05:19 2012 UTC. The chair is zere. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:05:19 <ewg-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:05:44 <zere> minutes of the last two meetings: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-10-22 and http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-10-29
18:06:12 <zere> actions from those, apart from the help.osm.org one, are all on me
18:06:18 <zere> #topic Matters arising
18:06:57 <zere> #info i've contacted LWG about the anonymous notes concerns, and will relay back the response
18:07:21 <zere> that was 5 minutes ago, so we may need to give them time to think ;-)
18:07:48 <zere> #info i haven't, yet, updated the TTTs page. that's pending for the next meeting
18:08:58 <zere> i don't recall anything specific being raise to put on the agenda, so the floor is open for anyone to propose a topic
18:11:23 <apmon_> I looked some more into vector tiles over the weekend
18:12:22 <alexbarth> apmon_: re: clickable POI's ?
18:13:20 <apmon_> Partly. It wouldn't fulfill quite the same purpose as clickable POI's, but it could potentially cover some of its benefits
18:13:35 <apmon_> and offers a lot of additional ones compared to simple clickable POI's
18:13:41 <alexbarth> apmon_: gotcha
18:14:11 <apmon_> It would make offering thematic map styles a lot easier, as there would be no additional server load to adding styles
18:14:39 <apmon_> Which would possibly allow to expose more of the data, which was imho part of the point of clickable POIs
18:15:30 <zere> #info updated the TTTs page to defer the routing backend task and split the clickable task: http://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#POI_inspection_tool_on_the_frontpage
18:15:37 <zere> #topic Vector tiles
18:15:56 <zere> apmon_: what did you find out, over the weekend?
18:16:12 <apmon_> One of this years GSoC projects (Cover) wrote a plugin for tirex that creates json tiles
18:16:40 <apmon_> So it makes it possible to reuse the rest of the stack. Standard osm2pgsql database, tirex and mod_tile
18:17:33 <apmon_> So pretty much all that would be needed to offer json tiles would be to update mod_tile and move from renderd to tirex on the tile server
18:18:06 <zere> json tiles how, though? geojson from the osm2pgsql database?
18:18:17 <apmon_> yes
18:18:54 <zere> and does it cache tiles to disk like regular tiles, or generate them always from the database?
18:19:44 <apmon_> No, it uses the standard caching, queing and load balancing of mod_tile / tirex
18:20:10 <apmon_> It stores the json tiles as typical metatiles (the json being gzip compressed inside)
18:20:42 <apmon_> So all of the other (backend) tools should work on the vector tiles just the same as on raster tiles
18:21:22 <zere> nice. so i guess the only problem is that the tiles must be huge at lower zooms due to the lack of generalisation support in osm2pgsql - or does it handle generalisation internally?
18:22:02 <apmon_> I think it does handle generalisation (through the postgis queries it sends to generate the geojson)
18:22:29 <zere> oh, and unless it filters the features somehow, it must produce a lot of output for a low zoom tile...
18:22:59 <ppawel> wouldn't poi's be limited to level >=14 or something?
18:23:56 <zere> that's what i mean - some POIs aren't relevant at low zooms, but some (e.g: place=city) are. i'm just trying to get a sense of whether this code handles that
18:25:09 <apmon_> http://pastebin.com/9CkLzL0E is what a tile looks like
18:25:24 <ppawel> oh, so a label for places (city etc) would be clickable?
18:25:39 <apmon_> zere: Cover has a whole style file specifying what gets included at what zoom levels
18:25:53 <apmon_> so one can discuss what the appropriate style would be
18:26:08 <apmon_> So that it is as general purpose as possible, but does not explode on low zoom
18:27:10 <apmon_> https://github.com/mdaines/cover/blob/master/config/render.rb is what the style looks like
18:27:10 <zere> oh, thats nice. i'll have to see whether there's any objection to moving from renderd to tirex for this...
18:27:52 <apmon_> It does feel a little on the slow side still, so it might be necessary to optimise the queries somewhat
18:28:05 <apmon_> But I can look into it more, if people think it is feasible
18:29:12 <zere> it would be cool to get this up on errol
18:29:23 <zere> is there a front-end renderer too?
18:29:30 <apmon_> KothicJS
18:29:53 <zere> ah, last time i tried that it was a little on the slow side too ;-)
18:30:38 <apmon_> Unfortunately, my ISP is behind a firewall, so I can't expose my test instance for now
18:31:14 <apmon_> As long as the json tiles load fast, it isn't too bad
18:31:15 <zere> although, wow. they've fixed the text rendering issues they used to have
18:33:20 <alexbarth> apmon_: fwiw, on owlviewer we're using leaflet for rendering geojson tiles https://github.com/mapbox/owlviewer/blob/gh-pages/geojson-tiles.js
18:33:39 <apmon_> I might give it a shot at getting it running on the wikimedia toolserver
18:33:58 <zere> that would be awesome.
18:34:08 <alexbarth> this is inspired by glenrobertson's https://github.com/glenrobertson/leaflet-tilelayer-geojson - I found some problem with this though and I still need to get back to him
18:34:10 <zere> with minutely updates, of course ;-)
18:34:44 <apmon_> If I get it working on the toolserver, it would be with (15 minutely) updates
18:35:20 <ppawel> what tile size does it use?
18:35:29 <zere> ah, re-using the existing database. good idea
18:35:40 <apmon_> same as the png tiles
18:36:27 <ppawel> with 256px tiles I've found it pretty painful. ajax requests blocking each other (because of the request limit imposed by RFC)
18:36:39 <ppawel> it takes up to 3 seconds to load a viewport of geojson tiles
18:36:42 <zere> SPDY ftw
18:36:49 <ppawel> on the server side each tile renders in ~20ms
18:37:14 <apmon_> I don't have much issue with loading speed on my local test setup
18:37:30 <apmon_> But it loads data over localhost, so doesn't haven any latency
18:37:33 <alexbarth> ppawel: also the payload is big, right?
18:37:36 <zere> your RTT is approximately zero :-)
18:38:05 <ppawel> yeah payload can be an issue but those styles per zoom level look nice
18:38:31 <apmon_> payload seems to be about comparable to png tiles (as long as the js is compressed)
18:38:34 <zere> presumably the payload is gzipped - what's the typical compressed size?
18:38:50 <apmon_> but I'd need to do a more thorough analysis of the required resources
18:39:15 <ppawel> with poi's that's less of an issue I guess.. in owlviewer we transfer whole changeset geometry..
18:39:22 <zere> Cover's use of integer coords + scale probably helps
18:41:14 <apmon_> OSM needs its own dev server with a worldwide minutely up-to-date osm2pgsql for tests like these... ;-)
18:41:31 <zere> funny... i seem to remember we used to do that
18:41:44 <apmon_> we do?
18:41:45 <zere> but then some idiot started running OWL there...
18:42:17 <apmon_> I don't remember there was ever a full planet osm2pgsql db on dev
18:42:21 <zere> and worldwide osm2pgsql database + OWL v1 = no disk i/o
18:42:29 <zere> oh, yeah, you're right
18:42:45 <zere> it wasn't an osm2pgsql database, it was an apidb database, wasn't it?
18:42:50 <TomH> even if it did it wouldn't tell you anything
18:43:08 <TomH> errol has horrid slow disks - nothing like what we would use in a production server
18:43:34 <zere> sure, but it's useful for developing stuff, makign it available
18:43:53 <zere> we can decide later if it's worth moving to better hardware
18:45:35 <zere> i'll have a go - see if it's too much to keep minutely updated with errol's disks.
18:45:49 <TomH> I'll need to do some work first
18:45:55 <TomH> as we'll need to move postgres to the other disks
18:46:47 <zere> /home?
18:47:33 <ppawel> TomH, I will remove my test owl database, it's not needed anymore
18:48:38 <TomH> zere: yep - don't think there will be enough space on / will there? eve with ppawel's database gone
18:50:11 <apmon_> Would it be within the resources of osmf to stick e.g. 256Gb SSD into errol to hold databases?
18:52:22 <zere> haha, i have a 256GB one at home that would do. the question is whether there's a free bay and SATA connection
18:53:01 <apmon_> The wiki page sais that errol has 10 drive bays and lists 7 disks (2 system + 5 data)
18:53:37 <zere> ah, but the raid controller only has 8 SATA ports. even so, that would leave one free...
18:54:04 <zere> anyway, hardware aside, we can see what the situation is once the old OWL database is gone.
18:54:18 <zere> i'll have a look around to see if there's any other old stuff of mine in there
18:56:19 <zere> would anyone like to discuss any other topics?
18:57:13 <zere> anyone interested in changing the time of the meeting, for example?
18:59:56 * alexbarth is good with time
19:01:26 <zere> ok, i guess that's it for this meeting. thanks to everyone for coming! and i hope to see you next week. :-)
19:01:31 <zere> #endmeeting
