Making Sense of RETS: Part 5

| | Comments (0) | TrackBacks (0)
RETS has a lot of benefits but let's talk about the big ones and the problems they solve.

How do I know how to connect to get the data I need?
With RETS, all you need to know from the MLS is the RETS login URL, your username and your password. From there, you can learn everything else on your own almost entirely using code if you want.

It seems like using a complex system would be harder for an MLS to support. How is this easier?
In most cases, if you have a question about how to log into a typical FTP server and process their data, you'll end up talking to someone that didn't actually create it so your answers will be scattered (if you get an answer at all). Maybe someone went through the MLS software and enabled new fields to be included in the feed. You can't expect everyone at the MLS to know about this so you may be disappointed with the answers you get.

With RETS, it is a more complex system, but it's well documented and as long as both the client and the server are compliant with the standard, you should have little trouble getting setup. You don't need to request help or documentation from them because it's either online (at the rets.org website) or available through the RETS server you're connecting to.

Logging in is pretty easy but then what do I do?
The process is very similar to what you'd do when you first get FTP access to an IDX feed for the first time. Once you login, you figure out what information is available. In RETS, these are called Resources. Once you request the Resources, you'll get back a list of information types that you can learn more about. From there, you can learn about the format of that data and learn how to search it for what you need.

Don't I need to understand the query language used by the MLS's database software to be able to get information?
Nope, that's a major benefit of RETS. RETS uses it's own query language and, when combined with StandardNames, allows you very easy access to pull property information that you need. The RETS server translates your RETS query into something it can understand, pulls the information out of it's database (the way it knows how) and morphs it into the RETS format so it's easy for you to understand when it sends it to you.

If RETS is so powerful and is truly live access to the data, can't I just have a website that connects directly to the RETS server instead of downloading a copy of the data locally?
Sure, and there are products that exist that do just that. Your website might have search criteria for listing price and number of bedrooms. That information could be put into a RETS query, sent to the RETS server, and the response could be displayed back to the user of the site.

The problem is that your MLS could catch onto what you're doing and could limit the amount of information you can pull (using queries) from the RETS server. They may even revoke your access to their system. In most cases, when you want to use data on your website, it's best to download a local copy of the data and access it from there.

You keep mentioning building a website using RETS access. Aren't there other applications for this system?
Absolutely. Having multiple MLS's in the same geographical area provides the potential for those MLS's to share property information between them so that agents in those areas have more to show potential buyers and provides agents with more exposure for their sellers. This is just 1 example. There are many others.

I really, really don't like the MLS software the MLS has for me to access it. Does RETS do anything in that situation?
In short, yes. If your MLS has a RETS server that you have access to, you could use any RETS-compliant program (called RETS clients) to access that data. This introduces more options for agents and brokers because they aren't tied to single user interface.

There are drawbacks, however. In most cases, the MLS software offers a lot of features. So far, it's difficult for a RETS client to offer the same features that the MLS might be able to offer through their own software because their software is made specifically to work with their data in their area. Work is continuing with RETS to try and introduce more capabilities for information sharing.

(continued in Part 6)

Categories

0 TrackBacks

Listed below are links to blogs that reference this entry: Making Sense of RETS: Part 5.

TrackBack URL for this entry: http://blog.troydavisson.com/mt-tb.cgi/7

Leave a comment

About this Entry

This page contains a single entry by Troy Davisson published on May 12, 2007 12:23 AM.

Making Sense of RETS: Part 4 was the previous entry in this blog.

Making Sense of RETS: Part 6 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.1