Porting Geo to Drupal 7

subscribe

subscribe

subscribing

subscribe

Subscribing

Subcribing. I can help testing

Subscribing

subscribe

subscribe

.

subscribe

We are as excited as all of you are to have GEO working in Drupal 7, and it our intention to port this module as soon as possible. We do not have a defined timeline for the work involved, but will update the module and issue queues as appropriate.

Of course we are looking for help and support in our efforts! Don't hesitate to contact us at Advantage Labs.

If you want more information, please subscribe to the issue queue for the GEO module.

This sounds encouraging, is there anything specific I could do to support your efforts?

I would be really interested in helping to port Geo to Drupal 7, maybe I just start to publish my progress on GitHub ...

Finally I managed to publish my progress on GitHub: https://github.com/geops/drupal-geo/tree/7.x-1.x

I started with applying patches generated by the coder module. Those changes fixed some API changes and coding standards. Furthermore I started to port the geo_field.module to the new Field API.

Of course I would be happy to work together on this issue and seeing these changes committed on drupal.org. Let me know if a patch file is more helpful then a github repository. I will start a sandbox project on drupal.org as soon as they are available.

The primary hold-up is that nobody is willing to fund development on Geo. This is heartbreaking for us because we have invested tens of thousands of dollars of our own on making it work, in hopes that others would push it to the next step. However, no resources are forthcoming, and we're forced to choose between making a living and contributing to this module. We receive offers for "help" with regularity, but the typical framing is "I can get paid by my client to work on Geo, but only if you teach me how to do that -- for free." It's truly unsustainable for us to teach people how to do our contrib work for free, when we'd much rather just have the resources to get it done according to our vision and roadmap!

You are, of course, free to do as you like by forking this work on Github, etc. However, there are some important architectural changes that we'd like to include in the D7 upgrade. Spending time coordinating forks only makes it more expensive and difficult for us to actually move the project forward.

In particular, Geo's primary focus is making easier for end users to work with Geo data by creating a loose-coupled abstraction between the front end, storage, and backend. I will not be upgrading geo_field in the way you describe, because we need to make an extensible field available to Drupal without forcing people to see "Geospatial data" in the field type dropdown. This means that I will likely deprecate geo_field, or make it very very small and move most of the field stuff into its API directly. I would very much like to work though the other key aspect of Geo - changing out the UI/Display using more flexible mechanisms. There was a start to this in the D6 version, but I would like to reimagine it so that users can add and view Geo data in the way that makes the most sense to them.

I don't mean to sound all doom and gloom. Geo is a priority for us, and we're already making time to fit it into our schedule. The majority of the D7 upgrade is already complete, but our timeline is dictated by the resources we have at our disposal - which is up to users like you, and not up to us.

Allie, how much funding (hourly rate or something) are you looking for? I e-mailed you on 2010-10-10 offering also to pay for things, but received no reply. You can contact me privately if needed.

Its great news that you are considering refactoring the widget, etc. Big plus. It only took about 50 lines of code to hack a small inline dual textfield that was attached to a google pop-up window. Only supported points, so not the best for the D6 version.

Yep, I can commiserate with the funding issues. I think that I've done about 4 months work for $200 on my projects. For the love of Drupal!

> Yep, I can commiserate with the funding issues.

The more I don't understand why you don't point people like friedi into the right direction instead of just disapproving their initiative. Of course nobody should expect that you teach them for free. But I would suggest that you publish and discuss your ideas about possible changes in architecture, and maybe work for a commonly accepted roadmap. Then others (those that are happy to be funded right now) could contribute their work to the community. This is a common and very efficient way in many open source projects.

Fully agree. (I'm not affiliated with the geo project) This project could potentially become the foundation stone to almost all of the geo modules, but a stable relesase in 6 months+ time will mean that this will almost certainly be bypassed until Drupal 8 is released.

Personally, I'd love it if the fields were split into components, with a combo field that supported multiple multiple input modes:

geo - as is
geo_point - only lat / lon
etc.

Subscribe

We have a lot of the same hopes and beliefs for this module and suite of tools as well, and we certainly do appreciate everyones work on furthering that, whether it's through providing feedback, submitting bugs, providing patches or other forms.

As individual developers and as a company, we've invested a significant amount of time and financial resources to build this set of tools in the hopes of redefining how GIS information is handled, stored and communicated within Drupal, opening up whole new worlds of possibilities for native Drupal applications. Stuff where we can even go beyond points and radiuses into using real information in meaningful ways.

I don't want to digress too much, but the bottom line is that continuing to support Geo, and in particular making a Drupal 7 stable release available, is a top priority for us. As a small shop who's receiving no funding for this work it's hard to fit it in our schedule, but we're working around that and continue to work on building our business in ways that will allow us to dedicate more time to tools like Geo and Pay. As Allie stated, she's begun in earnest on this, and we plan to make that work available on D.O. soon.

We'll also be attending DrupalCon Chicago and would be happy to meet and talk with some of you, either over a beer or perhaps in a BoF format.

subscribe

Hi Jerdavis and Allie,

I'm totally sympathetic to your funding needs. Our small shop released 9 modules and a distro in the last year and it's really hard to keep up with all the requests that come in. You all have produced so many great tools. Thank you so much.

At the same time, I've gotta say that I'm a bit frustrated by the /way/ that you all are going about asking for support on this and the other modules that you've produced. It feels like you keep providing the argument for /why/ you need funding - but you're not providing clear and specific ways that we, as a community of developers with our own modules to support, can actually fund you. (If there is a specific ask in this thread, I apologize, but I just haven't seen it.)

Help us help you! The Drupal marketplace doesn't currently exist - but there are other concrete ways that your team could help us raise money for this work. Toss the project on Kickstarter. Throw together a scrappy pledge site for this and your other projects. Flesh out a feature set with some back of the envelop estimates for what you need for various features, tell us how much an hour of dev time on the project would cost, etc. Because right now it feels like you are asking for a benefactor, or someone to subcontract you out to do implementations for their clients - and that's not likely to happen. It it does, rad! But if it doesn't, I think you'd be surprised by how many of us would toss in money on a Kickstarter pledge page.

Again, thank you so much for all your hard work. The Drupal Geo space would be years behind if it wasn't for you all. You deserve to get paid. We all want to pay you. Just give us a transparent mechanism to do so.

Thanks for hearing me out.

Sean Larkin
ThinkShout.com

subscribe

There's a geofield module here: http://drupal.org/project/geofield

There also exists the Geolocation Field module - http://drupal.org/project/geolocation. The names is almost the same as above, so it gets a bit confusing.

FYI for Drupal 6, I have put Geo up in git sandbox, and applied the 6-7 patches I need for myself (most of them created by me and submitted to issue queue here with no comments/commits from maintainers for 6 months): git@git.drupal.org:sandbox/ahtih/1081362.git

Note this issue on the drupal-core issue queue: http://drupal.org/node/293483

Here are we talking about getting native geometry column support in D8. It might be possible, once this patch is fixed up and committed to D8, to do a backport to D7 for those who need it.

Subscribe. Any news on this?
And/or an answer to the question of how to contribute? If there are no large funders, it might still be possible to crowd-fund a D7 version (Kickstarter?).

subscribing...

@Allie Micka, you said in #15:

The majority of the D7 upgrade is already complete

Would you care to share your work-in-progress so that those who want to collaborate/contribute (like @friedi) have a means to?

Thanks!

Subscribing, greetings, Martijn

subbing

sub.

Subscribing so I am reminded to update my blog post on D7, Geolocation & HTML5 - http://openconcept.ca/blog/mgifford/geolocation-drupal-7-html5

subscribe

sub

subscribe

Look at this http://drupal.org/sandbox/geops/1212962 and its explication in http://www.geops.de/blog/64-spatial-data-and-drupal-7

It will be a shame if MySQL functionality is lost. I'm doing this manually for a project and performance is not that bad using a simple lat/lon bounding box + user defined SQL distance function on a small circular radius (250km & ~150 points within this box). Syntax between MySQL 5.1 / 5.5 changed slightly, so there is added complexity there.

My base field is geofield, and I used the entity insert/update/delete hooks to pick up on changes to insert into the DB, and custom pages / blocks to do the queries.

Long way of saying, it would still be great to have a great base module ported before there is too much duplication of functionality with D7.

PS: NZ is a good starting country to test. It crosses the 180/-180 boundary, so I picked up a couple of bugs I would have otherwise missed in the bounding box. Simple solution was to add 180 to all longitude comparisons.

subscribe

subscribe

No need for further subscribe comments, use the 'Follow' button in the top right of the page.

Yep. Sadly we loss the barometer of interest :(

I put in a request here to try to re-engage that barometer:
#1341092: Follow is Great, But....

Can I ask what the functionality is exactly that folks are interested in porting to D7? Is it mainly that folks running this module in D6 are interested in an upgrade path? If that's the case, some people might want to consider writing a migration module that moves data from Geo in D6 to GeoField in D7. GeoField has a very active D7 development community - it's also the go-to geo storage solution for the folks working on front-end mapping solutions with OpenLayers and Leaflet.

If the issue is geospatial querying, GeoField also ships with geoPHP, which isn't as performant as native geospatial database extensions - but for most cases works just fine.

If the issue is direct import of shape files, well, there's isn't another good way to handle that in Drupal. But there's a lot of great ways to import geojson via the Feeds module.

I know that it could be construed as root for me to post these questions to the Geo module queue and suggesting that folks consider jumping ship. Apologies. But there's a great group of folks, our team included, that are working hard on GeoField and related modules. If there's a way to serve the community's interest via some of that other work, say the word!

native geospatial database

This is the magic needed. I'm currently doing this on MySQL using entity insert / update / delete hooks and custom queries and a custom db function to calculate distances inside the bounding box. I'm also working with a global geo database, so we talking about 100,000 entities. Anything other than core db support would make searches, etc unusable.

@Alan,

Then why MySQL? My understanding is that the geospatial database extensions are much better in Postgresql. For that much data, there's also geospatial options with Solr.

Regardless, I think that you've raised the main reason to port this module. However, there's a lot, lot more to it than just native geo storage. My sense is that that other stuff is slowing down the port - and that a lot of folks using this module need features that could be handled with improvements to GeoField.

Just an observation.

@seanberto Yep, PostGIS is the way to go, but this is not installed on our servers and it is not a commercial project so I couldn't afford to splash out. I'm only dealing with points, so it only took a few hours to write in the db layer procedures, and with an approximate lat / lon bounding box in the queries and the db procedures, the results were still measurable in ms even for the large dataset. If I dropped the db layer support, things slowed down by at least a factor of 10.

I actually love the idea of a base module that doesn't do much (not much is 45K of awesome geospatial goodies), but does what it does super well and allows you to choose what decorator that you want to throw at it. But I do feel that with the momentum that GeoField is gaining, Geo will slowly fade into obscurity. :(

So plus 1 for merging projects and to make GeoField an great solution of D7 onwards.

also see: #982534: Port Geocode to D7 (Geocode was forked to geocoder)

So, what is the road taken here? From going through the comments in this issue, I see these efforts:

Geo 7.x @ github
Geofield drupal project
Geolocation field drupal project
Patched Geo drupal sandbox by ahtih (see #1418992: Please update the sandbox's page to mention this is 6.x and also additional info about patches applied.)

What is the "official" choice to follow among these? Did I miss one perhaps? Is there any other work going on elsewhere?

Geo 7.x @ github is not maintained anymore and superseded by drupal project PostGIS. If you need spatial database support take a look at the PostGIS module, otherwise Geofield or Gelocation field might be easier to get started.

We are still interested in an abstracted spatial storage interface to improve interoperability of different storage implementations.

Also worth while checking out the Sync PostGIS module (http://drupal.org/project/sync_postgis) where you store things using geofield, but sync them off to postGIS. Essentially it's "postGIS as a service" in the same vien as apache solr.