Parse GEO ical and VVENUE fields

The standard for what can be placed into the iCal location field is only that it can be free text. There is potentially also a geo field that contains longitude and latitude.

Are there feeds that you are aware of that have a standard formatting in the location field? Or that are using the geo field?

You could try sending things through the google, or other, system to try an ascertain the long and lat. But it's certainly out of the scope of this module. I think you will find some of the location related modules do actually do this sort of thing though.

These are however within the scope of this module and/or the date.module iCal API

Meetup populates the VEVENT GEO field. For an example try this:
curl http://www.meetup.com/surrey-drupal/calendar/ical/Surrey+Drupal+Users+Group/

Unfortunately, the precision isn't high enough for my purposes. However, I didn't discover this until I wrote some code for the 2.x branch to implement mapping the field to a location enabled node. I've attached it in case it's useful to someone else, or ekes wants to include it (or an updated variation) in the module. ekes, if it doesn't pass muster I'm game for updating it to your specifications.

If you can parse out a decent address from the VEVENT LOCATION field the location module will look up lat/lon (using a selected provider like Google) when the node is submitted. Since the Meetup GEO lat/lon didn't work out for me, I'll be taking a quick look at this. Will let you know if I find anything.

Opps, and here's the patch for VEVENT GEO field mapping.

Scanning it, it looks good. It's the correct implementation of the GEO field, but yep their accuracy is pretty poor.
If you can add some tests I'd say GEO should be sorted for 2.x :-)

LOCATION can get more interesting if it has a ALTREP or VVENUE related to it.
However just starting with handling plain text ones would be good. For this, and not specifically related to this thread, have you looked at http://drupal.org/project/geocode ? It takes the first google geocode result for the location from a cck text field (for example) and puts it into a geo module field.

I'll take a crack at adding a test.

I see there's two test data files, Basic.ics and School.ics. Would you rather I add a new ics file, or add GEO info to an existing file?

Thanks for the heads up on the Geocode module. Will check it out.

For some reason I didn't get an email notification when new comments were added to this issue. Because I'm checking back manually, I might be slow to respond.

Cool. You could add it to the basic.ics which is a specially made feed to test variants, or make a new one. My thinking was in time to have one reference ics with lots of basic stuff and then maybe a few examples from the real world, so either would fit.

Cheers,

Should I be concerned that the module isn't currently passing all of it's tests? There are 12 errors associated with the datefield and datesite.

There should be a comment in the code iirc, sorry if I missed it out. There is a bug report #689152: All day events failing

Here is the patch with added test.

I added it as a second test just for location because it required the location module. This gives the option of only running the main test if you're not interested in location. I can merge it all back into one test, if that's better.

The Basic.ics file was updated to add the GEO info (as opposed to adding a new ics file).

Hi,

Thanks for that. Sorry for leaving it a while. I now understand that the patch is just for location node (and not location cck) and just for point; and that the mapper is in the patch. The mapper should certainly get merged into #623428: Provide hook_feeds_user_processor_targets_alter() - see my note on there, it's a case of working out how best to do it.

The tests work fine. In the iCal case the geo data that can be stored is quite basic, so a future location mapper should pass these tests - just as yours within the patch does now.

There's been work on mapping GEO fields in Feeds so this should now a much easier possibility.