On 3 Aug 2008, at 08:45, Philippe Furlan wrote:

> Here is the link:
>
http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=283286021&mt=8

and it rocks!

Easy download and nice integration to other FireEagle apps :-)

Thanks

	 f

• Use Fire Updater to quickly set your location through Mac OS X Dashboard. Automatically update your Adium or iChat status to your location (you'll have to turn that on using the back of the widget).
• Fire Weather keeps track of the local weather wherever you go.
• Checkout the most recent Flickr photos near your location with Fire Photos.

So, was this ever fixed?

We're having major trouble with the 'best guess' returned for any intersections
eg. 57th
and Broadway, NY, NY becomes W 57th St, NY, NY (incomplete address)

Other addresses that break are those common to Brooklyn and Manhattan,
including:

1) 613 11th St, Brooklyn, NY -> 613 W11th St, NY
2) 20 Jay St, Brooklyn, NY -> 20 Jay St, NY
3) 83 Wyckoff St, Brooklyn, NY -> 83 Wyckoff St, NY

Looks like FireEagle/Yahoo somehow drop the borough or something? Not sure what
is
causing intersection geocoding to break, but this pretty much makes FE un-usable
for the
New York area.

Any ideas would be greatly appreciated.

Cheers,
Aditya


--- In fireeagle@yahoogroups.com, nlb0666 <no_reply@...> wrote:
>
> Phil - that sounds reasonable.  Lemme give it a shot and see if
> that'll help us out.
>
> I suppose the remaining problem would be if two alternative services
> were sharing location via fireagle.   Ie your app posted an
> intersection to FireEagle, my app picks it up from FireEagle (and its
> not an intersection any more), then geocodes it to a different place.
>
> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
> >
> > One possible solution here... I think the 'user' method currently
> > returns a timestamp for the update, or for the individual location
> > levels -- you could compare this with your own internal "last moved"
> > time and ignore the update if it's within a minute or so.  How does
> that
> > sound?
> >
> > We're also thinking about putting timestamps on the tokens returned
> from
> > the 'recent' method, so you can do this without even retrieving the
> full
> > location - should make it a bit more convenient to poll FE as you'll be
> > able to just retrieve the new updates.
> >
> > Cheers,
> > Phil
> >
> > nlb0666 wrote:
> > > Phil - its basically option #3.  We're trying not to thrash fireeagle,
> > > so we only talk to fireeagle either a) to retrieve the location, if we
> > > haven't been spoken to by the user in 10 min, or b) to give fireeagle
> > > the location, if the user gave us one.
> > >
> > > So our problem scenario is: we get an intersection from the user, we
> > > give it to fireeagle, the user goes away for more than 10 min, on the
> > > users return we ask fireeagle if they've got an updated location - and
> > > - its different!  So we grab whats returned - essentially a
> > > thoroughfare in OASIS terms, or a lat/lon that may not correspond to
> > > the lat/long our geocoder gave us - and set a new location.
> > >
> > > This interplay results in the user moving around.  If FireEagle either
> > > notified us on an event basis (so we wouldn't have to guess if it was
> > > giving us back the same thing), or kept the "original string", so we
> > > could infer it was the same thing, or returned a "proper"
> > > intersection, that would geocode back to the same place, we'd be in
> > > business.
> > >
> > > Re signup - thanks for the feedback (and any other you might have).
> > > The service works only in certain cities, and we found people
> > > struggled a *lot* with the notion of location (as I'm sure you are
> > > finding!) so we tried to get them to pick a valid supported location
> > > on signup.
> > >
> > > --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
> > >
> > >> Yep, I'm in now, have authorized it with Fire Eagle, and all
> looks good
> > >> so far.
> > >>
> > >> I take it that the reason you want to be able to update with the
> > >> location string FE gives you is for the bookmark function?  Or
> are you
> > >> setting the FE location first, then using that to geocode for
> your map
> > >> display?  Or is the problem that you end up getting the update
> from FE
> > >> 10 mins later, and it looks like a new location, because it's
> different
> > >> from before?  (I'm trying to figure out where the issue lies here).
> > >>
> > >> A note: it would be nice if the account setup process didn't require
> > >>
> > > you
> > >
> > >> to give your gender/age/zip code.  Most people will put in a fake
> age,
> > >> and I'm actually outside the US so I put in the zipcode for
> Brickhouse
> > >> rather than for where I actually am (Christchurch, New Zealand).
> > >>
> > >> Cheers,
> > >> Phil
> > >>
> > >> nlb0666 wrote:
> > >>
> > >>> Phil - tks for taking a look.  Did the email ever make it
> through?  I
> > >>> checked this morning and it didn't look like it did.  I'll hit you
> > >>> with a direct note as well
> > >>>
> > >>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
> > >>>
> > >>>
> > >>>> One thing we could probably do would be to give you back the
> > >>>>
> > > query you
> > >
> > >>>> used to set the location in the first place, as long as the
> user has
> > >>>> given you permission to see their exact location.  This would be a
> > >>>>
> > >>>>
> > >>> hash,
> > >>>
> > >>>
> > >>>> something like {q: 'hurontario and lakesure, mississauga'} or
> > >>>>
> > > {woeid:
> > >
> > >>>> '123456789'} (to use javascript notation), that would put you back
> > >>>>
> > >>>>
> > >>> there
> > >>>
> > >>>
> > >>>> if passed to us.  In some cases we could do this as a string, and
> > >>>>
> > > if it
> > >
> > >>>> was useful we could get FE to parse woeids etc out of strings like
> > >>>> "woeid:123456789", so we could just give you a string...
> > >>>>
> > >>>> Just signed up to liketribe to see what you're actually doing, so
> > >>>>
> > > once
> > >
> > >>>> the e-mail verification msg makes it through my greylist filter,
> > >>>>
> > >>>>
> > >>> I'll be
> > >>>
> > >>>
> > >>>> able to get a better idea of what you need :)
> > >>>>
> > >>>> Cheers,
> > >>>> Phil
> > >>>>
> > >>>> nlb0666 wrote:
> > >>>>
> > >>>>
> > >>>>> Ok we can implement that as a workaround, but it is painful.
> > >>>>>
> > >>>>> Why?  Because fireeagle isn't the only source of location data
> > >>>>>
> > > for our
> > >
> > >>>>> application.  Nor are the fireeagle lat/lon for a given
> address the
> > >>>>> same as our underlying geocoder.   So if we use lat/lon,
> effectively
> > >>>>> the user "slides down the street" as different services reverse
> > >>>>> geocode differently.  If we use the woeid, this is a code
> unique to
> > >>>>> you guys, so we have to do a bunch of work to figure out if the
> > >>>>> address we gave to fireeagle is the same as the text string we had
> > >>>>> (since your returned text string is not the same as we gave
> > >>>>>
> > > you), and
> > >
> > >>>>> then remember, in those cases, to speak special fire eagle
> language.
> > >>>>>
> > >>>>> So this is a fairly large disappointment that for us at least
> really
> > >>>>> increases the amount of work to do "proper" fire eagle
> integration.
> > >>>>> From an app pov, it would be much nicer to remember the string you
> > >>>>> were given and pass it back
> > >>>>>
> > >>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> OK, so looking at the underlying data, our geocoder has
> recognized
> > >>>>>> "Hurontario and Lakeshore, Mississauga" as an intersection and
> > >>>>>>
> > >>>>>>
> > >>> geocoded
> > >>>
> > >>>
> > >>>>>> it correctly, but the data it returns to FireEagle doesn't even
> > >>>>>>
> > >>>>>>
> > >>> mention
> > >>>
> > >>>
> > >>>>>> Lakeshore at all, so what you see on the site or via the API is
> > >>>>>>
> > > just
> > >
> > >>>>>> "Hurontario St".  I'm afraid that's the best we can do for now,
> > >>>>>>
> > > and
> > >
> > >>>>>> you'll have to assume that location names returned from FireEagle
> > >>>>>>
> > >>>>>>
> > >>> won't
> > >>>
> > >>>
> > >>>>>> necessarily geocode correctly if you pass them back in to set
> your
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>> location.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> If you pass the lat/lon coords back into FE (set your
> location to
> > >>>>>> "43.555286407499999, -79.581794738799999") it'll reverse-geocode
> > >>>>>>
> > >>>>>>
> > >>> from
> > >>>
> > >>>
> > >>>>>> there, put you in approximately the right place, and give you
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>> "Lakeshore
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Rd E, Mississauga, Ontario, Canada".  Passing *that* back into FE
> > >>>>>>
> > >>>>>>
> > >>> also
> > >>>
> > >>>
> > >>>>>> puts you at Hurontario and Lakeshore.  I wouldn't count on being
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>> able to
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> do this all the time but it does seem to work here.  (Internally
> > >>>>>>
> > >>>>>>
> > >>> it's
> > >>>
> > >>>
> > >>>>>> geocoding it to L5G, a postcode, which seems to be centered on
> > >>>>>>
> > > that
> > >
> > >>>>>> intersection).
> > >>>>>>
> > >>>>>> In general, if you get a woeid from an API response, setting
> your
> > >>>>>> location to that woeid should always bring you back to the right
> > >>>>>> location, but exact points are trickier.  Probably the most
> > >>>>>>
> > > reliable
> > >
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>> way
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> of getting back to an exact point is passing us the lat/lon
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>> co-ordinates
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> rather than the string we return to you.
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>> Phil
> > >>>>>>
> > >>>>>>
> > >>>>>> nlb0666 wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>> Hey Tom any progress here? As far as I can tell, round tripping
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>> from the app to FireEagle to the app using an intersection as a
> > >>>>> location still screws up and results in the user being "somewhere
> > >>>>> else" at the end.  THe problem appears to be that fireeagle
> does not
> > >>>>> pass back an intersection as the new location, so the new
> input will
> > >>>>> be ambiguous (ie without the cross street).
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>> This should probably work no?
> > >>>>>>>
> > >>>>>>> I tested again this morning using Hurontario and Lakeshore,
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>> Mississauga, per the example below, and it failed.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>> Also... it does appear that intersections can get resolved to
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>> street addresses.  Specifically "38 and Broadway" becomes "38
> > >>>>> Broadway".   I have not pinpointed them precisely, but it appears
> > >>>>> again that passing in a string "38th and Broadway" to
> FireEagle can
> > >>>>> result in a string being returned which, when passed back, will
> > >>>>>
> > > become
> > >
> > >>>>> "38 Broadway".  This is not the only address this occurs for -
> > >>>>>
> > > see the
> > >
> > >>>>> example below.  This one is a particularly bad example as
> "38th and
> > >>>>> Broadway" does not locate correctly from the fireeagle user
> > >>>>>
> > > accessible
> > >
> > >>>>> website at any time.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>> Please advise
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --- Tom Coates wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> It's possible that the data we're using isn't terribly good
> at
> > >>>>>>>> handling intersections. I'll dig into it.
> > >>>>>>>>
> > >>>>>>>> On 19 May 2008, at 06:59, nlb0666 wrote:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> I tested this a little more over the weekend.  It worked well,
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>> but I
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>> did have a problem with intersections.  For example, feeding
> > >>>>>>>>> Hurontario and Lakeshore, Mississauga, Ontario correctly
> locates
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>> you
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>> at that intersection. But Fire Eagle returns the location as
> > >>>>>>>>> Hurontario St, Mississauga, Ontario.   If I enter THAT
> location
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>> into
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>> Fire Eagle, it will put me at Hurontario and Burnamthorpe.
> > >>>>>>>>>
> > >>>>>>>>> So: if I give Fire Eagle the location as an intersection, get
> > >>>>>>>>>
> > >>>>>>>>>
> > >>> the
> > >>>
> > >>>
> > >>>>>>>>> location from Fire Eagle, and then give that string back to
> > >>>>>>>>>
> > > Fire
> > >
> > >>>>>>>>> Eagle, I'll have moved.
> > >>>>>>>>>
> > >>>>>>>>> From an app perspective, it would be nice if giving an
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>> intersection
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>> in resulted in getting an intersection back so that the above
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>> would
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>> work consistently.  If an intersection cannot be returned,
> > >>>>>>>>>
> > >>>>>>>>>
> > >>> then at
> > >>>
> > >>>
> > >>>>>>>>> least a street address "123 hurontario" (or whatever is
> nearest
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>> that
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>> intersection), so that giving the string back to Fire Eagle
> > >>>>>>>>>
> > >>>>>>>>>
> > >>> would
> > >>>
> > >>>
> > >>>>>>>>> maintain my location.  If I'm missing the point here, please
> > >>>>>>>>>
> > >>>>>>>>>
> > >>> advise.
> > >>>
> > >>>
> > >>>>>>>>> I had a problem with another intersection "78th st and 2nd
> ave,
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>> New
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>> York".  I believe at some point my app gave fire eagle, or
> > >>>>>>>>>
> > > fire
> > >
> > >>>>>>>>> eagle gave me, the string "78 and 2nd, New York".   Yahoo
> Maps
> > >>>>>>>>> geocodes this as "78 2nd Avenue", not as "78th and 2nd ave".
> > >>>>>>>>>
> > >   I
> > >
> > >>>>>>>>> will need to look at this more to figure out whether Fire
> > >>>>>>>>>
> > >>>>>>>>>
> > >>> Eagle or
> > >>>
> > >>>
> > >>>>>>>>> we were the culprit.
> > >>>>>>>>>
> > >>>>>>>>> --- snowleo wrote:
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> ooops sorry to reply to myself - just realize you'd asked
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>> invite
> > >>>
> > >>>
> > >>>>>>>>>> requests to be emailed elsewhere, so I'll email you there....
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>> my
> > >>>
> > >>>
> > >>>>>>>>>> reading skills ARE improving :)
> > >>>>>>>>>>
> > >>>>>>>>>> --- snowleo wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>> I've done some initial testing and it looks good!   I'll
> play
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>> more
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>>>> over the next few days and make sure we don't see any
> breaks.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>  But
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>>>> first tests, on both toronto and new york, updating both
> via
> > >>>>>>>>>>> address and via lat lon (which I then removed as we want to
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>> update
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>>>> via address) work!  I found a break with 218 Bowery (this is
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>> Yahoo
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>>>> geocoding incorrectly coding this as W 218th st), but
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>> otherwise,
> > >>>
> > >>>
> > >>>>>>>>>>> so far so good....
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks guys!  Jumping the gun :) now that it looks like
> its
> > >>>>>>>>>>> working for us, I'd love to get more people playing with
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>> FireEagle
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>>>> <-> liketribe (our app)...  Any chance of some more
> invites?
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>> And/
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>>>> or if you guys or anyone else on the board has a chance,
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>> you'll
> > >>>
> > >>>
> > >>>>>>>>>>> find you can update from email, IM, or SMS (or our website
> > >>>>>>>>>>>
> > > of
> > >
> > >>>>>>>>>>> course) using street address, intersection, bookmarked
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>> locations,
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>>>> or venue names at liketribe.com (sign up, make account,
> go to
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>> the
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>>>> bottom of the "my mobile" page and click on FireEagle...
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>> hopefully
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>>>> to discover it all Just Works...)
> > >>>>>>>>>>>
> > >>>>>>>>>>> --- Tom Coates wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Yay. Seth rocks.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> nlb0666 - has this fixed the problem from your perspective?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 14 May 2008, at 19:27, Seth Fitzsimmons wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Hi all.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> This serves to let you know that a new build of Fire Eagle
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>> is
> > >>>
> > >>>
> > >>>>>>>>>>>>> live and
> > >>>>>>>>>>>>> kicking at fireeagle.com.  Nothing new, no API changes,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>> but a
> > >>>
> > >>>
> > >>>>>>>>>>>>> number
> > >>>>>>>>>>>>> of bugs
> > >>>>>>>>>>>>> were squished that were causing some precise locations
> > >>>>>>>>>>>>>
> > > to be
> > >
> > >>>>>>>>>>>>> dropped
> > >>>>>>>>>>>>> (some
> > >>>>>>>>>>>>> locations in NYC, Ontario, etc.).
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On my radar for tomorrow are lat/lons in Singapore and in
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>> the
> > >>>
> > >>>
> > >>>>>>>>>>>>> middle
> > >>>>>>>>>>>>> of the
> > >>>>>>>>>>>>> Pacific as well as a few other things that have come up
> > >>>>>>>>>>>>> internally.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Let me know (via the list) if you're continuing to
> bump into
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>> weird
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>>>>>> geocoding
> > >>>>>>>>>>>>> issues.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> thanks.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> seth
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>
> > >>> ------------------------------------
> > >>>
> > >>> Yahoo! Groups Links
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
>

Thank you for the reply, but I got this problem resolved by creating a
lib folder in the python directory (The place from where the python
mobile interpreter reads the files) on my N95 mobile phone and copying
the oauth.py file in the lib directory.


--- In fireeagle@yahoogroups.com, "Seth Fitzsimmons" <seth@...> wrote:
>
> Hey Samir.
>
> Late, but hopefully still helpful.
>
> (Someone correct me if my Python is wrong.)  For "import oauth" to work,
> oauth.py needs to be in the same directory as the script importing
it.  If
> it's in a subdir (or elsewhere in your PYTHONPATH), you'll need to
do "from
> oauth import oauth".
>
> seth
>
> On Tue, Jun 24, 2008 at 10:28 AM, talkwithsamir <talkwithsamir@...>
> wrote:
>
> >   Hi,
> >
> > I am trying to build and run the example Python App (Python App
> > Walkthrough) from the fireeagle site to run on nokia n95 device. In
> > the steps to be followed to build the app I have to download the
> > 'oauth python library' for building the code.
> >
> > So I downloaded the oauth.py from the site and copied it to my device,
> > to the location where my actual script is placed. When I try to run
> > my python script I get an following error message:
> > "ImportError: No Module named oauth"
> >
> > I get this error for the following line:
> >
> > "import oauth"
> >
> > I am not sure as what else I need to do?? Am I supposed the build the
> > python script?? Please help.
> >
> > Thanks
> > samir
> >
> >
> >
>

Hi,

I am trying to build and run the example Python App (Python App
Walkthrough) from the fireeagle site to run on nokia n95 device.  I
have downloaded the oauth.py file on my nokia phone.  In my python
script when I do "import oauth"  it gives me the following error:

File "e:\python\lin\oauth.py", line 35 return
''.join(str(random.randint(0,9)) for i in range(length))
                  ^
SyntaxError: invalid syntax

Please give me your valuable inputs and help me resolve my problem.

Thanks,
Samir




In
> > the steps to be followed to build the app I have to download the
> > 'oauth python library' for building the code.
> >
> > So I downloaded the oauth.py from the site and copied it to my device,
> > to the location where my actual script is placed. When I try to run
> > my python script I get an following error message:
> > "ImportError: No Module named oauth"
> >
> > I get this error for the following line:
> >
> > "import oauth"
> >
> > I am not sure as what else I need to do?? Am I supposed the build the
> > python script?? Please help.

On Tue, 5 Aug 2008 10:51:06 am talkwithsamir wrote:
> Hi,
>
> I am trying to build and run the example Python App (Python App
> Walkthrough) from the fireeagle site to run on nokia n95 device.  I
> have downloaded the oauth.py file on my nokia phone.  In my python
> script when I do "import oauth"  it gives me the following error:
>
> File "e:\python\lin\oauth.py", line 35 return
> ''.join(str(random.randint(0,9)) for i in range(length))
>                  ^
> SyntaxError: invalid syntax

You need to be using Python 2.4 or later.


      Richard

So, was this ever fixed?
We're having major trouble with the 'best guess' returned for any intersections eg. 57th and Broadway, NY, NY becomes W 57th St, NY, NY (incomplete address)
Other addresses that break are those common to Brooklyn and Manhattan, including:
1) 613 11th St, Brooklyn, NY -> 613 W11th St, NY
2) 20 Jay St, Brooklyn, NY -> 20 Jay St, NY
3) 83 Wyckoff St, Brooklyn, NY -> 83 Wyckoff St, NY
Looks like FireEagle/Yahoo somehow drop the borough or something? Not sure what is causing intersection geocoding to break, but this pretty much makes FE un-usable for the New York area.
Any ideas would be greatly appreciated.
Cheers,
Aditya
--- In fireeagle@yahoogroups.com, nlb0666 <no_reply@...> wrote:

Phil - that sounds reasonable. Lemme give it a shot and see if
that'll help us out.
I suppose the remaining problem would be if two alternative services
were sharing location via fireagle. Ie your app posted an
intersection to FireEagle, my app picks it up from FireEagle (and its
not an intersection any more), then geocodes it to a different place.
--- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:

One possible solution here... I think the 'user' method currently returns a timestamp for the update, or for the individual location levels -- you could compare this with your own internal "last moved" time and ignore the update if it's within a minute or so. How does

that 

sound?
We're also thinking about putting timestamps on the tokens returned

from 

the 'recent' method, so you can do this without even retrieving the

full 

location - should make it a bit more convenient to poll FE as you'll be able to just retrieve the new updates.
Cheers,
Phil
nlb0666 wrote:

Phil - its basically option #3. We're trying not to thrash fireeagle,
so we only talk to fireeagle either a) to retrieve the location, if we
haven't been spoken to by the user in 10 min, or b) to give fireeagle
the location, if the user gave us one.
So our problem scenario is: we get an intersection from the user, we
give it to fireeagle, the user goes away for more than 10 min, on the
users return we ask fireeagle if they've got an updated location - and
- its different! So we grab whats returned - essentially a
thoroughfare in OASIS terms, or a lat/lon that may not correspond to
the lat/long our geocoder gave us - and set a new location. This interplay results in the user moving around. If FireEagle either
notified us on an event basis (so we wouldn't have to guess if it was
giving us back the same thing), or kept the "original string", so we
could infer it was the same thing, or returned a "proper"
intersection, that would geocode back to the same place, we'd be in
business.
Re signup - thanks for the feedback (and any other you might have). The service works only in certain cities, and we found people
struggled a *lot* with the notion of location (as I'm sure you are
finding!) so we tried to get them to pick a valid supported location
on signup. --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:

Yep, I'm in now, have authorized it with Fire Eagle, and all

looks good 

so far.
I take it that the reason you want to be able to update with the location string FE gives you is for the bookmark function? Or

are you 

setting the FE location first, then using that to geocode for

your map 

display? Or is the problem that you end up getting the update

from FE 

10 mins later, and it looks like a new location, because it's

different 

from before? (I'm trying to figure out where the issue lies here).
A note: it would be nice if the account setup process didn't require

you 

to give your gender/age/zip code. Most people will put in a fake

age, 

and I'm actually outside the US so I put in the zipcode for

Brickhouse 

rather than for where I actually am (Christchurch, New Zealand).
Cheers,
Phil
nlb0666 wrote:

Phil - tks for taking a look. Did the email ever make it

through? I

checked this morning and it didn't look like it did. I'll hit you
with a direct note as well
--- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:

One thing we could probably do would be to give you back the

query you 

used to set the location in the first place, as long as the

user has 

given you permission to see their exact location. This would be a

hash, 

something like {q: 'hurontario and lakesure, mississauga'} or

{woeid: 

'123456789'} (to use javascript notation), that would put you back

there 

if passed to us. In some cases we could do this as a string, and

if it 

was useful we could get FE to parse woeids etc out of strings like "woeid:123456789", so we could just give you a string...
Just signed up to liketribe to see what you're actually doing, so

once 

the e-mail verification msg makes it through my greylist filter,

I'll be 

able to get a better idea of what you need :)
Cheers,
Phil
nlb0666 wrote:

Ok we can implement that as a workaround, but it is painful.
Why? Because fireeagle isn't the only source of location data

for our

application. Nor are the fireeagle lat/lon for a given

address the

same as our underlying geocoder. So if we use lat/lon,

effectively

the user "slides down the street" as different services reverse
geocode differently. If we use the woeid, this is a code

unique to

you guys, so we have to do a bunch of work to figure out if the
address we gave to fireeagle is the same as the text string we had
(since your returned text string is not the same as we gave

you), and

then remember, in those cases, to speak special fire eagle

language.

So this is a fairly large disappointment that for us at least

really

increases the amount of work to do "proper" fire eagle

integration. 

From an app pov, it would be much nicer to remember the string you
were given and pass it back
--- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:

OK, so looking at the underlying data, our geocoder has

recognized 

"Hurontario and Lakeshore, Mississauga" as an intersection and

geocoded 

it correctly, but the data it returns to FireEagle doesn't even

mention 

Lakeshore at all, so what you see on the site or via the API is

just 

"Hurontario St". I'm afraid that's the best we can do for now,

and 

you'll have to assume that location names returned from FireEagle

won't 

necessarily geocode correctly if you pass them back in to set

your

location.

If you pass the lat/lon coords back into FE (set your

location to 

"43.555286407499999, -79.581794738799999") it'll reverse-geocode

from 

there, put you in approximately the right place, and give you

"Lakeshore 

Rd E, Mississauga, Ontario, Canada". Passing *that* back into FE

also 

puts you at Hurontario and Lakeshore. I wouldn't count on being

able to 

do this all the time but it does seem to work here. (Internally

it's 

geocoding it to L5G, a postcode, which seems to be centered on

that 

intersection).
In general, if you get a woeid from an API response, setting

your 

location to that woeid should always bring you back to the right location, but exact points are trickier. Probably the most

reliable

way 

of getting back to an exact point is passing us the lat/lon

co-ordinates 

rather than the string we return to you.
Cheers,
Phil
nlb0666 wrote:

Hey Tom any progress here? As far as I can tell, round tripping

from the app to FireEagle to the app using an intersection as a
location still screws up and results in the user being "somewhere
else" at the end. THe problem appears to be that fireeagle

does not

pass back an intersection as the new location, so the new

input will

be ambiguous (ie without the cross street).

This should probably work no?
I tested again this morning using Hurontario and Lakeshore,

Mississauga, per the example below, and it failed.

Also... it does appear that intersections can get resolved to

street addresses. Specifically "38 and Broadway" becomes "38
Broadway". I have not pinpointed them precisely, but it appears
again that passing in a string "38th and Broadway" to

FireEagle can

result in a string being returned which, when passed back, will

become

"38 Broadway". This is not the only address this occurs for -

see the

example below. This one is a particularly bad example as

"38th and

Broadway" does not locate correctly from the fireeagle user

accessible

website at any time.

Please advise
--- Tom Coates wrote:

It's possible that the data we're using isn't terribly good

at 

handling intersections. I'll dig into it.
On 19 May 2008, at 06:59, nlb0666 wrote:

I tested this a little more over the weekend. It worked well,

but I 

did have a problem with intersections. For example, feeding Hurontario and Lakeshore, Mississauga, Ontario correctly

locates

you 

at that intersection. But Fire Eagle returns the location as Hurontario St, Mississauga, Ontario. If I enter THAT

location

into 

Fire Eagle, it will put me at Hurontario and Burnamthorpe.
So: if I give Fire Eagle the location as an intersection, get

the 

location from Fire Eagle, and then give that string back to

Fire 

Eagle, I'll have moved.
From an app perspective, it would be nice if giving an

intersection 

in resulted in getting an intersection back so that the above

would 

work consistently. If an intersection cannot be returned,

then at 

least a street address "123 hurontario" (or whatever is

nearest

that 

intersection), so that giving the string back to Fire Eagle

would 

maintain my location. If I'm missing the point here, please

advise.

I had a problem with another intersection "78th st and 2nd

ave,

New 

York". I believe at some point my app gave fire eagle, or

fire 

eagle gave me, the string "78 and 2nd, New York". Yahoo

Maps 

geocodes this as "78 2nd Avenue", not as "78th and 2nd ave".

 I 

will need to look at this more to figure out whether Fire

Eagle or 

we were the culprit.
--- snowleo wrote:

ooops sorry to reply to myself - just realize you'd asked

invite 

requests to be emailed elsewhere, so I'll email you there....

my 

reading skills ARE improving :)
--- snowleo wrote:

I've done some initial testing and it looks good! I'll

play

more 

over the next few days and make sure we don't see any

breaks.

 But 

first tests, on both toronto and new york, updating both

via 

address and via lat lon (which I then removed as we want to

update 

via address) work! I found a break with 218 Bowery (this is

Yahoo 

geocoding incorrectly coding this as W 218th st), but

otherwise, 

so far so good....
Thanks guys! Jumping the gun :) now that it looks like

its 

working for us, I'd love to get more people playing with

FireEagle 

<-> liketribe (our app)... Any chance of some more

invites? 

And/ 

or if you guys or anyone else on the board has a chance,

you'll 

find you can update from email, IM, or SMS (or our website

of 

course) using street address, intersection, bookmarked

locations, 

or venue names at liketribe.com (sign up, make account,

go to

the 

bottom of the "my mobile" page and click on FireEagle...

hopefully 

to discover it all Just Works...)
--- Tom Coates wrote:

Yay. Seth rocks.
nlb0666 - has this fixed the problem from your perspective?
On 14 May 2008, at 19:27, Seth Fitzsimmons wrote:

Hi all.
This serves to let you know that a new build of Fire Eagle

is 

live and
kicking at fireeagle.com. Nothing new, no API changes,

but a 

number
of bugs
were squished that were causing some precise locations

to be 

dropped
(some
locations in NYC, Ontario, etc.).
On my radar for tomorrow are lat/lons in Singapore and in

the 

middle
of the
Pacific as well as a few other things that have come up internally.
Let me know (via the list) if you're continuing to

bump into

weird

geocoding
issues.
thanks.
seth

------------------------------------
Yahoo! Groups Links

------------------------------------
Yahoo! Groups Links

------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/fireeagle/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/fireeagle/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:fireeagle-digest@yahoogroups.com mailto:fireeagle-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
fireeagle-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Thank you richard for your prompt reply.  But I am using python on my
nokia N95 phone and I have python version 1.4.3 on my phone.  If I
check on the pys60 website
(http://sourceforge.net/project/showfiles.php?group_id=154155) the
latest version available is 1.4.4.  So I believe version 2.4 is for
desktop computers.  So I was wondering what is the right version for
the nokia s60 mobile phones so I can resolve my issue???

Thanks,
Samir

--- In fireeagle@yahoogroups.com, Richard Jones <rjones@...> wrote:
>
> On Tue, 5 Aug 2008 10:51:06 am talkwithsamir wrote:
> > Hi,
> >
> > I am trying to build and run the example Python App (Python App
> > Walkthrough) from the fireeagle site to run on nokia n95 device.  I
> > have downloaded the oauth.py file on my nokia phone.  In my python
> > script when I do "import oauth"  it gives me the following error:
> >
> > File "e:\python\lin\oauth.py", line 35 return
> > ''.join(str(random.randint(0,9)) for i in range(length))
> >                  ^
> > SyntaxError: invalid syntax
>
> You need to be using Python 2.4 or later.
>
>
>      Richard
>

On Tue, 5 Aug 2008 01:23:55 pm talkwithsamir wrote:
> Thank you richard for your prompt reply.  But I am using python on my
> nokia N95 phone and I have python version 1.4.3 on my phone.  If I
> check on the pys60 website
> (http://sourceforge.net/project/showfiles.php?group_id=154155) the
> latest version available is 1.4.4.  So I believe version 2.4 is for
> desktop computers.  So I was wondering what is the right version for
> the nokia s60 mobile phones so I can resolve my issue???

I have no experience with Python on an N95, I'm afraid. I do know that their
version numbering doesn't necessarily correlate with the Python project
itself. I've been told that PyS60 version 1.4.4 is apparently Python version
2.3 ... ish.

I've attached a Python 2.3-compatible (I think) version of oauth.py


     Richard

Some good news... I have got Fire Eagle to recognize intersections.
This'll go out in the next code deploy, along with the New York-specific
change to include the borough in addresses.

The bad news is that our geocoder seems to treat Broadway oddly so "57th
and broadway" will continue to not work quite right.

The "hurontario and lakeshore, mississauga" example that nlb066 brought
up some time back now works nicely.

Experimenting a bit, it looks like it has trouble with things like "42nd
and 5th, nyc" but can cope with things like "42nd st and madison ave,
new york, ny" (which becomes "E 42nd St & Madison Ave, New York, NY")
and "22nd and 5th ave, nyc" (which becomes "W 22nd St & 5th Ave, New
York, NY").  "5th and 42nd, nyc" works, though (it becomes "5th Ave & E
42nd St, New York, NY").

Cheers,
Phil

pherric2000 wrote:
> So, was this ever fixed?
>
> We're having major trouble with the 'best guess' returned for any
intersections eg. 57th
> and Broadway, NY, NY becomes W 57th St, NY, NY (incomplete address)
>
> Other addresses that break are those common to Brooklyn and Manhattan,
including:
>
> 1) 613 11th St, Brooklyn, NY -> 613 W11th St, NY
> 2) 20 Jay St, Brooklyn, NY -> 20 Jay St, NY
> 3) 83 Wyckoff St, Brooklyn, NY -> 83 Wyckoff St, NY
>
> Looks like FireEagle/Yahoo somehow drop the borough or something? Not sure
what is
> causing intersection geocoding to break, but this pretty much makes FE
un-usable for the
> New York area.
>
> Any ideas would be greatly appreciated.
>
> Cheers,
> Aditya
>
>
> --- In fireeagle@yahoogroups.com, nlb0666 <no_reply@...> wrote:
>
>> Phil - that sounds reasonable.  Lemme give it a shot and see if
>> that'll help us out.
>>
>> I suppose the remaining problem would be if two alternative services
>> were sharing location via fireagle.   Ie your app posted an
>> intersection to FireEagle, my app picks it up from FireEagle (and its
>> not an intersection any more), then geocodes it to a different place.
>>
>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>
>>> One possible solution here... I think the 'user' method currently
>>> returns a timestamp for the update, or for the individual location
>>> levels -- you could compare this with your own internal "last moved"
>>> time and ignore the update if it's within a minute or so.  How does
>>>
>> that
>>
>>> sound?
>>>
>>> We're also thinking about putting timestamps on the tokens returned
>>>
>> from
>>
>>> the 'recent' method, so you can do this without even retrieving the
>>>
>> full
>>
>>> location - should make it a bit more convenient to poll FE as you'll be
>>> able to just retrieve the new updates.
>>>
>>> Cheers,
>>> Phil
>>>
>>> nlb0666 wrote:
>>>
>>>> Phil - its basically option #3.  We're trying not to thrash fireeagle,
>>>> so we only talk to fireeagle either a) to retrieve the location, if we
>>>> haven't been spoken to by the user in 10 min, or b) to give fireeagle
>>>> the location, if the user gave us one.
>>>>
>>>> So our problem scenario is: we get an intersection from the user, we
>>>> give it to fireeagle, the user goes away for more than 10 min, on the
>>>> users return we ask fireeagle if they've got an updated location - and
>>>> - its different!  So we grab whats returned - essentially a
>>>> thoroughfare in OASIS terms, or a lat/lon that may not correspond to
>>>> the lat/long our geocoder gave us - and set a new location.
>>>>
>>>> This interplay results in the user moving around.  If FireEagle either
>>>> notified us on an event basis (so we wouldn't have to guess if it was
>>>> giving us back the same thing), or kept the "original string", so we
>>>> could infer it was the same thing, or returned a "proper"
>>>> intersection, that would geocode back to the same place, we'd be in
>>>> business.
>>>>
>>>> Re signup - thanks for the feedback (and any other you might have).
>>>> The service works only in certain cities, and we found people
>>>> struggled a *lot* with the notion of location (as I'm sure you are
>>>> finding!) so we tried to get them to pick a valid supported location
>>>> on signup.
>>>>
>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>
>>>>
>>>>> Yep, I'm in now, have authorized it with Fire Eagle, and all
>>>>>
>> looks good
>>
>>>>> so far.
>>>>>
>>>>> I take it that the reason you want to be able to update with the
>>>>> location string FE gives you is for the bookmark function?  Or
>>>>>
>> are you
>>
>>>>> setting the FE location first, then using that to geocode for
>>>>>
>> your map
>>
>>>>> display?  Or is the problem that you end up getting the update
>>>>>
>> from FE
>>
>>>>> 10 mins later, and it looks like a new location, because it's
>>>>>
>> different
>>
>>>>> from before?  (I'm trying to figure out where the issue lies here).
>>>>>
>>>>> A note: it would be nice if the account setup process didn't require
>>>>>
>>>>>
>>>> you
>>>>
>>>>
>>>>> to give your gender/age/zip code.  Most people will put in a fake
>>>>>
>> age,
>>
>>>>> and I'm actually outside the US so I put in the zipcode for
>>>>>
>> Brickhouse
>>
>>>>> rather than for where I actually am (Christchurch, New Zealand).
>>>>>
>>>>> Cheers,
>>>>> Phil
>>>>>
>>>>> nlb0666 wrote:
>>>>>
>>>>>
>>>>>> Phil - tks for taking a look.  Did the email ever make it
>>>>>>
>> through?  I
>>
>>>>>> checked this morning and it didn't look like it did.  I'll hit you
>>>>>> with a direct note as well
>>>>>>
>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> One thing we could probably do would be to give you back the
>>>>>>>
>>>>>>>
>>>> query you
>>>>
>>>>
>>>>>>> used to set the location in the first place, as long as the
>>>>>>>
>> user has
>>
>>>>>>> given you permission to see their exact location.  This would be a
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> hash,
>>>>>>
>>>>>>
>>>>>>
>>>>>>> something like {q: 'hurontario and lakesure, mississauga'} or
>>>>>>>
>>>>>>>
>>>> {woeid:
>>>>
>>>>
>>>>>>> '123456789'} (to use javascript notation), that would put you back
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> there
>>>>>>
>>>>>>
>>>>>>
>>>>>>> if passed to us.  In some cases we could do this as a string, and
>>>>>>>
>>>>>>>
>>>> if it
>>>>
>>>>
>>>>>>> was useful we could get FE to parse woeids etc out of strings like
>>>>>>> "woeid:123456789", so we could just give you a string...
>>>>>>>
>>>>>>> Just signed up to liketribe to see what you're actually doing, so
>>>>>>>
>>>>>>>
>>>> once
>>>>
>>>>
>>>>>>> the e-mail verification msg makes it through my greylist filter,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I'll be
>>>>>>
>>>>>>
>>>>>>
>>>>>>> able to get a better idea of what you need :)
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Phil
>>>>>>>
>>>>>>> nlb0666 wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Ok we can implement that as a workaround, but it is painful.
>>>>>>>>
>>>>>>>> Why?  Because fireeagle isn't the only source of location data
>>>>>>>>
>>>>>>>>
>>>> for our
>>>>
>>>>
>>>>>>>> application.  Nor are the fireeagle lat/lon for a given
>>>>>>>>
>> address the
>>
>>>>>>>> same as our underlying geocoder.   So if we use lat/lon,
>>>>>>>>
>> effectively
>>
>>>>>>>> the user "slides down the street" as different services reverse
>>>>>>>> geocode differently.  If we use the woeid, this is a code
>>>>>>>>
>> unique to
>>
>>>>>>>> you guys, so we have to do a bunch of work to figure out if the
>>>>>>>> address we gave to fireeagle is the same as the text string we had
>>>>>>>> (since your returned text string is not the same as we gave
>>>>>>>>
>>>>>>>>
>>>> you), and
>>>>
>>>>
>>>>>>>> then remember, in those cases, to speak special fire eagle
>>>>>>>>
>> language.
>>
>>>>>>>> So this is a fairly large disappointment that for us at least
>>>>>>>>
>> really
>>
>>>>>>>> increases the amount of work to do "proper" fire eagle
>>>>>>>>
>> integration.
>>
>>>>>>>> From an app pov, it would be much nicer to remember the string you
>>>>>>>> were given and pass it back
>>>>>>>>
>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> OK, so looking at the underlying data, our geocoder has
>>>>>>>>>
>> recognized
>>
>>>>>>>>> "Hurontario and Lakeshore, Mississauga" as an intersection and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> geocoded
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> it correctly, but the data it returns to FireEagle doesn't even
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> mention
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> Lakeshore at all, so what you see on the site or via the API is
>>>>>>>>>
>>>>>>>>>
>>>> just
>>>>
>>>>
>>>>>>>>> "Hurontario St".  I'm afraid that's the best we can do for now,
>>>>>>>>>
>>>>>>>>>
>>>> and
>>>>
>>>>
>>>>>>>>> you'll have to assume that location names returned from FireEagle
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> won't
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> necessarily geocode correctly if you pass them back in to set
>>>>>>>>>
>> your
>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> location.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> If you pass the lat/lon coords back into FE (set your
>>>>>>>>>
>> location to
>>
>>>>>>>>> "43.555286407499999, -79.581794738799999") it'll reverse-geocode
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> from
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> there, put you in approximately the right place, and give you
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> "Lakeshore
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Rd E, Mississauga, Ontario, Canada".  Passing *that* back into FE
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> also
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> puts you at Hurontario and Lakeshore.  I wouldn't count on being
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> able to
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> do this all the time but it does seem to work here.  (Internally
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> it's
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> geocoding it to L5G, a postcode, which seems to be centered on
>>>>>>>>>
>>>>>>>>>
>>>> that
>>>>
>>>>
>>>>>>>>> intersection).
>>>>>>>>>
>>>>>>>>> In general, if you get a woeid from an API response, setting
>>>>>>>>>
>> your
>>
>>>>>>>>> location to that woeid should always bring you back to the right
>>>>>>>>> location, but exact points are trickier.  Probably the most
>>>>>>>>>
>>>>>>>>>
>>>> reliable
>>>>
>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> way
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> of getting back to an exact point is passing us the lat/lon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> co-ordinates
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> rather than the string we return to you.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> nlb0666 wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hey Tom any progress here? As far as I can tell, round tripping
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> from the app to FireEagle to the app using an intersection as a
>>>>>>>> location still screws up and results in the user being "somewhere
>>>>>>>> else" at the end.  THe problem appears to be that fireeagle
>>>>>>>>
>> does not
>>
>>>>>>>> pass back an intersection as the new location, so the new
>>>>>>>>
>> input will
>>
>>>>>>>> be ambiguous (ie without the cross street).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> This should probably work no?
>>>>>>>>>>
>>>>>>>>>> I tested again this morning using Hurontario and Lakeshore,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> Mississauga, per the example below, and it failed.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Also... it does appear that intersections can get resolved to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> street addresses.  Specifically "38 and Broadway" becomes "38
>>>>>>>> Broadway".   I have not pinpointed them precisely, but it appears
>>>>>>>> again that passing in a string "38th and Broadway" to
>>>>>>>>
>> FireEagle can
>>
>>>>>>>> result in a string being returned which, when passed back, will
>>>>>>>>
>>>>>>>>
>>>> become
>>>>
>>>>
>>>>>>>> "38 Broadway".  This is not the only address this occurs for -
>>>>>>>>
>>>>>>>>
>>>> see the
>>>>
>>>>
>>>>>>>> example below.  This one is a particularly bad example as
>>>>>>>>
>> "38th and
>>
>>>>>>>> Broadway" does not locate correctly from the fireeagle user
>>>>>>>>
>>>>>>>>
>>>> accessible
>>>>
>>>>
>>>>>>>> website at any time.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Please advise
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> It's possible that the data we're using isn't terribly good
>>>>>>>>>>>
>> at
>>
>>>>>>>>>>> handling intersections. I'll dig into it.
>>>>>>>>>>>
>>>>>>>>>>> On 19 May 2008, at 06:59, nlb0666 wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I tested this a little more over the weekend.  It worked well,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> but I
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> did have a problem with intersections.  For example, feeding
>>>>>>>>>>>> Hurontario and Lakeshore, Mississauga, Ontario correctly
>>>>>>>>>>>>
>> locates
>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> you
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> at that intersection. But Fire Eagle returns the location as
>>>>>>>>>>>> Hurontario St, Mississauga, Ontario.   If I enter THAT
>>>>>>>>>>>>
>> location
>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> into
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> Fire Eagle, it will put me at Hurontario and Burnamthorpe.
>>>>>>>>>>>>
>>>>>>>>>>>> So: if I give Fire Eagle the location as an intersection, get
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>> location from Fire Eagle, and then give that string back to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>> Fire
>>>>
>>>>
>>>>>>>>>>>> Eagle, I'll have moved.
>>>>>>>>>>>>
>>>>>>>>>>>> From an app perspective, it would be nice if giving an
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> intersection
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> in resulted in getting an intersection back so that the above
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> would
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> work consistently.  If an intersection cannot be returned,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> then at
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>> least a street address "123 hurontario" (or whatever is
>>>>>>>>>>>>
>> nearest
>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> that
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> intersection), so that giving the string back to Fire Eagle
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> would
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>> maintain my location.  If I'm missing the point here, please
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> advise.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>> I had a problem with another intersection "78th st and 2nd
>>>>>>>>>>>>
>> ave,
>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> New
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> York".  I believe at some point my app gave fire eagle, or
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>> fire
>>>>
>>>>
>>>>>>>>>>>> eagle gave me, the string "78 and 2nd, New York".   Yahoo
>>>>>>>>>>>>
>> Maps
>>
>>>>>>>>>>>> geocodes this as "78 2nd Avenue", not as "78th and 2nd ave".
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>   I
>>>>
>>>>
>>>>>>>>>>>> will need to look at this more to figure out whether Fire
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> Eagle or
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>> we were the culprit.
>>>>>>>>>>>>
>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> ooops sorry to reply to myself - just realize you'd asked
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>> invite
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>> requests to be emailed elsewhere, so I'll email you there....
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>> my
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>> reading skills ARE improving :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've done some initial testing and it looks good!   I'll
>>>>>>>>>>>>>>
>> play
>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> more
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> over the next few days and make sure we don't see any
>>>>>>>>>>>>>>
>> breaks.
>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>  But
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> first tests, on both toronto and new york, updating both
>>>>>>>>>>>>>>
>> via
>>
>>>>>>>>>>>>>> address and via lat lon (which I then removed as we want to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> update
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> via address) work!  I found a break with 218 Bowery (this is
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> Yahoo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> geocoding incorrectly coding this as W 218th st), but
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> otherwise,
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>> so far so good....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks guys!  Jumping the gun :) now that it looks like
>>>>>>>>>>>>>>
>> its
>>
>>>>>>>>>>>>>> working for us, I'd love to get more people playing with
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> FireEagle
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> <-> liketribe (our app)...  Any chance of some more
>>>>>>>>>>>>>>
>> invites?
>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> And/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> or if you guys or anyone else on the board has a chance,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> you'll
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>> find you can update from email, IM, or SMS (or our website
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>> of
>>>>
>>>>
>>>>>>>>>>>>>> course) using street address, intersection, bookmarked
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> locations,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> or venue names at liketribe.com (sign up, make account,
>>>>>>>>>>>>>>
>> go to
>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> bottom of the "my mobile" page and click on FireEagle...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> hopefully
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> to discover it all Just Works...)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yay. Seth rocks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> nlb0666 - has this fixed the problem from your perspective?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 14 May 2008, at 19:27, Seth Fitzsimmons wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi all.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This serves to let you know that a new build of Fire Eagle
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>> is
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>> live and
>>>>>>>>>>>>>>>> kicking at fireeagle.com.  Nothing new, no API changes,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>> but a
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>> of bugs
>>>>>>>>>>>>>>>> were squished that were causing some precise locations
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>> to be
>>>>
>>>>
>>>>>>>>>>>>>>>> dropped
>>>>>>>>>>>>>>>> (some
>>>>>>>>>>>>>>>> locations in NYC, Ontario, etc.).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On my radar for tomorrow are lat/lons in Singapore and in
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>> middle
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> Pacific as well as a few other things that have come up
>>>>>>>>>>>>>>>> internally.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Let me know (via the list) if you're continuing to
>>>>>>>>>>>>>>>>
>> bump into
>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> weird
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> geocoding
>>>>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> seth
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>

Phil,

This is awesome - thank you!

What about the other idea you had to send the actual address that was
passed in back to the person asking for the address? So, if I put 57th
and Broadway, NY, NY into FireEagle and then ask for it back using the
API, the returned data set includes both the geocoded address (W 57th
St, NY, NY) and the address that I passed in (57th and Broadway, NY,
NY) so that our apps can geocode the address ourselves?

Cheers,
Aditya

--
Aditya (http://aditya.sublucid.com/)



On Tue, Aug 5, 2008 at 7:40 AM, Phillip Pearson <pp@...> wrote:
> Some good news... I have got Fire Eagle to recognize intersections.
> This'll go out in the next code deploy, along with the New York-specific
> change to include the borough in addresses.
>
> The bad news is that our geocoder seems to treat Broadway oddly so "57th
> and broadway" will continue to not work quite right.
>
> The "hurontario and lakeshore, mississauga" example that nlb066 brought
> up some time back now works nicely.
>
> Experimenting a bit, it looks like it has trouble with things like "42nd
> and 5th, nyc" but can cope with things like "42nd st and madison ave,
> new york, ny" (which becomes "E 42nd St & Madison Ave, New York, NY")
> and "22nd and 5th ave, nyc" (which becomes "W 22nd St & 5th Ave, New
> York, NY"). "5th and 42nd, nyc" works, though (it becomes "5th Ave & E
> 42nd St, New York, NY").
>
> Cheers,
> Phil
>
> pherric2000 wrote:
>> So, was this ever fixed?
>>
>> We're having major trouble with the 'best guess' returned for any
>> intersections eg. 57th
>> and Broadway, NY, NY becomes W 57th St, NY, NY (incomplete address)
>>
>> Other addresses that break are those common to Brooklyn and Manhattan,
>> including:
>>
>> 1) 613 11th St, Brooklyn, NY -> 613 W11th St, NY
>> 2) 20 Jay St, Brooklyn, NY -> 20 Jay St, NY
>> 3) 83 Wyckoff St, Brooklyn, NY -> 83 Wyckoff St, NY
>>
>> Looks like FireEagle/Yahoo somehow drop the borough or something? Not sure
>> what is
>> causing intersection geocoding to break, but this pretty much makes FE
>> un-usable for the
>> New York area.
>>
>> Any ideas would be greatly appreciated.
>>
>> Cheers,
>> Aditya
>>
>>
>> --- In fireeagle@yahoogroups.com, nlb0666 <no_reply@...> wrote:
>>
>>> Phil - that sounds reasonable. Lemme give it a shot and see if
>>> that'll help us out.
>>>
>>> I suppose the remaining problem would be if two alternative services
>>> were sharing location via fireagle. Ie your app posted an
>>> intersection to FireEagle, my app picks it up from FireEagle (and its
>>> not an intersection any more), then geocodes it to a different place.
>>>
>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>
>>>> One possible solution here... I think the 'user' method currently
>>>> returns a timestamp for the update, or for the individual location
>>>> levels -- you could compare this with your own internal "last moved"
>>>> time and ignore the update if it's within a minute or so. How does
>>>>
>>> that
>>>
>>>> sound?
>>>>
>>>> We're also thinking about putting timestamps on the tokens returned
>>>>
>>> from
>>>
>>>> the 'recent' method, so you can do this without even retrieving the
>>>>
>>> full
>>>
>>>> location - should make it a bit more convenient to poll FE as you'll be
>>>> able to just retrieve the new updates.
>>>>
>>>> Cheers,
>>>> Phil
>>>>
>>>> nlb0666 wrote:
>>>>
>>>>> Phil - its basically option #3. We're trying not to thrash fireeagle,
>>>>> so we only talk to fireeagle either a) to retrieve the location, if we
>>>>> haven't been spoken to by the user in 10 min, or b) to give fireeagle
>>>>> the location, if the user gave us one.
>>>>>
>>>>> So our problem scenario is: we get an intersection from the user, we
>>>>> give it to fireeagle, the user goes away for more than 10 min, on the
>>>>> users return we ask fireeagle if they've got an updated location - and
>>>>> - its different! So we grab whats returned - essentially a
>>>>> thoroughfare in OASIS terms, or a lat/lon that may not correspond to
>>>>> the lat/long our geocoder gave us - and set a new location.
>>>>>
>>>>> This interplay results in the user moving around. If FireEagle either
>>>>> notified us on an event basis (so we wouldn't have to guess if it was
>>>>> giving us back the same thing), or kept the "original string", so we
>>>>> could infer it was the same thing, or returned a "proper"
>>>>> intersection, that would geocode back to the same place, we'd be in
>>>>> business.
>>>>>
>>>>> Re signup - thanks for the feedback (and any other you might have).
>>>>> The service works only in certain cities, and we found people
>>>>> struggled a *lot* with the notion of location (as I'm sure you are
>>>>> finding!) so we tried to get them to pick a valid supported location
>>>>> on signup.
>>>>>
>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>
>>>>>
>>>>>> Yep, I'm in now, have authorized it with Fire Eagle, and all
>>>>>>
>>> looks good
>>>
>>>>>> so far.
>>>>>>
>>>>>> I take it that the reason you want to be able to update with the
>>>>>> location string FE gives you is for the bookmark function? Or
>>>>>>
>>> are you
>>>
>>>>>> setting the FE location first, then using that to geocode for
>>>>>>
>>> your map
>>>
>>>>>> display? Or is the problem that you end up getting the update
>>>>>>
>>> from FE
>>>
>>>>>> 10 mins later, and it looks like a new location, because it's
>>>>>>
>>> different
>>>
>>>>>> from before? (I'm trying to figure out where the issue lies here).
>>>>>>
>>>>>> A note: it would be nice if the account setup process didn't require
>>>>>>
>>>>>>
>>>>> you
>>>>>
>>>>>
>>>>>> to give your gender/age/zip code. Most people will put in a fake
>>>>>>
>>> age,
>>>
>>>>>> and I'm actually outside the US so I put in the zipcode for
>>>>>>
>>> Brickhouse
>>>
>>>>>> rather than for where I actually am (Christchurch, New Zealand).
>>>>>>
>>>>>> Cheers,
>>>>>> Phil
>>>>>>
>>>>>> nlb0666 wrote:
>>>>>>
>>>>>>
>>>>>>> Phil - tks for taking a look. Did the email ever make it
>>>>>>>
>>> through? I
>>>
>>>>>>> checked this morning and it didn't look like it did. I'll hit you
>>>>>>> with a direct note as well
>>>>>>>
>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> One thing we could probably do would be to give you back the
>>>>>>>>
>>>>>>>>
>>>>> query you
>>>>>
>>>>>
>>>>>>>> used to set the location in the first place, as long as the
>>>>>>>>
>>> user has
>>>
>>>>>>>> given you permission to see their exact location. This would be a
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> hash,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> something like {q: 'hurontario and lakesure, mississauga'} or
>>>>>>>>
>>>>>>>>
>>>>> {woeid:
>>>>>
>>>>>
>>>>>>>> '123456789'} (to use javascript notation), that would put you back
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> there
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> if passed to us. In some cases we could do this as a string, and
>>>>>>>>
>>>>>>>>
>>>>> if it
>>>>>
>>>>>
>>>>>>>> was useful we could get FE to parse woeids etc out of strings like
>>>>>>>> "woeid:123456789", so we could just give you a string...
>>>>>>>>
>>>>>>>> Just signed up to liketribe to see what you're actually doing, so
>>>>>>>>
>>>>>>>>
>>>>> once
>>>>>
>>>>>
>>>>>>>> the e-mail verification msg makes it through my greylist filter,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> I'll be
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> able to get a better idea of what you need :)
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> nlb0666 wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Ok we can implement that as a workaround, but it is painful.
>>>>>>>>>
>>>>>>>>> Why? Because fireeagle isn't the only source of location data
>>>>>>>>>
>>>>>>>>>
>>>>> for our
>>>>>
>>>>>
>>>>>>>>> application. Nor are the fireeagle lat/lon for a given
>>>>>>>>>
>>> address the
>>>
>>>>>>>>> same as our underlying geocoder. So if we use lat/lon,
>>>>>>>>>
>>> effectively
>>>
>>>>>>>>> the user "slides down the street" as different services reverse
>>>>>>>>> geocode differently. If we use the woeid, this is a code
>>>>>>>>>
>>> unique to
>>>
>>>>>>>>> you guys, so we have to do a bunch of work to figure out if the
>>>>>>>>> address we gave to fireeagle is the same as the text string we had
>>>>>>>>> (since your returned text string is not the same as we gave
>>>>>>>>>
>>>>>>>>>
>>>>> you), and
>>>>>
>>>>>
>>>>>>>>> then remember, in those cases, to speak special fire eagle
>>>>>>>>>
>>> language.
>>>
>>>>>>>>> So this is a fairly large disappointment that for us at least
>>>>>>>>>
>>> really
>>>
>>>>>>>>> increases the amount of work to do "proper" fire eagle
>>>>>>>>>
>>> integration.
>>>
>>>>>>>>> From an app pov, it would be much nicer to remember the string you
>>>>>>>>> were given and pass it back
>>>>>>>>>
>>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> OK, so looking at the underlying data, our geocoder has
>>>>>>>>>>
>>> recognized
>>>
>>>>>>>>>> "Hurontario and Lakeshore, Mississauga" as an intersection and
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> geocoded
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> it correctly, but the data it returns to FireEagle doesn't even
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> mention
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> Lakeshore at all, so what you see on the site or via the API is
>>>>>>>>>>
>>>>>>>>>>
>>>>> just
>>>>>
>>>>>
>>>>>>>>>> "Hurontario St". I'm afraid that's the best we can do for now,
>>>>>>>>>>
>>>>>>>>>>
>>>>> and
>>>>>
>>>>>
>>>>>>>>>> you'll have to assume that location names returned from FireEagle
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> won't
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> necessarily geocode correctly if you pass them back in to set
>>>>>>>>>>
>>> your
>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> location.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> If you pass the lat/lon coords back into FE (set your
>>>>>>>>>>
>>> location to
>>>
>>>>>>>>>> "43.555286407499999, -79.581794738799999") it'll reverse-geocode
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> from
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> there, put you in approximately the right place, and give you
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> "Lakeshore
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Rd E, Mississauga, Ontario, Canada". Passing *that* back into FE
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> also
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> puts you at Hurontario and Lakeshore. I wouldn't count on being
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> able to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> do this all the time but it does seem to work here. (Internally
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> it's
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> geocoding it to L5G, a postcode, which seems to be centered on
>>>>>>>>>>
>>>>>>>>>>
>>>>> that
>>>>>
>>>>>
>>>>>>>>>> intersection).
>>>>>>>>>>
>>>>>>>>>> In general, if you get a woeid from an API response, setting
>>>>>>>>>>
>>> your
>>>
>>>>>>>>>> location to that woeid should always bring you back to the right
>>>>>>>>>> location, but exact points are trickier. Probably the most
>>>>>>>>>>
>>>>>>>>>>
>>>>> reliable
>>>>>
>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> way
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> of getting back to an exact point is passing us the lat/lon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> co-ordinates
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> rather than the string we return to you.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> nlb0666 wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hey Tom any progress here? As far as I can tell, round tripping
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> from the app to FireEagle to the app using an intersection as a
>>>>>>>>> location still screws up and results in the user being "somewhere
>>>>>>>>> else" at the end. THe problem appears to be that fireeagle
>>>>>>>>>
>>> does not
>>>
>>>>>>>>> pass back an intersection as the new location, so the new
>>>>>>>>>
>>> input will
>>>
>>>>>>>>> be ambiguous (ie without the cross street).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> This should probably work no?
>>>>>>>>>>>
>>>>>>>>>>> I tested again this morning using Hurontario and Lakeshore,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> Mississauga, per the example below, and it failed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Also... it does appear that intersections can get resolved to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> street addresses. Specifically "38 and Broadway" becomes "38
>>>>>>>>> Broadway". I have not pinpointed them precisely, but it appears
>>>>>>>>> again that passing in a string "38th and Broadway" to
>>>>>>>>>
>>> FireEagle can
>>>
>>>>>>>>> result in a string being returned which, when passed back, will
>>>>>>>>>
>>>>>>>>>
>>>>> become
>>>>>
>>>>>
>>>>>>>>> "38 Broadway". This is not the only address this occurs for -
>>>>>>>>>
>>>>>>>>>
>>>>> see the
>>>>>
>>>>>
>>>>>>>>> example below. This one is a particularly bad example as
>>>>>>>>>
>>> "38th and
>>>
>>>>>>>>> Broadway" does not locate correctly from the fireeagle user
>>>>>>>>>
>>>>>>>>>
>>>>> accessible
>>>>>
>>>>>
>>>>>>>>> website at any time.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Please advise
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> It's possible that the data we're using isn't terribly good
>>>>>>>>>>>>
>>> at
>>>
>>>>>>>>>>>> handling intersections. I'll dig into it.
>>>>>>>>>>>>
>>>>>>>>>>>> On 19 May 2008, at 06:59, nlb0666 wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> I tested this a little more over the weekend. It worked well,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> but I
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> did have a problem with intersections. For example, feeding
>>>>>>>>>>>>> Hurontario and Lakeshore, Mississauga, Ontario correctly
>>>>>>>>>>>>>
>>> locates
>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> you
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> at that intersection. But Fire Eagle returns the location as
>>>>>>>>>>>>> Hurontario St, Mississauga, Ontario. If I enter THAT
>>>>>>>>>>>>>
>>> location
>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> into
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> Fire Eagle, it will put me at Hurontario and Burnamthorpe.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So: if I give Fire Eagle the location as an intersection, get
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> location from Fire Eagle, and then give that string back to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> Fire
>>>>>
>>>>>
>>>>>>>>>>>>> Eagle, I'll have moved.
>>>>>>>>>>>>>
>>>>>>>>>>>>> From an app perspective, it would be nice if giving an
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> intersection
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> in resulted in getting an intersection back so that the above
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> would
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> work consistently. If an intersection cannot be returned,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> then at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> least a street address "123 hurontario" (or whatever is
>>>>>>>>>>>>>
>>> nearest
>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> intersection), so that giving the string back to Fire Eagle
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> would
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> maintain my location. If I'm missing the point here, please
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> advise.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> I had a problem with another intersection "78th st and 2nd
>>>>>>>>>>>>>
>>> ave,
>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> New
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> York". I believe at some point my app gave fire eagle, or
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> fire
>>>>>
>>>>>
>>>>>>>>>>>>> eagle gave me, the string "78 and 2nd, New York". Yahoo
>>>>>>>>>>>>>
>>> Maps
>>>
>>>>>>>>>>>>> geocodes this as "78 2nd Avenue", not as "78th and 2nd ave".
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> I
>>>>>
>>>>>
>>>>>>>>>>>>> will need to look at this more to figure out whether Fire
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> Eagle or
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> we were the culprit.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> ooops sorry to reply to myself - just realize you'd asked
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>> invite
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> requests to be emailed elsewhere, so I'll email you there....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>> my
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> reading skills ARE improving :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've done some initial testing and it looks good! I'll
>>>>>>>>>>>>>>>
>>> play
>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> more
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> over the next few days and make sure we don't see any
>>>>>>>>>>>>>>>
>>> breaks.
>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> But
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> first tests, on both toronto and new york, updating both
>>>>>>>>>>>>>>>
>>> via
>>>
>>>>>>>>>>>>>>> address and via lat lon (which I then removed as we want to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> update
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> via address) work! I found a break with 218 Bowery (this is
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> Yahoo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> geocoding incorrectly coding this as W 218th st), but
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>> otherwise,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> so far so good....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks guys! Jumping the gun :) now that it looks like
>>>>>>>>>>>>>>>
>>> its
>>>
>>>>>>>>>>>>>>> working for us, I'd love to get more people playing with
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> FireEagle
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> <-> liketribe (our app)... Any chance of some more
>>>>>>>>>>>>>>>
>>> invites?
>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> And/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> or if you guys or anyone else on the board has a chance,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>> you'll
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> find you can update from email, IM, or SMS (or our website
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> of
>>>>>
>>>>>
>>>>>>>>>>>>>>> course) using street address, intersection, bookmarked
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> locations,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> or venue names at liketribe.com (sign up, make account,
>>>>>>>>>>>>>>>
>>> go to
>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> bottom of the "my mobile" page and click on FireEagle...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> hopefully
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> to discover it all Just Works...)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yay. Seth rocks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> nlb0666 - has this fixed the problem from your perspective?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 14 May 2008, at 19:27, Seth Fitzsimmons wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi all.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This serves to let you know that a new build of Fire Eagle
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>> is
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> live and
>>>>>>>>>>>>>>>>> kicking at fireeagle.com. Nothing new, no API changes,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>> but a
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>> of bugs
>>>>>>>>>>>>>>>>> were squished that were causing some precise locations
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> to be
>>>>>
>>>>>
>>>>>>>>>>>>>>>>> dropped
>>>>>>>>>>>>>>>>> (some
>>>>>>>>>>>>>>>>> locations in NYC, Ontario, etc.).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On my radar for tomorrow are lat/lons in Singapore and in
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> middle
>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>> Pacific as well as a few other things that have come up
>>>>>>>>>>>>>>>>> internally.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Let me know (via the list) if you're continuing to
>>>>>>>>>>>>>>>>>
>>> bump into
>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>> weird
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>> geocoding
>>>>>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> seth
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>
>

Also, when will the next deploy be?

Cheers,
Aditya

--
Aditya (http://aditya.sublucid.com/)



On Tue, Aug 5, 2008 at 10:22 AM, Aditya Chadha <aditya@...> wrote:
> Phil,
>
> This is awesome - thank you!
>
> What about the other idea you had to send the actual address that was
> passed in back to the person asking for the address? So, if I put 57th
> and Broadway, NY, NY into FireEagle and then ask for it back using the
> API, the returned data set includes both the geocoded address (W 57th
> St, NY, NY) and the address that I passed in (57th and Broadway, NY,
> NY) so that our apps can geocode the address ourselves?
>
> Cheers,
> Aditya
>
> --
> Aditya (http://aditya.sublucid.com/)
>
>
>
> On Tue, Aug 5, 2008 at 7:40 AM, Phillip Pearson <pp@...> wrote:
>> Some good news... I have got Fire Eagle to recognize intersections.
>> This'll go out in the next code deploy, along with the New York-specific
>> change to include the borough in addresses.
>>
>> The bad news is that our geocoder seems to treat Broadway oddly so "57th
>> and broadway" will continue to not work quite right.
>>
>> The "hurontario and lakeshore, mississauga" example that nlb066 brought
>> up some time back now works nicely.
>>
>> Experimenting a bit, it looks like it has trouble with things like "42nd
>> and 5th, nyc" but can cope with things like "42nd st and madison ave,
>> new york, ny" (which becomes "E 42nd St & Madison Ave, New York, NY")
>> and "22nd and 5th ave, nyc" (which becomes "W 22nd St & 5th Ave, New
>> York, NY"). "5th and 42nd, nyc" works, though (it becomes "5th Ave & E
>> 42nd St, New York, NY").
>>
>> Cheers,
>> Phil
>>
>> pherric2000 wrote:
>>> So, was this ever fixed?
>>>
>>> We're having major trouble with the 'best guess' returned for any
>>> intersections eg. 57th
>>> and Broadway, NY, NY becomes W 57th St, NY, NY (incomplete address)
>>>
>>> Other addresses that break are those common to Brooklyn and Manhattan,
>>> including:
>>>
>>> 1) 613 11th St, Brooklyn, NY -> 613 W11th St, NY
>>> 2) 20 Jay St, Brooklyn, NY -> 20 Jay St, NY
>>> 3) 83 Wyckoff St, Brooklyn, NY -> 83 Wyckoff St, NY
>>>
>>> Looks like FireEagle/Yahoo somehow drop the borough or something? Not sure
>>> what is
>>> causing intersection geocoding to break, but this pretty much makes FE
>>> un-usable for the
>>> New York area.
>>>
>>> Any ideas would be greatly appreciated.
>>>
>>> Cheers,
>>> Aditya
>>>
>>>
>>> --- In fireeagle@yahoogroups.com, nlb0666 <no_reply@...> wrote:
>>>
>>>> Phil - that sounds reasonable. Lemme give it a shot and see if
>>>> that'll help us out.
>>>>
>>>> I suppose the remaining problem would be if two alternative services
>>>> were sharing location via fireagle. Ie your app posted an
>>>> intersection to FireEagle, my app picks it up from FireEagle (and its
>>>> not an intersection any more), then geocodes it to a different place.
>>>>
>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>
>>>>> One possible solution here... I think the 'user' method currently
>>>>> returns a timestamp for the update, or for the individual location
>>>>> levels -- you could compare this with your own internal "last moved"
>>>>> time and ignore the update if it's within a minute or so. How does
>>>>>
>>>> that
>>>>
>>>>> sound?
>>>>>
>>>>> We're also thinking about putting timestamps on the tokens returned
>>>>>
>>>> from
>>>>
>>>>> the 'recent' method, so you can do this without even retrieving the
>>>>>
>>>> full
>>>>
>>>>> location - should make it a bit more convenient to poll FE as you'll be
>>>>> able to just retrieve the new updates.
>>>>>
>>>>> Cheers,
>>>>> Phil
>>>>>
>>>>> nlb0666 wrote:
>>>>>
>>>>>> Phil - its basically option #3. We're trying not to thrash fireeagle,
>>>>>> so we only talk to fireeagle either a) to retrieve the location, if we
>>>>>> haven't been spoken to by the user in 10 min, or b) to give fireeagle
>>>>>> the location, if the user gave us one.
>>>>>>
>>>>>> So our problem scenario is: we get an intersection from the user, we
>>>>>> give it to fireeagle, the user goes away for more than 10 min, on the
>>>>>> users return we ask fireeagle if they've got an updated location - and
>>>>>> - its different! So we grab whats returned - essentially a
>>>>>> thoroughfare in OASIS terms, or a lat/lon that may not correspond to
>>>>>> the lat/long our geocoder gave us - and set a new location.
>>>>>>
>>>>>> This interplay results in the user moving around. If FireEagle either
>>>>>> notified us on an event basis (so we wouldn't have to guess if it was
>>>>>> giving us back the same thing), or kept the "original string", so we
>>>>>> could infer it was the same thing, or returned a "proper"
>>>>>> intersection, that would geocode back to the same place, we'd be in
>>>>>> business.
>>>>>>
>>>>>> Re signup - thanks for the feedback (and any other you might have).
>>>>>> The service works only in certain cities, and we found people
>>>>>> struggled a *lot* with the notion of location (as I'm sure you are
>>>>>> finding!) so we tried to get them to pick a valid supported location
>>>>>> on signup.
>>>>>>
>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>
>>>>>>
>>>>>>> Yep, I'm in now, have authorized it with Fire Eagle, and all
>>>>>>>
>>>> looks good
>>>>
>>>>>>> so far.
>>>>>>>
>>>>>>> I take it that the reason you want to be able to update with the
>>>>>>> location string FE gives you is for the bookmark function? Or
>>>>>>>
>>>> are you
>>>>
>>>>>>> setting the FE location first, then using that to geocode for
>>>>>>>
>>>> your map
>>>>
>>>>>>> display? Or is the problem that you end up getting the update
>>>>>>>
>>>> from FE
>>>>
>>>>>>> 10 mins later, and it looks like a new location, because it's
>>>>>>>
>>>> different
>>>>
>>>>>>> from before? (I'm trying to figure out where the issue lies here).
>>>>>>>
>>>>>>> A note: it would be nice if the account setup process didn't require
>>>>>>>
>>>>>>>
>>>>>> you
>>>>>>
>>>>>>
>>>>>>> to give your gender/age/zip code. Most people will put in a fake
>>>>>>>
>>>> age,
>>>>
>>>>>>> and I'm actually outside the US so I put in the zipcode for
>>>>>>>
>>>> Brickhouse
>>>>
>>>>>>> rather than for where I actually am (Christchurch, New Zealand).
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Phil
>>>>>>>
>>>>>>> nlb0666 wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Phil - tks for taking a look. Did the email ever make it
>>>>>>>>
>>>> through? I
>>>>
>>>>>>>> checked this morning and it didn't look like it did. I'll hit you
>>>>>>>> with a direct note as well
>>>>>>>>
>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> One thing we could probably do would be to give you back the
>>>>>>>>>
>>>>>>>>>
>>>>>> query you
>>>>>>
>>>>>>
>>>>>>>>> used to set the location in the first place, as long as the
>>>>>>>>>
>>>> user has
>>>>
>>>>>>>>> given you permission to see their exact location. This would be a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> hash,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> something like {q: 'hurontario and lakesure, mississauga'} or
>>>>>>>>>
>>>>>>>>>
>>>>>> {woeid:
>>>>>>
>>>>>>
>>>>>>>>> '123456789'} (to use javascript notation), that would put you back
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> there
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> if passed to us. In some cases we could do this as a string, and
>>>>>>>>>
>>>>>>>>>
>>>>>> if it
>>>>>>
>>>>>>
>>>>>>>>> was useful we could get FE to parse woeids etc out of strings like
>>>>>>>>> "woeid:123456789", so we could just give you a string...
>>>>>>>>>
>>>>>>>>> Just signed up to liketribe to see what you're actually doing, so
>>>>>>>>>
>>>>>>>>>
>>>>>> once
>>>>>>
>>>>>>
>>>>>>>>> the e-mail verification msg makes it through my greylist filter,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I'll be
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> able to get a better idea of what you need :)
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> nlb0666 wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Ok we can implement that as a workaround, but it is painful.
>>>>>>>>>>
>>>>>>>>>> Why? Because fireeagle isn't the only source of location data
>>>>>>>>>>
>>>>>>>>>>
>>>>>> for our
>>>>>>
>>>>>>
>>>>>>>>>> application. Nor are the fireeagle lat/lon for a given
>>>>>>>>>>
>>>> address the
>>>>
>>>>>>>>>> same as our underlying geocoder. So if we use lat/lon,
>>>>>>>>>>
>>>> effectively
>>>>
>>>>>>>>>> the user "slides down the street" as different services reverse
>>>>>>>>>> geocode differently. If we use the woeid, this is a code
>>>>>>>>>>
>>>> unique to
>>>>
>>>>>>>>>> you guys, so we have to do a bunch of work to figure out if the
>>>>>>>>>> address we gave to fireeagle is the same as the text string we had
>>>>>>>>>> (since your returned text string is not the same as we gave
>>>>>>>>>>
>>>>>>>>>>
>>>>>> you), and
>>>>>>
>>>>>>
>>>>>>>>>> then remember, in those cases, to speak special fire eagle
>>>>>>>>>>
>>>> language.
>>>>
>>>>>>>>>> So this is a fairly large disappointment that for us at least
>>>>>>>>>>
>>>> really
>>>>
>>>>>>>>>> increases the amount of work to do "proper" fire eagle
>>>>>>>>>>
>>>> integration.
>>>>
>>>>>>>>>> From an app pov, it would be much nicer to remember the string you
>>>>>>>>>> were given and pass it back
>>>>>>>>>>
>>>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> OK, so looking at the underlying data, our geocoder has
>>>>>>>>>>>
>>>> recognized
>>>>
>>>>>>>>>>> "Hurontario and Lakeshore, Mississauga" as an intersection and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> geocoded
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> it correctly, but the data it returns to FireEagle doesn't even
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> mention
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> Lakeshore at all, so what you see on the site or via the API is
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> just
>>>>>>
>>>>>>
>>>>>>>>>>> "Hurontario St". I'm afraid that's the best we can do for now,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> and
>>>>>>
>>>>>>
>>>>>>>>>>> you'll have to assume that location names returned from FireEagle
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> won't
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> necessarily geocode correctly if you pass them back in to set
>>>>>>>>>>>
>>>> your
>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> location.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> If you pass the lat/lon coords back into FE (set your
>>>>>>>>>>>
>>>> location to
>>>>
>>>>>>>>>>> "43.555286407499999, -79.581794738799999") it'll reverse-geocode
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> from
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> there, put you in approximately the right place, and give you
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> "Lakeshore
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Rd E, Mississauga, Ontario, Canada". Passing *that* back into FE
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> also
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> puts you at Hurontario and Lakeshore. I wouldn't count on being
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> able to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> do this all the time but it does seem to work here. (Internally
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> it's
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> geocoding it to L5G, a postcode, which seems to be centered on
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> that
>>>>>>
>>>>>>
>>>>>>>>>>> intersection).
>>>>>>>>>>>
>>>>>>>>>>> In general, if you get a woeid from an API response, setting
>>>>>>>>>>>
>>>> your
>>>>
>>>>>>>>>>> location to that woeid should always bring you back to the right
>>>>>>>>>>> location, but exact points are trickier. Probably the most
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> reliable
>>>>>>
>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> way
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> of getting back to an exact point is passing us the lat/lon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> co-ordinates
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> rather than the string we return to you.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> nlb0666 wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hey Tom any progress here? As far as I can tell, round tripping
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> from the app to FireEagle to the app using an intersection as a
>>>>>>>>>> location still screws up and results in the user being "somewhere
>>>>>>>>>> else" at the end. THe problem appears to be that fireeagle
>>>>>>>>>>
>>>> does not
>>>>
>>>>>>>>>> pass back an intersection as the new location, so the new
>>>>>>>>>>
>>>> input will
>>>>
>>>>>>>>>> be ambiguous (ie without the cross street).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> This should probably work no?
>>>>>>>>>>>>
>>>>>>>>>>>> I tested again this morning using Hurontario and Lakeshore,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> Mississauga, per the example below, and it failed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Also... it does appear that intersections can get resolved to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> street addresses. Specifically "38 and Broadway" becomes "38
>>>>>>>>>> Broadway". I have not pinpointed them precisely, but it appears
>>>>>>>>>> again that passing in a string "38th and Broadway" to
>>>>>>>>>>
>>>> FireEagle can
>>>>
>>>>>>>>>> result in a string being returned which, when passed back, will
>>>>>>>>>>
>>>>>>>>>>
>>>>>> become
>>>>>>
>>>>>>
>>>>>>>>>> "38 Broadway". This is not the only address this occurs for -
>>>>>>>>>>
>>>>>>>>>>
>>>>>> see the
>>>>>>
>>>>>>
>>>>>>>>>> example below. This one is a particularly bad example as
>>>>>>>>>>
>>>> "38th and
>>>>
>>>>>>>>>> Broadway" does not locate correctly from the fireeagle user
>>>>>>>>>>
>>>>>>>>>>
>>>>>> accessible
>>>>>>
>>>>>>
>>>>>>>>>> website at any time.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Please advise
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> It's possible that the data we're using isn't terribly good
>>>>>>>>>>>>>
>>>> at
>>>>
>>>>>>>>>>>>> handling intersections. I'll dig into it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 19 May 2008, at 06:59, nlb0666 wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tested this a little more over the weekend. It worked well,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> but I
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> did have a problem with intersections. For example, feeding
>>>>>>>>>>>>>> Hurontario and Lakeshore, Mississauga, Ontario correctly
>>>>>>>>>>>>>>
>>>> locates
>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> you
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> at that intersection. But Fire Eagle returns the location as
>>>>>>>>>>>>>> Hurontario St, Mississauga, Ontario. If I enter THAT
>>>>>>>>>>>>>>
>>>> location
>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> into
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> Fire Eagle, it will put me at Hurontario and Burnamthorpe.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So: if I give Fire Eagle the location as an intersection, get
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> location from Fire Eagle, and then give that string back to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> Fire
>>>>>>
>>>>>>
>>>>>>>>>>>>>> Eagle, I'll have moved.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From an app perspective, it would be nice if giving an
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> intersection
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> in resulted in getting an intersection back so that the above
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> would
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> work consistently. If an intersection cannot be returned,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> then at
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> least a street address "123 hurontario" (or whatever is
>>>>>>>>>>>>>>
>>>> nearest
>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> intersection), so that giving the string back to Fire Eagle
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> would
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> maintain my location. If I'm missing the point here, please
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> advise.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> I had a problem with another intersection "78th st and 2nd
>>>>>>>>>>>>>>
>>>> ave,
>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> New
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> York". I believe at some point my app gave fire eagle, or
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> fire
>>>>>>
>>>>>>
>>>>>>>>>>>>>> eagle gave me, the string "78 and 2nd, New York". Yahoo
>>>>>>>>>>>>>>
>>>> Maps
>>>>
>>>>>>>>>>>>>> geocodes this as "78 2nd Avenue", not as "78th and 2nd ave".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> I
>>>>>>
>>>>>>
>>>>>>>>>>>>>> will need to look at this more to figure out whether Fire
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> Eagle or
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> we were the culprit.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ooops sorry to reply to myself - just realize you'd asked
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>> invite
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>> requests to be emailed elsewhere, so I'll email you there....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>> my
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>> reading skills ARE improving :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've done some initial testing and it looks good! I'll
>>>>>>>>>>>>>>>>
>>>> play
>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> more
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> over the next few days and make sure we don't see any
>>>>>>>>>>>>>>>>
>>>> breaks.
>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> But
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> first tests, on both toronto and new york, updating both
>>>>>>>>>>>>>>>>
>>>> via
>>>>
>>>>>>>>>>>>>>>> address and via lat lon (which I then removed as we want to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> update
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> via address) work! I found a break with 218 Bowery (this is
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> Yahoo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> geocoding incorrectly coding this as W 218th st), but
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> otherwise,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> so far so good....
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks guys! Jumping the gun :) now that it looks like
>>>>>>>>>>>>>>>>
>>>> its
>>>>
>>>>>>>>>>>>>>>> working for us, I'd love to get more people playing with
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> FireEagle
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> <-> liketribe (our app)... Any chance of some more
>>>>>>>>>>>>>>>>
>>>> invites?
>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> And/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> or if you guys or anyone else on the board has a chance,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> you'll
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> find you can update from email, IM, or SMS (or our website
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>> of
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>> course) using street address, intersection, bookmarked
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> locations,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> or venue names at liketribe.com (sign up, make account,
>>>>>>>>>>>>>>>>
>>>> go to
>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> bottom of the "my mobile" page and click on FireEagle...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> hopefully
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> to discover it all Just Works...)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yay. Seth rocks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> nlb0666 - has this fixed the problem from your perspective?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 14 May 2008, at 19:27, Seth Fitzsimmons wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi all.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This serves to let you know that a new build of Fire Eagle
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>> is
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>> live and
>>>>>>>>>>>>>>>>>> kicking at fireeagle.com. Nothing new, no API changes,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>> but a
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>> of bugs
>>>>>>>>>>>>>>>>>> were squished that were causing some precise locations
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>> to be
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>> dropped
>>>>>>>>>>>>>>>>>> (some
>>>>>>>>>>>>>>>>>> locations in NYC, Ontario, etc.).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On my radar for tomorrow are lat/lons in Singapore and in
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>> middle
>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>> Pacific as well as a few other things that have come up
>>>>>>>>>>>>>>>>>> internally.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Let me know (via the list) if you're continuing to
>>>>>>>>>>>>>>>>>>
>>>> bump into
>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>> weird
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>> geocoding
>>>>>>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> seth
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>
>>
>

Richard,

I am not able to download the attachment you have uploaded, it
specifies that the attachment is not stored. Could you please reattach
the attachment or send me a URL pointer from where I can download the
older version of oauth.py.

Thanks a lot,
samir
--- In fireeagle@yahoogroups.com, Richard Jones <rjones@...> wrote:
>
> On Tue, 5 Aug 2008 01:23:55 pm talkwithsamir wrote:
> > Thank you richard for your prompt reply.  But I am using python on my
> > nokia N95 phone and I have python version 1.4.3 on my phone.  If I
> > check on the pys60 website
> > (http://sourceforge.net/project/showfiles.php?group_id=154155) the
> > latest version available is 1.4.4.  So I believe version 2.4 is for
> > desktop computers.  So I was wondering what is the right version for
> > the nokia s60 mobile phones so I can resolve my issue???
>
> I have no experience with Python on an N95, I'm afraid. I do know
that their
> version numbering doesn't necessarily correlate with the Python project
> itself. I've been told that PyS60 version 1.4.4 is apparently Python
version
> 2.3 ... ish.
>
> I've attached a Python 2.3-compatible (I think) version of oauth.py
>
>
>     Richard
>

Hi Devs on Fire,

We've added an API Explorer to the Fire Eagle developer section:

http://fireeagle.yahoo.net/developer/explorer/

It lets you try out API methods using some sample user tokens and see
the response (in JSON and XML).  Also, much fun can be had seeing how
many Cairos are in the world. I guessed wrong. :)

Check it out and let us know what you think.

-ayman.

Hey everyone,
We just pushed some new changes to Dipity. If you want to give it a
try you will need to sign for an account at Dipity.com. You can then
either add a Fire Eagle feed to your personal timeline or create an
entirely separate timeline for your Fire Eagle updates.

To attach Fire Eagle to your timeline click the "add source" button,
authorize, and then import. Once you have enabled the service on
Dipity will then poll for your movements every 5 minutes. You are also
able to post back to Fire Eagle whenever you add a new event, anywhere
inside the Dipity experience.

Bugs, feedback, suggestions would be helpful!

Thanks
Ryan

--- In fireeagle@yahoogroups.com, "Ryan Romanchuk" <rromanchuk@...> wrote:
>
> Hey everyone,
> I'm a developer over at dipity.com and have been quietly integrating
> FE into our product. I would love if any other devs would mind giving
>  suggestions and feedback.
>
> Also interested in other applications and services that would like to
> partner with or be included in Dipity's list of 'sources'.
>
> I will create an environment for FE devs and post the link around if
> anyone is interested.
>
> ps Where are all of you? Come hang out @ #fireeagle on freenode...It's
> too quiet in there.
>

Hi Aditya,

The intersection and NY borough fixes are now live.  (This is a partial
deploy - we have more stuff in the pipeline that will go out later).

Cheers,
Phil

Aditya Chadha wrote:
> Also, when will the next deploy be?
>
> Cheers,
> Aditya
>
> --
> Aditya (http://aditya.sublucid.com/)
>
>
>
> On Tue, Aug 5, 2008 at 10:22 AM, Aditya Chadha <aditya@...> wrote:
>
>> Phil,
>>
>> This is awesome - thank you!
>>
>> What about the other idea you had to send the actual address that was
>> passed in back to the person asking for the address? So, if I put 57th
>> and Broadway, NY, NY into FireEagle and then ask for it back using the
>> API, the returned data set includes both the geocoded address (W 57th
>> St, NY, NY) and the address that I passed in (57th and Broadway, NY,
>> NY) so that our apps can geocode the address ourselves?
>>
>> Cheers,
>> Aditya
>>
>> --
>> Aditya (http://aditya.sublucid.com/)
>>
>>
>>
>> On Tue, Aug 5, 2008 at 7:40 AM, Phillip Pearson <pp@...> wrote:
>>
>>> Some good news... I have got Fire Eagle to recognize intersections.
>>> This'll go out in the next code deploy, along with the New York-specific
>>> change to include the borough in addresses.
>>>
>>> The bad news is that our geocoder seems to treat Broadway oddly so "57th
>>> and broadway" will continue to not work quite right.
>>>
>>> The "hurontario and lakeshore, mississauga" example that nlb066 brought
>>> up some time back now works nicely.
>>>
>>> Experimenting a bit, it looks like it has trouble with things like "42nd
>>> and 5th, nyc" but can cope with things like "42nd st and madison ave,
>>> new york, ny" (which becomes "E 42nd St & Madison Ave, New York, NY")
>>> and "22nd and 5th ave, nyc" (which becomes "W 22nd St & 5th Ave, New
>>> York, NY"). "5th and 42nd, nyc" works, though (it becomes "5th Ave & E
>>> 42nd St, New York, NY").
>>>
>>> Cheers,
>>> Phil
>>>
>>> pherric2000 wrote:
>>>
>>>> So, was this ever fixed?
>>>>
>>>> We're having major trouble with the 'best guess' returned for any
>>>> intersections eg. 57th
>>>> and Broadway, NY, NY becomes W 57th St, NY, NY (incomplete address)
>>>>
>>>> Other addresses that break are those common to Brooklyn and Manhattan,
>>>> including:
>>>>
>>>> 1) 613 11th St, Brooklyn, NY -> 613 W11th St, NY
>>>> 2) 20 Jay St, Brooklyn, NY -> 20 Jay St, NY
>>>> 3) 83 Wyckoff St, Brooklyn, NY -> 83 Wyckoff St, NY
>>>>
>>>> Looks like FireEagle/Yahoo somehow drop the borough or something? Not sure
>>>> what is
>>>> causing intersection geocoding to break, but this pretty much makes FE
>>>> un-usable for the
>>>> New York area.
>>>>
>>>> Any ideas would be greatly appreciated.
>>>>
>>>> Cheers,
>>>> Aditya
>>>>
>>>>
>>>> --- In fireeagle@yahoogroups.com, nlb0666 <no_reply@...> wrote:
>>>>
>>>>
>>>>> Phil - that sounds reasonable. Lemme give it a shot and see if
>>>>> that'll help us out.
>>>>>
>>>>> I suppose the remaining problem would be if two alternative services
>>>>> were sharing location via fireagle. Ie your app posted an
>>>>> intersection to FireEagle, my app picks it up from FireEagle (and its
>>>>> not an intersection any more), then geocodes it to a different place.
>>>>>
>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>
>>>>>
>>>>>> One possible solution here... I think the 'user' method currently
>>>>>> returns a timestamp for the update, or for the individual location
>>>>>> levels -- you could compare this with your own internal "last moved"
>>>>>> time and ignore the update if it's within a minute or so. How does
>>>>>>
>>>>>>
>>>>> that
>>>>>
>>>>>
>>>>>> sound?
>>>>>>
>>>>>> We're also thinking about putting timestamps on the tokens returned
>>>>>>
>>>>>>
>>>>> from
>>>>>
>>>>>
>>>>>> the 'recent' method, so you can do this without even retrieving the
>>>>>>
>>>>>>
>>>>> full
>>>>>
>>>>>
>>>>>> location - should make it a bit more convenient to poll FE as you'll be
>>>>>> able to just retrieve the new updates.
>>>>>>
>>>>>> Cheers,
>>>>>> Phil
>>>>>>
>>>>>> nlb0666 wrote:
>>>>>>
>>>>>>
>>>>>>> Phil - its basically option #3. We're trying not to thrash fireeagle,
>>>>>>> so we only talk to fireeagle either a) to retrieve the location, if we
>>>>>>> haven't been spoken to by the user in 10 min, or b) to give fireeagle
>>>>>>> the location, if the user gave us one.
>>>>>>>
>>>>>>> So our problem scenario is: we get an intersection from the user, we
>>>>>>> give it to fireeagle, the user goes away for more than 10 min, on the
>>>>>>> users return we ask fireeagle if they've got an updated location - and
>>>>>>> - its different! So we grab whats returned - essentially a
>>>>>>> thoroughfare in OASIS terms, or a lat/lon that may not correspond to
>>>>>>> the lat/long our geocoder gave us - and set a new location.
>>>>>>>
>>>>>>> This interplay results in the user moving around. If FireEagle either
>>>>>>> notified us on an event basis (so we wouldn't have to guess if it was
>>>>>>> giving us back the same thing), or kept the "original string", so we
>>>>>>> could infer it was the same thing, or returned a "proper"
>>>>>>> intersection, that would geocode back to the same place, we'd be in
>>>>>>> business.
>>>>>>>
>>>>>>> Re signup - thanks for the feedback (and any other you might have).
>>>>>>> The service works only in certain cities, and we found people
>>>>>>> struggled a *lot* with the notion of location (as I'm sure you are
>>>>>>> finding!) so we tried to get them to pick a valid supported location
>>>>>>> on signup.
>>>>>>>
>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Yep, I'm in now, have authorized it with Fire Eagle, and all
>>>>>>>>
>>>>>>>>
>>>>> looks good
>>>>>
>>>>>
>>>>>>>> so far.
>>>>>>>>
>>>>>>>> I take it that the reason you want to be able to update with the
>>>>>>>> location string FE gives you is for the bookmark function? Or
>>>>>>>>
>>>>>>>>
>>>>> are you
>>>>>
>>>>>
>>>>>>>> setting the FE location first, then using that to geocode for
>>>>>>>>
>>>>>>>>
>>>>> your map
>>>>>
>>>>>
>>>>>>>> display? Or is the problem that you end up getting the update
>>>>>>>>
>>>>>>>>
>>>>> from FE
>>>>>
>>>>>
>>>>>>>> 10 mins later, and it looks like a new location, because it's
>>>>>>>>
>>>>>>>>
>>>>> different
>>>>>
>>>>>
>>>>>>>> from before? (I'm trying to figure out where the issue lies here).
>>>>>>>>
>>>>>>>> A note: it would be nice if the account setup process didn't require
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> you
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> to give your gender/age/zip code. Most people will put in a fake
>>>>>>>>
>>>>>>>>
>>>>> age,
>>>>>
>>>>>
>>>>>>>> and I'm actually outside the US so I put in the zipcode for
>>>>>>>>
>>>>>>>>
>>>>> Brickhouse
>>>>>
>>>>>
>>>>>>>> rather than for where I actually am (Christchurch, New Zealand).
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> nlb0666 wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Phil - tks for taking a look. Did the email ever make it
>>>>>>>>>
>>>>>>>>>
>>>>> through? I
>>>>>
>>>>>
>>>>>>>>> checked this morning and it didn't look like it did. I'll hit you
>>>>>>>>> with a direct note as well
>>>>>>>>>
>>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> One thing we could probably do would be to give you back the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> query you
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> used to set the location in the first place, as long as the
>>>>>>>>>>
>>>>>>>>>>
>>>>> user has
>>>>>
>>>>>
>>>>>>>>>> given you permission to see their exact location. This would be a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> hash,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> something like {q: 'hurontario and lakesure, mississauga'} or
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> {woeid:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> '123456789'} (to use javascript notation), that would put you back
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> there
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> if passed to us. In some cases we could do this as a string, and
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> if it
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> was useful we could get FE to parse woeids etc out of strings like
>>>>>>>>>> "woeid:123456789", so we could just give you a string...
>>>>>>>>>>
>>>>>>>>>> Just signed up to liketribe to see what you're actually doing, so
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> once
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> the e-mail verification msg makes it through my greylist filter,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I'll be
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> able to get a better idea of what you need :)
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>> nlb0666 wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Ok we can implement that as a workaround, but it is painful.
>>>>>>>>>>>
>>>>>>>>>>> Why? Because fireeagle isn't the only source of location data
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> for our
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> application. Nor are the fireeagle lat/lon for a given
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> address the
>>>>>
>>>>>
>>>>>>>>>>> same as our underlying geocoder. So if we use lat/lon,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> effectively
>>>>>
>>>>>
>>>>>>>>>>> the user "slides down the street" as different services reverse
>>>>>>>>>>> geocode differently. If we use the woeid, this is a code
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> unique to
>>>>>
>>>>>
>>>>>>>>>>> you guys, so we have to do a bunch of work to figure out if the
>>>>>>>>>>> address we gave to fireeagle is the same as the text string we had
>>>>>>>>>>> (since your returned text string is not the same as we gave
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> you), and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> then remember, in those cases, to speak special fire eagle
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> language.
>>>>>
>>>>>
>>>>>>>>>>> So this is a fairly large disappointment that for us at least
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> really
>>>>>
>>>>>
>>>>>>>>>>> increases the amount of work to do "proper" fire eagle
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> integration.
>>>>>
>>>>>
>>>>>>>>>>> From an app pov, it would be much nicer to remember the string you
>>>>>>>>>>> were given and pass it back
>>>>>>>>>>>
>>>>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> OK, so looking at the underlying data, our geocoder has
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> recognized
>>>>>
>>>>>
>>>>>>>>>>>> "Hurontario and Lakeshore, Mississauga" as an intersection and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> geocoded
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> it correctly, but the data it returns to FireEagle doesn't even
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> mention
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> Lakeshore at all, so what you see on the site or via the API is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> just
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> "Hurontario St". I'm afraid that's the best we can do for now,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> you'll have to assume that location names returned from FireEagle
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> won't
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> necessarily geocode correctly if you pass them back in to set
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> your
>>>>>
>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> location.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> If you pass the lat/lon coords back into FE (set your
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> location to
>>>>>
>>>>>
>>>>>>>>>>>> "43.555286407499999, -79.581794738799999") it'll reverse-geocode
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> from
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> there, put you in approximately the right place, and give you
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> "Lakeshore
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Rd E, Mississauga, Ontario, Canada". Passing *that* back into FE
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> also
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> puts you at Hurontario and Lakeshore. I wouldn't count on being
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> able to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> do this all the time but it does seem to work here. (Internally
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> it's
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> geocoding it to L5G, a postcode, which seems to be centered on
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> that
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> intersection).
>>>>>>>>>>>>
>>>>>>>>>>>> In general, if you get a woeid from an API response, setting
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> your
>>>>>
>>>>>
>>>>>>>>>>>> location to that woeid should always bring you back to the right
>>>>>>>>>>>> location, but exact points are trickier. Probably the most
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> reliable
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> way
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> of getting back to an exact point is passing us the lat/lon
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> co-ordinates
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> rather than the string we return to you.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Phil
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> nlb0666 wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey Tom any progress here? As far as I can tell, round tripping
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> from the app to FireEagle to the app using an intersection as a
>>>>>>>>>>> location still screws up and results in the user being "somewhere
>>>>>>>>>>> else" at the end. THe problem appears to be that fireeagle
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> does not
>>>>>
>>>>>
>>>>>>>>>>> pass back an intersection as the new location, so the new
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> input will
>>>>>
>>>>>
>>>>>>>>>>> be ambiguous (ie without the cross street).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> This should probably work no?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tested again this morning using Hurontario and Lakeshore,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> Mississauga, per the example below, and it failed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Also... it does appear that intersections can get resolved to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> street addresses. Specifically "38 and Broadway" becomes "38
>>>>>>>>>>> Broadway". I have not pinpointed them precisely, but it appears
>>>>>>>>>>> again that passing in a string "38th and Broadway" to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> FireEagle can
>>>>>
>>>>>
>>>>>>>>>>> result in a string being returned which, when passed back, will
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> become
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> "38 Broadway". This is not the only address this occurs for -
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> see the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> example below. This one is a particularly bad example as
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> "38th and
>>>>>
>>>>>
>>>>>>>>>>> Broadway" does not locate correctly from the fireeagle user
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> accessible
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> website at any time.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Please advise
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's possible that the data we're using isn't terribly good
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>> at
>>>>>
>>>>>
>>>>>>>>>>>>>> handling intersections. I'll dig into it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 19 May 2008, at 06:59, nlb0666 wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I tested this a little more over the weekend. It worked well,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> but I
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> did have a problem with intersections. For example, feeding
>>>>>>>>>>>>>>> Hurontario and Lakeshore, Mississauga, Ontario correctly
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> locates
>>>>>
>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> you
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> at that intersection. But Fire Eagle returns the location as
>>>>>>>>>>>>>>> Hurontario St, Mississauga, Ontario. If I enter THAT
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> location
>>>>>
>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> into
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> Fire Eagle, it will put me at Hurontario and Burnamthorpe.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So: if I give Fire Eagle the location as an intersection, get
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> location from Fire Eagle, and then give that string back to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>> Fire
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> Eagle, I'll have moved.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From an app perspective, it would be nice if giving an
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> intersection
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> in resulted in getting an intersection back so that the above
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> would
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> work consistently. If an intersection cannot be returned,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> then at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> least a street address "123 hurontario" (or whatever is
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> nearest
>>>>>
>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> that
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> intersection), so that giving the string back to Fire Eagle
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> would
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> maintain my location. If I'm missing the point here, please
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> advise.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> I had a problem with another intersection "78th st and 2nd
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> ave,
>>>>>
>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> New
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> York". I believe at some point my app gave fire eagle, or
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>> fire
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> eagle gave me, the string "78 and 2nd, New York". Yahoo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> Maps
>>>>>
>>>>>
>>>>>>>>>>>>>>> geocodes this as "78 2nd Avenue", not as "78th and 2nd ave".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>> I
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> will need to look at this more to figure out whether Fire
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> Eagle or
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> we were the culprit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ooops sorry to reply to myself - just realize you'd asked
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>> invite
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>> requests to be emailed elsewhere, so I'll email you there....
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>> my
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>> reading skills ARE improving :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've done some initial testing and it looks good! I'll
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> play
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> more
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> over the next few days and make sure we don't see any
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> breaks.
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> But
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> first tests, on both toronto and new york, updating both
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> via
>>>>>
>>>>>
>>>>>>>>>>>>>>>>> address and via lat lon (which I then removed as we want to
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> update
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> via address) work! I found a break with 218 Bowery (this is
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> Yahoo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> geocoding incorrectly coding this as W 218th st), but
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>> otherwise,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>> so far so good....
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks guys! Jumping the gun :) now that it looks like
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> its
>>>>>
>>>>>
>>>>>>>>>>>>>>>>> working for us, I'd love to get more people playing with
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> FireEagle
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <-> liketribe (our app)... Any chance of some more
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> invites?
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> And/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> or if you guys or anyone else on the board has a chance,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>> you'll
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>> find you can update from email, IM, or SMS (or our website
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>> of
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> course) using street address, intersection, bookmarked
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> locations,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> or venue names at liketribe.com (sign up, make account,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> go to
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> bottom of the "my mobile" page and click on FireEagle...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> hopefully
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> to discover it all Just Works...)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yay. Seth rocks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> nlb0666 - has this fixed the problem from your perspective?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 14 May 2008, at 19:27, Seth Fitzsimmons wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi all.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This serves to let you know that a new build of Fire Eagle
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>> is
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>>>> live and
>>>>>>>>>>>>>>>>>>> kicking at fireeagle.com. Nothing new, no API changes,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>> but a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>>> of bugs
>>>>>>>>>>>>>>>>>>> were squished that were causing some precise locations
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>> to be
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>>>> dropped
>>>>>>>>>>>>>>>>>>> (some
>>>>>>>>>>>>>>>>>>> locations in NYC, Ontario, etc.).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On my radar for tomorrow are lat/lons in Singapore and in
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>>>> middle
>>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>>> Pacific as well as a few other things that have come up
>>>>>>>>>>>>>>>>>>> internally.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Let me know (via the list) if you're continuing to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>> bump into
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>> weird
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> geocoding
>>>>>>>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> seth
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>

Still have to talk this over within the team... will get back to the
list once we have something definite.

Cheers,
Phil

Aditya Chadha wrote:
> Phil,
>
> This is awesome - thank you!
>
> What about the other idea you had to send the actual address that was
> passed in back to the person asking for the address? So, if I put 57th
> and Broadway, NY, NY into FireEagle and then ask for it back using the
> API, the returned data set includes both the geocoded address (W 57th
> St, NY, NY) and the address that I passed in (57th and Broadway, NY,
> NY) so that our apps can geocode the address ourselves?
>
> Cheers,
> Aditya
>
> --
> Aditya (http://aditya.sublucid.com/)
>
>
>
> On Tue, Aug 5, 2008 at 7:40 AM, Phillip Pearson <pp@...> wrote:
>
>> Some good news... I have got Fire Eagle to recognize intersections.
>> This'll go out in the next code deploy, along with the New York-specific
>> change to include the borough in addresses.
>>
>> The bad news is that our geocoder seems to treat Broadway oddly so "57th
>> and broadway" will continue to not work quite right.
>>
>> The "hurontario and lakeshore, mississauga" example that nlb066 brought
>> up some time back now works nicely.
>>
>> Experimenting a bit, it looks like it has trouble with things like "42nd
>> and 5th, nyc" but can cope with things like "42nd st and madison ave,
>> new york, ny" (which becomes "E 42nd St & Madison Ave, New York, NY")
>> and "22nd and 5th ave, nyc" (which becomes "W 22nd St & 5th Ave, New
>> York, NY"). "5th and 42nd, nyc" works, though (it becomes "5th Ave & E
>> 42nd St, New York, NY").
>>
>> Cheers,
>> Phil
>>
>> pherric2000 wrote:
>>
>>> So, was this ever fixed?
>>>
>>> We're having major trouble with the 'best guess' returned for any
>>> intersections eg. 57th
>>> and Broadway, NY, NY becomes W 57th St, NY, NY (incomplete address)
>>>
>>> Other addresses that break are those common to Brooklyn and Manhattan,
>>> including:
>>>
>>> 1) 613 11th St, Brooklyn, NY -> 613 W11th St, NY
>>> 2) 20 Jay St, Brooklyn, NY -> 20 Jay St, NY
>>> 3) 83 Wyckoff St, Brooklyn, NY -> 83 Wyckoff St, NY
>>>
>>> Looks like FireEagle/Yahoo somehow drop the borough or something? Not sure
>>> what is
>>> causing intersection geocoding to break, but this pretty much makes FE
>>> un-usable for the
>>> New York area.
>>>
>>> Any ideas would be greatly appreciated.
>>>
>>> Cheers,
>>> Aditya
>>>
>>>
>>> --- In fireeagle@yahoogroups.com, nlb0666 <no_reply@...> wrote:
>>>
>>>
>>>> Phil - that sounds reasonable. Lemme give it a shot and see if
>>>> that'll help us out.
>>>>
>>>> I suppose the remaining problem would be if two alternative services
>>>> were sharing location via fireagle. Ie your app posted an
>>>> intersection to FireEagle, my app picks it up from FireEagle (and its
>>>> not an intersection any more), then geocodes it to a different place.
>>>>
>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>
>>>>
>>>>> One possible solution here... I think the 'user' method currently
>>>>> returns a timestamp for the update, or for the individual location
>>>>> levels -- you could compare this with your own internal "last moved"
>>>>> time and ignore the update if it's within a minute or so. How does
>>>>>
>>>>>
>>>> that
>>>>
>>>>
>>>>> sound?
>>>>>
>>>>> We're also thinking about putting timestamps on the tokens returned
>>>>>
>>>>>
>>>> from
>>>>
>>>>
>>>>> the 'recent' method, so you can do this without even retrieving the
>>>>>
>>>>>
>>>> full
>>>>
>>>>
>>>>> location - should make it a bit more convenient to poll FE as you'll be
>>>>> able to just retrieve the new updates.
>>>>>
>>>>> Cheers,
>>>>> Phil
>>>>>
>>>>> nlb0666 wrote:
>>>>>
>>>>>
>>>>>> Phil - its basically option #3. We're trying not to thrash fireeagle,
>>>>>> so we only talk to fireeagle either a) to retrieve the location, if we
>>>>>> haven't been spoken to by the user in 10 min, or b) to give fireeagle
>>>>>> the location, if the user gave us one.
>>>>>>
>>>>>> So our problem scenario is: we get an intersection from the user, we
>>>>>> give it to fireeagle, the user goes away for more than 10 min, on the
>>>>>> users return we ask fireeagle if they've got an updated location - and
>>>>>> - its different! So we grab whats returned - essentially a
>>>>>> thoroughfare in OASIS terms, or a lat/lon that may not correspond to
>>>>>> the lat/long our geocoder gave us - and set a new location.
>>>>>>
>>>>>> This interplay results in the user moving around. If FireEagle either
>>>>>> notified us on an event basis (so we wouldn't have to guess if it was
>>>>>> giving us back the same thing), or kept the "original string", so we
>>>>>> could infer it was the same thing, or returned a "proper"
>>>>>> intersection, that would geocode back to the same place, we'd be in
>>>>>> business.
>>>>>>
>>>>>> Re signup - thanks for the feedback (and any other you might have).
>>>>>> The service works only in certain cities, and we found people
>>>>>> struggled a *lot* with the notion of location (as I'm sure you are
>>>>>> finding!) so we tried to get them to pick a valid supported location
>>>>>> on signup.
>>>>>>
>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Yep, I'm in now, have authorized it with Fire Eagle, and all
>>>>>>>
>>>>>>>
>>>> looks good
>>>>
>>>>
>>>>>>> so far.
>>>>>>>
>>>>>>> I take it that the reason you want to be able to update with the
>>>>>>> location string FE gives you is for the bookmark function? Or
>>>>>>>
>>>>>>>
>>>> are you
>>>>
>>>>
>>>>>>> setting the FE location first, then using that to geocode for
>>>>>>>
>>>>>>>
>>>> your map
>>>>
>>>>
>>>>>>> display? Or is the problem that you end up getting the update
>>>>>>>
>>>>>>>
>>>> from FE
>>>>
>>>>
>>>>>>> 10 mins later, and it looks like a new location, because it's
>>>>>>>
>>>>>>>
>>>> different
>>>>
>>>>
>>>>>>> from before? (I'm trying to figure out where the issue lies here).
>>>>>>>
>>>>>>> A note: it would be nice if the account setup process didn't require
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> you
>>>>>>
>>>>>>
>>>>>>
>>>>>>> to give your gender/age/zip code. Most people will put in a fake
>>>>>>>
>>>>>>>
>>>> age,
>>>>
>>>>
>>>>>>> and I'm actually outside the US so I put in the zipcode for
>>>>>>>
>>>>>>>
>>>> Brickhouse
>>>>
>>>>
>>>>>>> rather than for where I actually am (Christchurch, New Zealand).
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Phil
>>>>>>>
>>>>>>> nlb0666 wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Phil - tks for taking a look. Did the email ever make it
>>>>>>>>
>>>>>>>>
>>>> through? I
>>>>
>>>>
>>>>>>>> checked this morning and it didn't look like it did. I'll hit you
>>>>>>>> with a direct note as well
>>>>>>>>
>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> One thing we could probably do would be to give you back the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> query you
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> used to set the location in the first place, as long as the
>>>>>>>>>
>>>>>>>>>
>>>> user has
>>>>
>>>>
>>>>>>>>> given you permission to see their exact location. This would be a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> hash,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> something like {q: 'hurontario and lakesure, mississauga'} or
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> {woeid:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> '123456789'} (to use javascript notation), that would put you back
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> there
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> if passed to us. In some cases we could do this as a string, and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> if it
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> was useful we could get FE to parse woeids etc out of strings like
>>>>>>>>> "woeid:123456789", so we could just give you a string...
>>>>>>>>>
>>>>>>>>> Just signed up to liketribe to see what you're actually doing, so
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> once
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> the e-mail verification msg makes it through my greylist filter,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I'll be
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> able to get a better idea of what you need :)
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> nlb0666 wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Ok we can implement that as a workaround, but it is painful.
>>>>>>>>>>
>>>>>>>>>> Why? Because fireeagle isn't the only source of location data
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> for our
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>> application. Nor are the fireeagle lat/lon for a given
>>>>>>>>>>
>>>>>>>>>>
>>>> address the
>>>>
>>>>
>>>>>>>>>> same as our underlying geocoder. So if we use lat/lon,
>>>>>>>>>>
>>>>>>>>>>
>>>> effectively
>>>>
>>>>
>>>>>>>>>> the user "slides down the street" as different services reverse
>>>>>>>>>> geocode differently. If we use the woeid, this is a code
>>>>>>>>>>
>>>>>>>>>>
>>>> unique to
>>>>
>>>>
>>>>>>>>>> you guys, so we have to do a bunch of work to figure out if the
>>>>>>>>>> address we gave to fireeagle is the same as the text string we had
>>>>>>>>>> (since your returned text string is not the same as we gave
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> you), and
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>> then remember, in those cases, to speak special fire eagle
>>>>>>>>>>
>>>>>>>>>>
>>>> language.
>>>>
>>>>
>>>>>>>>>> So this is a fairly large disappointment that for us at least
>>>>>>>>>>
>>>>>>>>>>
>>>> really
>>>>
>>>>
>>>>>>>>>> increases the amount of work to do "proper" fire eagle
>>>>>>>>>>
>>>>>>>>>>
>>>> integration.
>>>>
>>>>
>>>>>>>>>> From an app pov, it would be much nicer to remember the string you
>>>>>>>>>> were given and pass it back
>>>>>>>>>>
>>>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> OK, so looking at the underlying data, our geocoder has
>>>>>>>>>>>
>>>>>>>>>>>
>>>> recognized
>>>>
>>>>
>>>>>>>>>>> "Hurontario and Lakeshore, Mississauga" as an intersection and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> geocoded
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> it correctly, but the data it returns to FireEagle doesn't even
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> mention
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> Lakeshore at all, so what you see on the site or via the API is
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> just
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>> "Hurontario St". I'm afraid that's the best we can do for now,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> and
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>> you'll have to assume that location names returned from FireEagle
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> won't
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> necessarily geocode correctly if you pass them back in to set
>>>>>>>>>>>
>>>>>>>>>>>
>>>> your
>>>>
>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> location.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> If you pass the lat/lon coords back into FE (set your
>>>>>>>>>>>
>>>>>>>>>>>
>>>> location to
>>>>
>>>>
>>>>>>>>>>> "43.555286407499999, -79.581794738799999") it'll reverse-geocode
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> from
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> there, put you in approximately the right place, and give you
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> "Lakeshore
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Rd E, Mississauga, Ontario, Canada". Passing *that* back into FE
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> also
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> puts you at Hurontario and Lakeshore. I wouldn't count on being
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> able to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> do this all the time but it does seem to work here. (Internally
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> it's
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> geocoding it to L5G, a postcode, which seems to be centered on
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> that
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>> intersection).
>>>>>>>>>>>
>>>>>>>>>>> In general, if you get a woeid from an API response, setting
>>>>>>>>>>>
>>>>>>>>>>>
>>>> your
>>>>
>>>>
>>>>>>>>>>> location to that woeid should always bring you back to the right
>>>>>>>>>>> location, but exact points are trickier. Probably the most
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> reliable
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> way
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> of getting back to an exact point is passing us the lat/lon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> co-ordinates
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> rather than the string we return to you.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> nlb0666 wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hey Tom any progress here? As far as I can tell, round tripping
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> from the app to FireEagle to the app using an intersection as a
>>>>>>>>>> location still screws up and results in the user being "somewhere
>>>>>>>>>> else" at the end. THe problem appears to be that fireeagle
>>>>>>>>>>
>>>>>>>>>>
>>>> does not
>>>>
>>>>
>>>>>>>>>> pass back an intersection as the new location, so the new
>>>>>>>>>>
>>>>>>>>>>
>>>> input will
>>>>
>>>>
>>>>>>>>>> be ambiguous (ie without the cross street).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> This should probably work no?
>>>>>>>>>>>>
>>>>>>>>>>>> I tested again this morning using Hurontario and Lakeshore,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> Mississauga, per the example below, and it failed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Also... it does appear that intersections can get resolved to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> street addresses. Specifically "38 and Broadway" becomes "38
>>>>>>>>>> Broadway". I have not pinpointed them precisely, but it appears
>>>>>>>>>> again that passing in a string "38th and Broadway" to
>>>>>>>>>>
>>>>>>>>>>
>>>> FireEagle can
>>>>
>>>>
>>>>>>>>>> result in a string being returned which, when passed back, will
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> become
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>> "38 Broadway". This is not the only address this occurs for -
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> see the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>> example below. This one is a particularly bad example as
>>>>>>>>>>
>>>>>>>>>>
>>>> "38th and
>>>>
>>>>
>>>>>>>>>> Broadway" does not locate correctly from the fireeagle user
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> accessible
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>> website at any time.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Please advise
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> It's possible that the data we're using isn't terribly good
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>> at
>>>>
>>>>
>>>>>>>>>>>>> handling intersections. I'll dig into it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 19 May 2008, at 06:59, nlb0666 wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tested this a little more over the weekend. It worked well,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> but I
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> did have a problem with intersections. For example, feeding
>>>>>>>>>>>>>> Hurontario and Lakeshore, Mississauga, Ontario correctly
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>> locates
>>>>
>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> you
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> at that intersection. But Fire Eagle returns the location as
>>>>>>>>>>>>>> Hurontario St, Mississauga, Ontario. If I enter THAT
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>> location
>>>>
>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> into
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> Fire Eagle, it will put me at Hurontario and Burnamthorpe.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So: if I give Fire Eagle the location as an intersection, get
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> location from Fire Eagle, and then give that string back to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> Fire
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>> Eagle, I'll have moved.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From an app perspective, it would be nice if giving an
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> intersection
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> in resulted in getting an intersection back so that the above
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> would
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> work consistently. If an intersection cannot be returned,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> then at
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> least a street address "123 hurontario" (or whatever is
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>> nearest
>>>>
>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> intersection), so that giving the string back to Fire Eagle
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> would
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> maintain my location. If I'm missing the point here, please
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> advise.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> I had a problem with another intersection "78th st and 2nd
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>> ave,
>>>>
>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> New
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> York". I believe at some point my app gave fire eagle, or
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> fire
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>> eagle gave me, the string "78 and 2nd, New York". Yahoo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>> Maps
>>>>
>>>>
>>>>>>>>>>>>>> geocodes this as "78 2nd Avenue", not as "78th and 2nd ave".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> I
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>> will need to look at this more to figure out whether Fire
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>> Eagle or
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> we were the culprit.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ooops sorry to reply to myself - just realize you'd asked
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>> invite
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>> requests to be emailed elsewhere, so I'll email you there....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>> my
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>> reading skills ARE improving :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've done some initial testing and it looks good! I'll
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>> play
>>>>
>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> more
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> over the next few days and make sure we don't see any
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>> breaks.
>>>>
>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> But
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> first tests, on both toronto and new york, updating both
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>> via
>>>>
>>>>
>>>>>>>>>>>>>>>> address and via lat lon (which I then removed as we want to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> update
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> via address) work! I found a break with 218 Bowery (this is
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> Yahoo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> geocoding incorrectly coding this as W 218th st), but
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> otherwise,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> so far so good....
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks guys! Jumping the gun :) now that it looks like
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>> its
>>>>
>>>>
>>>>>>>>>>>>>>>> working for us, I'd love to get more people playing with
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> FireEagle
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> <-> liketribe (our app)... Any chance of some more
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>> invites?
>>>>
>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> And/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> or if you guys or anyone else on the board has a chance,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> you'll
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> find you can update from email, IM, or SMS (or our website
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>> of
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>> course) using street address, intersection, bookmarked
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> locations,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> or venue names at liketribe.com (sign up, make account,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>> go to
>>>>
>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> bottom of the "my mobile" page and click on FireEagle...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> hopefully
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> to discover it all Just Works...)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yay. Seth rocks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> nlb0666 - has this fixed the problem from your perspective?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 14 May 2008, at 19:27, Seth Fitzsimmons wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi all.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This serves to let you know that a new build of Fire Eagle
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>> is
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>> live and
>>>>>>>>>>>>>>>>>> kicking at fireeagle.com. Nothing new, no API changes,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>> but a
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>> of bugs
>>>>>>>>>>>>>>>>>> were squished that were causing some precise locations
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>> to be
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>> dropped
>>>>>>>>>>>>>>>>>> (some
>>>>>>>>>>>>>>>>>> locations in NYC, Ontario, etc.).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On my radar for tomorrow are lat/lons in Singapore and in
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>> middle
>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>> Pacific as well as a few other things that have come up
>>>>>>>>>>>>>>>>>> internally.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Let me know (via the list) if you're continuing to
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>> bump into
>>>>
>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>> weird
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>> geocoding
>>>>>>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> seth
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>

Yeah!  Thanks the fixes work great... except for 57th and Broadway ;-)

For anyone that wants to check out our integration, hit
http://outside.in/neighbors/edit_profile pair your account and hit
http://outside.in/radar


(You have to be a registered user, of course)

Cheers,
Aditya

--
Aditya (http://aditya.sublucid.com/)



On Wed, Aug 6, 2008 at 6:45 PM, Phillip Pearson <pp@...> wrote:
> Hi Aditya,
>
> The intersection and NY borough fixes are now live. (This is a partial
> deploy - we have more stuff in the pipeline that will go out later).
>
> Cheers,
> Phil
>
> Aditya Chadha wrote:
>> Also, when will the next deploy be?
>>
>> Cheers,
>> Aditya
>>
>> --
>> Aditya (http://aditya.sublucid.com/)
>>
>>
>>
>> On Tue, Aug 5, 2008 at 10:22 AM, Aditya Chadha <aditya@...>
>> wrote:
>>
>>> Phil,
>>>
>>> This is awesome - thank you!
>>>
>>> What about the other idea you had to send the actual address that was
>>> passed in back to the person asking for the address? So, if I put 57th
>>> and Broadway, NY, NY into FireEagle and then ask for it back using the
>>> API, the returned data set includes both the geocoded address (W 57th
>>> St, NY, NY) and the address that I passed in (57th and Broadway, NY,
>>> NY) so that our apps can geocode the address ourselves?
>>>
>>> Cheers,
>>> Aditya
>>>
>>> --
>>> Aditya (http://aditya.sublucid.com/)
>>>
>>>
>>>
>>> On Tue, Aug 5, 2008 at 7:40 AM, Phillip Pearson <pp@...> wrote:
>>>
>>>> Some good news... I have got Fire Eagle to recognize intersections.
>>>> This'll go out in the next code deploy, along with the New York-specific
>>>> change to include the borough in addresses.
>>>>
>>>> The bad news is that our geocoder seems to treat Broadway oddly so "57th
>>>> and broadway" will continue to not work quite right.
>>>>
>>>> The "hurontario and lakeshore, mississauga" example that nlb066 brought
>>>> up some time back now works nicely.
>>>>
>>>> Experimenting a bit, it looks like it has trouble with things like "42nd
>>>> and 5th, nyc" but can cope with things like "42nd st and madison ave,
>>>> new york, ny" (which becomes "E 42nd St & Madison Ave, New York, NY")
>>>> and "22nd and 5th ave, nyc" (which becomes "W 22nd St & 5th Ave, New
>>>> York, NY"). "5th and 42nd, nyc" works, though (it becomes "5th Ave & E
>>>> 42nd St, New York, NY").
>>>>
>>>> Cheers,
>>>> Phil
>>>>
>>>> pherric2000 wrote:
>>>>
>>>>> So, was this ever fixed?
>>>>>
>>>>> We're having major trouble with the 'best guess' returned for any
>>>>> intersections eg. 57th
>>>>> and Broadway, NY, NY becomes W 57th St, NY, NY (incomplete address)
>>>>>
>>>>> Other addresses that break are those common to Brooklyn and Manhattan,
>>>>> including:
>>>>>
>>>>> 1) 613 11th St, Brooklyn, NY -> 613 W11th St, NY
>>>>> 2) 20 Jay St, Brooklyn, NY -> 20 Jay St, NY
>>>>> 3) 83 Wyckoff St, Brooklyn, NY -> 83 Wyckoff St, NY
>>>>>
>>>>> Looks like FireEagle/Yahoo somehow drop the borough or something? Not
>>>>> sure
>>>>> what is
>>>>> causing intersection geocoding to break, but this pretty much makes FE
>>>>> un-usable for the
>>>>> New York area.
>>>>>
>>>>> Any ideas would be greatly appreciated.
>>>>>
>>>>> Cheers,
>>>>> Aditya
>>>>>
>>>>>
>>>>> --- In fireeagle@yahoogroups.com, nlb0666 <no_reply@...> wrote:
>>>>>
>>>>>
>>>>>> Phil - that sounds reasonable. Lemme give it a shot and see if
>>>>>> that'll help us out.
>>>>>>
>>>>>> I suppose the remaining problem would be if two alternative services
>>>>>> were sharing location via fireagle. Ie your app posted an
>>>>>> intersection to FireEagle, my app picks it up from FireEagle (and its
>>>>>> not an intersection any more), then geocodes it to a different place.
>>>>>>
>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>
>>>>>>
>>>>>>> One possible solution here... I think the 'user' method currently
>>>>>>> returns a timestamp for the update, or for the individual location
>>>>>>> levels -- you could compare this with your own internal "last moved"
>>>>>>> time and ignore the update if it's within a minute or so. How does
>>>>>>>
>>>>>>>
>>>>>> that
>>>>>>
>>>>>>
>>>>>>> sound?
>>>>>>>
>>>>>>> We're also thinking about putting timestamps on the tokens returned
>>>>>>>
>>>>>>>
>>>>>> from
>>>>>>
>>>>>>
>>>>>>> the 'recent' method, so you can do this without even retrieving the
>>>>>>>
>>>>>>>
>>>>>> full
>>>>>>
>>>>>>
>>>>>>> location - should make it a bit more convenient to poll FE as you'll
>>>>>>> be
>>>>>>> able to just retrieve the new updates.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Phil
>>>>>>>
>>>>>>> nlb0666 wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Phil - its basically option #3. We're trying not to thrash
>>>>>>>> fireeagle,
>>>>>>>> so we only talk to fireeagle either a) to retrieve the location, if
>>>>>>>> we
>>>>>>>> haven't been spoken to by the user in 10 min, or b) to give
>>>>>>>> fireeagle
>>>>>>>> the location, if the user gave us one.
>>>>>>>>
>>>>>>>> So our problem scenario is: we get an intersection from the user, we
>>>>>>>> give it to fireeagle, the user goes away for more than 10 min, on
>>>>>>>> the
>>>>>>>> users return we ask fireeagle if they've got an updated location -
>>>>>>>> and
>>>>>>>> - its different! So we grab whats returned - essentially a
>>>>>>>> thoroughfare in OASIS terms, or a lat/lon that may not correspond to
>>>>>>>> the lat/long our geocoder gave us - and set a new location.
>>>>>>>>
>>>>>>>> This interplay results in the user moving around. If FireEagle
>>>>>>>> either
>>>>>>>> notified us on an event basis (so we wouldn't have to guess if it
>>>>>>>> was
>>>>>>>> giving us back the same thing), or kept the "original string", so we
>>>>>>>> could infer it was the same thing, or returned a "proper"
>>>>>>>> intersection, that would geocode back to the same place, we'd be in
>>>>>>>> business.
>>>>>>>>
>>>>>>>> Re signup - thanks for the feedback (and any other you might have).
>>>>>>>> The service works only in certain cities, and we found people
>>>>>>>> struggled a *lot* with the notion of location (as I'm sure you are
>>>>>>>> finding!) so we tried to get them to pick a valid supported location
>>>>>>>> on signup.
>>>>>>>>
>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Yep, I'm in now, have authorized it with Fire Eagle, and all
>>>>>>>>>
>>>>>>>>>
>>>>>> looks good
>>>>>>
>>>>>>
>>>>>>>>> so far.
>>>>>>>>>
>>>>>>>>> I take it that the reason you want to be able to update with the
>>>>>>>>> location string FE gives you is for the bookmark function? Or
>>>>>>>>>
>>>>>>>>>
>>>>>> are you
>>>>>>
>>>>>>
>>>>>>>>> setting the FE location first, then using that to geocode for
>>>>>>>>>
>>>>>>>>>
>>>>>> your map
>>>>>>
>>>>>>
>>>>>>>>> display? Or is the problem that you end up getting the update
>>>>>>>>>
>>>>>>>>>
>>>>>> from FE
>>>>>>
>>>>>>
>>>>>>>>> 10 mins later, and it looks like a new location, because it's
>>>>>>>>>
>>>>>>>>>
>>>>>> different
>>>>>>
>>>>>>
>>>>>>>>> from before? (I'm trying to figure out where the issue lies here).
>>>>>>>>>
>>>>>>>>> A note: it would be nice if the account setup process didn't
>>>>>>>>> require
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> you
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> to give your gender/age/zip code. Most people will put in a fake
>>>>>>>>>
>>>>>>>>>
>>>>>> age,
>>>>>>
>>>>>>
>>>>>>>>> and I'm actually outside the US so I put in the zipcode for
>>>>>>>>>
>>>>>>>>>
>>>>>> Brickhouse
>>>>>>
>>>>>>
>>>>>>>>> rather than for where I actually am (Christchurch, New Zealand).
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> nlb0666 wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Phil - tks for taking a look. Did the email ever make it
>>>>>>>>>>
>>>>>>>>>>
>>>>>> through? I
>>>>>>
>>>>>>
>>>>>>>>>> checked this morning and it didn't look like it did. I'll hit you
>>>>>>>>>> with a direct note as well
>>>>>>>>>>
>>>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> One thing we could probably do would be to give you back the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> query you
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> used to set the location in the first place, as long as the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> user has
>>>>>>
>>>>>>
>>>>>>>>>>> given you permission to see their exact location. This would be a
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> hash,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> something like {q: 'hurontario and lakesure, mississauga'} or
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> {woeid:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> '123456789'} (to use javascript notation), that would put you
>>>>>>>>>>> back
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> there
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> if passed to us. In some cases we could do this as a string, and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> if it
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> was useful we could get FE to parse woeids etc out of strings
>>>>>>>>>>> like
>>>>>>>>>>> "woeid:123456789", so we could just give you a string...
>>>>>>>>>>>
>>>>>>>>>>> Just signed up to liketribe to see what you're actually doing, so
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> once
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> the e-mail verification msg makes it through my greylist filter,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> I'll be
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> able to get a better idea of what you need :)
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>> nlb0666 wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Ok we can implement that as a workaround, but it is painful.
>>>>>>>>>>>>
>>>>>>>>>>>> Why? Because fireeagle isn't the only source of location data
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> for our
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> application. Nor are the fireeagle lat/lon for a given
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> address the
>>>>>>
>>>>>>
>>>>>>>>>>>> same as our underlying geocoder. So if we use lat/lon,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> effectively
>>>>>>
>>>>>>
>>>>>>>>>>>> the user "slides down the street" as different services reverse
>>>>>>>>>>>> geocode differently. If we use the woeid, this is a code
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> unique to
>>>>>>
>>>>>>
>>>>>>>>>>>> you guys, so we have to do a bunch of work to figure out if the
>>>>>>>>>>>> address we gave to fireeagle is the same as the text string we
>>>>>>>>>>>> had
>>>>>>>>>>>> (since your returned text string is not the same as we gave
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> you), and
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> then remember, in those cases, to speak special fire eagle
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> language.
>>>>>>
>>>>>>
>>>>>>>>>>>> So this is a fairly large disappointment that for us at least
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> really
>>>>>>
>>>>>>
>>>>>>>>>>>> increases the amount of work to do "proper" fire eagle
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> integration.
>>>>>>
>>>>>>
>>>>>>>>>>>> From an app pov, it would be much nicer to remember the string
>>>>>>>>>>>> you
>>>>>>>>>>>> were given and pass it back
>>>>>>>>>>>>
>>>>>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> OK, so looking at the underlying data, our geocoder has
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>> recognized
>>>>>>
>>>>>>
>>>>>>>>>>>>> "Hurontario and Lakeshore, Mississauga" as an intersection and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> geocoded
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> it correctly, but the data it returns to FireEagle doesn't even
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> mention
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> Lakeshore at all, so what you see on the site or via the API is
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>> just
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> "Hurontario St". I'm afraid that's the best we can do for now,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>> and
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> you'll have to assume that location names returned from
>>>>>>>>>>>>> FireEagle
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> won't
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> necessarily geocode correctly if you pass them back in to set
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>> your
>>>>>>
>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> location.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> If you pass the lat/lon coords back into FE (set your
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>> location to
>>>>>>
>>>>>>
>>>>>>>>>>>>> "43.555286407499999, -79.581794738799999") it'll
>>>>>>>>>>>>> reverse-geocode
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> from
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> there, put you in approximately the right place, and give you
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> "Lakeshore
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Rd E, Mississauga, Ontario, Canada". Passing *that* back into
>>>>>>>>>>>>> FE
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> also
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> puts you at Hurontario and Lakeshore. I wouldn't count on being
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> able to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> do this all the time but it does seem to work here. (Internally
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> it's
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> geocoding it to L5G, a postcode, which seems to be centered on
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>> that
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> intersection).
>>>>>>>>>>>>>
>>>>>>>>>>>>> In general, if you get a woeid from an API response, setting
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>> your
>>>>>>
>>>>>>
>>>>>>>>>>>>> location to that woeid should always bring you back to the
>>>>>>>>>>>>> right
>>>>>>>>>>>>> location, but exact points are trickier. Probably the most
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>> reliable
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> way
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> of getting back to an exact point is passing us the lat/lon
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> co-ordinates
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> rather than the string we return to you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> nlb0666 wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hey Tom any progress here? As far as I can tell, round
>>>>>>>>>>>>>> tripping
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>> from the app to FireEagle to the app using an intersection as a
>>>>>>>>>>>> location still screws up and results in the user being
>>>>>>>>>>>> "somewhere
>>>>>>>>>>>> else" at the end. THe problem appears to be that fireeagle
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> does not
>>>>>>
>>>>>>
>>>>>>>>>>>> pass back an intersection as the new location, so the new
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> input will
>>>>>>
>>>>>>
>>>>>>>>>>>> be ambiguous (ie without the cross street).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> This should probably work no?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tested again this morning using Hurontario and Lakeshore,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>> Mississauga, per the example below, and it failed.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> Also... it does appear that intersections can get resolved to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>> street addresses. Specifically "38 and Broadway" becomes "38
>>>>>>>>>>>> Broadway". I have not pinpointed them precisely, but it appears
>>>>>>>>>>>> again that passing in a string "38th and Broadway" to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> FireEagle can
>>>>>>
>>>>>>
>>>>>>>>>>>> result in a string being returned which, when passed back, will
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> become
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> "38 Broadway". This is not the only address this occurs for -
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> see the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> example below. This one is a particularly bad example as
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> "38th and
>>>>>>
>>>>>>
>>>>>>>>>>>> Broadway" does not locate correctly from the fireeagle user
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> accessible
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> website at any time.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> Please advise
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It's possible that the data we're using isn't terribly good
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>>>>>>>>>>>>> handling intersections. I'll dig into it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 19 May 2008, at 06:59, nlb0666 wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I tested this a little more over the weekend. It worked
>>>>>>>>>>>>>>>> well,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> but I
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> did have a problem with intersections. For example, feeding
>>>>>>>>>>>>>>>> Hurontario and Lakeshore, Mississauga, Ontario correctly
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>> locates
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> you
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> at that intersection. But Fire Eagle returns the location as
>>>>>>>>>>>>>>>> Hurontario St, Mississauga, Ontario. If I enter THAT
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>> location
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> into
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Fire Eagle, it will put me at Hurontario and Burnamthorpe.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So: if I give Fire Eagle the location as an intersection,
>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> location from Fire Eagle, and then give that string back to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> Fire
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> Eagle, I'll have moved.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> From an app perspective, it would be nice if giving an
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> intersection
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> in resulted in getting an intersection back so that the
>>>>>>>>>>>>>>>> above
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> would
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> work consistently. If an intersection cannot be returned,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> then at
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> least a street address "123 hurontario" (or whatever is
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>> nearest
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> intersection), so that giving the string back to Fire Eagle
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> would
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> maintain my location. If I'm missing the point here, please
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> advise.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> I had a problem with another intersection "78th st and 2nd
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>> ave,
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> New
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> York". I believe at some point my app gave fire eagle, or
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> fire
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> eagle gave me, the string "78 and 2nd, New York". Yahoo
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>> Maps
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>> geocodes this as "78 2nd Avenue", not as "78th and 2nd ave".
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> I
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> will need to look at this more to figure out whether Fire
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>> Eagle or
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> we were the culprit.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ooops sorry to reply to myself - just realize you'd asked
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>> invite
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>> requests to be emailed elsewhere, so I'll email you
>>>>>>>>>>>>>>>>> there....
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>> my
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>> reading skills ARE improving :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I've done some initial testing and it looks good! I'll
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>> play
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> more
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> over the next few days and make sure we don't see any
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>> breaks.
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> But
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> first tests, on both toronto and new york, updating both
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>> via
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>> address and via lat lon (which I then removed as we want
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> update
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> via address) work! I found a break with 218 Bowery (this
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> Yahoo
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> geocoding incorrectly coding this as W 218th st), but
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>> otherwise,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>> so far so good....
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks guys! Jumping the gun :) now that it looks like
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>> its
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>> working for us, I'd love to get more people playing with
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> FireEagle
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> <-> liketribe (our app)... Any chance of some more
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>> invites?
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> And/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> or if you guys or anyone else on the board has a chance,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>> you'll
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>> find you can update from email, IM, or SMS (or our website
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>> of
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>> course) using street address, intersection, bookmarked
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> locations,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> or venue names at liketribe.com (sign up, make account,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>> go to
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> bottom of the "my mobile" page and click on FireEagle...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> hopefully
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> to discover it all Just Works...)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yay. Seth rocks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> nlb0666 - has this fixed the problem from your
>>>>>>>>>>>>>>>>>>> perspective?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 14 May 2008, at 19:27, Seth Fitzsimmons wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi all.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This serves to let you know that a new build of Fire
>>>>>>>>>>>>>>>>>>>> Eagle
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>> is
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> live and
>>>>>>>>>>>>>>>>>>>> kicking at fireeagle.com. Nothing new, no API changes,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>> but a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>>>> of bugs
>>>>>>>>>>>>>>>>>>>> were squished that were causing some precise locations
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>> to be
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>>>> dropped
>>>>>>>>>>>>>>>>>>>> (some
>>>>>>>>>>>>>>>>>>>> locations in NYC, Ontario, etc.).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On my radar for tomorrow are lat/lons in Singapore and
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> middle
>>>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>>>> Pacific as well as a few other things that have come up
>>>>>>>>>>>>>>>>>>>> internally.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Let me know (via the list) if you're continuing to
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>> bump into
>>>>>>
>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> weird
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> geocoding
>>>>>>>>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> thanks.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> seth
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>
>

Good news... this is all go, not implemented yet but will be relatively
soon.  Look for a <query> element appearing inside 'exact' level
<location> elements in the near future!

It will be formatted as a query string, e.g.:

     q=500%203rd%20st,%20san%20francisco,%20ca
     woeid=12345
     lat=15.0&lon=25.0

Also we've gone through and added 'located-at' attributes to a bunch of
places, in most of the API methods.  So now (or soon) when you update
you'll get:

     <user token="i71yc3myixg3" located-at="2008-08-06T16:04:46+12:00"/>

... which is exactly what you'll see in the response from 'recent' and
part of what 'user' will give you.  So if you stash the update timestamp
along with your user, you'll be able to tell if you've seen this update
before, and thus don't need to call 'user'.  If the update came from
your app, you probably have your own idea of what the location means and
may not want to re-geocode it.  (Of course you're welcome to call 'user'
and use our geocoding if you don't already have one).

Cheers,
Phil

Phillip Pearson wrote:
> Still have to talk this over within the team... will get back to the
> list once we have something definite.
>
> Cheers,
> Phil
>
> Aditya Chadha wrote:
>> Phil,
>>
>> This is awesome - thank you!
>>
>> What about the other idea you had to send the actual address that was
>> passed in back to the person asking for the address? So, if I put 57th
>> and Broadway, NY, NY into FireEagle and then ask for it back using the
>> API, the returned data set includes both the geocoded address (W 57th
>> St, NY, NY) and the address that I passed in (57th and Broadway, NY,
>> NY) so that our apps can geocode the address ourselves?
>>
>> Cheers,
>> Aditya
>>
>> --
>> Aditya (http://aditya.sublucid.com/)
>>
>>
>>
>> On Tue, Aug 5, 2008 at 7:40 AM, Phillip Pearson <pp@...> wrote:
>>
>>> Some good news... I have got Fire Eagle to recognize intersections.
>>> This'll go out in the next code deploy, along with the New
>>> York-specific
>>> change to include the borough in addresses.
>>>
>>> The bad news is that our geocoder seems to treat Broadway oddly so
>>> "57th
>>> and broadway" will continue to not work quite right.
>>>
>>> The "hurontario and lakeshore, mississauga" example that nlb066 brought
>>> up some time back now works nicely.
>>>
>>> Experimenting a bit, it looks like it has trouble with things like
>>> "42nd
>>> and 5th, nyc" but can cope with things like "42nd st and madison ave,
>>> new york, ny" (which becomes "E 42nd St & Madison Ave, New York, NY")
>>> and "22nd and 5th ave, nyc" (which becomes "W 22nd St & 5th Ave, New
>>> York, NY"). "5th and 42nd, nyc" works, though (it becomes "5th Ave & E
>>> 42nd St, New York, NY").
>>>
>>> Cheers,
>>> Phil
>>>
>>> pherric2000 wrote:
>>>
>>>> So, was this ever fixed?
>>>>
>>>> We're having major trouble with the 'best guess' returned for any
>>>> intersections eg. 57th
>>>> and Broadway, NY, NY becomes W 57th St, NY, NY (incomplete address)
>>>>
>>>> Other addresses that break are those common to Brooklyn and Manhattan,
>>>> including:
>>>>
>>>> 1) 613 11th St, Brooklyn, NY -> 613 W11th St, NY
>>>> 2) 20 Jay St, Brooklyn, NY -> 20 Jay St, NY
>>>> 3) 83 Wyckoff St, Brooklyn, NY -> 83 Wyckoff St, NY
>>>>
>>>> Looks like FireEagle/Yahoo somehow drop the borough or something?
>>>> Not sure
>>>> what is
>>>> causing intersection geocoding to break, but this pretty much makes FE
>>>> un-usable for the
>>>> New York area.
>>>>
>>>> Any ideas would be greatly appreciated.
>>>>
>>>> Cheers,
>>>> Aditya
>>>>
>>>>
>>>> --- In fireeagle@yahoogroups.com, nlb0666 <no_reply@...> wrote:
>>>>
>>>>
>>>>> Phil - that sounds reasonable. Lemme give it a shot and see if
>>>>> that'll help us out.
>>>>>
>>>>> I suppose the remaining problem would be if two alternative services
>>>>> were sharing location via fireagle. Ie your app posted an
>>>>> intersection to FireEagle, my app picks it up from FireEagle (and its
>>>>> not an intersection any more), then geocodes it to a different place.
>>>>>
>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>
>>>>>
>>>>>> One possible solution here... I think the 'user' method currently
>>>>>> returns a timestamp for the update, or for the individual location
>>>>>> levels -- you could compare this with your own internal "last moved"
>>>>>> time and ignore the update if it's within a minute or so. How does
>>>>>>
>>>>>>
>>>>> that
>>>>>
>>>>>
>>>>>> sound?
>>>>>>
>>>>>> We're also thinking about putting timestamps on the tokens returned
>>>>>>
>>>>>>
>>>>> from
>>>>>
>>>>>
>>>>>> the 'recent' method, so you can do this without even retrieving the
>>>>>>
>>>>>>
>>>>> full
>>>>>
>>>>>
>>>>>> location - should make it a bit more convenient to poll FE as
>>>>>> you'll be
>>>>>> able to just retrieve the new updates.
>>>>>>
>>>>>> Cheers,
>>>>>> Phil
>>>>>>
>>>>>> nlb0666 wrote:
>>>>>>
>>>>>>
>>>>>>> Phil - its basically option #3. We're trying not to thrash
>>>>>>> fireeagle,
>>>>>>> so we only talk to fireeagle either a) to retrieve the location,
>>>>>>> if we
>>>>>>> haven't been spoken to by the user in 10 min, or b) to give
>>>>>>> fireeagle
>>>>>>> the location, if the user gave us one.
>>>>>>>
>>>>>>> So our problem scenario is: we get an intersection from the
>>>>>>> user, we
>>>>>>> give it to fireeagle, the user goes away for more than 10 min,
>>>>>>> on the
>>>>>>> users return we ask fireeagle if they've got an updated location
>>>>>>> - and
>>>>>>> - its different! So we grab whats returned - essentially a
>>>>>>> thoroughfare in OASIS terms, or a lat/lon that may not
>>>>>>> correspond to
>>>>>>> the lat/long our geocoder gave us - and set a new location.
>>>>>>>
>>>>>>> This interplay results in the user moving around. If FireEagle
>>>>>>> either
>>>>>>> notified us on an event basis (so we wouldn't have to guess if
>>>>>>> it was
>>>>>>> giving us back the same thing), or kept the "original string",
>>>>>>> so we
>>>>>>> could infer it was the same thing, or returned a "proper"
>>>>>>> intersection, that would geocode back to the same place, we'd be in
>>>>>>> business.
>>>>>>>
>>>>>>> Re signup - thanks for the feedback (and any other you might have).
>>>>>>> The service works only in certain cities, and we found people
>>>>>>> struggled a *lot* with the notion of location (as I'm sure you are
>>>>>>> finding!) so we tried to get them to pick a valid supported
>>>>>>> location
>>>>>>> on signup.
>>>>>>>
>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Yep, I'm in now, have authorized it with Fire Eagle, and all
>>>>>>>>
>>>>>>>>
>>>>> looks good
>>>>>
>>>>>
>>>>>>>> so far.
>>>>>>>>
>>>>>>>> I take it that the reason you want to be able to update with the
>>>>>>>> location string FE gives you is for the bookmark function? Or
>>>>>>>>
>>>>>>>>
>>>>> are you
>>>>>
>>>>>
>>>>>>>> setting the FE location first, then using that to geocode for
>>>>>>>>
>>>>>>>>
>>>>> your map
>>>>>
>>>>>
>>>>>>>> display? Or is the problem that you end up getting the update
>>>>>>>>
>>>>>>>>
>>>>> from FE
>>>>>
>>>>>
>>>>>>>> 10 mins later, and it looks like a new location, because it's
>>>>>>>>
>>>>>>>>
>>>>> different
>>>>>
>>>>>
>>>>>>>> from before? (I'm trying to figure out where the issue lies here).
>>>>>>>>
>>>>>>>> A note: it would be nice if the account setup process didn't
>>>>>>>> require
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> you
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> to give your gender/age/zip code. Most people will put in a fake
>>>>>>>>
>>>>>>>>
>>>>> age,
>>>>>
>>>>>
>>>>>>>> and I'm actually outside the US so I put in the zipcode for
>>>>>>>>
>>>>>>>>
>>>>> Brickhouse
>>>>>
>>>>>
>>>>>>>> rather than for where I actually am (Christchurch, New Zealand).
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> nlb0666 wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Phil - tks for taking a look. Did the email ever make it
>>>>>>>>>
>>>>>>>>>
>>>>> through? I
>>>>>
>>>>>
>>>>>>>>> checked this morning and it didn't look like it did. I'll hit you
>>>>>>>>> with a direct note as well
>>>>>>>>>
>>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> One thing we could probably do would be to give you back the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> query you
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> used to set the location in the first place, as long as the
>>>>>>>>>>
>>>>>>>>>>
>>>>> user has
>>>>>
>>>>>
>>>>>>>>>> given you permission to see their exact location. This would
>>>>>>>>>> be a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> hash,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> something like {q: 'hurontario and lakesure, mississauga'} or
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> {woeid:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> '123456789'} (to use javascript notation), that would put you
>>>>>>>>>> back
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> there
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> if passed to us. In some cases we could do this as a string, and
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> if it
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> was useful we could get FE to parse woeids etc out of strings
>>>>>>>>>> like
>>>>>>>>>> "woeid:123456789", so we could just give you a string...
>>>>>>>>>>
>>>>>>>>>> Just signed up to liketribe to see what you're actually
>>>>>>>>>> doing, so
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> once
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> the e-mail verification msg makes it through my greylist filter,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I'll be
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> able to get a better idea of what you need :)
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>> nlb0666 wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Ok we can implement that as a workaround, but it is painful.
>>>>>>>>>>>
>>>>>>>>>>> Why? Because fireeagle isn't the only source of location data
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> for our
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> application. Nor are the fireeagle lat/lon for a given
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> address the
>>>>>
>>>>>
>>>>>>>>>>> same as our underlying geocoder. So if we use lat/lon,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> effectively
>>>>>
>>>>>
>>>>>>>>>>> the user "slides down the street" as different services reverse
>>>>>>>>>>> geocode differently. If we use the woeid, this is a code
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> unique to
>>>>>
>>>>>
>>>>>>>>>>> you guys, so we have to do a bunch of work to figure out if the
>>>>>>>>>>> address we gave to fireeagle is the same as the text string
>>>>>>>>>>> we had
>>>>>>>>>>> (since your returned text string is not the same as we gave
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> you), and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> then remember, in those cases, to speak special fire eagle
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> language.
>>>>>
>>>>>
>>>>>>>>>>> So this is a fairly large disappointment that for us at least
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> really
>>>>>
>>>>>
>>>>>>>>>>> increases the amount of work to do "proper" fire eagle
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> integration.
>>>>>
>>>>>
>>>>>>>>>>> From an app pov, it would be much nicer to remember the
>>>>>>>>>>> string you
>>>>>>>>>>> were given and pass it back
>>>>>>>>>>>
>>>>>>>>>>> --- In fireeagle@yahoogroups.com, Phillip Pearson <pp@> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> OK, so looking at the underlying data, our geocoder has
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> recognized
>>>>>
>>>>>
>>>>>>>>>>>> "Hurontario and Lakeshore, Mississauga" as an intersection and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> geocoded
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> it correctly, but the data it returns to FireEagle doesn't
>>>>>>>>>>>> even
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> mention
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> Lakeshore at all, so what you see on the site or via the
>>>>>>>>>>>> API is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> just
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> "Hurontario St". I'm afraid that's the best we can do for now,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> you'll have to assume that location names returned from
>>>>>>>>>>>> FireEagle
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> won't
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> necessarily geocode correctly if you pass them back in to set
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> your
>>>>>
>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> location.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> If you pass the lat/lon coords back into FE (set your
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> location to
>>>>>
>>>>>
>>>>>>>>>>>> "43.555286407499999, -79.581794738799999") it'll
>>>>>>>>>>>> reverse-geocode
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> from
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> there, put you in approximately the right place, and give you
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> "Lakeshore
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Rd E, Mississauga, Ontario, Canada". Passing *that* back
>>>>>>>>>>>> into FE
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> also
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> puts you at Hurontario and Lakeshore. I wouldn't count on
>>>>>>>>>>>> being
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> able to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> do this all the time but it does seem to work here.
>>>>>>>>>>>> (Internally
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> it's
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> geocoding it to L5G, a postcode, which seems to be centered on
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> that
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> intersection).
>>>>>>>>>>>>
>>>>>>>>>>>> In general, if you get a woeid from an API response, setting
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> your
>>>>>
>>>>>
>>>>>>>>>>>> location to that woeid should always bring you back to the
>>>>>>>>>>>> right
>>>>>>>>>>>> location, but exact points are trickier. Probably the most
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> reliable
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> way
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> of getting back to an exact point is passing us the lat/lon
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> co-ordinates
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> rather than the string we return to you.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Phil
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> nlb0666 wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey Tom any progress here? As far as I can tell, round
>>>>>>>>>>>>> tripping
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> from the app to FireEagle to the app using an intersection as a
>>>>>>>>>>> location still screws up and results in the user being
>>>>>>>>>>> "somewhere
>>>>>>>>>>> else" at the end. THe problem appears to be that fireeagle
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> does not
>>>>>
>>>>>
>>>>>>>>>>> pass back an intersection as the new location, so the new
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> input will
>>>>>
>>>>>
>>>>>>>>>>> be ambiguous (ie without the cross street).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> This should probably work no?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tested again this morning using Hurontario and Lakeshore,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> Mississauga, per the example below, and it failed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Also... it does appear that intersections can get resolved to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> street addresses. Specifically "38 and Broadway" becomes "38
>>>>>>>>>>> Broadway". I have not pinpointed them precisely, but it appears
>>>>>>>>>>> again that passing in a string "38th and Broadway" to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> FireEagle can
>>>>>
>>>>>
>>>>>>>>>>> result in a string being returned which, when passed back, will
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> become
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> "38 Broadway". This is not the only address this occurs for -
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> see the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> example below. This one is a particularly bad example as
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> "38th and
>>>>>
>>>>>
>>>>>>>>>>> Broadway" does not locate correctly from the fireeagle user
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> accessible
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>> website at any time.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Please advise
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's possible that the data we're using isn't terribly good
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>> at
>>>>>
>>>>>
>>>>>>>>>>>>>> handling intersections. I'll dig into it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 19 May 2008, at 06:59, nlb0666 wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I tested this a little more over the weekend. It worked
>>>>>>>>>>>>>>> well,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> but I
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> did have a problem with intersections. For example, feeding
>>>>>>>>>>>>>>> Hurontario and Lakeshore, Mississauga, Ontario correctly
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> locates
>>>>>
>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> you
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> at that intersection. But Fire Eagle returns the
>>>>>>>>>>>>>>> location as
>>>>>>>>>>>>>>> Hurontario St, Mississauga, Ontario. If I enter THAT
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> location
>>>>>
>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> into
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> Fire Eagle, it will put me at Hurontario and Burnamthorpe.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So: if I give Fire Eagle the location as an
>>>>>>>>>>>>>>> intersection, get
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> location from Fire Eagle, and then give that string back to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>> Fire
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> Eagle, I'll have moved.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From an app perspective, it would be nice if giving an
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> intersection
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> in resulted in getting an intersection back so that the
>>>>>>>>>>>>>>> above
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> would
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> work consistently. If an intersection cannot be returned,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> then at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> least a street address "123 hurontario" (or whatever is
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> nearest
>>>>>
>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> that
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> intersection), so that giving the string back to Fire Eagle
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> would
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> maintain my location. If I'm missing the point here, please
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> advise.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> I had a problem with another intersection "78th st and 2nd
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> ave,
>>>>>
>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> New
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> York". I believe at some point my app gave fire eagle, or
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>> fire
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> eagle gave me, the string "78 and 2nd, New York". Yahoo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> Maps
>>>>>
>>>>>
>>>>>>>>>>>>>>> geocodes this as "78 2nd Avenue", not as "78th and 2nd
>>>>>>>>>>>>>>> ave".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>> I
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> will need to look at this more to figure out whether Fire
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>> Eagle or
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> we were the culprit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ooops sorry to reply to myself - just realize you'd asked
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>> invite
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>> requests to be emailed elsewhere, so I'll email you
>>>>>>>>>>>>>>>> there....
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>> my
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>> reading skills ARE improving :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --- snowleo wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've done some initial testing and it looks good! I'll
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> play
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> more
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> over the next few days and make sure we don't see any
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> breaks.
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> But
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> first tests, on both toronto and new york, updating both
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> via
>>>>>
>>>>>
>>>>>>>>>>>>>>>>> address and via lat lon (which I then removed as we
>>>>>>>>>>>>>>>>> want to
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> update
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> via address) work! I found a break with 218 Bowery
>>>>>>>>>>>>>>>>> (this is
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> Yahoo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> geocoding incorrectly coding this as W 218th st), but
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>> otherwise,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>> so far so good....
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks guys! Jumping the gun :) now that it looks like
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> its
>>>>>
>>>>>
>>>>>>>>>>>>>>>>> working for us, I'd love to get more people playing with
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> FireEagle
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <-> liketribe (our app)... Any chance of some more
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> invites?
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> And/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> or if you guys or anyone else on the board has a chance,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>> you'll
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>> find you can update from email, IM, or SMS (or our
>>>>>>>>>>>>>>>>> website
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>> of
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> course) using street address, intersection, bookmarked
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> locations,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> or venue names at liketribe.com (sign up, make account,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>> go to
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> bottom of the "my mobile" page and click on FireEagle...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> hopefully
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> to discover it all Just Works...)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --- Tom Coates wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yay. Seth rocks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> nlb0666 - has this fixed the problem from your
>>>>>>>>>>>>>>>>>> perspective?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 14 May 2008, at 19:27, Seth Fitzsimmons wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi all.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This serves to let you know that a new build of Fire
>>>>>>>>>>>>>>>>>>> Eagle
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>> is
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>>>> live and
>>>>>>>>>>>>>>>>>>> kicking at fireeagle.com. Nothing new, no API changes,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>> but a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>>> of bugs
>>>>>>>>>>>>>>>>>>> were squished that were causing some precise locations
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>> to be
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>>>> dropped
>>>>>>>>>>>>>>>>>>> (some
>>>>>>>>>>>>>>>>>>> locations in NYC, Ontario, etc.).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On my radar for tomorrow are lat/lons in Singapore
>>>>>>>>>>>>>>>>>>> and in
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>>>> middle
>>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>>> Pacific as well as a few other things that have come up
>>>>>>>>>>>>>>>>>>> internally.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Let me know (via the list) if you're continuing to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>> bump into
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>> weird
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> geocoding
>>>>>>>>>>>>>>>>>>> issues.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> seth
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>
>

Another update for you all -- the 'time' parameter hasn't been working
in the 'recent' API method.  That's fixed now, I think, and will go out
in the next code deploy.

So you'll be able to:

- call recent with no params -> tokens for the 10 most recently located
users (reverse chrono order)
- call recent with start=10, count=10 -> second page of most recently
located users (reverse chrono order)
- call recent with time=(1 hour ago) -> first 10 movements since 1 hour ago

... and so on.

Cheers,
Phil

How does FireEagle identify a "user"? By IP address? That won't work very well from behind a NAT...

 

I'd like to be able to have several robots running on my workstation, registered with FE and updating their location, in order to test my app. How can I differentiate them?

 

Thanks.