Jump to content

Working Group Minutes/EWG 2012-02-27

From OpenStreetMap Foundation

Attendees

IRC nick Real name
ajashton AJ Ashton
apmon Kai Krueger
migurski Michal Migurski
pnorman Paul Norman
RichardF Richard Fairhurst
stevensn Steven Singer
tmcw Tom MacWright
TomH Tom Hughes
zere Matt Amos

Summary

  • Why can't people find EWG / rails-dev?
    • No inward links - need mentions in READMEs, on the IRC page on the wiki.
    • TomH added inward links from the rails_port README.
  • TomH / zere had worked on a new README for rails, which got some support. TomH added it to the project and we'll improve it in-situ from now on.
  • SVN: "SVN is pretty much considered deprecated. there's lots of (poorly categorized) software in there and i don't think we're ready to retire it just yet, but no new projects should use it."
    • Would be better to add that to a banner at the top of the SVN-generated pages.
    • Plan to start moving projects out of SVN and into the OSM organisation on github - being vigilant for inward links to SVN that need to be converted, e.g: on the wiki.
    • The deployed / official code should be on git.openstreetmap.org, although this wouldn't be the target of pull requests - that should be the OSM organisation on github.
  • ajashton has done some work towards porting the current OSM "Standard" XML stylesheet to Carto, but it is complicated due to the "combinatorial explosions of tag intersections".
  • There was some discussion of next generation imposm / osm2pgsql successors / alternatives. It seems there are many approaches of various levels of technical difficulty and no obvious way forward at present.
  • TomH and tmcw ran through status of proposed patches to the rails_port.
    • The 'tabs' and 'login' items are ready.
    • It was agreed that the 'data browser' one "needs more baking".
    • The 'comments' one is nearly ready.
  • There was discussion of OpenStreetBugs branch & how to get that moving again.
    • tmcw offered to take a look at the JS front-end.
    • There might be overlap with clickable-POIs in terms of leading to a better UX for casual editing.

IRC Log

18:05 < RichardF> hello!
18:05 < TomH> alloa
18:05 < zere> minutes of the last meeting, please let me know if there's something objectionable, wrong, etc...: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-02-20
18:06 < zere> draft agenda for today: UX (user experience) on the rails port and license change
18:06 < TomH> and review the new README
18:07 < zere> yup
18:07 -!- migurski [~migurski@173-164-158-185-SFBA.hfc.comcastbusiness.net] has joined #osm-ewg
18:07 < TomH> we should also consider if there's anything more we can do to advertise EWG and rails-dev - tmcw may have some ideas since whatever we did wasn't found by him
18:08 < tmcw> TomH: a bunch of places for more visibility: on the irc page, in readmes of relevant projects
18:08 < TomH> well they're both in the new README for the rails code now - I added EWG yesterday
18:08 < zere> that probably falls under the heading "why can't i find anything on the wiki", which is a bit broader, but sure... :-)
18:08 < tmcw> Also possibly an announcement in #osm-dev
18:09 < zere> TomH: what's the latest gist for the README you have?
18:09 < TomH> https://gist.github.com/1915229
18:10 < TomH> I added a mention of the license and of EWG to your last version
18:11 -!- ajashton [~aj@c-98-218-228-75.hsd1.dc.comcast.net] has joined #osm-ewg
18:12 < tmcw> Can I add the SVN repo & trac status to the agenda?
18:12 < RichardF> TomH: that looks good - can't find anything immediate to add to that
18:12 < TomH> bwaha - that's a whole meeting in it's own right ;-)
18:13 < tmcw> TomH: heh, okay, will leave that for an in-person sotm throwdown
18:13 < zere> TomH: i added a link to EWG's OSMF wiki page https://gist.github.com/1925920
18:13 < TomH> RichardF: well I think it's clearly better than the current one so I say we stick in it - we can always improve it in situ
18:13 < RichardF> +1
18:14 < zere> i think it's safe to state for the record that SVN is pretty much considered deprecated. there's lots of (poorly categorized) software in there and i don't think we're ready to retire it just yet, but no new projects should use it.
18:14 < zere> am i close to the mark there?
18:14 < TomH> well that's my POV
18:14 < migurski> possible to add a note that effect to the top of every HTTP view of the repo? 
18:15 < TomH> and (JOSM plugins aside...) I try and dissuade people who ask for account from using it, but don't always succeed
18:15 < zere> it's true that there's a whole bunch of links to it from the wiki... not sure whether there's an easy way to track them down and update them.
18:15 < tmcw> There are quite a few projects still lingering, besides josm plugins
18:15 < zere> migurski: good idea!
18:15 < RichardF> I think the one thing that slightly bemuses me is why (AIUI) JOSM plugins are in the OSM rather than the JOSM svn
18:15 < TomH> tmcw: oh sure, many of them long abandoned - plugins is the main source of new requests for accounts
18:15 < RichardF> could we suggest gently to the JOSM people that they take them?
18:15 < tmcw> as frederick pointed out on the wiki page, stuff like tirex, mod_tile, osm2pgsql
18:16 < apmon> RichardF: I think it is due to user permissions
18:16 < TomH> RichardF: it may need to be more than gentle - only the other day I was told they were "quite happy with the current arrangements"
18:16 < apmon> the osm one is open, so suitable for the various authors of plugins, whereas the josm repo is relatively restrictd
18:17 < migurski> any reason not to maintain SVN and keep it connected to Git using git-svn?
18:18 < migurski> I mean, I guess that's what's happening now, but any reason to not wrap an official policy around it? 
18:19 < TomH> migurski: it doesn't make sense to have one git for the whole of svn - there are hundreds of separate projects in svn
18:19 < tmcw> migurski: mainly my reasoning for encouraging Git is so that contributors, once they've put in the time to get git set up, can contribute to other things
18:19 < migurski> can be done for subdirs, though
18:19 < TomH> the only common factor being a link (sometimes vague) to osm
18:19 < zere> we could probably pretty easily extract the "active" projects from SVN and put them into the openstreetmap organisation on github, right? things like mod_tile, tirex, osm2pgsql, the OSM mapnik style?
18:19 < migurski> yeah 
18:19 < tmcw> zere: y, exactly
18:20 < TomH> that's been what we've done so far - everything I commonly edit is now out I think
18:20 < migurski> although: there may often be code bases that reference those SVN repos
18:20 < tmcw> Needs some personal attention, like I'm game to help out the maintainers of the mapnik style to transition
18:20 < zere> and then gradually try and clear out the remainder. most will be junk and hopefully we can just freeze a snapshot and say "no more, please, use github instead"?
18:20 < TomH> tmcw: BTW where did you see a copy of the rails code in svn? AFAIK there is only a text file pointing at git?
18:21 < tmcw> TomH: yeah, I think it's just the text file. Must have seen the copy of the rails port earlier when it was still there.
18:21 < TomH> README is now up: https://github.com/tomhughes/openstreetmap-website
18:21 < RichardF> \o/
18:21 < apmon> would it move to git.openstreetmap.org or gitbub.org/openstreetmap?
18:22 < TomH> probably both for the mapnik style
18:22 < TomH> though we would have to think about that - it's a minor detail though
18:23 < apmon> what about things like mod_tile or osm2pgsql?
18:23 < RichardF> (related issue - at some point it'd also be good to talk about transitioning the Mapnik style to <CSS styling language du jour>)
18:23 < TomH> rule of thumb is that if we use it in production then git.osm.org has the version that is being used in production
18:23 < tmcw> RichardF: ajashton can chime in there, definitely a complex issue
18:23 < TomH> but we don't really expect people to interact with that - it is just a deployment tool
18:23  * tmcw wrote one of the css styling languages du jour
18:23 < RichardF> :)
18:24 < tmcw> y - I think pointing to git.openstreetmap.org too much is confusing
18:24 < RichardF> I'm aware that the demands on the Mapnik style are likely to get greater given the imminent demise of t@h
18:24 < tmcw> calling it the 'official repo' is just likely to make people clone it and then be stuck as far as contributing
18:24 < zere> having the OSM mapnik style in something like carto would be wonderful. i suspect steve chilton would much prefer to use tilemill than editing mapnik XML by hand ;-)
18:24 < apmon> tomh: so e.g. the mod_tile on git.osm.org would currently be a somewhat outdated version of master in github?
18:24 < ajashton> I did begin an attempt at a direct port from the XML to Carto, but there are some issues with Carto that made that difficult
18:24 < zere> i suspect it would take a fairly large amount of time, however.
18:24 < TomH> tmcw: there was some reluctance when we moved to git to make a commercial site like github the "official" source
18:25 < migurski> TomH, I agree with that.
18:25 < tmcw> TomH: yes, definitely - and I agree that git.openstreetmap.org should be the official source
18:25 < migurski> Git makes it possible to have Github be a fleetingly-official source
18:25 < migurski> but the real shit should always be an owned domain
18:25 < TomH> tmcw: I think that has largely subsided now and like I say git.osm.org is mostly a deployment tool in that our chef recipes pull from there to deplot
18:26 < zere> ajashton: wow - that's cool. even if you only got part of the way thought, would it be worth releasing what you have? perhaps others might pick it up and continue?
18:26 < tmcw> I'm talking just about how we say 'want to contribute to the rails port'? Point to GitHub.
18:26 < RichardF> yep. if you care about such things, you'll know the difference between git.osm.org/github.
18:26 < ajashton> I didn't get very far with the port (only landusages basically)... the problem is the way tag combinations work in the osm2pgsql schema does not play nice with the way carto (and cascadenik, I believe) process the stylesheets into xml
18:27 < TomH> tmcw: sure, which is what the new README does I hope, whiel offering the option of mailing patches to rails-dev for people with philosophical problems using github...
18:27 < migurski> ajashton: you talking about the kinds of combinatorial explosions of tag intersections we see?
18:27 < ajashton> yes
18:27 < ajashton> a few hundred lines of mapnik xml -> 90 lines of carto -> 100,000 lines of xml
18:27 < migurski> ha yeah
18:27 < migurski> also, a related issue is that the osm2pgsql schema is a horrible fit for Tilemill
18:28 < zere> tmcw: yup, and that gets a bunch easier with the new README, i think. we can just say "see https://github.com/openstreetmap/openstreetmap-website" and the rest of the information should be accessible from there.
18:28 < TomH> help Jochen replace osm2pgsql then ;-) http://blog.jochentopf.com/2012-02-27-hacking-weekend-ii.html
18:28 < tmcw> zere: TomH: great
18:28 < migurski> so perhaps there's a way to get the official style up to Cascadenik or Carto or whatever, by way of a custom mapping in something like Imposm
18:28 < tmcw> I think we're all on the same page as far as github/git/svn
18:28 < zere> migurski: yeah, we talked about that a little before. i dunno what's the shortest-path from here to something with imposm's flexibility and osm2pgsql's diff-updating.
18:29 < migurski> I've had good luck with postgres views on top of osm2pgsql tables
18:29 < migurski> though, I am unfamiliar with the possible performance implications of that
18:29 < migurski> e.g. https://github.com/migurski/HighRoad/
18:29 < TomH> should be fine if you have the right indexes
18:30 < TomH> postgres just rewrites queries against views into queries against rthe underlyign tables
18:30 < migurski> right
18:30 < RichardF> is Jon Burgess still around? he'd seem like an obvious person to get involved with some of this, but I've not seen hide nor hair of him for ages.
18:30 < TomH> he turned up at the last OWG
18:30 < RichardF> ah, excellent
18:31 < migurski> well, cool - that might be a way to keep the osm2pgsql schema under the hood while still providing a more broken-down set of views to keep the rules short and sweet
18:31 < zere> we do a similar thing with the MQ styles (without the intermediate views), but i find that the partial indexes aren't quite as good as having a dedicated (and fewer-columned) table.
18:31 < migurski> I would imagine a lot of skipping around on disk
18:32 < migurski> are they better than direct queries into a many-columned table, though?
18:32 < tmcw> migurski: we've found that imposm can get you a lot of the way that highroad does as well, but in a static'ish way that's pretty fast
18:32 < tmcw> imposm = shockingly flexible
18:32 < zere> indeed. and the row records are wider, which presumably wastes disk bandwidth. although i guess it's possible that postgres is clever enough to do something about that.
18:32 < migurski> yeah I've found that as well
18:33 < TomH> zere: well 9.2 will finally have key only reads, but I guess that is unlikely to be enough?
18:33 < migurski> been quietly adding imposm support to various tools and thing because it's so good 
18:33 < zere> yeah. the place where i really, really want imposm is for the stuff you can't easily do with indexes alone, like generalising geometry.
18:33 < tmcw> Okay, cool, so imposm/mapnik/cssy maps - worth some experiments
18:34 < migurski> might geometry generalization be added to osmpgsql? 
18:34 < migurski> imposm makes additional tables
18:34 < zere> but, sadly, the lack of diff support is a killer for us...
18:34 < migurski> but it's often possible to get the same result by making additional geometry columns
18:34 < zere> yes, we could make osm2pgsql more flexible. 
18:34 < tmcw> *cough* http://ds.io/yDhnHc  *couch*
18:34 < ajashton> oliver was open to sponsors for a push on diff support a while back I think
18:35 < migurski> interesting - I'm not familiar with the internals but I believe it's in python, which makes it easier for me to approach than C
18:35 < tmcw> migurski: y, it's basically c where it matters
18:35 < migurski> schwing
18:36 < zere> tmcw: that link doesn't seem to be working for me :-(
18:36 < tmcw> > http://mapbox.com/blog/announcing-mapbox-streets/
18:36 < zere> ah, it finally loaded, sorry :-)
18:36 < tmcw> (appropriate, github is getting ddos'ed right now)
18:36 < RichardF> aaand http://twitter.com/#!/openstreetmap/status/174197248211685376
18:36 < migurski> tmcw: there's a release-outside bug on the slippy maps on that page
18:37 < tmcw> migurski: y, they're in iframes so it's hard to prevent.
18:37 < migurski> ah
18:37 < migurski> sadness.
18:37 < apmon> It shouldn't be too difficult to add a second way_simplified column to osm2pgsql
18:38 < migurski> I do it all the time anyway, doesn't take long to do all the motorways in the US for example - having it integrated into osm2pgsql would be really cool
18:38 < migurski> imposm's two levels of simplification seem good enough
18:39 < apmon> migurski: Are you planning on giving it a try to include a way_simplified column into osm2pgsql?
18:40 < migurski> I'm not much of a C developer unfortunately, all I can really do is cheer from the sidelines
18:40 < zere> surely you don't want a way_simplified column on all geometries, though?
18:41 < migurski> why not?
18:41 < apmon> It can be null for the ones for which the geometry is too simple
18:41 < migurski> yeah
18:41 < apmon> e.g. mostly buildings and residential roads
18:41 < zere> seems like it would be a waste of disk space & cpu time to do it for everything. 
18:41 < zere> the stuff that goes into planet_osm_roads might be worthwhile, though.
18:42 < migurski> We could skip the points. Those are pretty simple already.
18:42 < zere> but i'm drifting back into thinking that a table per feature type is the best option. :-)
18:42 < apmon> you could probably do a quick bbox calculation. if it is less than e.g. 500m wide, then don't do the simplification
18:43 < apmon> there would need to be something equivalent to planet_osm_roads for polygons
18:44 < apmon> zere: A short agenda item I forgot to add, evaluating gosmore routing for larger scales
18:44 < migurski> apmon: planet_osm_parks, that sort of thing? 
18:45 < migurski> I tend to roughly divide polygons into "green things", "gray things", and buildings when I develop a new style
18:45 < migurski> basically parks/pitches/golf/woods for the one, schools/parking/hopsitals for the other, and building=yes for the third
18:45 < apmon> migurski: planet_osm_no_building_polygons would be a good start
18:46 < migurski> yeah
18:46 < apmon> The ratio between building polygons and non building polygons is about 6:1 at the moment
18:46 < migurski> wow
18:47 < apmon> Which is why I added a partial geometry index on building==null to osm2pgsql. But Frederik deleted that code again
18:47 < migurski> heh
18:48 < zere> how easy would it be to run multiple backends for osm2pgsql? the majority of the time spend when diff updating is in the middle code, right?
18:48 < apmon> majority is spent on looking up nodes
18:49 < apmon> so, yes, the middle code
18:50 < apmon> I attempted to store the coordinates in a 12Gb mmaped file. It should be much more efficient than the 100Gb planet_osm_nodes table or such
18:50 < apmon> but at least on my laptop that didn't work out too well.
18:50 < apmon> Possibly, as I never tried it on full planet imports, but just on small extracts for which the non sparse coding is not very efficient.
18:51 < apmon> I.e. basically taking the existing node cache and making it persistent.
18:52 < migurski> that seems to be how imposm uses tokyo cabinet
18:52 < apmon> Somewhere on the wiki, I read that if you have little ram and full planet imports, it is faster to use  large -C and then rely on swap than use a small C and rely on the db backend
18:53 < migurski> for me that usually results in the process getting killed by the OOM
18:53 < zere> possibly this is somewhere that postgres 9.1's unlogged tables can help?
18:53 < apmon> I don't think so
18:53 < zere> stevensn: ^^ would unlogged tables help with this?
18:53 < apmon> you wouldn't want to truncate those when postgresql crashes
18:53  * pnorman waves
18:54 < apmon> also I think the problem is pretty much on the read side, not the write part
18:54 < migurski> the seek time basically? 
18:54 < apmon> my guess would be yes, it is the seek time.
18:55 < stevensn> zere: writing to an unlogged table would be faster than writing to a logged one, but it is still writing to a table on disk
18:55 < apmon> And that the nodes table with index was something like 100Gb if I remember correctly vs about 12Gb in a flat array, presumably doesn't help
18:57 < tmcw> okay, so improving osm2pgsql / testing other stuff: can that conversation branch off?
18:57 < zere> so the time is spent less in updating the nodes table than gathering node positions from it for the ways?
18:57 < TomH> yes we should probably get back on the agenda ;-)
18:57 < zere> tmcw: yup, sorry. back to the agenda...
18:58 < zere> who wants to lead on the UX discussion?
18:58 < tmcw> this guy?
18:58 < TomH> well a quick run through of patch statuses...
18:58 < apmon> zere: That is my understanding, but I might be wrong on it. It is a little difficult to benchmark and test. But Yes, we should get back to the agenda... ;-)
18:58 < TomH> no comments on the tabs except me
18:58 < TomH> one positive comment on login so I'm inclined to pull that unless anybody objects?
18:59 < ajashton> +1 for the login
18:59 < TomH> data browser one looks like it still needs work, but I see tmcw has a new branch there
18:59 < tmcw> y, that one needs more baking.
18:59 < apmon> I am wondering if the OpenID stuff could be clearer with respect to account creation
18:59 < TomH> and ssinger's comments one is nearly ready I think
18:59 < TomH> I left some more comments on that earlier on
19:00 < tmcw> apmon: Yes, I think that should be in a second push to login stuff, which would also tackle the top-right menu of the home page.
19:00 < zere> is there anywhere where these are merged on a branch we could get up on apis.dev.osm.org?
19:00 < pnorman> I have a spare raid array for benchmarking - talk to me later (on iPad)
19:00 < TomH> zere: yes tomh.aps.dev.osm.org has them all
19:00  * TomH wonders if zere is reading rails-dev
19:00 < TomH> tomh.apis is the "next" branch from my repo
19:01  * tmcw only subscribed to rails-dev like three weeks after starting doing rails dev
19:01 < apmon> tmcw: The easiest way to create an (openID) account, is to go to the login page and click on the appropriate OpenID logo. It should then redirect you to the prefilled out account creation page
19:01 < migurski> guys I have to duck out. No particular opinions on the UX from me except Good Luck. ;)
19:02  * migurski stops paying attention but remains in the room
19:02 < tmcw> we don't need luck when we have jfdi
19:02 < zere> TomH: if i could clone myself, then perhaps i'd have time to read all the OSM mailing lists ;-)
19:02 < migurski> Good Luck Just Fucking Doing The Right Thing then 
19:02 < tmcw> thx
19:02 < TomH> zere2 = zere.clone
19:03 < tmcw> okay, so UX: my plans are mostly in http://wiki.openstreetmap.org/wiki/Improving_OpenStreetMap
19:03 < tmcw> home page improvement top priorities: tabs, and then map controls.
19:03 < apmon> Does this interact with the redesign branch in any way?
19:03 < tmcw> apmon: nope
19:04 < tmcw> I'm not working on the redesign branch; if others want to, go for it.
19:05 < tmcw> So, dodging whether I think it's pretty/ugly, and just making improvements to the main branch. It seems more actionable, committable, and immediate.
19:05 < tmcw> After the cosmetic rails port stuff I want to start focusing on editing UI, where RichardF clearly has lots of ideas and code
19:06 < tmcw> The simplest, first addition here would be a bug-adding interface or more prominent placement of openstreetbugs
19:06 < TomH> oh please don't go there...
19:06  * TomH should really pull his finger out on that
19:07 < tmcw> Is there openstreetbugs baggage that I'm not aware of?
19:07 < TomH> ha ha yes
19:07 < apmon> tmcw: You are aware of http://openstreetbugs.dev.openstreetmap.org/
19:07 < zere> as far as "technical issues #1" is concerned - could we provide a dump of one of the api.dev DBs? presumably we can take and anonymize one of those easily enough?
19:07  * tmcw hasn't been here long enough to understand all historical drama
19:07 < tmcw> TomH: quick summary?
19:07  * RichardF is considering setting up an OSM instance of Encyclop�aedia Dramatica
19:07 < tmcw> Is it a 'bad thing'?
19:08 < zere> tmcw: http://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#OpenStreetBugs.2Fnotes_integration
19:08 < apmon> tmcw: Basically it has been the plan for years to integrate that. But for various reasons it hasn't happened so far
19:08 < TomH> tmcw: there is code to add bugs support to the site but it needs major surgery and I
19:08 < tmcw> Or just a crashed rails app?
19:08 < TomH> I'm halfway through stitching it back together
19:08 < RichardF> it's a terrific thing, it's just one of those proposed-for-the-last-n-years-and-still-not-ready-for-primetime things
19:08 < tmcw> Okay, so openstreetbugs doesn't really exist.
19:09 < RichardF> TomH: are your stitches published somewhere?
19:09 < TomH> I'll try and finish the backend stuff at get it up so people can hack the UI into shape
19:09 < tmcw> Gotcha, so task: evaluate finishing it, or a different approach for simple contributions of that sort.
19:09 < TomH> RichardF: it's in a kind of "in pieces" state at the moment
19:09 < TomH> as in I know how I want to put it together again
19:09  * RichardF nods
19:09 < zere> tmcw: "doesn't exist" in the same way as any unfinished branch, yes.
19:10 < RichardF> well, I'm beyond terrible at JS, but would be very interested in taking a look and fiddling when it's readier.
19:10 < tmcw> I basically write javascript all day long, so could hack on whether's necessary to get that up and going
19:10 < apmon> same here. And I guess me being terrible at JS is the reason TomH needs to do major surgery on it...
19:11 < apmon> same here refering to RicharFs comment
19:11 < TomH> apmon: well I'm trying to get rid of a lot of the horrendous JS (which is mostly from OSB rather than you I think)
19:12 < tmcw> Does anyone else have top UX tasks?
19:12 < RichardF> OOI - it seems to me that OSB/"simple contributions interface" dovetails extremely well with the "clickable POI" task.
19:12 < RichardF> But I may be being too astronautical.
19:12 < tmcw> Yes, somewhat. I have mixed views on clickable pois
19:13 < zere> well, they don't dovetail quite as nicely as you might think. 
19:13 < RichardF> tmcw: the idea that's been floated sometimes (I think Komzpa implemented this on openstreetmap.by) is that you don't actually throw POI click regions back to the user, but you run a serverside lookup on the osm2pgsql db on click
19:13 < apmon> tmcw: I just realise that  http://openstreetbugs.dev.openstreetmap.org/ currently doesn't work. Probably because it is still old code running on rails 2.3 instead of 3.2
19:13 < RichardF> (just popping out for five minutes)
19:13 < zere> but an "editable browse page" would work very nicely with clickable POIs (imho).
19:14 < tmcw> RichardF: yes, I mean, I've spent a lot of time in that area (and wrote a great deal of the spec and implementation of UTFGrid, one of the major options)
19:14 < tmcw> My issue with clickable pois isn't the implementation, I think that they're coming from a rather weird area
19:14 < tmcw> The line about the osm.org home page map has often been that it's focused on data, and not meant to be beautiful or serve the same purpose as Google Maps
19:15 < tmcw> This doesn't really mesh with spending a significant amount of time to implement a Google Mapsy feature on it
19:15 < tmcw> Like if we were recommending people use the standard OSM tiles on their websites, and were trying to make them beautiful and such, it'd make more sense
19:16 < zere> yes, clickable POIs is a technology and there are lots of conflicting / overlapping uses that are being proposed.
19:16 < tmcw> To the extent that clickable regions help editing, they do to a very limited degree; pretty much every approach doesn't send vector data to the browser immediately, so you wouldn't be able to 'edit' without a separate roundtrip and an implementation of a vector interface
19:16 < apmon> tmcw: clickable POIs is a good way to see all of the data behind things. So can be seen in the "focused on data rather than be a google maps clone" category.
19:17 < zere> apmon: except you only see a fraction of the real data and even then the data that renders well (fsvo "well"), so it's never going to be a full answer to editing.
19:17 < tmcw> apmon: yes, if we're trying to go for a data-heavy display, I think straight-up vectors are more relevant than clickable pois
19:17 < apmon> You would still need a separate editor, but at least you can easily see if you need to edit it at all in the first place
19:18 < zere> on a technology side, images + click areas makes much less of a demand on users' browsers than a full-on JS / flash editor, though.
19:19 < tmcw> zere: definitely, but that's not really the point
19:19 < apmon> Imho POIs are usually the ones with the most additional (non-redered) data, and the one newbies are most likely to know/add. So it would be a good start and cover a lot of the usecases
19:20 < apmon> But perhaps it can actually be based off of the current data browser. One can select if one wants to view only POIs or lines or polygons or all.
19:21 < tmcw> Er, okay - I think this area just needs some experimentation.
19:21 < zere> yes. let's JFDI and see what happens. talk is cheap ;-)
19:22 < tmcw> I think that a JSON-friendly API + strict POI editing is probably about 15% of the work of adding utfgrid or some sort of getfeatureinfo clone through the stack
19:22 < tmcw> So I'll probably start off with that for a first shot
19:23 < zere> cool. for reference, there's working JSON support for many existing API calls in the "experimental" branch of cgimap https://github.com/zerebubuth/openstreetmap-cgimap/tree/content-types
19:23 < TomH> just what I was going to say
19:23 < zere> TomH: yes, yes, yes... i'll merge that into master Real Soon Now
19:23 < TomH> ;-)
19:24 < zere> just after the license change stuff is done, and OWL is up on zark, and all the rest of the stuff ;-)
19:25 < apmon> zere: Is that also needed for getting ramoth up?
19:26 < apmon> i.e. the read-only part?
19:26 < zere> no... i don't know what's holding that up.
19:26 < TomH> nothin really
19:26 < TomH> except soebody making a decision about whether thew current raid config is good
19:26 < TomH> and then planning a date for downtime
19:27 < zere> ok. final agenda item is license change, but i'll make it quick: if anyone wants to help with https://github.com/zerebubuth/openstreetmap-license-change i would be very grateful.
19:28 < apmon> would it be simply switching over to ramoth as a first pass, or setting up replication across ramoth and smaug straight away?
19:28 < zere> tl;dr is that it's just a set of tests for whether the license change algorithm is working properly. needs much work, more tests, etc...
19:29 < TomH> apmon: well first job is to migrate to 9 on ramoth
19:29 < tmcw> zere: quick summary of wtf this does :)?
19:30 < tmcw> this... purges non-odbl contributions?
19:30 < zere> yes, it's an algorithm (with stubbed-out other bits) for purging / redacting non-odbl edits from the version history of an object.
19:31 < zere> the aim is to get some tests, make the code pass the tests, then extend the code to work on real data.
19:31 < tmcw> Gotcha, cool.
19:31 < zere> with a bit in between where everyone can see the tests, read the tests and (ha ha) agree on what should happen.
19:32 < zere> it's a new one on me - i'm trying to engage with several people who are legally-minded, but can't necessarily read code. will be interesting to see if the tests are too code-y and how human-readable they can be made.
19:38 < zere> looks like we've run out of steam. great to have everyone & thanks for coming!
19:38 < zere> hope to see you next week
Retrieved from "https://osmfoundation.org/w/index.php?title=Working_Group_Minutes/EWG_2012-02-27&oldid=1579"