Writing the mapstraction module - How much work?
Hi all
I would like to create a map which small scale organic food producers can use to advertise their efforts.
I would like for users to be able to submit their location, a photo and some text.
Most of what I want to do has been implemented on the excellent http://www.opengreenmap.org/
Tom who did the work on that system told me "There's a fair amount of custom coding, but most of that is just tweaks for
the icon navigation key, adding the two-stage popup infowindows, and a slight change to the way stuff is added to the map. The user submission stuff is basically just the gmap module, location module, cck, organic groups."
My question is how much work would be involved to develop the mapstraction module to the stage that it could be used to create a map system similar to the http://www.opengreenmap.org/ system?
I am currently seeking grant funding for my project, if the funding bid is successful then I would want to hire someone to
1) Develop the Drupal mapstraction module to a usable state.
2) Build an opengreenmap type of site using the new mapstraction module.
The code would be released GPL.
In order to do the funding bid I need a fairly accurate assessment of how much work that is, and what it would cost.
Is anyone out there prepared to draft a roadmap for the project, and quote for the work?
Thanks
Sam
Geobrowser?
Have you looked at the http://drupal.org/project/geobrowser project? It'd designed for a similar use case.
For those interested in
For those interested in Mapstraction:
There's some very early code in CVS at http://drupal.org/project/mapstraction
Andrew Turner, one of the creators of Mapstraction, built a Mapstraction module for Wordpress, but it's just to embed a map with a single point in a node (as of last time I checked). It would be easy enough to do this for Drupal, however it would be more work to use the mapstraction module in the same way as the GMap module.
Is there any broader interest in supporting alternatives to Google Maps in the GMap module? Or is there too much dependency on the Google Maps API?
Definitely there's a need...
...to break the on dependency on proprietary Google code and the data sucking that goes along with any use of Google services.
Several initiatives have been made or sketched in, including:
Mapping client based approaches (like Mapstraction):
http://drupal.org/project/openlayers
http://drupal.org/project/mapbuilder (now defunct)
Data-centric approaches focused on APIs and Open Geospatial standards:
http://drupal.org/project/mappingkit
http://drupal.org/project/geo
Of these initiatives, both geo and mappingkit appear to be under active development and to take a broad standards-based approach. If I were digging into this sort of work, I'd take a close look at both of these and look to select one as a base to build on.
Abstraction of abstractions?
I'm maintaining the Geo module ( thanks for pointing it out, by the way! :) ). Geo provides point/linestring/polygon/etc. storage via CCK fields. It also allows you to upload geospatial data in zip files and then link to them via a reference field. You can then query for your data via Views.
Geo supports PostGIS and MySQL Spatial. It's all very rudimentary, but it "works". However, what it doesn't do is create maps, and I believe it should never have to. Here's why:
CCK separates the concept of fields ( storage ), widgets ( ways for users to input data ) and formatters ( ways of presenting the field's data ). Views allows you to query for any type of data - whether it's geospatial, text, taxonomy, or anything else your heart desires. And it uses CCK formatters to display the data.
Because of this architecture, I can maintain a responsibility for storing and querying geospatial data, but other modules elsewhere can implement widgets and formatters to handle the input and output of Geo's data. I don't even have to know about them!
Now, my point is that this is an abstraction system in itself. If the GMap module knew how to take Geo's field data ( it comes out in a standards-compliant Well-Known-Text format ), then you could:
1) Install Geo
2) Create some fields
3) Install GMap
4) Use GMap to format Geo's field data
Now, if someone else came along and wrote a module that knew how to take Geo's field data and display it on a different mapping source, you could:
5) Install module X
6) Update your views and/or field formatters to use Module X's formatters
To me, it seems like needless complexity and an added layer of indirection to build something on top of Drupal that can change out the mapping source. I could be wrong, but from here it seems like an uneven cost/benefit.
So, to recap:
+1 on using Geo to store mappable data (totally unbiased, I promise!)
+1 to writing and/or funding mapping tools that leverage existing Geospatial data sources
-1 on implementing an abstraction layer on top of Drupal's native input / storage / query / output mechanisms
P.S. I could really use some funded development on Geo :)
Bit confused
Hi Allie
Are you saying that using geo you could easily swap between mapping paroviders?
Thanks
Sam
As long as they're written that way.
Geo stores data, and maps show data that has been stored or provided from "some source". If the mapping and storage are completely wedded, you can't use different maps with your storage - or different storage with your maps.
Thanks to CCK, you can write modules that separate the data from its output. And thanks to Views, you can use different methods of searching and listing that data. Thus, any mapping provider that can implement formatters for CCK and understand Geo's fields can be swappable.
Unfortunately, many modules in this space focus on grouping the storage and presentation together, which is what makes them difficult to use in more than one way.