Do You Care About a Centralized Mapping Solution in Drupal?

Hi,

You forgot trackfield ;)

Trackfield was developed for documenting... erm... tracks on maps. One feature I wanted was the ability to store user (and by this I mean, site configured) data at each point. In this way an athlete with a GPS can store heart rate, altitude, etc. on their path. It is possible to build a site very similar to MotionBased based on Drupal and this module.

It is in heavy use on Northern Beaches Mountain Biking Group. The way this is setup is that a 'track' is associated with an 'area'. Eg: Manly Dam page. It has a 'tracks' tab that is just a view showing the tracks within them.

There is a KML module for viewing in Google Earth (or Google Maps for that matter - NoBMoB Manly Dam on Google Maps) them automatically appear on the site's KML feed (check out http://nobmob.com/rides/kml - this is a custom module that includes all KML for all 'area' nodes) along with images.

I recently wrote a small stats page too (http://nobmob.com/rides/statistics) and there's a small module that uses trackfield (here: http://nobmob.com/hill_profiles) that allows a few hill profiles to be compared.

From what I know a couple of other outdoor based sites are using this but not sure exactly who is.

Interestingly I just committed some nice changes on the weekend for D5 which make things more configurable and make the graphs (altitude, heartrate, etc) look nicer.

There is a D6 version and I need to get the above commits into that ASAP. Oh - where to find the time! ;)

Cheers!

Hey, zzolo.

I don't mind a decentralized ecosystem of mapping modules--however I'm committed to a unified way of dealing with actual geodata--storing and retrieving with Geo.

There are plenty of mapping services and mapping stacks, and I think that there's no way to effectively unify them; Mapstraction will work well for some, while others might want to take advantage of platform-specific features or code written for their chosen mapping service.

I think it would be useful to us geo-drupal developers to keep the core pieces of functionality laid out in BDragon's vision in mind as we build things; that document lays out the problem set well.

Agreed as well.

Brandon and I have been working on moving towards getting location_cck into the entry space as is mentioned in his vision. We have several people here that are either largely working with geo work in Drupal or are willing to.

Let's start getting organized and I think that we can really make this happen.

We obviously have this g.d.o group, and I've just stepped over to #drupal-geo on IRC for us to be able to hash things out as well.

Jeff, Alan, Tom, and others what do you say? Ready to take this to the next level.

I encourage you to have a look at the presentation on Geo from DCDC, which provides a decent overview of what Geo is and is not.

Basically, Geo stores point, line and polygon data in databases that support spatial extensions. The most feature-rich solution is PostgreSQL, but the version of MySQL you've already got running support spatial extensions as well. The Geo module acts as a bridge between those databases and Drupal. It also provides the capacity to import shape data from public sources and use it to contextualize your Drupal content. There's the beginnings of documentation here, and we're all really interested in getting help with that so that we can spend more time working on geo than on describing what it does :)

WKT is a text format. It's cumbersome, not easily indexable, and often incompatible with how you want to use data. It is, however, a good language to transmit data around with, which is why it's used to input data into Geo.

As for outputting information, Geo provides a binary parser that can finagle its spatial data into just about anything. Bec's work on the GMAP Geo module shows how geo data can be retrieved into array format for use by a CCK field formatter. Geo ships with Views outputs in SVG and KML, which also use the binary parser.

I agree with others in this thread that it's less important couple our efforts loosely, focusing on areas of core competency. The abstraction we need for a "centralized solution" already comes from Views and CCK, so we'll get close to what we need by writing CCK input widgets, CCK output formatters, Views style plugins, and helper modules.

The part that feels the most difficult is ensuring that Geo is stable and well-supported. We absolutely don't want to create something half-baked, and we'd really like to finish what we've started! A strong Geo module is a strong glue for everyone else's efforts. Advantage Labs has almost all of the development on Geo "off the clock", and despite interest at DrupalCON, we haven't locked on additional funding. We've been denied for several grant applications - while putting dots on maps looks cool and is easily funded, proving a storage mechanism to collect, store, search data, and provide data in an open data format for other sites - is more esoteric.

Many have suggested that the can code/learn to code in order to help out with Geo, but we're really hoping we can find a way to get some of the architectural/heavy-lifting polished out beforehand. Explaining the module, explaining the architecture and design goals, vetting patches, and providing support and followup is just not something we can do sustainably right now.

But we're optimistic! We'll be launching a grassroots campaign for funding and participation during the coming weeks, and rallying around our Roadmap to a 1.0 release. Please stay tuned here, or contact us directly if you'd like to participate in the planning and execution.

hello
i totally agree with this post and hope that a standardized solution will be done

im not a geo user but i think that a lot of infos are still the same and can be shared between modules

i would like to use a module for mapping google and yahoo but i need to test all of them......
i would like to implement the new secondlife mapping system but wich module should i use to depend on ?

i would like to see a common api module as an entrance door to speak to any geo mapping module
like this, anyone would be able to build its own mapping module but other developers needing to use them on dependencies would not have problems to test a lot of modules to choose one

After starting a personal project that required multiple unique mapping features, I quickly realized that this discussion is really about a three headed monster.

The first is storage, which Allie is making a great start on, albeit hindered by the state of MySQL geo support. The only negative is that I found it easier to manually handle the data storage myself that to tie into the framework. I didn't need view support, so it was trivial to handle the storage / queries myself. Things are always so much easier bypassing a couple layers of abstraction. :)

The second is data interface and this is where I find that, as a general rule, the more modules implementing different mechanisms the better. A CCK / View based solution will cripple the performance of a high performance FAPI based site, but this is what is required for the Newbie personal blogs. I would imagine that most sites would only require one or two different interfaces here, so bloating a module with multiple methods seems to add unnecessary overhead and complications IMHO. The fairly new GMap Blocks module provides the required functionality if over 98% of our clients, when coupled with a simple custom insert gmap_block filter (the beta 4 version has a fatal installation error, use beta 3 or correct the schema in the installation file if you want to play with it).

The last is the presentation. It is at this level that I think that we can make a huge step forward in unifying duplicate efforts. How many modules out there have an interface for the Google Mapping API key, 10, 20? Probably more like 30 or 40! As Mapstraction shows, it is not that hard to create a general wrapper for the common functionality required. A WYSIWYG project for map rendering. Has anyone made an attempt at this?

The big question is the adapter interface between these. Maybe just a simple node / edge model as this would be trivial to implement and there is no real learning curve required. Without that much domain knowledge here, I would not really see the need for many modules implementing the second / third steps to have to know much about spatial ref. system ids or having to parse special formats (KML, WKT, etc). How many of the 20,000 GMap users have more that just a couple of lat/lng points defined?

Anyway, just my 2 cents.

The second is data interface and this is where I find that, as a general rule, the more modules implementing different mechanisms the better. ... I would imagine that most sites would only require one or two different interfaces here, so bloating a module with multiple methods seems to add unnecessary overhead and complications IMHO.

A weakness of this approach is that feature overlap and sparse documentation can make it difficult for the site builder to choose. For me, and ideal world would be an umbrella API / sub-module model.