I have worked with several MLS IDX feeds and recently launched a RETS based site, http://nashvillehomes.com. With Nashville I did not do a node import, I decided to instead use a custom module which has some advantages but then it leaves you with having to custom code everything.

I have found only 1 module that deals with RETS and it's 5x and seems to be maybe more complicated than it has to be.

I was thinking of putting together something similar, but simpler.

The dependencies would be:

CCK, node_import and optionally views for a UI to show the MLS listings as a way to administer.

In a nutshell:

It would create a default CCK content type (s) and allow for some customization as to how the fields are mapped to MLS columns. It would do a batch import on cron run at a particular interval, delete old listings and update listings that has have a newer 'moddate' than the last updated date. I like the node_import for importing CCK content bc it works well with CCK. I would probably opt to use the phrets library since I've used it in the past and package it in the module.

Why?

The idea is that this would be a plug and play module where all you need are your RETS credentials/settings and it handles the import. Once RETS data in is CCK, you can build views and do whatever you want with it.

Potential Issues:

-RETS is implemented differently across providers
--I would propose we have includes for overrides to handle differences as they come up instead of each developer just hacking the module
--I think being able to customize how CCK maps to the MLS columns gives some flexibility here, bc the module would read the columns of the content types and allow you to modify the CCK field, add/remove CCK fields so that you can handle differences without hacking
-RETS splits up different listing types as different 'content types' with different fields, eg Commercial, Residential, etc.
--So I might have to have a content type for each listing type and let views handle pulling them together in searches

Scope:

I would like to keep the scope of this project very narrow, just manage the importing of RETS mls content into nodes. I'd like an optional module packaged that implements an administrative view for viewing MLS data in a table and maybe that module could grow to add additional views later on.

Thoughts/concerns? Thx -J

Comments

kevinquillen’s picture

Hi J,

Earlier this month I put together a module that parses RETS data (using phRETS) and does most of what you have defined here, based on the same reasons you listed (no solution available). We too have faced this and would like to provide a way to hook into a RETS feed and import the data.

The only module I needed was CCK for the MLS fields, and I did not need any additional tables. There are some code tweaks left to do, mostly dealing with getting RETS queries just right, but it works pretty well and also obtains photos for listings.

Currently I am only working with InnoVia RETS 1.5 system. I planned on having submodules within the module that would be used depending on what RETS you are interfacing with, like Rappatoni or flexMLS.

We should collaborate for the greater good of the community. I am currently awaiting approval of a CVS account for my RETS module and interested in any feedback you may have.

===========
read my thoughts

drupalninja99’s picture

can i have a look at the module you created? thx -J

kevinquillen’s picture

===========
read my thoughts

will_kelly’s picture

I would be interested in helping with the development of this project.

Coming up with a plug and play would be ideal.

Jay are you talking about starting from scratch? Changing you module? What are your plans for the foundation of the project?

Let me know how I can help.

Will

kevinquillen’s picture

n/t

===========
read my thoughts

drupalninja99’s picture

create one and i'll join it

WorldFallz’s picture

Garrett Albright’s picture

It's not publicly available yet, unfortunately, but my company has built a D6 module called PIRETS which fetches RETS listings and turns them into nodes, complete with faceted CCK fields. We've been working with about half a dozen different users to ensure maximum compatibility with all of the various different implementations of the RETS "standard." Check this out for more information. It can't create nodes of different content types depending on its property class, but it does store that class info in a CCK field, so using Views to filter listings by property class is trivial.

Russell Mann’s picture

subscribe