[jdev] update on XMPP location (wherein beer is offered)
Stephen Pendleton
pendleto at movsoftware.com
Mon Apr 6 09:57:23 CDT 2009
I can't seem to get this to work. For example I send:
<iq to="butler.buddycloud.com" type="get" xml:lang="en" id="location1">
<locationquery xmlns="urn:xmpp:locationquery:0">
<timestamp>2009-04-05T08:09:56Z</timestamp>
<publish>true</publish>
<reference>
<id>262:07:51520:34124757</id>
<type>cell</type>
<signalstrength>88</signalstrength>
</reference>
</locationquery>
<locationquery xmlns="urn:xmpp:locationquery:0">
<timestamp>2009-04-05T08:09:56Z</timestamp>
<reference>
<id>262:07:51520:34104756</id>
<type>cell</type>
<signalstrength>88</signalstrength>
</reference>
</locationquery>
<locationquery xmlns="urn:xmpp:locationquery:0">
<timestamp>2009-04-05T08:09:56Z</timestamp>
<reference>
<id>262:07:51520:34084753</id>
<type>cell</type>
<signalstrength>88</signalstrength>
</reference>
</locationquery>
</iq>
and I get back the placename OK. I then send the nearby places query and get
an error back:
<iq to="butler.buddycloud.com" type="get" id="nearbyplaces1">
<command xmlns="http://jabber.org/protocol/commands"
node="location">
<x xmlns="jabber:x:data" type="form">
<field type="hidden" var="FORM_TYPE">
<value>buddycloud:location:places_near</value>
</field>
</x>
</command>
</iq>
and get back:
<iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
id="nearbyplaces1" type="error" xml:lang="en-GB">
<command xmlns="http://jabber.org/protocol/commands"
node="location">
<x xmlns="jabber:x:data" type="form">
<field type="hidden" var="FORM_TYPE">
<value>buddycloud:location:places_near</value>
</field>
</x>
</command>
<error code="500" type="wait"><internal-server-error
xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text
xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>
Also, I dont understand the <publish>true</publish> stanza. In the case
where I am sending cellids what is it publishing to my PEP node? Not my
lat/lon right, because you do not have lat/lon mappings from cellids to
lat/long coordinates and I dont have a placename published with that
lat/lon.
Also, if I remove or set the <publish> to <publish>false</publish> I get
back:
iq from="butler.buddycloud.com" to="spendleton at movsoftware.com/spark"
id="location31" type="result"><geoloc
xmlns="http://jabber.org/protocol/geoloc"
xml:lang="en"><accuracy>1000000</accuracy></geoloc></iq>
Not sure what this means.
Thanks
-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Simon Tennant
Sent: 04/01/2009 3:10 PM
To: Jabber/XMPP software development list
Subject: Re: [jdev] update on XMPP location (wherein beer is offered)
Stephen Pendleton wrote:
> I like this a lot. How does the "nearby" query work? Does it returned
> bookmarked places that are owned by the submitting jid, or any
> bookmarked place nearby? What is "cellpatternquality" mean?
A place can have one of two modes.
* Public places are those that can be shared with other people. Eg
my placemark for Starbucks would be useful to others.
* Private places are those that will not be shared with others. For
example my placemark called "Home sweet home" is probably not
useful to others on the network (and/or I want it to be private to
just me and only shared with my friends).
butler.buddycloud.com will only show public in a nearby query. These will be
public places from all users. Additionally you can subscribe to a place
which then places it on your own list of places that you are placed at in
the future.
CellPatternQuality reflects the certainty of the place. How "distinct" it
is. For example when you are driving the location butler will be seeing lots
of new wifi and cell towers. Saving a placemark at that point will save it
but it will be a "blurry" pattern in the database.
Better would be to wait a moment, submit a couple more location queries,
watch for the cellpatternquality to increase to 100% and then send a
placemark save stanza. Then the butler will be far more likely to
accurately place you back at that point in the future.
> Also, how does the component push my location to my PEP node if I am
> on another server? Would this be allowed by XMPP servers? I would be
> interested in seeing these stanzas though to test it out.
Indeed for non-buddycloud.com domains PEP would not work. There are two
solutions for this that we are looking at. Either:
* having the remote non buddycloud node publish their own pep node
after getting a reply to their location query stanza or
* granting publisher rights to butler.buddycloud.com on your own
pubsub geoloc node and passing the address to this node as part of
the location query. The query results would then be published on
your behalf in XEP-0080 (user location) format as well as being
returned to the client.
> There is another application we are working on that involves XEP-0255.
> It currently supports what you are calling "beacon logs" stanzas to
> return back postal addresses. The system uses a combination of wifi
> access points/mobile
> towers to pinpoint your position and return back a lat/lon. It is very
> accurate in a populated area.
The butler does a best effort on the lookup of lat/long too and publishes it
as part of the XEP-0080 stack. I don't think we fill out the post code for
general locations (we do for known places) but this could presumably be
added with access to the right lat/long -> postcode mapping tables. It's
not something that we have spent too much time on. Our main efforts in
butler development have focused on making location something social by
describing it as known places like home or work or "on the road in munich"
(travelling) or "near Jo's house" for example.
S.
--
Simon Tennant
Buddycloud
uk: +44 20 7043 6756 de: +49 89 420 955 854
uk: +44 78 5335 6047 de: +49 17 8545 0880
email and xmpp: simon at buddycloud.com
http://buddycloud.com
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org
_______________________________________________
More information about the JDev
mailing list