There’s a bit of buzz in the blogosphere over Real Tech LLC adding polygon searching to John L Scott’s web site. Joel Burslem over at FoREM says, “It’s a neat gimmick, designed by real estate technology provider Real Tech LLC. But it’s just that, a gimmick. I gave it a shot on their web site and while fun, it doesn’t really add much to making the search experience any more intuitive.” In tune with questions I’ve posed previously, Joel goes on to say:

Unfortunately, the more time you spend searching on these sites (and I’ve spent a lot lately) – the more you realize that map based searches are still quirky, buggy and sometimes downright annoying. Scroll wheels that jump around, or having to click all over the place to zoom in and out; some sites that allow you drag the maps around, others make it down right impossible to zoom in to where you want to be.

And then Joel concludes: “I suspect that there are going to take several more generations before searching for property on a map become a truly usable way to find a home.”

Robbie, posting over at Rain City Guide, is more upbeat, “hats off to RealTech on John L Scott for raising the bar for everybody!” Robbie did note that the mapping seemed a bit sluggish from his work computer but snappy at the rocket ship he has at home. (Robbie, you should bug your bosses to get a rocket ship at work, too. :-) ). Some of the sluggishness may well be coming from the drawing as opposed to the actual searching.

Interestingly enough, this type of searching has been in most MLS systems for years. In the original incarnations, the Walter Zorn vector libraries were used most commonly for the drawing. These are great because they are cross-browser, but they do not scale very well and require a lot of local processing power once you have large or more than one shape and have to move them around the screen.

More recently, the adoption of canvas by most browsers (and Google’s extension of canvas into Internet Explorer) has provided significant improvements in both the scalability and visual appeal of drawing shapes in browsers. Here’s an example from our first implementation of MapServer:

map_search

The beauty of using MapServer is that it’s open source and DM Solutions Group, a leader in open source mapping, has helped us by implementing canvas support and many other tools we needed into their ka-map libraries.

The searching of the map using the shapes is actually easier than it at first appears. Thanks to some brilliant mathematicians, there are some cool point-in-polygon algorithms that make this type of query almost trivial using stored procedures in your favorite database. As long as your database is fast, the searching should be fast, too. As I’m hoping you’ll be able to see in the above screen shot, you can even do useful things like intersecting sets so you can make sure you are in the neighborhood you want and within a certain distance from work.

As Joel pointed out in his quotes above, though, the real challenge in implementing map searching is in the user interface and figuring out how to minimize the zooming often required to see the properties because of the scalability limitations of using Javascript to plot the listings on the map. We’re working now on a version that will plot in real time very large numbers of matches on the map so that users can truly use the map to explore the listings in full context from all zoom levels.

Ironically, when we first started using MapQuest Enterprise for mapping many years ago, plotting large numbers of listings wasn’t a problem. When we replaced MapQuest earlier this spring with MapServer, our clients have really missed seeing all those dots. They can see their result set still, but seeing the full context while searching is really useful. In the fall, we’ll be restoring balance to the Force by adding this capability into our MapServer implementation.

We’d love to hear from others working with mapping, particularly on the issue of the best interfaces for searching. If you want, check out and vote at this poll we ran a few months ago. In the meantime, happy map searching!

7 Responses to MLS Map Searching: Point in Polygon

  1. MattL.com says:

    Map-Based Searching and Why We Don’t Do It

    Michael Wurzer posted (over at the FBS Blog) his commentary on the ever-roiling hype around map-based searching in MLSes and for real estate consumers, borne out of Real Tech LLC’s implementation of polygon-based mapping for John L Scott. Whenever I…

  2. Robbie says:

    I’ve always wondered what MLS capabilities were. I’ve heard they were pretty leading edge, but since consumers (and IDX vendors) don’t see them, the world doesn’t know. Oh well, I fully expect the capabilites to converge over time anyway.

    I think the main limitation is going to be bandwidth. Typically whenever you pan the map, the browser throws away it’s pin set and asks the DB for a new set. When you pan out, thats a lot of data you need to get back… Either that or we need richer overlay capabilites for tile based mapping platforms. A browser side storage mechanism would definitely help here, but the evolution of such technology hasn’t gotten much ink compared to the UI innovations going on.

    I think is speed will be less of an issue. We’re doing things today, I thought we’re impossible in browsers 5 years ago. Currently, I think Mozilla, Adobe, Google is working on a Javascript compiler (Tamarin). MS is going to make sure SilverLight smokes Flash & whatever else anybody else cooks up. And now that the band is back together, I’m sure pure AJAX in IE will improve markedly too. And don’t forget Moore’s Law is still alive and well. Whatever the software companies don’t fix, 64 bit Quad Core CPUs will.

    I tend to think of browsers as streaming applications that have little/no state, I think the UI differences between browsers and desktops are becoming less of a factor.

  3. Regarding Moore’s law and programming, check out this O’Reilly post discussing the need for programmers to start re-thinking things to take advantage of multi-core processing. Relying on the OS ain’t gonna cut it. I’ll try to get someone from here with more knowledge than I to post something more in-depth about that, but I think it’s a huge issue and where real revolutions in computing will come in the next few years. As you say, this will be “close to the metal.” :-)

  4. Actually, Robbie, it’s funny, but you do *not* have to throw away the pinset for each pan… it’s a poor implementation decision (made by some of the biggest sites) to simplify the query/new pinset logic. I faulted a Big broker at Connect SF for doing exactly that with Microsoft’s Live Maps.

    Half of what makes these implementations so poor is the overwhelming amount of data they expect the browser to interpret. They seem to forget that this is uncompiled Javascript, and it’s not nice to throw a 2MB object-oriented dataset at a realtime parser. This reality is exacerbated by the fact that user only clicks two or three of the million pins to get “rich” data (i.e., a prettified link with thumbnails pointing to the actual listing page).

    It’s still not ready for prime time, IMHO.

    -Matt

  5. Until the JS interpreters become multi-threaded (which the browsers barely even are), quad-core ain’t gonna help. In fact, if the clock speeds of each core continue to wind down in favor of multi-core implementations, it’ll only get worse.

    -Matt

  6. That’s the point, exactly, of my earlier http://www.flexmls.com/blog/?p=40 rel=”nofollow”>Mapping Mayhem post. We’re now doing live rendering of tiles with the listings plotted and can do tens and likely hundreds of thousands of matches. ColoradoHomeStop is doing something like this, too, though I think ours will be better. ;-)

  7. vvckdznckm says:

    Hello! Good Site! Thanks you! syqekknswtyjbd

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>