Attendees
| IRC nick
|
Real name
|
| pnorman |
Paul Norman
|
| zere |
Matt Amos
|
Summary
- Osm2pgsql PR #164
- https://github.com/openstreetmap/osm2pgsql/pull/164
- The PR splits the dual meaning of the existing "polygon" flag into two separate flags.
- The name of one flag, "hstore", is misleading as it indicates whether or not the presence of a tag with that key will cause the object to be stored. While it overlaps with hstore, calling it that would lead to (even more) confusion.
- pnorman suggests "nomatch" instead, which fits better.
- Osm2pgsql release practices
- Using a numeric x.y.z triple for several revisions is potentially problematic, as it does not indicate a specific revision which can then be tested / bug fixed.
- pnorman suggests appending '-dev' or '-rcN' or something similar to distinguish the "non-release" versions.
- Budget 2015
- EWG has tried various things in the past, e.g: funding for hack weekends, without much take-up. This year it seems simpler to not budget for things we've demonstrably not spent in the past.
IRC Log
17:32:52 <zere> minutes of the last meeting - they're a short read: http://wiki.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2014-12-12
17:33:23 <pnorman> also osm2pgsql releases
17:33:35 <zere> on the agenda today: https://github.com/openstreetmap/osm2pgsql/pull/164 & osm2pgsql releases
17:33:47 <zere> #topic osm2pgsql PR #164
17:34:14 <zere> i must confess, i'm not entirely sure what the PR accomplishes
17:35:18 <pnorman> if you're running with hstore match only you effectively can't have name as a real column with the current version, because it forces everything with a name (i.e. lots of stuff) to appear in the tables
17:37:19 <zere> okay, but the patch doesn't appear to change the logic at all
17:38:18 <pnorman> my understanding is that by adding hstore as its own flag https://github.com/openstreetmap/osm2pgsql/pull/164/files#diff-723033792967b078548cb322ad03c2d3L86 (taginfo.cpp:87) works with linear,hstore
17:39:34 <zere> i dunno... i would have expected that FLAG_HSTORE (which didn't exist before) would have to be checked somewhere else as well?
17:42:09 <pnorman> I haven't played around with it, but i think it's sufficient. phstore was always 17 which is 16 and 1, now polygon and hstore
17:43:39 <pnorman> I think one conclusion is that it needs clear examples of usage with polygon and linear, interactions with hstore options, and tests for the above
17:46:44 <zere> yup, i guess the logic must be something like "if tag not in normal_columns then hstore", which i guess is sufficient.
17:48:05 <pnorman> in some ways the logic would be better redone inverted - one flag to indicate polygon status, and others to indicate that it belongs in the linear and/or polygon tables
17:48:18 <pnorman> but this would break every existing style file
17:49:09 <zere> s/polygon status/hstore status/?
17:49:35 <zere> i guess it needs a mention here: https://github.com/openstreetmap/osm2pgsql/blob/master/docs/usage.md#hstore although there's no existing mention ofphstore
17:51:24 <zere> in fact, i can't find where the 'style' file format is documented at all...
17:52:00 <pnorman> in default.style
17:53:40 <zere> yeah, didn't look there ;-)
17:53:41 <pnorman> and to your s/..., no - "add to hstore" is really about "don't add objects based on this flag"
17:54:04 <zere> probably worth having that doc in the "docs" directory at some point, but not important for this PR.
17:55:42 <zere> i mean, the polygon flag presumbly already indicates polygon status and whether it belongs in the linear and/or polygon tables. the hstore flag might not mean what it says, but it's unrelated to whether something goes into the polygon or linear tables (i thought that was the point of this PR)
18:03:47 * zere obtains a case of West Berk's "Yule Fuel" to celebrate planetdump-ng deployment.
18:04:10 <zere> now all i have to do is make sure i drink it before it all falls over ;-)
18:05:03 <pnorman> no, the hstore flag causes something to not go in the polygon tables unless some other command line option causes it to (an hstore option without --hstore-match-only)
18:06:05 <zere> polygon or linear, though? i thought the whole point of this PR was that it makes the hstore flag independent of the linear/polygon status?
18:06:29 <pnorman> both
18:06:46 <pnorman> but the polygon case is clearer since I understand it since it's just phstore
18:07:14 <pnorman> maybe a name like nomatch would be clearer for the flag?
18:07:31 <zere> right. so hstore is a bad name for it: "hstore_if_you_have_enabled_that_through_the_command_line_switch_or_else_drop_the_whole_feature" is better, although more of a pain to type ;-)
18:10:14 <zere> there's two separate things at work here: 1) whether the presence of this tag should cause the feature to be dropped or put in the table, 2) whether the tag should have its own column or be in an hstore column
18:10:52 <zere> nomatch would be good for (1), and hstore for (2). so perhaps leave hstore as it is for now and add an issue to split "nomatch" out as a separate flag.
18:12:08 <zere> except, of course, hstore currently implies nomatch... which is a bit of a pain. it would then require 2 new flags.
18:12:48 <zere> yes.
18:13:16 <zere> having thought about it fr all of 5 minutes: pnorman is right - it should be called nomatch at the moment. then hstore can be pulled out of it later.
18:14:23 <pnorman> so, we suggest renaming it to nomatch to be clearer, documenting it better?
18:16:23 <zere> the documentation is... well, probably a separate task. but yes, renaming to nomatch would (for the moment) be clearer.
18:16:35 <zere> especially for anyone not running with the hstore command line args.
18:16:56 <pnorman> well documenting nomatch/hstore/whatever is in scope, since it's a new flag
18:17:44 <zere> right, but in default.style - i think it would be great to have more documentation about the style file, flags and expected behaviour, but it might be a bit much to ask for that in this PR
18:18:31 <pnorman> yes, not after an entirely new set of docs for .style files, which we do need, but just something clearer than "add tag to hstore only instead of its own column"
18:21:47 <pnorman> okay, i'll summarize it on the PR
18:27:04 <pnorman> release practices?
18:27:55 <zere> #topic osm2pgsql release practices
18:28:36 <zere> pnorman: what about the release practices did you want to talk about?
18:29:05 <pnorman> currently we do use x.y.z tagging, do dev work, advance .z, tag it, do dev work, advance .z, tag it. the problem is that this gives no indication if someone is using a released build or built from git master
18:29:36 <pnorman> should we be appending -dev, -rc1 or similar to the version?
18:31:38 <zere> the version in the configure.ac, you mean?
18:31:47 <pnorman> yes
18:35:33 <zere> yes, i guess they should... but it's a bit of a pain to have that extra commit for a revision. i suppose there's no other way to do it
18:35:55 <pnorman> i'd rather have that then try to guess from version output what they're doing :)
18:37:06 <zere> i was wondering if it would be possible to include the output of `git describe` in there somewhere
18:37:57 <pnorman> probably, i'll look into other practices
18:38:21 <zere> but then you run into problems when people `git archive` it and it doesn't have the revision information any more.
18:38:44 <zere> i think setting it manually in the configure.ac is probably the least error-prone option.
18:42:22 <pnorman> k.
18:47:05 <pnorman> AOB?
18:49:22 <zere> yup
18:49:25 <zere> #topci AoB
18:49:35 <zere> #topic AoB
18:49:43 <zere> anything else anyone wanted to discuss?
18:50:12 <pnorman> we need our budget. given we've not spent it in the past, do we want to not request anything?
18:52:25 <pnorman> I mean, I'd like to request some money to help out hack days, on the other hand, I'd guess our chance of using it is probably <10%. maybe request it anyways?
18:52:47 <zere> as i understand it, we get a "default budget" ok £1k
18:52:52 <zere> s/ok/of/
18:52:54 <pnorman> yes
18:53:13 <zere> and in the last few years we've had exactly zero people apply for funds to help out hack days
18:53:36 <pnorman> probably because we've had approximately zero people aware who were running new hack days
18:56:23 <zere> perhaps. although we tried promoting it more (https://blog.openstreetmap.org/2014/01/20/hack-weekend-december-2013/) and still had zero interest
18:57:20 <zere> i think perhaps by the time people are willing and ready to run a hack event, they're already beyond needing that sort of help.
18:57:26 <pnorman> yes
18:58:28 <zere> i'm afraid i have to go... but i'll put this on the agenda for the next meeting (jan 5th?) and we can discuss it some more
18:58:33 <pnorman> k
18:58:47 * pnorman needs to go too
18:59:09 <zere> thanks to everyone for coming. have a wonderful winter holiday & a happy new year. hope to see you on the 5th :-)