Re: skeleton Geolocation API

Sure - they're are several geo APIs in the industry. The key point for us is
to understand the level we're pitching this Web API at. We're targetting Web
developers in a client-side scripting environment. As such, our API design
will be higher level than typical native APIs. One might draw the analogy of
XHR to MIDP's HttpConnection.

Dave

On Sat, Jun 28, 2008 at 12:36 AM, Kartikaya Gupta <
lists.geolocation@stakface.com> wrote:

>
> On Fri, 27 Jun 2008 21:15:16 +0100, "Andrei Popescu" <andreip@google.com>
> wrote:
> > On Fri, Jun 27, 2008 at 12:42 AM, Chris Butler <cbutler@dash.net> wrote:
> > >
> > > One more request for the position is to have a heading vector
> > > potentially with estimated speed.
> > >
> >
> > Nice idea. I think many implementations will not support these but
> > it's probably worth having them in the spec. What do other people
> > think?
>
> Sounds like a good idea.
>
> Also, I'm not sure how many people are familiar with JSR179, which adds a
> Location API to J2ME/CLDC1.1. It's probably worth taking a look at if you
> haven't. There's javadoc for it online at
> http://www-users.cs.umn.edu/~czhou/docs/jsr179/lapi/<http://www-users.cs.umn.edu/%7Eczhou/docs/jsr179/lapi/>among other places.
>
> Note that they have the concept of a "Landmark" which provides a mapping
> between a name and a coordinate set (and optionally an "AddressInfo"). They
> also have a "Criteria" object which allows for much more granular control
> over what the device should and shouldn't do when trying to obtain a
> location. It seems like a bit of overkill on that one, but I guess they
> figured better safe than sorry :)
>
> kats
>
>