Here's what's necessary to set up polyline style plugin:

  1. Implement back-end logic as a mapstraction_polyline_style_map class, that inherits from mapstraction_style_map and reuses the most of it's functionality. Applying patch #808098: Allow grouping in mapstraction style plugin is neccessary. (see the file attached)
  2. Implement front-end logic. I took the risk to alter the original mapstraction.drupal.js file, meanwhile refactoring it a bit and adding a necessary processing for a polylines. (This new version is attached as wel)
  3. Register newly created style plugin as follows inside a hook_views_plugins():
    $path = drupal_get_path('module', 'mapstraction');
  return array(
    'module' => 'mapstraction',
    'style' => array(
      'mapstraction_polyline' => array(
        'title' => 'Mapstraction polyline',
        'help' => 'Displays nodes and polylines as a Maptraction map.',
        'handler' => 'mapstraction_polyline_style_map',
        'theme' => 'mapstraction_map',
        'theme file' => 'mapstraction.module',
        'theme path' => $path,
        'uses fields' => TRUE,
        'uses grouping' => TRUE,
        'uses options' => TRUE,
        'type' => 'normal',
        'parent' => 'mapstraction'
      ),
    ),
  );
CommentFileSizeAuthor
#11 20100607-drupal-mapstraction-setGroupName.patch1.01 KBesteewhy
#4 20100528-drupal-mapstraction-cumulative-808134-3.patch13.78 KBesteewhy
#1 20100526-drupal-mapstraction-cumulative.patch14.77 KBesteewhy
#1 20100526-mapstraction-808134.zip9.69 KBesteewhy
20100524-drupal-mapstraction-implement_polyline.zip2.33 KBesteewhy

Comments

esteewhy’s picture

esteewhy commented
Title: Implement polyline rendering » Implement polyline rendering, row plugin, libraries.module support and other improvements
StatusFileSize
new 20100526-mapstraction-808134.zip9.69 KB
new 20100526-drupal-mapstraction-cumulative.patch14.77 KB

Because my activities in Mapstraction support grew beyond simple patches I've decided to re-roll all of my changes and fixes into single set.

Here's what included:

New functionality

  • Enabled grouping in a style plugin
  • Support polyline rendering of point groups
  • Allow selectively displaying of map overlays by type: markers and/or polylines
  • Enabled row plugin to be used as a bubble content for markers. Insipred by gmap.module
  • Implemented libraries.module support to keep Mapstraction sources out of module directory

Fixes

  • OpenLayers breaks when map type was set
  • Allow programmatic view rendering
  • Updated options form defaults format to Views2
  • Removed dead code
esteewhy’s picture

esteewhy commented
Status: Active » Needs review
levelos’s picture

levelos commented

Thanks @esteewhy, looking forward to checking out and implementing your changes. Can you re-roll your patch against 6.x-2-x-dev? There were some changes (yesterday) since you created the patch and I'm unable to apply it cleanly. It would also help to use the mapstraction module directory as the index root rather than contributions (my contrib dev environment is different, as our others :). Thanks.

esteewhy’s picture

esteewhy commented
StatusFileSize
new 20100528-drupal-mapstraction-cumulative-808134-3.patch13.78 KB

Privet Lev.

Thanks for noticing - fixed my patch as per your remarks.

(Hope to contribute some more improvements over next week:-)

levelos’s picture

levelos commented
Status: Needs review » Needs work

This is great stuff, nice work! I'll be happy to include once we get it polished up. Some things I found in initial testing.
* The map no longer respects the selected field to use as the info bubble text. It's always showing ALL the fields included in the view.
* The grouping change does not seem to be working. What's the intended functionality? In my testing, I associated a taxonomy term with the point nodes, added that as a field to the view, and selected that field as my grouping field.
* I don't think calling the polylines an overlay is quite right. Really, this is determining whether we want to render the map as points or as a line. In my thinking/experience, an overlay is an additional map layer. But I could be convinced otherwise. Either way, just a messaging question.
* Inconsistent code formatting; sorry, but this is problematic, especially when comparing versions. Biggest issue I noticed was indentation problems.

levelos’s picture

levelos commented

Quick follow up re: my point
> The map no longer respects the selected field to use as the info bubble text. It's always showing ALL the fields included in the view.

I see now that your rendering the entire Views row as the info balloon text. So users would have to explicitly exclude all the other fields that they don't want appearing in the info balloon. I'm torn between that approach and explicitly specifying a single field, which is simpler in most use cases. Just opening as a point to discuss.

levelos’s picture

levelos commented
Status: Needs work » Fixed

Ok, I made some other minor changes and committed the patch. Overall, good improvements, thanks.

levelos’s picture

levelos commented

Also, esteewhy, still looking for an explanation on the grouping you intended to implement.

esteewhy’s picture

esteewhy commented

Ups, I was so slow at answering that You've managed to do all the dirty work, great sorry!

1) As to grouping:

The primary purpose for it is to render polylines. That is, every group of "points" is rendered as one poly.

What does grouping mean when NOT in a polyline mode - that's a an open question so far. At least, I'd reserve it for future use: mapstraction has something like setGroupName() method for Marker class, which is somehow used for marker decluttering by mapstraction itself (I've forgotten to call it, so let's queue it as ongoing task). Otherwise, one can imagine quite a lot of a vendor-specific applications for grouping information, to name a few:

  • in OpenLayers and GMaps: rendering each group in a dedicated layer and taking advantage of OL's layer switching built-in control
  • in GMaps: marker decluttering by group by 3rd party plugins

2) On the question You raised above about row plugin vs. explicitly selectable field for bubble content.

With all my heart I'd vote for the row plugin :-):

  • it's in vein with Views paradigm
  • it has an endless potential for extension and customisation (for now, it only support "fields" row plugin), custom templates and what's not
  • edit links and other controls available in fields within a bubble (somebody has already asked for this here at forum)
levelos’s picture

levelos commented

Great, thanks for the follow up.

Re: grouping, lets open a new feature ticket, say grouped markers as layers, and leaving that open. I'll adjust the messaging to explain it currently only works for polylines.

Re: the row text, I'm convinced and will leave as is, although we need to then remove the title field attribute as it's not used.

esteewhy’s picture

esteewhy commented
StatusFileSize
new 20100607-drupal-mapstraction-setGroupName.patch1.01 KB

Lou, I've tried a quick experiment with setGroupName() for markers, but got no sensible result: the only vendor that seems to benefit from marker group info is MultiMap. But I didn't even manage to get it displaying a simplest map. So leaving a patch just for the sake of completeness.

esteewhy’s picture

esteewhy commented

BTW, what do You think about joining forces: #634602: Possible to merge with the Mapstraction module?. I could spend some coding time on integration if there was a strategic decision ;-)

levelos’s picture

levelos commented

Yeah, it looks like none of the big providers have declutterMarkers implemented.

I think this would require quite bit of refactoring, but ideally it would be great if each group being returned by a View could be rendered as an overlay on the map. At least with OpenLayers, we could then toggle the visible layers/groups. map.addPolyline() in MXN really just adds an overlay. Regardless, this patch is a good first step, thanks!

levelos’s picture

levelos commented

In general, I'm all for it. I took over the Mapstraction module after that thread was started, and I know the maintainers participated a bit in the Mapstraction library mailing list as well. Some of the challenges I see:
* I'm not comfortable with the dependency on the Geo module. I don't think that's needed for most use cases, and every time I try using it there are lots of critical issues.
* Mapstraction_CCK is relying on a fork of the Mapstraction library. It needs to be made to work with the main development branch.
* Mapstraction_CCK relies on Post_GIS or a special build of MySql.

They also mentioned they're backing off of active development. Some great work has been done there; it might make most sense to port over the parts that make sense, like a CCK field / map picker, into this module. It has a stronger namespace anyways ;)

Status: Fixed » Closed (fixed)

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