CREA DDF Standard-XML Real Estate Board

[jus...@hellomedia.ca]

Hi,

I'm having trouble finding the Board/Association field in DDF Standard-XML that represents the real estate board responsible for the listing which must be displayed at the bottom of all single listing views as per CREA terms.

Compact return this value in the "ListAOR" field, but we can't seem to find a field in Standard-XML and the Standard-XML payload in the DDF documentation doesn't list any fields that contain the Board or Association responsible.

We did find a field in the returned Standard-XML called "Boards" which seems like the right field, but isn't mentioned in the CREA DDF documentation or listed in Standard-XML payload in the docs.

The value of "Boards" is also always numeric so I'm at a bit of a loss..

Any help would be appreciated.

Thanks

Justin

[Jason Graham]

Justin,

The value in Standard-XML that identifies this is called "Board".  You're right - its missing in the documentation.  I'll make sure it gets added in the next update to that document.

If you're only seeing the ID and not name of the board in the XML payload, is it possible you're requesting Standard-XML-Encoded, which would return just the ID?

You can also get a full list of the board IDs and names in the metadata:

http://data.crea.ca/Metadata.svc/GetMetadata?Type=METADATA-LOOKUP_Type&Format=Standard-XML&ID=Property:Boards

You can see the results in a browser by hitting http://data.crea.ca/Login.svc/Login first, and entering your password before opening that link.

Jason

[jus...@hellomedia.ca]

Thanks so much for your reply Jason.

It actually turned out to be the opposite, when I change to Standard-XML-Encoded than the Board text representation is pulled, when I use Standard-XML I only get teh metadata lookup value.  This behaviour seems to be the opposite on how Standard-XML and Standard-XML-Encoded are supposed to work, is this correct behaviour? Is it possible that field is returning the incorrect value in Standard-XML, I've tested over and over this evening and this seems to be the only field behaving in an opposite manner.

I've come across another issue when looking into the above.   I noticed that when using GetObject() to pull Office data a province is never returned in the payload, it is listed in docs but I've synced over 1000 offices and not a single return contains a province for an office but all other details are returned.  Do you have any ideas why it would not be returned in the payload.

Thanks for yor help Jason

Justin

[Jason Graham]

Sounds like we must have got the endcoded/decoded bahviour backwards in our data mappings.  I'll review and get it corrected.

You're right about the missing province in the Office data.  It was pointed out by another client, and we have a support ticket set up for get it populated.  I'm not sure exactly when our next maintenance release will be though.  I'm trying to get it done before Christmas, but it may get bumped to New Year due to other projects.

Jason

--
You received this message because you are subscribed to the Google Groups "PHRETS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phrets+un...@googlegroups.com.
To post to this group, send email to phr...@googlegroups.com.
Visit this group at http://groups.google.com/group/phrets.
For more options, visit https://groups.google.com/d/optout.

[jus...@hellomedia.ca]

Ok, Thanks

Is it possible to be notified when the changes is rolled out?

We are releasing a premium plugin Nov. 1 and will need to adjust the code when it changes, since we'll have to use Standard-XML-Encoded until it's fixed unless there is another way to show the data provider.  I am correct that we have to show the data provider on a single listing correct?

Just a heads up that the following are missing from the address payload in the docs as well.

StreetNumber

StreetName

StreetSuffix'

[jus...@hellomedia.ca]

Hi Jason,

I tried looking up the metadata value to put in place as a fix until the mappings are sorted, but am a little confused.

When I get Boards using Standard-XML, the value returned is '13'.

When I get Boards using Standard-XML-Encoded, the value returned is ''London and St. Thomas Association of REALTORS®".

When I do a MetaData lookup an find the value 13 in Boards response I expected the response to the same as the Standard-XML-Encoded response.

But below is what is returned, only the board name itself.

<LookupType>

<MetadataEntryID>13</MetadataEntryID>

<Value>13</Value>

<LongValue>London</LongValue>

<ShortValue>London</ShortValue>

</LookupType>

I'm confused how "London" becomes ''London and St. Thomas Association of REALTORS®", St. Thomas doesn't exist in the Boards metadata when using.

http://data.crea.ca/Metadata.svc/GetMetadata?Type=METADATA-LOOKUP_Type&Format=Standard-XML&ID=Property:Boards

Are we best to just wait for the mappings to be fixed, is there any ETA on the fix or is it in the release you spoke of for late dec possibly new year.

Thanks

Justin

[Jason Graham]

Justin,

As a registered technology provider, you'll get a copy of our release notes describing any changes to the feed a few weeks before the release goes live.  We try to make sure any changes are backwards compatible, but we do this to make sure you have time to make any adjustments that might be necessary in advance.

I've attached a spreadsheet with all of the board IDs and names.  We have both a short and long name for each board, so "London" and "'London and St. Thomas Association of REALTORS" is the same, single board.  Our metadata currently only exposes the short version of the name, so we'll be adjusting that to expose both, since the long version may be better for display purposes..

These fixes would all be included in the next maintenance release, possibly early new year.