Hello,
a while ago, i built the module CCK GMap Address: http://drupal.org/project/cck_gmapaddress. It is dependant on the GMap module. It provides a CCK Field to enter an address and display it in a GMap. Therefore GMap is used to get geodata (lon/lat) validate the address and display the GoogleMap. Data stored in the field are lon, lat, accuracy and the address string. Display of the GMap can be customized per field (e.g. for teaser,full, views display).
At the time I built the module, there wasn't any that satified my needs on such a CCK Field.
In the near future I want to expand the features of this module. Because there are a lot of GMap/Geolocation modules with a lot of different features, but also al lot of common ones.
So I first want to present my planned features. In second I want to initiate a discussion on this module and other existing modules, dealing with the same aspects.
My ambition is to cooperate with other module mantainers and programmers, to build a more efficient way of implementing Geocoding in Drupal, especially as CCK Field.
My planned features:
- Second Widget to fetch address data from different existing Fields (like cck textfield, taxonomy)
** on the fly/cron geocoding for this widget, to be able to add GMap to an existing site, withput saving every node - Display route in embed GMap
- GMap Views implementation (also gProximity?)
- Radius search - Views and/or search implementation
- improved Documentation
I did test a lot of modules, but that was some weeks ago. So I could need some help on planning future features or some hints to existing
modules.
If you are a module mantainer, you are welcome to contact me ;)
Edit:
For bringing existing modules together (especially in CCk matter), I think of building a base cck field that stores data like (lan, lot, street,...), and provides different Widgets for typing an Address, mark a place on a GMap, etc. pp. .
Comments
Good news, bad news!
It's great to see someone else working in this space, but disappointing to see yet another duplicate project on the scene. As long as new development initiatives are incompatible with existing ones, we're all going to waste our efforts on 70% solutions, rather than collaborating on a 100% solution. I'm sure you investigated other modules, but did you contact the authors to see if you could get the features you needed through patches or co-maintainership rather than starting with something that does 0 things?
I'm not singling you out, as it's clear you're reaching out now. There are a lot of people frustrated with this space, and that's resulting in a lot of duplicate efforts. As geospatial data management and presentation is a complex and multifaceted problem, it's even more important to collaborate and hear each other out, rather than having any "maverick solution" that attempts to solve this.
I agree with the assessment that this problem needs to be deconstructed, rather than relying on an "ubermodule" to handle the whole shootin' match. For example, the proposal to store addresses at all is incompatible with the needs we've encountered, which involve tracking points ( windmills, minefields, etc. ). Meanwhile, there are at least 4 modules trying to maintain addresses in CCK fields. RE: geocoding, I think this should happen separately from addresses and geo storage. I posted more here.
I hope there's more open discussion on this group about collaboration and short/long-term development goals. Ultimately, the reality is that some of the duplicate modules will need to be phased out, so that "working together" can mean actually working together ;)
Agreed, of course. (Once
Agreed, of course.
(Once Location3 is relaeased, I can start ripping the geospatial storage out and depending on geo for that... Gonna be exciting!)
You are definitely right!
You are definitely right! When I built the module, I did not contact any module maintainer. Sure that was my fault, but at that moment it seems to be the best, because fastest solution.. But fast isn't allways best;)
I also aggree with your content on http://groups.drupal.org/node/9612. My intention was to build or use some module for this "field stalking", best by using existing modules.
Therefore I had in mind to work with a CCK field, that manages saving and loading of this data. Widgets can be provided to fullfill the needs of -for example- "simply type in some address" or "read data from other sources".
I'm not big into theoretical geospatial/GIS, and did not read a lot fo it. I did only have in mind to store and let output my locations in a comfortable CCK Field. So for storing data, e.g. to be able to implement some comfortable search functionality, I have in mind to use some database-table like this:
nid | vid | field | delta | references (...) | LocationName | Longitude | Latitude | street | zipcode | city | state | country
I guess there's a need of a lot more columns,but as I said, I'm not big into general discussion.
+ It is only for D6?
2. Is there any module that intents to be such a CCK-field-stalking-module?
This week I have to code some "field stalking"-widget (above list#1) for a project. So I have to add some feature to the current CCK GMapAddress. I'm willing to bring it to a stable release.
But in the future there is the need to put some modules together, and I think GMapAddress will be one of these.
So my question is, what you'd propose to do next? What modules should I have an eye on?