Brandonian’s picture

Issue tags:+Novice, +mapping

Tagging for mapping sprint. Can't believe I forgot about this one!

ekes’s picture

Some notes:-

* Could also add (and displayed as RDFa or even allow RDF export).
* Lon/Lat requires markup within the output, so it's going to have to be in #markup
* Other rdf / looks like it could be defined using RDF module (for example see that allows adding schemaorg to fields). This mainly seems to be done at entity level though.
* For an itemprop should be in an itemscope. In this case 'place'. But we're working at the field level, not the entity level. The entity may have other place information.

So adding #markup in immediate term looks quickest. Need more info about how to expose this information to Drupal / Themer.

ekes’s picture

Update (end of sprint for now):-

So rdf (core module) and schemaorg (contrib module, using rdf core) don't support field level suggestions for metadata. Microdata (contrib module) does. This also enables the user to put the correct itemscope, and select the itemprop (like is it GeoCoordinates or GeoShape - I'm still working if it can be set automatically for certain formatters).

Unlike hardcoding into #markup this integrates with the entity and it lets the user change them. So 'the right way' TM.

I've done the suggestions in the microdata module. These can be made available in the formatter. What is needed is (preferably theme functions) from the formatter_view. At the moment the #markup is generated without theme().

Patch will follow, at some point, with or without these theme functions.

ekes’s picture

new9.18 KB

Basic working patch for adding with microdata attached.

The patch adds suggestions for using GeoCoordinates or GeoShape. The former works fully, although the implementation method is in development (see paragraph below). The lat lon properties are added directly iff that schema has been selected, the rest of the required markup is added with the microdata module. The later has a comment about implementation.

The immediate question is:- The properties (itemprop) options, and suggestions, for the (field) properties don't make so much sense. See code comments in: geofield_microdata_suggestions(), geofield_data_property_info() and _geofield_item_microdata_propertyvalue(). Does it make sense to expose, and make suggestions, these field properties via microdata module at all?

linclark’s picture

Status:Active» Needs review
new10.48 KB

Thanks for the great start, ekes. In the attached patch, I addressed the shape issue.

The shape format

First off, we need to get the value in the format that consumers expect. The documentation at gives descriptions of how the values should be formatted, but they aren't precise enough. The coordinator said he would get back to me about whether or not there is a standard that it should follow.

In the meantime, I've called the format 'schemaorg_shape' and have a function that creates that string based on the geo_type. This format is also available to other tools (like Views and Rules) via the Entity Property API since it has been added to property info.

This formatting still needs to be finalized once the coordinator gets back to me. Right now it only handles polygons using what I expect to be the correct formatting.


I changed the exposed properties to only include the following (changing wkt and latlon to FALSE):

  • latitude
  • longitude
  • shape (new property)

These were the only properties that had direct correlates in

Microdata suggested mappings

I split the suggestion into two:

  1. line
  2. polygon

These seem to be the only really applicable GeoShape mappings, since there isn't a way to denote a circle or elevation in Geofield.

Microdata placement

I made the microdata placement code in _geofield_item_microdata_propertyvalue more generic, so that it doesn't place terms directly. Instead, it checks what the geo_type is. If it is a point, it will just place the user-defined microdata attributes for the 'lat' and 'lon' properties. Otherwise, it will get the schemaorg_shape format and place that with the user-defined microdata attributes.

  if ($item['geo_type'] == 'point') {
    foreach (array('lat', 'lon') as $property) {
      $microdata[$property]['#attributes']['content'] = $item[$property];
      $output .= '<meta' . drupal_attributes($microdata[$property]['#attributes']) .' />';
  else {
    $schemaorg_shape = geofield_schemaorg_shape($item);
    $microdata['schemaorg_shape']['#attributes']['content'] = $schemaorg_shape;
    $output .= '<meta' . drupal_attributes($microdata['schemaorg_shape']['#attributes']) .' />';

This also has the advantage of placing the content value in the attributes array, which then gets pushed through drupal_attributes, sanitizing the user input.

+++ b/geofield.formatters.incundefined
@@ -252,7 +252,11 @@ function geofield_field_formatter_view($entity_type, $entity, $field, $instance,
+        // @todo are there instances (views?) where WKT #markup rather than
+        // $item['wkt'] are used as a WKT string. Adding any other text to the
+        // string would break these.
+        $microdata = _geofield_item_microdata_propertyvalue($entity, $field, $item);

I removed this comment. Since '#markup' is expected to have HTML values, I believe it would be incorrect for other systems to assume a plaintext value. The meta tag used to place the microdata is invisible, so it won't have any visual impact.

colette’s picture

new10.69 KB

I added microdata placement for WKT linestrings, by considering the convex hull of the points in the line, then getting the 4 points with the minimum/maximum coordinate values. The microdata will show these 4 points.

case 'linestring':
      $output  = $bottom . ',' . $left . ' ';
      $output .= $bottom . ',' . $right . ' ';
      $output .= $top . ',' . $right . ' ';
      $output .= $top . ',' . $left;
Brandonian’s picture

Status:Needs review» Needs work
Issue tags:+Needs Documentation

Looks good. I've committed the patches in #5 and #6, but I'd like some help with documentation, since I'm not super-familiar with the microdata module. @linclark, @colette, would either of you be willing to help with updating ?

linclark’s picture

Thanks for commiting. I added some documentation, let me know if it leaves you with any questions still and I will try to answer them.

Brandonian’s picture

Status:Needs work» Fixed

Works for me. Marking as complete. Thanks @linclark et al!

Automatically closed -- issue fixed for 2 weeks with no activity.