It''s been a while since the W3C geolocation API came out into the open and more and more Javascript Maps APIs are now supporting this natively rather than the W3G navigator.geolocation API call. Should this be something that we should include and support as part of the MXN API? An admittedly cursory trawl through the native Maps APIs that we support in MXN shows that Bing v7, Google v3 and Nokia do natively support geolocation. MapQuest, GeoCommons, Cloudmade, OpenLayers and OpenSpace don''t. I wasn''t able to look into Yandex in too much detail as I don''t speak Russian and Google Translate barfs at the deeper reaches of the Yandex web site. Admittedly only 3 of the support Maps APIs provide native geolocation support but for the others one could (hopefully) easily fall back on the W3C geolocation API. Throwing this out for general discussion, is this something we should think about formalising in the MXN API? I''m more than happy to give it a crack implementation wise but I don''t want to waste time and effort on something that the general MXN community is against. Thoughts? Best G -- gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale | www.garygale.com
I don''t understand what the mapping providers are doing that is better than the W3C geolocation API. Would we be writing wrappers for others wrappers of the W3C API when the client could just call it directly? Forgive me if I''m missing something, maybe you could link me to an example that illustrates the benefit? I''m not against the idea, just need a couple of pointer to learn more. -dylan- On Wed, Oct 5, 2011 at 4:08 AM, Gary Gale <gary at vicchi.org> wrote:> It''s been a while since the W3C geolocation API came out into the open and > more and more Javascript Maps APIs are now supporting this natively rather > than the W3G navigator.geolocation API call. > > Should this be something that we should include and support as part of the > MXN API? > > An admittedly cursory trawl through the native Maps APIs that we support in > MXN shows that Bing v7, Google v3 and Nokia do natively support geolocation. > MapQuest, GeoCommons, Cloudmade, OpenLayers and OpenSpace don''t. I wasn''t > able to look into Yandex in too much detail as I don''t speak Russian and > Google Translate barfs at the deeper reaches of the Yandex web site. > > Admittedly only 3 of the support Maps APIs provide native geolocation > support but for the others one could (hopefully) easily fall back on the W3C > geolocation API. > > Throwing this out for general discussion, is this something we should think > about formalising in the MXN API? > > I''m more than happy to give it a crack implementation wise but I don''t want > to waste time and effort on something that the general MXN community is > against. > > Thoughts? > > Best > > G > > > -- > gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale | > www.garygale.com > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20111007/d5022dad/attachment.htm>
Some of them offer IP-based geolocation that works even if the browser doesn''t have (or the user refuses) wi-fi or gps based lookups. Wrapping with their own API also offers the chance to use other heuristics (for example Google knows my home city from other applications*) or even use simple tricks like time-zone to get a starting point. Tom. * I don''t know if they use this but they could. On 7 October 2011 07:35, Dylan Kuhn <dylan.k.kuhn at gmail.com> wrote:> I don''t understand what the mapping providers are doing that is better than > the W3C geolocation API. Would we be writing wrappers for others wrappers of > the W3C API when the client could just call it directly? Forgive me if I''m > missing something, maybe you could link me to an example that illustrates > the benefit? I''m not against the idea, just need a couple of pointer to > learn more. > -dylan- > > On Wed, Oct 5, 2011 at 4:08 AM, Gary Gale <gary at vicchi.org> wrote: >> >> It''s been a while since the W3C geolocation API came out into the open and >> more and more Javascript Maps APIs are now supporting this natively rather >> than the W3G navigator.geolocation API call. >> >> Should this be something that we should include and support as part of the >> MXN API? >> >> An admittedly cursory trawl through the native Maps APIs that we support >> in MXN shows that Bing v7, Google v3 and Nokia do natively support >> geolocation. MapQuest, GeoCommons, Cloudmade, OpenLayers and OpenSpace >> don''t. I wasn''t able to look into Yandex in too much detail as I don''t speak >> Russian and Google Translate barfs at the deeper reaches of the Yandex web >> site. >> >> Admittedly only 3 of the support Maps APIs provide native geolocation >> support but for the others one could (hopefully) easily fall back on the W3C >> geolocation API. >> >> Throwing this out for general discussion, is this something we should >> think about formalising in the MXN API? >> >> I''m more than happy to give it a crack implementation wise but I don''t >> want to waste time and effort on something that the general MXN community is >> against. >> >> Thoughts? >> >> Best >> >> G >> >> >> -- >> gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale | >> www.garygale.com >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >
Here''s my overall thinking on this ... Firstly the W3C geolocation API isn''t without its quirks; a quick trawl through your search engine of choice reveals that there''s a plethora of wrappers around the basic core W3C API which try to take into account desktop/laptop browser vs. mobile browser quirks and differing implementations across the varying browsers, to name but a few of the reasons. Secondly, as Tom points out, the native maps APIs implementations (often) take into account other sensors in addition to the core W3C implementation, as well as ironing out differing browser support and the like. Thirdly, people are creatures of habit. Though I have no firm empirical evidence to back this up I can easily foresee someone using MXN and wanting to use geolocation; as MXN doesn''t currently support geolocation it''s not unfair to assume that they''d use the native maps API implementation which is provided by the API they''re using via MXN, rather than "raw" W3C geolocation. If they then want to change providers then they need to rewrite their geolocation support. I don''t think this classes as writing wrappers of other wrappers but merely enhancing MXN to support an extremely useful technology. I see the actual implementation panning out as follows ... We add a geolocation function to the core MXN source file which returns a new GeoLocation object. When invoked, MXN.geolocation calls the currently used native MXN wrapper. If this supports native geolocation, that method gets invoked. If this doesn''t support native geolocation we degrade gracefully to a simple W3C APi call. This way, we support base geolocation across the board and allow one of MXN''s core strengths to shine through, namely the ease of swapping native API providers with no re-coding needed other than including the new provider''s JS source and changing the provider name when MXN in instantiated. I appreciate that this is a bit of a brain dump but hopefully it shows my thinking ... unless there''s strong objections and a sense of "even if you write this it won''t get merged into the main trunk", I''ll probably get started on a trial implementation in my fork of MXN on github.com ... And now, over the to the MXN community for frank and open discussion :-) ! G On 7 Oct 2011, at 16:28, Tom Carden wrote:> Some of them offer IP-based geolocation that works even if the browser > doesn''t have (or the user refuses) wi-fi or gps based lookups. > Wrapping with their own API also offers the chance to use other > heuristics (for example Google knows my home city from other > applications*) or even use simple tricks like time-zone to get a > starting point. > > Tom. > > * I don''t know if they use this but they could. > > On 7 October 2011 07:35, Dylan Kuhn <dylan.k.kuhn at gmail.com> wrote: >> I don''t understand what the mapping providers are doing that is better than >> the W3C geolocation API. Would we be writing wrappers for others wrappers of >> the W3C API when the client could just call it directly? Forgive me if I''m >> missing something, maybe you could link me to an example that illustrates >> the benefit? I''m not against the idea, just need a couple of pointer to >> learn more. >> -dylan- >> >> On Wed, Oct 5, 2011 at 4:08 AM, Gary Gale <gary at vicchi.org> wrote: >>> >>> It''s been a while since the W3C geolocation API came out into the open and >>> more and more Javascript Maps APIs are now supporting this natively rather >>> than the W3G navigator.geolocation API call. >>> >>> Should this be something that we should include and support as part of the >>> MXN API? >>> >>> An admittedly cursory trawl through the native Maps APIs that we support >>> in MXN shows that Bing v7, Google v3 and Nokia do natively support >>> geolocation. MapQuest, GeoCommons, Cloudmade, OpenLayers and OpenSpace >>> don''t. I wasn''t able to look into Yandex in too much detail as I don''t speak >>> Russian and Google Translate barfs at the deeper reaches of the Yandex web >>> site. >>> >>> Admittedly only 3 of the support Maps APIs provide native geolocation >>> support but for the others one could (hopefully) easily fall back on the W3C >>> geolocation API. >>> >>> Throwing this out for general discussion, is this something we should >>> think about formalising in the MXN API? >>> >>> I''m more than happy to give it a crack implementation wise but I don''t >>> want to waste time and effort on something that the general MXN community is >>> against. >>> >>> Thoughts? >>> >>> Best >>> >>> G >>> >>> >>> -- >>> gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale | >>> www.garygale.com >>> >>> _______________________________________________ >>> Mapstraction mailing list >>> Mapstraction at lists.mapstraction.com >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
Ok, thanks, I can see the motivation. It sounds like a good candidate to follow the pattern used now for geocoders, so you can load the geolocation module only when you need the functionality. -dylan- On Mon, Oct 10, 2011 at 1:42 AM, Gary Gale <gary at vicchi.org> wrote:> Here''s my overall thinking on this ... > > Firstly the W3C geolocation API isn''t without its quirks; a quick trawl > through your search engine of choice reveals that there''s a plethora of > wrappers around the basic core W3C API which try to take into account > desktop/laptop browser vs. mobile browser quirks and differing > implementations across the varying browsers, to name but a few of the > reasons. > > Secondly, as Tom points out, the native maps APIs implementations (often) > take into account other sensors in addition to the core W3C implementation, > as well as ironing out differing browser support and the like. > > Thirdly, people are creatures of habit. Though I have no firm empirical > evidence to back this up I can easily foresee someone using MXN and wanting > to use geolocation; as MXN doesn''t currently support geolocation it''s not > unfair to assume that they''d use the native maps API implementation which is > provided by the API they''re using via MXN, rather than "raw" W3C > geolocation. If they then want to change providers then they need to rewrite > their geolocation support. > > I don''t think this classes as writing wrappers of other wrappers but merely > enhancing MXN to support an extremely useful technology. > > I see the actual implementation panning out as follows ... > > We add a geolocation function to the core MXN source file which returns a > new GeoLocation object. When invoked, MXN.geolocation calls the currently > used native MXN wrapper. If this supports native geolocation, that method > gets invoked. If this doesn''t support native geolocation we degrade > gracefully to a simple W3C APi call. > > This way, we support base geolocation across the board and allow one of > MXN''s core strengths to shine through, namely the ease of swapping native > API providers with no re-coding needed other than including the new > provider''s JS source and changing the provider name when MXN in > instantiated. > > I appreciate that this is a bit of a brain dump but hopefully it shows my > thinking ... unless there''s strong objections and a sense of "even if you > write this it won''t get merged into the main trunk", I''ll probably get > started on a trial implementation in my fork of MXN on github.com ... > > And now, over the to the MXN community for frank and open discussion :-) ! > > G > > On 7 Oct 2011, at 16:28, Tom Carden wrote: > > > Some of them offer IP-based geolocation that works even if the browser > > doesn''t have (or the user refuses) wi-fi or gps based lookups. > > Wrapping with their own API also offers the chance to use other > > heuristics (for example Google knows my home city from other > > applications*) or even use simple tricks like time-zone to get a > > starting point. > > > > Tom. > > > > * I don''t know if they use this but they could. > > > > On 7 October 2011 07:35, Dylan Kuhn <dylan.k.kuhn at gmail.com> wrote: > >> I don''t understand what the mapping providers are doing that is better > than > >> the W3C geolocation API. Would we be writing wrappers for others > wrappers of > >> the W3C API when the client could just call it directly? Forgive me if > I''m > >> missing something, maybe you could link me to an example that > illustrates > >> the benefit? I''m not against the idea, just need a couple of pointer to > >> learn more. > >> -dylan- > >> > >> On Wed, Oct 5, 2011 at 4:08 AM, Gary Gale <gary at vicchi.org> wrote: > >>> > >>> It''s been a while since the W3C geolocation API came out into the open > and > >>> more and more Javascript Maps APIs are now supporting this natively > rather > >>> than the W3G navigator.geolocation API call. > >>> > >>> Should this be something that we should include and support as part of > the > >>> MXN API? > >>> > >>> An admittedly cursory trawl through the native Maps APIs that we > support > >>> in MXN shows that Bing v7, Google v3 and Nokia do natively support > >>> geolocation. MapQuest, GeoCommons, Cloudmade, OpenLayers and OpenSpace > >>> don''t. I wasn''t able to look into Yandex in too much detail as I don''t > speak > >>> Russian and Google Translate barfs at the deeper reaches of the Yandex > web > >>> site. > >>> > >>> Admittedly only 3 of the support Maps APIs provide native geolocation > >>> support but for the others one could (hopefully) easily fall back on > the W3C > >>> geolocation API. > >>> > >>> Throwing this out for general discussion, is this something we should > >>> think about formalising in the MXN API? > >>> > >>> I''m more than happy to give it a crack implementation wise but I don''t > >>> want to waste time and effort on something that the general MXN > community is > >>> against. > >>> > >>> Thoughts? > >>> > >>> Best > >>> > >>> G > >>> > >>> > >>> -- > >>> gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale| > >>> www.garygale.com > >>> > >>> _______________________________________________ > >>> Mapstraction mailing list > >>> Mapstraction at lists.mapstraction.com > >>> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >> > >> > >> _______________________________________________ > >> Mapstraction mailing list > >> Mapstraction at lists.mapstraction.com > >> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >> > >> > > _______________________________________________ > > Mapstraction mailing list > > Mapstraction at lists.mapstraction.com > > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20111010/09d686f0/attachment.htm>