1. Notes + log
    1. https://docs.google.com/document/d/19F8XCwyxQc4JwouNxDDspiDCjPAWFsVb--xxOyedpmw/edit?pli=1
  2. Documentation
    1. Documentation sprint planning
    2. Brandonian proposes geo documentation sprint
    3. jeffschuler proposes updating Drupal Geo Stack page http://groups.drupal.org/node/138884
    4. Kartagis links blog post on mapping documentation
    5. http://www.interworks.com/blogs/mmueggenborg/2012/01/03/setting-drupal-7-locations-map
    6. log
      1. [1:02pm] Brandonian: So, next up is documentation sprint planning. Our documenation sucks, and we should clean it up.
      2. [1:02pm] jeffschuler: Brandonian: geo docs as a whole?
      3. [1:03pm] Brandonian: jeffschuler: yes, but especially geofield. Openlayers is semi-outdated
      4. [1:09pm] kricklin: If there is (or is to be) a list of doc topics, I'd be able to at least review and pick out a topic(s) that I feel comfortable documenting - virtually.
      5. [1:10pm] Brandonian: kricklin has a good point with docs, maybe it's worth doing some stub documentation and let others fill in the details?
      6. [1:11pm] Brandonian: we do have some of that for geofield, less so with geocoder
      7. [1:11pm] Brandonian: Correct me if I'm wrong, but openlayers documentation is fairly complete, but may be out of date?
      8. [1:12pm] phayes: zzolo ^ ?
      9. [1:13pm] betoscopio: last time i checked seems mostly focused on Drupal 6
      10. [1:13pm] jeffschuler: we could really use more/better top-level docs for the current Drupal geo "stack", itself.
      11. [1:14pm] dasjo: recently jeffschuler pointed me to the ol_locator feature module which seems to be a nice wrap to the different geo modules http://drupal.org/project/ol_locator
      12. [1:14pm] jeffschuler: Brandonian, your presentations (and that podcast), and zzolo & tom_o_t's book have been getting at that.
      13. [1:14pm] Brandonian: Going through openlayers docs now (http://drupal.org/node/595850). At the very least, it could use a reorganization at the very least.
      14. [1:14pm] Brandonian: jeffschuler++
      15. [1:14pm] jeffschuler: it'd be useful to have docs outside of Geofield or any individual modue
      16. [1:14pm] jeffschuler: dasjo: I was just going to bring that up, http://drupal.org/project/ol_locator
      17. [1:15pm] zzolo: Brandonian: there is a lot of docs, but yes they are out of date. and overall need some love on organizing things. also we are missing a lot of API style docs
      18. [1:15pm] kricklin: Suggest adding a "tips and tricks" section - couldn't find one the other day.
      19. [1:16pm] Brandonian: So, anybody in the room want to take the initiative to rally an overall geo docs update?
      20. [1:16pm] Brandonian: <~ Imagine the cheesiest grin possible, then multiply by 10
      21. [1:17pm] Brandonian: Ideally, I think that the docs person should be someone who isn't maintaining one of geo modules
      22. [1:18pm] jeffschuler: Brandonian++
      23. [1:18pm] zzolo: Brandonian: I can commit to going through the OL docs next Sunday and frame it as a docs sprints for geo
      24. [1:18pm] zzolo: but i can't commit to the overall task of geo docs
      25. [1:18pm] Brandonian: zzolo: Cool, that's a start
      26. [1:18pm] zzolo: (i am flailing as the OL maintainer already)
      27. [1:19pm] Brandonian: zzolo: That's why I'd like the docs person to not be a current maintainer. We're all hurting a bit, and it'd be a nice place to get some fresh blood in the mix
      28. [1:19pm] dasjo: Brandonian i don't really plan to do an overall geo docs update, but as part of my "server-side geo clustering with drupal 7" initiative i think it would tackle most of the modules involved and therefore touch the different implementations
      29. [1:20pm] zzolo: Brandonian: maybe what our take away is that we need to find that person. I am not sure if that person is in the room.
      30. [1:20pm] dasjo: ideally i could think of bridging an end-user oriented documenter with module-maintainers
      31. [1:20pm] Brandonian: dasjo: Cool beans! Have you met jeffschuler yet? He's maintaining views_geojson, and probably a good contact to have
      32. [1:20pm] Brandonian: zzolo: I think you're right
      33. [1:20pm] jeffschuler: I would be willing to take on updating the "Geo Stack" doc on g.d.o./mapping : http://groups.drupal.org/node/138884
      34. [1:21pm] dasjo: Brandionian: we haven't met but i have had some first contact with jeffschuler in the issue queue
      35. [1:21pm] Brandonian: jeffschuler: awesome, thanks!
      36. [1:21pm] jeffschuler: is there another place to meet people?
      37. [1:21pm] dasjo: that would be great jeffschuler, your slides might very well fit into that page!
      38. [1:21pm] jeffschuler: (Brandonian's slides…)
      39. [1:22pm] Brandonian: So, action item, hunt down person/people to help us document what we're doing
      40. [1:22pm] jeffschuler: & phayes's slides
      41. [1:23pm] Brandonian: cool, does anybody else have anything to say about documentation before we move on to zzolo's presentation?
      42. [1:24pm] zzolo: Brandonian: I think we might want to find a point person for drupal geospatial things. basically a Geo Lead. this way there is a single person to bring questions to (that will then delegate them out)
      43. [1:24pm] zzolo: Brandonian: I would think you're the one
      44. [1:24pm] Kartagis: regarding docs
      45. [1:24pm] Brandonian: zzolo: I can work with that
      46. [1:25pm] Kartagis: docs could be clearer
      47. [1:25pm] Kartagis: I found an off-d.o tut to do what I wanted to do
      48. [1:25pm] Kartagis: I couldn't find a d.o. one
      49. [1:25pm] jeffschuler: I just put a shout-out in #drupal-docs
      50. [1:25pm] zzolo: Brandonian: we might want to set a time limit sort of thing, like a year or 6 months so that there is not burnout and its is more digestible. this is kind of like the D8 initiatives
      51. [1:26pm] Kartagis: http://www.interworks.com/blogs/mmueggenborg/2012/01/03/setting-drupal-7-locations-map
      52. [1:29pm] dasjo: also note, that for the long-term, linclark is working on linking back external documentation pages to drupal.org
  3. Events
    1. [1:02pm] Brandonian: Anybody know of any camps coming up that are holding sprints as well?
    2. [1:03pm] dasjo: i have proposed a mapping sprint for dev days in barcelona
    3. [1:03pm] dasjo: and there is a mapping session in barcelona as well, but so far i haven't found people contacting me in that matter
    4. [1:04pm] Brandonian: when will they announce, rather
    5. [1:04pm] dasjo: i will check
    6. [1:05pm] jeffschuler: zzolo: you're speaking at the Twin Cities camp, right?
    7. [1:05pm] dasjo: anyone planning to go to dev days barcelona here?
    8. [1:05pm] Brandonian: cool. Anybody else know of a camp that's happening in the next couple of months? Twin Cities is an option
    9. [1:05pm] Brandonian: dasjo: I won't be able to go, but if the sprint gets accepted, I'd like to participate virtually
    10. [1:06pm] phayes: I'm going to go to PNW Drupal Summit - but that's not until the fall
    11. [1:06pm] zzolo: jeffschuler: yep
    12. [1:06pm] jeffschuler: supposed to be in Pittsburgh but I would try to make it to twin cities if a geo sprint happened…
    13. [1:06pm] Brandonian: http://buildamodule.com/drupal-camps-calendar
    14. [1:06pm] dasjo: ok Brandonian great, nod_ was saying maybe he could come but not sure yet
    15. [1:06pm] zzolo: jeffschuler: Brandonian I thinking about doing a geo sprint on that Sunday, but not sure yet
    16. [1:07pm] zzolo: hopefully I will be at PNW Summit as well, but don't know yet
    17. [1:07pm] Brandonian: Anybody in the room from Utah or North Carolina?
    18. [1:07pm] eggonbeagle: great calendar..thanks brandonian
    19. [1:07pm] kricklin: Virginia
    20. [1:08pm] Brandonian: kricklin: cool, do you happen to have any contacts with the organizers at the Charlotte camp?
    21. [1:09pm] Brandonian: Actually, I know the organizer… *embarassed* should have clicked the link
    22. [1:09pm] kricklin: brandonian: No I don't
  4. Zzolo's presentation
    1. [1:30pm] Brandonian: Cool. In the interest of time, zzolo's presentation?
    2. [1:31pm] zzolo: So, I am working on a presentation to give an overview of "GeoDrupal". This includes history, current efforts, and the future. So, mostly I just want to make sure I have a good overview of what people are working on
    3. [1:32pm] dasjo: session link is http://2012.tcdrupal.org/sessions/spatially-drupal-state-drupal-geocms
    4. [1:32pm] zzolo: dasjo: thanks
    5. [1:32pm] zzolo: I think this will also be good to just hear as a group what people are working on, as some of the most difficult things in the geospatial realm of Drupal has been disparate efforts
    6. [1:32pm] dasjo: zzolo i'm wondering about the "lots of efforts" link on the session page...
    7. [1:33pm] Brandonian: where is the link supposed to go? It's currently pointing to the home page of the camp
    8. [1:34pm] jeffschuler: zzolo: how can we help?
    9. [1:34pm] zzolo: oh weird, it should be this: http://groups.drupal.org/node/89769
    10. [1:35pm] Druplicon: http://groups.drupal.org/node/89769 => Geospatial Modules Assessment => 0 comments, 13 IRC mentions
    11. [1:37pm] dasjo: zzolo: do you already have a draft presentation, your most recent mapping presentation that you might plan your presentation to build upon?
    12. [1:38pm] zzolo: dasjo: no, not yet. will start from scrath
    13. [1:40pm] zzolo: also, jeffschuler or dasjo or Brandonian or phayes or whoever, are you working on things at your job that are related that may not be released but worth mentining
    14. [1:40pm] zzolo: maybe, i am asking too general of a question with this. i just know how difficult it is to really know what is being worked on in this space as lots of people do their own thing sometimes.
    15. [1:40pm] jeffschuler: zzolo: IOW, maybe we could use a "Drupal Geo examples" alongside the Use Cases page http://groups.drupal.org/node/22370
    16. [1:41pm] Brandonian: zzolo: We have some basic geo stuff going on with the DoE site (energy.gov)
    17. [1:42pm] Brandonian: zzolo: Also, I'm wanting to get the distance filtering views thing worked out sooner than later with geofield
    18. [1:42pm] zzolo: Brandonian: are you guys doing anything with hooking up Drupal data to tiles (like in TileMill)?
    19. [1:43pm] Brandonian: zzolo: No, but I've played around with it a little bit. At Denver, DS showed off how to use views_geojson to feed data into tilemill
    20. [1:43pm] zzolo: Brandonian: but not in a "live" way
    21. [1:43pm] Brandonian: and I've done some playing around locally to tweak on that
    22. [1:44pm] Brandonian: zzolo: Sort of. They suggested using a server instance of tilemill and updating automatically on a regular basis.
    23. [1:44pm] jeffschuler: zzolo: I think the "live" way is still something that Tilemill doesn't do, (or at least not well,) yet
  5. Cartaro
    1. [1:37pm] Brandonian: Somebody was asking in IRC earlier today about Cartaro, which is basically the geofield stack, but with a postgis module instead of geofield
    2. [1:37pm] zzolo: so, for instance, i know phayes 's postgis_sync module is being taken up by some folks and wondering what is going on there
    3. [1:37pm] zzolo: yeah, also whtas the deal with Cartaro
    4. [1:38pm] jeffschuler: http://cartaro.org/ http://drupal.org/project/cartaro
    5. [1:38pm] friedjoff: Brandonian: right, that's us at geops.de working on cartaro
    6. [1:38pm] friedjoff: actually there is also geoserver in the mix
    7. [1:38pm] Brandonian: friedjoff: Cool, we should talk later about merging.
    8. [1:39pm] zzolo: see, i had no idea that Cartaro really existed until recently, and don't really know the people working on that and what is the direction there
    9. [1:39pm] friedjoff: Brandonian: yeah
    10. [1:39pm] zzolo: friedjoff: good to meet you and Cartaro looks pretty cool
    11. [1:39pm] friedjoff: zzolo: thanks, i would be really interested what other people think about that direction
    12. [1:43pm] zzolo: friedjoff: is Cartaro producing tiles directly from Drupal data
    13. [1:44pm] friedjoff: zzolo: yes, geoserver reads from the postgis database where drupal has it's data
  6. Leaflet
    1. [1:44pm] dasjo: glad to see levelos … looking forward to more leaflet development
    2. [1:44pm] levelos: thanks dasjo ... we're a little underwater with a few CRM projects, which we'll be wrapping up soon and refocusing on mapping
    3. [1:45pm] zzolo: levelos: maybe you can talk a bit about the Leaflet module and anything going on there
    4. [1:45pm] levelos: sure ... but, unfortunately, not too much to report.
    5. [1:45pm] levelos: the module working well in production on a handful or larger sites, namely theintertwine.org/explore
    6. [1:46pm] levelos: I know there are a few patches in the queue that look great, in particular one for Views integration. We're hoping to release a 1.0 version, with Views integration, in June
    7. [1:46pm] zzolo: levelos: nice
  7. Sync / Live
    1. [1:44pm] zzolo: phayes: have you looked at Affinity Bridges work on your module: https://drupal.org/project/sync_postgis Is that pretty stable?
    2. [1:44pm] Brandonian: It's a bit of a technical challenge
    3. [1:44pm] Brandonian: Honestly, I think solutions like cartodb.com are better for live tile stuff.
    4. [1:45pm] phayes: zzolo - yeah, the SyncPostGIS is look pretty stable now
    5. [1:45pm] phayes: They've put a lot of good work into it
    6. [1:55pm] phayes: arianek, makckh: Good work on SyncPostGIS. I added a graphic to the project page: http://drupal.org/project/sync_postgis
  8. Gaps
    1. [1:47pm] zzolo: ok, so maybe the next question I have is: What do you all think is the biggest gap in the "GeoDrupal" stack?
    2. [1:47pm] levelos: spatial querying!!!
    3. [1:48pm] Brandonian: yeah, spatial querying is a definite need
    4. [1:48pm] levelos: E.g., we need to add fairly simple proximity querying based on a users location ... other than doing the math with a SQL query, need to rely on an external GIS db
    5. [1:48pm] zzolo: i think mapping has a big gap now. OL is not maintained and is not that great of a solution. Leaflet is great but the module is not very full featured. Gmap is pretty wayside. and I don't know of anything else that is integrated with Drupal yet
    6. [1:49pm] zzolo: (OL is not very maintained)
    7. [1:49pm] Brandonian: We have a few issues in the geofield queue that should help with spatial querying (native storage, sql-query--based distance search)
    8. [1:49pm] jeffschuler: spatial querying for more advanced GIS folks, and ease of use (for the "stack" as a whole) for novice users wanting to add substantive mapping capabilities to their site… knowing which modules to use and how to fit them together
    9. [1:49pm] dasjo: would be great to see some support for leaflet as we have for openlayers in drupal yet
    10. [1:49pm] levelos: I think one of the challenges is a lack of sugar daddy clients/firms really pushing the Drupal geo space
    11. [1:50pm] Brandonian: levelos: lol and levelos++
    12. [1:50pm] jeffschuler: levelos: agreed
    13. [1:50pm] dasjo: true
    14. [1:50pm] zzolo: levelos: definitely need more sugar daddys
    15. [1:50pm] jeffschuler: or sugar mamas
    16. [1:50pm] zzolo: overall, just more sugar
  9. Mapping
    1. [1:50pm] Brandonian: Re mapping: I'd really like to see some movement on drupal.org/project/mapping
    2. [1:50pm] Brandonian: i.e., abstract all the cool stuff about the openlayers module
    3. [1:51pm] zzolo: Brandonian: yeah, i haven't touched that in a while. but i think its overall still a good drection
    4. [1:51pm] friedjoff: Brandonian: ++
    5. [1:51pm] Brandonian: and probably put together a better ui
    6. [1:51pm] nod_: I know a few big french companies using drupal mapping but they are pretty clueless
    7. [1:51pm] jeffschuler: agreed on Mapping, but that one seems like a sugar daddy sized undertaking
    8. [1:52pm] Brandonian: It'll probably take a pretty decent initial push
    9. [1:52pm] levelos: a few of us are friendly with the MapBox team, who have some big time clients these days and are pushing mapbox/drupal integration. maybe they'd want to sponsor/support more abstract mapping framework in Drupal
    10. [1:52pm] Brandonian: It might be worth trying to organize a sprint for it
    11. [1:52pm] Brandonian: levelos: I think they've left drupal behind in a big way, but it doesn't hurt to ask
  10. Server-side-clustering
    1. [1:52pm] zzolo: there is still a pretty big hole when trying to map (and handle) lots of geospatial features in Drupal
    2. [1:53pm] phayes: zzolo - I think the answer there is a combination of ViewsGeoJSON / server-side clustering
    3. [1:58pm] dasjo: final question before i have to leave: do we need a server-side clustering like nod_ and me discussed? http://drupal.org/node/1547610
    4. [1:59pm] nod_: dasjo: phayes seems to agree, see backscroll
    5. [1:59pm] Brandonian: dasjo: Definitlely think it'd be a cool feature, not sure what other work is being done with that in php/drupal land though
    6. [2:00pm] zzolo: dasjo: my initial thought is no, if we can focus on toolking up thinks like postgis and tilestache. but since that is not really going to happen overnight, a good stop gap solon could be server side clustering
    7. [2:00pm] phayes: dasjo: Yes we need it! That's going to be critical as we scale to support larger data sets
    8. [2:00pm] dasjo: yep Brandonian zzolo. basically some parts of the database implementation and client-side handling should be pluggable
    9. [2:01pm] dasjo: but maybe we can come with some basic out-of-the-box implementations and leave it open to a database to optimize the clustering
  11. tilestash sync_postgis + leaflet
    1. log
      1. [1:57pm] mackh: thanks! we're building systems to do consultaiton tracking and traditional use data collection for first nations communities in the north who are trying to deal with the oil industry. The postgis sync stuff was to make it easy to do buffer and intersection queries
      2. [1:57pm] zzolo: oh, that sounds cool, is it public, mackh ?
      3. [1:57pm] mackh: we're also (tom is) building a bunch of stuff on tilestacsh to do tile compositing, and getting wax integration workinf
      4. [1:57pm] mackh: the site is not public
      5. [1:57pm] mackh: but we're releasing all the derivative modules
      6. [1:58pm] Brandonian: sa-weet.
      7. [1:58pm] zzolo: mackh: and tnightingale thats what i am talking bout. this is with drupal data and tilestach?
      8. [1:59pm] mackh: the tilestash stuff looks like https://img.skitch.com/20120426-jfu9fj5c17y5rfa9392y48xmb7.jpg - the features (non-marker) are layers
      9. [1:59pm] tnightingale: yeah - tilestache is (using mapnik) is able to generate tiles on demand from a postgis backend
      10. [1:59pm] mackh: of data from the oil and gas commksion - like pipeline right-of-ways, access roads, wellsites, watercrossings
      11. [2:00pm] tnightingale: zzolo: so we can sync drupal data into postgis and render that data into tiles using mapnik+tilestache
      12. [2:00pm] zzolo: tnightingale: and mackh just to confirm, the postgi data is drupal data? (from sync_postgis, i assume)
      13. [2:00pm] zzolo: sweet
      14. [2:00pm] mackh: yes and no?
      15. [2:00pm] tnightingale: yep
      16. [2:01pm] mackh: stored in drupal, synced to postgis
      17. [2:01pm] tnightingale: but doesn't have to be
      18. [2:01pm] zzolo: awesome. thats what i was hoping. this is the stack i have been envisioning, but i don't get paid to do any of this stuff so i don't have time.
      19. [2:02pm] Brandonian: for the more python/mapnik literate in the room: How feasible is it to do mapnik renders based directly off drupal field data if the database is Postgres/postgis and stored properly?
      20. [2:02pm] tnightingale: Brandonian: that's essentially what we're doing with sync_postgis & tilestache
      21. [2:03pm] zzolo: Brandonian: what i image is getting your design in tile mill, export out the mapnik xml file, then it should be pretty easy
      22. [2:03pm] tnightingale: using a mapnik xml file produced in tilemill as our style guide
      23. [2:06pm] tnightingale: zzolo: we also have a rough cut at a tilestache config management module on g.h
      24. [2:06pm] phayes: ooo! link tnightingale?
      25. [2:07pm] phayes: Oh tnightingale, what's the status of D7 Spatial-tools?
      26. [2:07pm] zzolo: tnightingale: you have a link. i am actually gonna try to get this stack running locally this week as part of my presentation at the TC Drupal camp
      27. [2:07pm] mackh: https://github.com/affinitybridge/drupal-tilestache]
      28. [2:07pm] zzolo: i think this is definitely the future of geo
      29. [2:07pm] tnightingale: re: tilestache module - still pretty rough, be warned
      30. [2:08pm] zzolo: and i think postgis sync is the way to go to handle goespatial data and spatial querying.
    2. https://github.com/affinitybridge/drupal-tilestache
    3. https://img.skitch.com/20120426-jfu9fj5c17y5rfa9392y48xmb7.jpg
  12. Office hours finishing
    1. [1:18pm] Kartagis: when is it q&a time?
    2. [2:07pm] tom_o_t: Brandonian: perhaps schedule dedicated Q&A time for stuff general questions that aren't related to module development?
    3. [2:08pm] Brandonian: tom_o_t: Not a bad idea.
    4. [2:09pm] jeffschuler: tom_o_t++ … this has been super useful, but It's been more of a facilitated discussion on high-level geo in drupal topics rather than a time for folks to come get help or figure out how they can pitch in… different from core office hours http://drupal.org/node/1242856
  13. More
    1. search api
      1. [2:08pm] mackh: i also want to extend search api to return WKT onto maps
      2. [2:08pm] mackh: from faceted results, hoping to get that client funded in the next 3 months
    2. Schema
      1. [1:54pm] levelos: zzolo: I spoke with Moshe W a while back, and he said there's nothing stopping extending core schema api to support spatial field types ... so we could target solutions for PostGIS specifically while still using core Drupal APIs
      2. [1:55pm] zzolo: levelos: that would be sweet.