Attendees
| IRC nick
|
Real name
|
| apmon |
Kai Krueger
|
| gravitystorm |
Andy Allan
|
| lonvia |
Sarah Hoffmann
|
| pnorman |
Paul Norman
|
| RichardF |
Richard Fairhurst
|
| TomH |
Tom Hughes
|
Summary
- Low zoom tiles
- Discussion on the relative merits of forming low-zoom tiles by downscaling higher zoom level tiles.
- For now: they aren't going on Orm, and if there's interest in seeing them regenerated frequently then we'd recommend someone investigates using dev for them.
- rails port docs
- gravitystorm has finished the Ubuntu docs and is looking for people to verify it works.
- Some discussion on how to incorporate instructions for various distributions of Linux, as they don't differ radically - does it make sense to keep them together, or have them apart and risk drift?
- RichardF is having a look at the Mac OS X docs.
- orm
- Last remaining issue is getting shapefiles sorted.
- test suites
- pnorman and iandees are looking to put together an HTTP test suite for testing the rails_port and other API implementations.
- osm2pgsql testing
- looking at doing unit tests.
- apmon to ask on the postgres IRC channel if there's any existing tools libraries for this.
IRC Log
17:27:56 <gravitystorm> topics: osm-carto rails-port docs. Anyone got other things?
17:28:14 <lonvia> Can we have a quick chat about Fred's low zoom tiles?
17:28:34 <gravitystorm> sure, let's do that first then
17:28:38 <pnorman> me and ian were talking about a test suite to compare one api implementation against another, probably using gatling and a sample .osm file
17:28:44 <gravitystorm> #info zere is on holiday
17:28:50 <gravitystorm> #topic low zoom tiles
17:28:56 <gravitystorm> lonvia: go for it
17:29:18 <lonvia> Are there any plans/interest to get that on orm?
17:29:42 <TomH> no plans that I know of
17:30:21 <lonvia> So how about interest?
17:30:24 <TomH> not opposed, but no idea what is involved
17:30:40 <TomH> I defer to others (ie gravitystorm) on cartographic issues ;-)
17:30:43 <apmon> aren't thos simply stiching tiles together and rescaling them?
17:30:45 <gravitystorm> personally, I don't like the approach - it's not cartographically sharp, it's just a texture of colours
17:31:05 <apmon> gravitystorm: Isn't that the point of them
17:31:17 <pnorman> I like the idea, but not that particular implementation, and I think frederik said as much at one point
17:31:31 <apmon> I don't think they were intended as cartographically sharp. They were intended has a high level overview of where OSM has dense data
17:31:35 <gravitystorm> So it's impossible to do nice cartographic things, e.g. drawing an outline around forested areas. I'd rather work on an approach that downscales the data, rather than downscaling the output.
17:32:05 <lonvia> It has the advantage that it exists at the moment.
17:33:13 <apmon> lonvia: for what use do you intend them for?
17:33:21 <TomH> but needs a whole new set of tooling, while were already setup to render from source with mapnik
17:34:26 <pnorman> frederik did the tiles of a proof of concept of the value of rendering more on low zooms and of downscaling, not as something ready to implement
17:34:55 <lonvia> apmon: they give a good sense of how much data exists.
17:35:19 <lonvia> I'd look into the tooling/deployment, if that is the main issue.
17:35:20 <apmon> OK, so you also don't care about cartography for that purpose
17:35:47 <apmon> You could probably run that fairly easily from dev would be my guess
17:35:59 <apmon> as it probably won't need updating too often or see high loads of serving
17:36:44 <gravitystorm> apmon: +1
17:37:29 <gravitystorm> anyone else got thoughts?
17:37:39 <lonvia> Probably makes more sense to integrate it into the low-zoom-update scripts.
17:37:47 <pnorman> is it possible to tell renderd to never attempt to render tiles in a particular zoom range? or maybe just direct via apache to pre-sliced?
17:38:38 <apmon> not explicitly. You'd have to use the expiry mechanism
17:38:50 <apmon> and e.g. touch all of your tiles in a zoon range to mark them as clean
17:38:52 <gravitystorm> I think perhaps we need to back up - is this a request for these tiles to be generated for those who want them, or is this a request for these tiles to be incorporated into the main tiles served by orm?
17:39:32 <TomH> the latter I think gravitystorm
17:39:38 <lonvia> yes
17:39:45 <TomH> but I would rather concentrate on getting orm into production rather than getting distracted
17:40:20 <apmon> TomH: +1 on getting it into production first
17:40:35 <pnorman> I'd rather see if it can be done by mapnik than tile-merging
17:40:40 <apmon> but also I don't think they are appropriate for a replacement of the current low-zoom tiles
17:41:04 <apmon> they are great as an additional resource, but not realy as the main source, as there cartography does matter
17:41:23 <TomH> and I think it was more than just tile merging - wasn't he generaing labels separately and overlaying the, like t@h used to?
17:41:35 <gravitystorm> TomH: yes
17:42:29 <gravitystorm> apmon: I'd agree with you there, I find there's a novelty to them and they do have a purpose, but the cartography is terrible and I wouldn't want to see them used on the main map style
17:42:54 <lonvia> Well, that answers my question then. ;)
17:43:04 <gravitystorm> :-)
17:43:12 <apmon> Yes the cartography is terrible, but that is kind of the point of them, or their appeal :-)
17:44:07 <gravitystorm> OK, lets say for now that they aren't going on ORM (for now), if there's interest in seeing them regenerated frequently then we'd (for now) recommend someone investigates using dev for them
17:44:45 <gravitystorm> #topic rails port docs
17:45:25 <gravitystorm> I haven't organised any "translations" for the other platforms (fedora and MacOSX) yet, but I'll try to sort these out soonish
17:45:43 <gravitystorm> Has anyone tried to follow through the Ubuntu versions, to check that they work?
17:46:10 <pnorman> I did a partial follow-through, but I only needed to go as far as database setup, I was loading some data into an apidb
17:46:10 <gravitystorm> https://github.com/openstreetmap/openstreetmap-website/pull/317 is the pull request
17:47:01 <gravitystorm> perhaps if nobody wants to run through them, we should just assume they work?
17:47:23 <gravitystorm> TomH: any other thoughts on the docs, beyond the bundle/bundler change?
17:47:37 <TomH> I can do Fedora, but I don't really want to copy and paste the whole thing just to change 5 lines
17:48:01 <TomH> as they will just get out of sync
17:48:09 <gravitystorm> yeah, it's not ideal
17:48:37 <gravitystorm> until I see what the MacOSX notes are like, it's hard for me to judge where to split them.
17:49:01 <pnorman> well, with TomH on fedora, wouldn't ubuntu get out of sync? :)
17:49:07 <gravitystorm> Of course, if you'd prefer, we could inline the yum notes, and only link out to macosx
17:49:38 <RichardF> that would make sense
17:49:45 <RichardF> the OS X notes would roughly be "use Homebrew, use Postgres.app"
17:51:03 <gravitystorm> RichardF: I guess there's quite a lot of https://github.com/gravitystorm/openstreetmap-website/blob/a5fd9af604af631c72358b1324332a1b9d9a79c3/INSTALL.md that would need changing
17:51:43 <gravitystorm> well, maybe I should say "is there a lot that needs changing?"
17:52:10 <RichardF> mostly the "these can be installed on Ubuntu 10.10 or later with:..." line
17:52:26 <TomH> maybe e should try knocking up the other versions, and then seeing how much they differ and decide what to do from there?
17:52:52 <RichardF> I'd need to check that btree_gist is included with Postgres.app but I'd expect that it is
17:52:54 <gravitystorm> i.e. how to binary names (psql, createuser) compare cross-platform, does the backticks in the db functions section work
17:53:12 <gravitystorm> https://github.com/gravitystorm/openstreetmap-website/blob/a5fd9af604af631c72358b1324332a1b9d9a79c3/INSTALL.md#postgresql-functions
17:53:51 <RichardF> psql and createuser are the same
17:54:11 <RichardF> Postgres.app is 9.2.2 so the CREATE EXTENSION syntax works
17:54:29 <pnorman> gravitystorm: I scanned and didn't see anything except for the apt section which would vary between any BSD or linux distro that has recent enough packages
17:54:53 <apmon> I ran into gem issues with "target ruby_20" not valid the other day
17:55:27 <apmon> looks like the default ruby on ubuntu has issues with unknow (newer) targets and prevents execution
17:55:35 <TomH> that means you need a newer bundler
17:55:42 <TomH> but I think I worked around that
17:55:58 <gravitystorm> So it sounds like inlining the prerequisites might be a better approach then
17:56:49 <gravitystorm> RichardF: can you send me something MacOSX-y that i could put there?
17:57:07 <RichardF> yep. how'd you want it? (preferably not involving git)
17:57:14 <gravitystorm> RichardF: email is fine
17:57:39 <gravitystorm> cool, next topic
17:57:47 <gravitystorm> #topic orm
17:58:06 <gravitystorm> where are we at with getting orm into production?
17:58:26 <gravitystorm> oh, one outstanding request is on me, I remember that now. Sorting out shapefiles.
17:58:38 <gravitystorm> anything else?
17:58:52 <TomH> don't think so
17:59:25 <pnorman> nothing afaik
17:59:36 <gravitystorm> OK
17:59:43 <gravitystorm> I'm out of topics. Anyone else?
18:00:11 <apmon> pnorman: Was there something to discuss about test suits?
18:00:37 <gravitystorm> that's a good EWG topic
18:00:41 <pnorman> ya. we have no test suite to test one api implementation against another. e.g. cgimap vs rails port
18:00:44 <gravitystorm> #topic test suites
18:01:53 <pnorman> since i have the gsoc project, me and ian were talking about writing one for gatling (http test framework) where you'd load up a sample fake .osm file into the server of your choice, point gatling at it and fire away
18:02:58 <gravitystorm> is this http://gatling-tool.org/ ?
18:03:02 <pnorman> yes
18:03:26 * pnorman is not set on any particular framework really
18:03:37 <apmon> Is it possible to point the rails_port integration test suit at a different api [http://git.openstreetmap.org/rails.git/tree/HEAD:/test/integration]
18:03:49 <apmon> or is that too integrated into rails?
18:05:33 <TomH> it doesn't actually make requests to a web server if taht is what you mean
18:05:35 <pnorman> doesn't seem to have API stuff, just website stuff
18:06:11 <TomH> oh the integration tests we have currently are minimal
18:06:24 <TomH> most of the api stuff is tested in the functional tests
18:06:39 <pnorman> I think this is the large part of the barrier to getting cgimap deployed for other calls
18:09:40 <gravitystorm> I don't know what the best approach is on having tests within each piece of software (close to the developer vs duplication of tests) vs having tests in an external framework (consistency between implementation vs extra faffing while testing).
18:10:02 <gravitystorm> Perhaps it's worth setting something up and coming back with pros/cons?
18:10:09 <pnorman> for my purpose I need it in an external framework
18:10:24 <gravitystorm> pnorman: is this perfomance comparisons?
18:10:34 <pnorman> gravitystorm: no, validating what I did is right
18:11:05 <pnorman> performance is pretty simple. I'm about 50% faster than apidb, even if I screw things up badly.
18:11:40 <gravitystorm> well, technically to pieces of software with two comprehensive test suites would be fine, even if both test suites had duplicate tests (e.g. create node 1, ensure XML says "<foo>")
18:11:54 <gravitystorm> s/technically to/technically two/
18:12:28 <pnorman> well, if you can find a 100% accurate description of all details of the API calls including headers in and out, let me know :)
18:13:07 <apmon> Yes, having one definative set of tests, which can be tested agains each of the API implementations would imho be very desirable
18:13:26 <TomH> cross validation was what zere wanted I think, before he was happy to make the other methods live
18:15:01 <gravitystorm> so from this it sounds like the external approach is wanted.
18:15:15 <apmon> yes
18:15:38 <pnorman> based on the reading I've done so far, I'm inclined to gatling, but open to any other suggestions
18:15:38 <gravitystorm> I hereby say "Good luck" to whoever is attempting to build the aforementioned 100% accurate description
18:17:28 <pnorman> the other test suite issue is osm2pgsql
18:17:47 <apmon> yes!
18:17:56 <gravitystorm> pnorman: I don't have any suggestions beyond just checking if existing test frameworks that we're familiar with (e.g. Test::Unit/minitest from the rails port) work
18:18:16 <gravitystorm> pnorman: that was for the previous topic, of course
18:18:18 <pnorman> I saw on the list that gravitystorm was volunteering to write one :)
18:18:21 <gravitystorm> #topic osm2pgsql testing
18:18:40 <pnorman> basically, I need to issue HTTP requests with specific headers, get requests back and check for headers and for XML contents
18:18:53 <gravitystorm> someone pick a framework, I have no idea how that works in "proper" languages
18:19:05 <apmon> For osm2pgsql testing I suspect one needs to setup a db.
18:19:10 <apmon> rather than do it as unit tests?
18:19:25 <RichardF> gravitystorm: you have mail!
18:19:33 <gravitystorm> RichardF: ta
18:19:47 <pnorman> probably some room for unit tests, but I doubt you can unit test the entire thing
18:20:22 <gravitystorm> apmon: I'm not entirely sure what's available. I suspect unit tests will go a long way (all the geometry processing) and maybe even just mocking the database connections
18:21:03 <pnorman> part of the issue to me seems to be that we don't have any defined output for osm2pgsql
18:22:08 <gravitystorm> well, similar to the behaviour of the API, that can be nailed down when the tests are written
18:22:18 <apmon> me neither. So I'd really appreciate if someone you set up the scafolding of a good test suit, to work from
18:22:42 <lonvia> It would be fairly easy to set up a test suite that produces small XML files, runs osm2pgsql and checks DB content. All blackbox.
18:22:54 <apmon> I don't have experience with many test suits and what their pro and cons are
18:23:17 <lonvia> apmon: just get started with one. Any tests are useful at this point.
18:23:48 <pnorman> I'll ask in #postgresql about frameworks suitable for testing an ETL program
18:23:49 <apmon> so somewhat like the approach already taken in https://github.com/openstreetmap/osm2pgsql/blob/master/tests/regression-test.sh ?
18:23:59 <apmon> just with more thorow checking of the results
18:24:19 <apmon> and using a well crafted osm.pbf instead of just liechtenstein.osm.pbf?
18:24:30 <gravitystorm> I'm not a big fan of only having "entire system" checks like that
18:24:45 <gravitystorm> but of course, enemy of the good and all that
18:25:02 <lonvia> gravitystorm: those are the one you neeed if somebody wants to attempt refactoring.
18:25:06 <pnorman> they catch when stuff goes wrong, but good luck finding what went wrong
18:25:41 <gravitystorm> pnorman: indeed
18:26:09 <pnorman> fyi - takes about 4 hours and $1.40 on EC2 to do a europe import
18:26:17 <apmon> unit testing possibly needs refactoring of the code in osm2pgsql to have better encapsulation
18:26:45 <lonvia> Which you shouldn't be doing before you have tests.
18:26:45 <apmon> In mod_tile renderd, I am adding tests while doing the refactoring to better abstraction
18:27:07 <gravitystorm> apmon: I guess we'll find that out when we try. I suspect there's a bunch of methods - pg_out_relation or whatever - that are reasonably easy to test independently.
18:27:14 <apmon> well, you can't really unit test, if there isn't a clean unit to stat with ;-)
18:27:54 <apmon> pg_out_relation, pulls in the whole middle layer and everything else as well currently.
18:28:03 <apmon> So that is probably the worst choice to start with... ;-)
18:28:03 <gravitystorm> apmon: how about trying http://check.sourceforge.net/ ? First result from a bit of google/stackoverflow work
18:28:39 <gravitystorm> apmon: I defer to your (infinitely) larger knowledge of osm2pgsql internals :-)
18:29:01 <apmon> For unit testing, I'd probably prefer if we could use the same framework as in mod_tile / renderd
18:29:53 <apmon> which appears to be using https://github.com/philsquared/Catch/
18:30:35 <gravitystorm> sounds good
18:31:38 <apmon> but I'd also like a integration test suit, as it is hard to mock up all of the peaces necessary for testing units each time
18:32:34 <gravitystorm> Any other thoughts on this topic?
18:34:22 <pnorman> i'd also welcome any suggestions on frameworks
18:35:05 <gravitystorm> cool
18:35:25 <gravitystorm> I'm going to end the meeting now then, sorry it's all been shifted by 30mins
