todo: * re-order & condense notes, fill in holes * flowcharts & boxes. * develop a "functional map" sort of overlaid over a "module map" (where location/gmap stands, and where geo stands to cover in the future) Attach:drupal-gis-capabilities-by-module.2.png ----- !!presentation is weds the 5th at 3:30 pm !!![20:04] The old Location project never got properly converted to using the Forms API. This has left the current implementation with some baggage. Says Bdragon: "ankur rishi had done lots of 4.6 and 4.7 location work. This kinda tapered off, and the 5.0 release was kinda sucky, as the 4.7 release hadn't been a rewrite from the 4.6 version (4.6 was pre FormsAPI)" Location is difficult to theme because (1) it doesn't fully utilize the FormsAPI and (2) the default theme for the location fieldset involved a table. The point of location module is to keep track of addresses and sometimes geographical coordinates. Location provides the ability for people to enter postal addresses and/or geographical coordinates associated with a node or user. It contains stuff like a country / province list, zipcode databases for several countries, and an interface for country specific geocoding. bdragon is thinking about adding taxonomy/term locations under the "new" system !!![20:10] addon modules exist for phone/fax fields -- these are holdovers from pre-cck days and aren't the best solution now that cck is everywhere. !!![20:13] Bdragon's 2 to 3 transition was intended to be a bugfix run, but turned into a major FormsAPI implementation and table normalization. A lot of the code is touched by that, but there's as little of a rewrite as possible. Also changing the default fieldset theme (used to be a table). !!![20:15] Location 2 to Location 3 improvements: * easier themeing * easier extending * ability to associate locations with anything * full revision support ->previously: locations were keyed on vid but the relationship was not honored; reverted nodes would not also revert locations; locations would be suddenly dissociated. same w/ viewing revisions. ->now: old revisions will have older versions of a location; a location will keep its lid until it's edited. bdragon mentions a "diff for locations" as part of the new code... * faster Our top pri: get this in and tested. !!![20:23] !!!Maptogether Mapt will have a database of places. A place is a physical location with information about it. Our hypothetical use case here will be "searchable community-generated database of homeless shelters". To build this site, we create a CCK custom nodetype called Shelter, which contains fields for the shelter_name, shelter_phone, shelter_contact, shelter_num_beds. !!![20:30] Using Location 3 (aka Location 2 + patch). Location can "attach" to any node type -- set prefs in /admin/content/types/typename in a fieldset titled "Locative information"; when you do this, you basically only have control over how many addresses are associated with a node. This is the Location 2 way of doing it. Location 3 adds cck location fields; this means you can have multiple labeled locations associated with a node. For example, you might have a location field for "street address" and another location field for "mailing address". These location fields have address fields as defined by the Location module, the locations are stored in the Location module's db table, and they are geocoded by location (if Location is configured to geocode). Bdragon describes this behavior as acting "more like a nodereference or userreference in the backend." !!![20:37] Need bug report on the fact that fields are labled Province/Postal by default. We want users to see the correct "division" name; US users should see State/ZIP Address fieldsets for various countries are defined in per-country .inc files; each country a site plans to use needs to be enabled in the huge stack of checkboxes at /admin/settings/location. !!![20:46] Back to the use-case. Enable each desired country in /admin/settings/location, then enable locative information in /admin/content/types/type-name. After that, when you add nodes of that type there will be location fields included in the node creation form. On node creation, Location grabs the address and geocodes it by (a) accepting the user's input, (b) submitting it to a geocoding service, if one is configured for that country, (c) using the built-in approximate postal code geocoding (if enabled), or (d) leaving it blank. !!![20:51] Each country has it's own .inc file that defines address format, best services to send users to for maps, and a list of geocoders that support that country. After enabling a country, you can choose which geocoder to use. On node submission, the location data gets passed to the geocoder chosen by the admin to be the active one for that country. The geocoder returns latitude and longitude, which are stored with the address data as a "location". !!![20:55] See extending_support.txt in the Location package for an exhaustive description of the country.inc files. country.inc files specify # the provinces/states of that country # methods for getting a url to a map # a method for getting a 'rough idea' of a geocode based on postal data # methods for getting an exact geocode from a web service links to terms of service for #2 and #4 things bdragon wants to add: # local names for the different parts of a location (i.e. "State" in the US vs "Province" in Canada) (3.0) # move most of the stuff to the DB so there can be automatic updates (post 3.0) # enable the "generic" google geocoder everywhere it makes sense (post 3.0) Adding features to .inc files is extremely annoying, because it requires changing 249 (last count) files. !!![21:01] For our use case, the geocoding options are Google, Geocoder.us, or our own USTIGER geocoder server (or Yahoo). These options are in the us.inc file. Geocoding is configured in /admin/settings/location/geocoding. A private geocoder would require its own definition in the inc file. Google geocoding can be added to a country by adding a function like this to a country's .inc file (CC = country code): @@ location_map_link_CC_default_providers() { return array('google'); } @@ see also: @@ function location_geocode_us_providers() { return array( 'yahoo' => array( 'name' => 'Yahoo! Maps Web Services', 'url' => 'http://developer.yahoo.com/maps/rest/V1/geocode.html', 'tos' => 'http://developer.yahoo.com/maps/mapsTerms.html' ), ); } @@ Defining a custom/private geocoder is something only advanced users or users from places w/out public geocoding services will do, so they're just going to have to edit text files. !!![21:06] Bdragon notes that he hates the .inc files and is going to make them go away, in a Location 3 point release if possible but otherwise in 4. !!![21:08] Set up the geocoder for each country in /admin/settings/location/geocoding: this means picking a geocoder and generally entering an API key for that service. For "standardized" geocoders you only have to enter the API key once. !!![21:09] Every country you enable means loading another .inc file !!![21:15] In the past, Location has not been able to delete locations from the database; they would never show if the post that owned them was deleted, but they would still be in there. In 3.0, there is automatic garbage collection. !!![21:19] should be a retreat aim - set up unified, team-wide credential management on Herman or something !!![21:25] In Location 2, the locations are associated directly with a node; the locations table has a "type" column and an "eid" column, which would be filled in like type='node', eid=103 (an nid), or type='user', eid=6 (a uid). If it helps, this is similar to the way flexinode tied stuff together. In Location 3, the location table has only the data and an lid. Locations are connected to nodes and users via a join table called location_instance. The location_instance table has nid, vid, uid, and lid columns; for any single entry in location_instance, either the nid, vid, and lid OR the uid and lid will be filled out. Aside: In 3.x it will be possible (though not yet implemented) to have a single location associated with multiple things (nodes and/or users). This will *not* be a good idea to implement independently of Location until there is some functionality where editing a location creates a new location entry. Also note that the Location 2 storage implementation was the source of the revision bug--where locations were disassociated with nodes once a new revision was created. eid = vid, not nid. lid is always unique in the locations table, both in L2 and L3. ---- !!![21:36] Next in our use-case: # Show a ChicagoAncestors-style (paged) list of locations, listed on a map. Let's talk about the performance impact of too many mapnodes per map, and solutions (JS clustering for client-side? backend clustering of some sort?) # Maps of shelters filtered by a taxonomy; in our case, a taxonomy for shelters called "Type" with Men only, Women only, Co-ed, Family; there would be a link or tabs for each term. !!![21:39] The Geobrowser module, by Patrick Hayes (http://drupal.org/project/geobrowser) can render map layers; it's a UI-side thing rather than sets of seperate queries/maps/whatevs. see http://www.localfooddirectory.ca/foodshed/geobrowser/ for an example. Also, CA is 'basically a REALLY hacked up location+views+gmap". !!![21:45] Geobrowser treats the map as the 'main event'; Drupal just manages the content inside the map. How does viewing nodes and mapping fit together with location? * Location provides some hooks for views to allow filtering by proximity/postal code/whatever. * Gmap provides a views display plugin to show the results as a map. With no Gmap, they get returned as a list or table, like a normal view. * In the future, Geo will be the one providing "better faster cheaper" versions of these filters; that will probably happen around the same time as Views 2. !!!Views filters: *SQL LIKE: Filter by ->*location name ->*street ->*additional ("street line 2" basically) ->*city *Direct selection: Filter by ->*Province ->*country *Direct entry: Filter by ->*postal code ->*proximity to latitude / longitude (special somewhat working mini locpick thingie available) -- This is VERY hacky and shaky under views 1 ->*distance from postal code There are versions of each of these for both nodes and users. !!![22:00] UI mockups; shady and bec are supposed to come up with something here. # Search (with filter and sort) places and sets based on metadata # Search (with filter and sort) places and sets based on GIS ->* proximity (show X within Radius Y) # Show All Shelters of Type ---- Family/etc # Show All Shelters close to $INPUT_ADDRESS in order of proximity !!! Ways to implement search: # a generic "search results + map" - the Views way # hook a map into the "normal" drupal search system (just numeric markers or something) -- the search.module way As part of the search, we would want to be able to display a list of results *and* a map of results on the same page, either next to eachother or above/below eachother OR put the results in a legend on the map, OR only show result details when a map marker is clicked. There's already a "map" display plugin for Views as part of Gmap. A "list PLUS map" display plugin would make this happen. !!![22:18] geo.module is a geometry tool; it doesn't deal with things like addresses or zip codes, just spatial data. * stores geospatial data. For optimization purposes, geo does this in database-specific ways, and takes advantage of PostGIS or Mysql Spatial when available. * allow querying and complex spatial computations on the data, in a fast way. Geo becomes more useful with a large dataset; gmap.module is for displaying spatial data on maps. It deals mostly with points right now, though as geo.module progresses, geo should be able to feed line and polygon data to gmap. * can get latitude/longitude data from location.module * can get other spatial data from geo.module * defines a display pluginx for Views * provides some default pages containing maps of nodes and users * defines a macro language and provides an interface for building macros (looks like [gmap|stuff]) so that users can put maps in their content. * deals with some map-based input, but if you want to work with more complex geospatial data, you would want to use Openlayers. (Since we'll just be dealing with point data from a geocoder, we don't need Openlayers at this point.) location.module deals with associating point locations with drupal nodes and users (and perhaps in the future other things, like taxonomy terms). * deals with address formats for different countries ->* provides an appropriate address entry form ->* stores ->* formats ->* geocodes * contains lists of countries and their states/provinces and postal codes * provides links to maps on external services * contains basic geographic search algorithms * contains basic postal-code based geocoding Some location.module gotchas: * postal code features are generally not used, because loading the codes into your db is a hassle * geographic algorithms suck, but are backwards compatible to mysql3 something. openlayers is a little desktop GIS application in your web browser, "rolled into a tight little javascript package". "the cartographer's choice". For examples, see http://openlayers.org/dev/doc/examples.html * can map some layers from places like NASA, Yahoo, and WFS layers * provides a nice interface to edit maps over WFS-T * can speak every(?) mapping protocol openlayers gotchas: * default theme is fairly ugly, which is why most people use gmap for user-facing things. * no openlayers module exists yet. Bdragon has a functional tech demo of passing WKT data back and forth, but it's not hooked into anything useful at the moment. hook_elements() and '#type' => 'editable-map'... Openlayers is mostly outside the scope of maptogether at the moment. Openlayers will be within the scope of MapTogether eventually because it will # make our mapping applications more professional # provide real UI-side GIS capabilities # allow us to charge for a hosted service without a $10,000 Google Maps for Enterprise annual service key # help establish us as a GIS4OSS powerhouse !!![22:39] Two big things on our internal roadmap: #"the turnkey solution" -- lets users integrate Location, Geo, Gmap, and do simple "add Place", "view Place", and "view Place Views (search results, tag filters, etc) ->* aka "Mapedelic" ->* will likely start out being just location and gmap # a Gmap alternative using all FLOSS and free-data tools !!![22:41] Location currently contains a superset of the "bullet point features" of geo; the geo implementations are much better. The Future is geo, but the Present is location. However, the migration between the two should be easy and non-lossy. Currently, most of location is half assed attempts at spatial operators; the optimal solution is to move everything except address handling from location. Geo deals with spatial data rather than addresses, in the future all of locations geospatial storage and manipulation work will be done by geo. Sidenote: in this proposed future, it would be more accurate to rename location to something like "places.module". We can do a simple version of MapTogether using location with its current handling of address and spatial data; at the same time, we should be working on making geo shine. When geo is ready, we will write migration code and make the next version of location depend on geo. Brandon is co-maintainer of Geo with Mark ---, though geo is basically inactive ATM; (sidenote: Mark is no longer with Advantage Labs--was he doing this geo work for them? Brandon asserts that he's still available etc.) Since there is currently not even a dev release of geo, noone is really aware of it/playing with it/extending support. As geo becomes available, location and gmap will need to start calling geo APIs; Location can already use gmap's APIs, and gmap can use location's data. !!![23:00] -- Wrapup bec: * take the lead on documenting this conversation, overall GIS on Drupal architechture * create flowcharts/boxes/something to make it easier to see at a glance how all this stuff fits together. can get nick to pretty them up later. * develop a "functional map" and a "module map"... which functionality is part of which modules, in the present and the future; basically, where location/gmap stands, and where geo stands to cover in the future. bec + shady: turn this into a suitable 30 minute presentation (+ 10 mins overhead, 20 mins q&a) brandon: be available to bec for q&a ---- !!!EOF