Mapstraction - Feb 2009 - Mapstraction v2 architecture demo - work in progress

Hi guys,
Been working on this over the past few evenings and, although it''s not
actually working yet, I thought I''d give you a first glance.

The core mapstraction stuff is about 1800 lines with the Google
implementation code adding another 500. Original mapstraction is 5353 lines
so we''re looking at 5800 for this version if you were to include all
provider implementations but that''s not the point.

The key bits are the helper methods and classes in mxn.js, take a look in
the other two files to see how they''re used.

Have a look and let me know any thoughts. I''ll try and get it working
ASAP
but I just wanted to get this out there so you know I''m actually doing
something on it.

http://dfowler.geeksbox.co.uk/files/mapstraction-2/1/wip.htm

Cheers,
Derek

-- 
Derek Fowler
m. 07966 512 369
e. dezfowler at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090209/afe203ac/attachment.htm>

On Sun, Feb 8, 2009 at 7:40 PM, Derek Fowler <dezfowler at gmail.com>
wrote:
> Hi guys,
> Been working on this over the past few evenings and, although it''s
not
> actually working yet, I thought I''d give you a first glance.
> The core mapstraction stuff is about 1800 lines with the Google
> implementation code adding another 500. Original mapstraction is 5353 lines
> so we''re looking at 5800 for this version if you were to include
all
> provider implementations but that''s not the point.
Definitely agree re: not the point to lower overall line size. The key
here is that *everyone* had to include all lines (and subsequent size
and processing) regardless if only subset of providers desired.

Good to know that the architecture doesn''t overly bloat the entire
library though.
>
> The key bits are the helper methods and classes in mxn.js, take a look in
> the other two files to see how they''re used.
> Have a look and let me know any thoughts. I''ll try and get it
working ASAP
> but I just wanted to get this out there so you know I''m actually
doing
> something on it.
> http://dfowler.geeksbox.co.uk/files/mapstraction-2/1/wip.htm
>
The provider specific implementation looks incredibly
straight-forward. Definitely something that is easy for anyone to add
or maintain.

Can''t wait to see the example demo.

What are your thoughts Rob?
> Cheers,
> Derek
> --
> Derek Fowler
> m. 07966 512 369
> e. dezfowler at gmail.com
>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>
>


-- 
Andrew Turner
mobile: 248.982.3609
andrew at fortiusone.com
http://highearthorbit.com

http://geocommons.com           Helping build the Geospatial Web
Introduction to Neogeography - http://oreilly.com/catalog/neogeography

This makes sense to me now. It looks well organized and extensible.

Am I correct that implementing a new feature will require touching  
every provider file? Seems worth the effort for not having to dload  
all providers when you''re only using one or two.
--Adam


On Feb 8, 2009, at 5:03 PM, Andrew Turner wrote:
> On Sun, Feb 8, 2009 at 7:40 PM, Derek Fowler <dezfowler at gmail.com>
> wrote:
>> Hi guys,
>> Been working on this over the past few evenings and, although
it''s
>> not
>> actually working yet, I thought I''d give you a first glance.
>> The core mapstraction stuff is about 1800 lines with the Google
>> implementation code adding another 500. Original mapstraction is  
>> 5353 lines
>> so we''re looking at 5800 for this version if you were to
include all
>> provider implementations but that''s not the point.
>
> Definitely agree re: not the point to lower overall line size. The key
> here is that *everyone* had to include all lines (and subsequent size
> and processing) regardless if only subset of providers desired.
>
> Good to know that the architecture doesn''t overly bloat the entire
> library though.
>
>>
>> The key bits are the helper methods and classes in mxn.js, take a  
>> look in
>> the other two files to see how they''re used.
>> Have a look and let me know any thoughts. I''ll try and get it
>> working ASAP
>> but I just wanted to get this out there so you know I''m
actually
>> doing
>> something on it.
>> http://dfowler.geeksbox.co.uk/files/mapstraction-2/1/wip.htm
>>
>
> The provider specific implementation looks incredibly
> straight-forward. Definitely something that is easy for anyone to add
> or maintain.
>
> Can''t wait to see the example demo.
>
> What are your thoughts Rob?
>
>> Cheers,
>> Derek
>> --
>> Derek Fowler
>> m. 07966 512 369
>> e. dezfowler at gmail.com
>>
>> _______________________________________________
>> Mapstraction mailing list
>> Mapstraction at lists.mapstraction.com
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>
>>
>
>
>
> -- 
> Andrew Turner
> mobile: 248.982.3609
> andrew at fortiusone.com
> http://highearthorbit.com
>
> http://geocommons.com           Helping build the Geospatial Web
> Introduction to Neogeography - http://oreilly.com/catalog/neogeography
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com

If it''s a feature that requires some provider implementation then yes.
If
the implementations weren''t present you''d get a JavaScript
error when you
tried to use the particular function. I think we may need some automated
checking of which providers have implementations for which functions on
build.

One disadvantage of doing the dynamic method creation thing is that we
don''t
have function declarations for all those methods in the mapstraction file so
the automated document generation won''t work any more. I think we
should
have a dummy file that just contains the interface definition for
mapstraction that we build the documentation from.

Also, forgot to mention I''m putting together a matrix of which events
are
supported by which providers and what arguments they pass to the handler.

Derek

On Mon, Feb 9, 2009 at 7:44 AM, Adam DuVander <mapstraction at
duvander.com>wrote:
> This makes sense to me now. It looks well organized and extensible.
>
> Am I correct that implementing a new feature will require touching every
> provider file? Seems worth the effort for not having to dload all providers
> when you''re only using one or two.
> --Adam
>
>
>
> On Feb 8, 2009, at 5:03 PM, Andrew Turner wrote:
>
>  On Sun, Feb 8, 2009 at 7:40 PM, Derek Fowler <dezfowler at
gmail.com> wrote:
>>
>>> Hi guys,
>>> Been working on this over the past few evenings and, although
it''s not
>>> actually working yet, I thought I''d give you a first
glance.
>>> The core mapstraction stuff is about 1800 lines with the Google
>>> implementation code adding another 500. Original mapstraction is
5353
>>> lines
>>> so we''re looking at 5800 for this version if you were to
include all
>>> provider implementations but that''s not the point.
>>>
>>
>> Definitely agree re: not the point to lower overall line size. The key
>> here is that *everyone* had to include all lines (and subsequent size
>> and processing) regardless if only subset of providers desired.
>>
>> Good to know that the architecture doesn''t overly bloat the
entire
>> library though.
>>
>>
>>> The key bits are the helper methods and classes in mxn.js, take a
look in
>>> the other two files to see how they''re used.
>>> Have a look and let me know any thoughts. I''ll try and get
it working
>>> ASAP
>>> but I just wanted to get this out there so you know I''m
actually doing
>>> something on it.
>>> http://dfowler.geeksbox.co.uk/files/mapstraction-2/1/wip.htm
>>>
>>>
>> The provider specific implementation looks incredibly
>> straight-forward. Definitely something that is easy for anyone to add
>> or maintain.
>>
>> Can''t wait to see the example demo.
>>
>> What are your thoughts Rob?
>>
>>  Cheers,
>>> Derek
>>> --
>>> Derek Fowler
>>> m. 07966 512 369
>>> e. dezfowler at gmail.com
>>>
>>> _______________________________________________
>>> Mapstraction mailing list
>>> Mapstraction at lists.mapstraction.com
>>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>>
>>>
>>>
>>
>>
>> --
>> Andrew Turner
>> mobile: 248.982.3609
>> andrew at fortiusone.com
>> http://highearthorbit.com
>>
>> http://geocommons.com           Helping build the Geospatial Web
>> Introduction to Neogeography - http://oreilly.com/catalog/neogeography
>> _______________________________________________
>> Mapstraction mailing list
>> Mapstraction at lists.mapstraction.com
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>
>
>

-- 
Derek Fowler
m. 07966 512 369
e. dezfowler at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090209/f94b3e48/attachment.htm>

Nice. Looks like this is turning into a very neat solution.A brief pass of
your demo has given me a few thoughts.

Are we to mandate that all providers can only implement a core set of
functionality? e.g. they may not all be able to implement the
"enablescrollwheelzoom" and there may be other provider-specific
functionality we may want. If we are to mandate this, all is fine, although
we may need to remove some such functions. Alternatively, the solution as it
stands may be able to support this by extending the objects within the
provider implementations.

I wonder if there is a way of registering the functions without the proxies?

dodgy pseudo code:

register: function(object, sApiId, oApiImpl){
if (mxn has object) { // could be object[]
for (sPropName in oApiImpl) mxn.object.prototype[sPropName] oApiImpl[sPropName];
}
...
}
 mxn.register(''mapstraction'', ''google'', {...

Excuse my tired ramblings, don''t know if it is possible.

Is it possible to have a function call a provider function to reduce
duplicated code? e.g.addAPI has a few lines all providers will duplicate:

mapstraction.prototype.addAPI = function(){

//common functiuonality

mxn.invoke(provider specific functionality)
}

It would be nice to also include the script loading functions so users
don''t
have to worry about including lots of scripts or working out what to include
based on their needs.

The layout of the implementations is a personal preference (as I already
mentioned I prefer extracting methods specifically :)) but this layout may
restrict implementations. e.g. where would a ''helper'' function
for a
specific provider be placed and would it be registered? This layout is also
easy to miss commas and break IE, but that would be a concern of whoever is
implementing the script.

With regard to the jsdoc comments, does it mandate that a function signature
must exist and be available to use? If not, ''dummy'' comments
may be added
 for the proxy functions which are stripped out during the minify process?

Cheers,

Rob

2009/2/9 Derek Fowler <dezfowler at gmail.com>
> If it''s a feature that requires some provider implementation then
yes. If
> the implementations weren''t present you''d get a
JavaScript error when you
> tried to use the particular function. I think we may need some automated
> checking of which providers have implementations for which functions on
> build.
>
> One disadvantage of doing the dynamic method creation thing is that we
> don''t have function declarations for all those methods in the
mapstraction
> file so the automated document generation won''t work any more. I
think we
> should have a dummy file that just contains the interface definition for
> mapstraction that we build the documentation from.
>
> Also, forgot to mention I''m putting together a matrix of which
events are
> supported by which providers and what arguments they pass to the handler.
>
> Derek
>
>
> On Mon, Feb 9, 2009 at 7:44 AM, Adam DuVander <mapstraction at
duvander.com>wrote:
>
>> This makes sense to me now. It looks well organized and extensible.
>>
>> Am I correct that implementing a new feature will require touching
every
>> provider file? Seems worth the effort for not having to dload all
providers
>> when you''re only using one or two.
>> --Adam
>>
>>
>>
>> On Feb 8, 2009, at 5:03 PM, Andrew Turner wrote:
>>
>>  On Sun, Feb 8, 2009 at 7:40 PM, Derek Fowler <dezfowler at
gmail.com>
>>> wrote:
>>>
>>>> Hi guys,
>>>> Been working on this over the past few evenings and, although
it''s not
>>>> actually working yet, I thought I''d give you a first
glance.
>>>> The core mapstraction stuff is about 1800 lines with the Google
>>>> implementation code adding another 500. Original mapstraction
is 5353
>>>> lines
>>>> so we''re looking at 5800 for this version if you were
to include all
>>>> provider implementations but that''s not the point.
>>>>
>>>
>>> Definitely agree re: not the point to lower overall line size. The
key
>>> here is that *everyone* had to include all lines (and subsequent
size
>>> and processing) regardless if only subset of providers desired.
>>>
>>> Good to know that the architecture doesn''t overly bloat
the entire
>>> library though.
>>>
>>>
>>>> The key bits are the helper methods and classes in mxn.js, take
a look
>>>> in
>>>> the other two files to see how they''re used.
>>>> Have a look and let me know any thoughts. I''ll try and
get it working
>>>> ASAP
>>>> but I just wanted to get this out there so you know
I''m actually doing
>>>> something on it.
>>>> http://dfowler.geeksbox.co.uk/files/mapstraction-2/1/wip.htm
>>>>
>>>>
>>> The provider specific implementation looks incredibly
>>> straight-forward. Definitely something that is easy for anyone to
add
>>> or maintain.
>>>
>>> Can''t wait to see the example demo.
>>>
>>> What are your thoughts Rob?
>>>
>>>  Cheers,
>>>> Derek
>>>> --
>>>> Derek Fowler
>>>> m. 07966 512 369
>>>> e. dezfowler at gmail.com
>>>>
>>>> _______________________________________________
>>>> Mapstraction mailing list
>>>> Mapstraction at lists.mapstraction.com
>>>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Andrew Turner
>>> mobile: 248.982.3609
>>> andrew at fortiusone.com
>>> http://highearthorbit.com
>>>
>>> http://geocommons.com           Helping build the Geospatial Web
>>> Introduction to Neogeography -
http://oreilly.com/catalog/neogeography
>>> _______________________________________________
>>> Mapstraction mailing list
>>> Mapstraction at lists.mapstraction.com
>>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>>
>>
>>
>
>
> --
> Derek Fowler
> m. 07966 512 369
> e. dezfowler at gmail.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/20090210/9aa8a6e9/attachment.htm>

>
> Are we to mandate that all providers can only implement a core set of
> functionality? e.g. they may not all be able to implement the
> "enablescrollwheelzoom" and there may be other provider-specific
> functionality we may want. If we are to mandate this, all is fine, although
> we may need to remove some such functions. Alternatively, the solution as
it
> stands may be able to support this by extending the objects within the
> provider implementations.
>
I think that the rule should be that for functionality to be in mapstraction
it has to be supported by all the "majority" providers. As
I''ve said before
there is no point extending provider implementations to support additional
provider specific functionality because that goes against the whole point of
mapstraction which is that you can code against it, switch provider and
everything still works without you having to alter your code. If folks want
feature x of provider y they should use provider y, not mapstraction. What
does everyone think about adopting this as a policy?

> I wonder if there is a way of registering the functions without the
> proxies?
>
> dodgy pseudo code:
>
> register: function(object, sApiId, oApiImpl){
>  if (mxn has object) { // could be object[]
> for (sPropName in oApiImpl) mxn.object.prototype[sPropName] >
oApiImpl[sPropName];
>  }
> ...
> }
>  mxn.register(''mapstraction'', ''google'',
{...
>
> Excuse my tired ramblings, don''t know if it is possible.
>
We can''t do this because each API registered will overwrite the
prototype
methods added to the core class by the last API registered. Having said that
there''s no reason why we couldn''t add the provider function on
to the
instance once we''ve invoked it once and know it''s there. That
might save
some effort.

> Is it possible to have a function call a provider function to reduce
> duplicated code? e.g.addAPI has a few lines all providers will duplicate:
>
> mapstraction.prototype.addAPI = function(){
>
> //common functiuonality
>
> mxn.invoke(provider specific functionality)
> }
>
There are functions like this in the code already but the call is:

this.invoker.go(''blah'');

Currently you can also pass a "context" object though to the API
implementation with any variables that were defined in the body of the
mapstraction method. I''m also considering whether it would be worth
being
able to pass some methods in along with that "context" object. Ones
that
allow the API implementation greater control over altering the mapstraction
object but that are not exposed to the user.

It would be nice to also include the script loading functions so users
don''t
> have to worry about including lots of scripts or working out what to
include
> based on their needs.
>
I''ll see about getting that stuff back in there.

> The layout of the implementations is a personal preference (as I already
> mentioned I prefer extracting methods specifically :)) but this layout may
> restrict implementations. e.g. where would a ''helper''
function for a
> specific provider be placed and would it be registered? This layout is also
> easy to miss commas and break IE, but that would be a concern of whoever is
> implementing the script.
>
The reason I prefer doing it as object notation is because you don''t
want to
defined classes, they''re in mapstraction, you just want a collection of
functions. You could do it by defining "implementing" classes which
you
instantiate and pass in to mapstraction with the register but I think the
code for that would be a lot less concise.

With regard to the jsdoc comments, does it mandate that a function
signature
> must exist and be available to use? If not, ''dummy''
comments may be added
>  for the proxy functions which are stripped out during the minify process?
>
This is a possibility, yes. I''m not sure whether jsdoc will complain
that
the comment isn''t next to an actual function or variable declaration
though.

Thanks for the feedback.

Derek
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090211/9e4f117b/attachment-0001.htm>

Derek Fowler wrote:
> I think that the rule should be that for functionality to be in 
> mapstraction it has to be supported by all the "majority"
providers.
> As I''ve said before there is no point extending provider 
> implementations to support additional provider specific functionality 
> because that goes against the whole point of mapstraction which is 
> that you can code against it, switch provider and everything still 
> works without you having to alter your code. If folks want feature x 
> of provider y they should use provider y, not mapstraction. What does 
> everyone think about adopting this as a policy?
Speaking as one of the original developers, let me first say a big Thank 
You to everyone who''s been taking care of the library since I put it 
down.  It''s great to see it being taken so seriously.

Such a rule as you suggest does make sense. In terms of the original 
aims though, I always intended that we would write code to cover holes 
in the offerings from the big providers (when we started, Yahoo didn''t 
have polylines and Microsoft didn''t support info bubbles, for example) 
or that you could use base maps from provider x and routing/geocoding 
from provider y as needed. 

There are some features that can be added at the mapstraction level and 
applied equally to all providers that support a basic set of 
functionality, and there are some features that all-but-one provider 
will support... in that case the Mapstractionest thing to do is not to 
operate at the lowest common denominator but to patch the required 
features into the deficient provider and move on :)

But really, you guys are on top of things already, I should just keep quiet.

Cheers,

Tom.

2009/2/11 Derek Fowler <dezfowler at gmail.com>
> Are we to mandate that all providers can only implement a core set of
>> functionality? e.g. they may not all be able to implement the
>> "enablescrollwheelzoom" and there may be other
provider-specific
>> functionality we may want. If we are to mandate this, all is fine,
although
>> we may need to remove some such functions. Alternatively, the solution
as it
>> stands may be able to support this by extending the objects within the
>> provider implementations.
>>
>
> I think that the rule should be that for functionality to be in
> mapstraction it has to be supported by all the "majority"
providers. As I''ve
> said before there is no point extending provider implementations to support
> additional provider specific functionality because that goes against the
> whole point of mapstraction which is that you can code against it, switch
> provider and everything still works without you having to alter your code.
> If folks want feature x of provider y they should use provider y, not
> mapstraction. What does everyone think about adopting this as a policy?
>
Andrew''s call methinks, it will ease decisions in the future with new
functionality, though.
>
>
>> I wonder if there is a way of registering the functions without the
>> proxies?
>>
>> dodgy pseudo code:
>>
>> register: function(object, sApiId, oApiImpl){
>>  if (mxn has object) { // could be object[]
>> for (sPropName in oApiImpl) mxn.object.prototype[sPropName] >>
oApiImpl[sPropName];
>>  }
>> ...
>> }
>>  mxn.register(''mapstraction'',
''google'', {...
>>
>> Excuse my tired ramblings, don''t know if it is possible.
>>
>
> We can''t do this because each API registered will overwrite the
prototype
> methods added to the core class by the last API registered. Having said
that
> there''s no reason why we couldn''t add the provider
function on to the
> instance once we''ve invoked it once and know it''s there.
That might save
> some effort.
>
Ah, of course :p And an object per api would eat uneccessary memory.
>
>
>> Is it possible to have a function call a provider function to reduce
>> duplicated code? e.g.addAPI has a few lines all providers will
duplicate:
>>
>> mapstraction.prototype.addAPI = function(){
>>
>> //common functiuonality
>>
>> mxn.invoke(provider specific functionality)
>> }
>>
>
> There are functions like this in the code already but the call is:
>
> this.invoker.go(''blah'');
>
> Currently you can also pass a "context" object though to the API
> implementation with any variables that were defined in the body of the
> mapstraction method. I''m also considering whether it would be
worth being
> able to pass some methods in along with that "context" object.
Ones that
> allow the API implementation greater control over altering the mapstraction
> object but that are not exposed to the user.
>
> It would be nice to also include the script loading functions so users
>> don''t have to worry about including lots of scripts or working
out what to
>> include based on their needs.
>>
>
> I''ll see about getting that stuff back in there.
>
Let me know if you need a hand.
>
>
>> The layout of the implementations is a personal preference (as I
already
>> mentioned I prefer extracting methods specifically :)) but this layout
may
>> restrict implementations. e.g. where would a ''helper''
function for a
>> specific provider be placed and would it be registered? This layout is
also
>> easy to miss commas and break IE, but that would be a concern of
whoever is
>> implementing the script.
>>
>
> The reason I prefer doing it as object notation is because you
don''t want
> to defined classes, they''re in mapstraction, you just want a
collection of
> functions. You could do it by defining "implementing" classes
which you
> instantiate and pass in to mapstraction with the register but I think the
> code for that would be a lot less concise.
>
OK, no probs.
>
> With regard to the jsdoc comments, does it mandate that a function
>> signature must exist and be available to use? If not,
''dummy'' comments may
>> be added  for the proxy functions which are stripped out during the
minify
>> process?
>>
>
> This is a possibility, yes. I''m not sure whether jsdoc will
complain that
> the comment isn''t next to an actual function or variable
declaration though.
>
I may have a play and either dummy comments or a dummy script as you suggest
may be the way.
A less clean way may be to take a single ''master'' provider
which contained
the implementation comments, but eugh :)
>
> Thanks for the feedback.
>
> Derek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090211/8a043608/attachment.htm>

Almost an abstraction layer. Perhaps some gap analysis is required alongside
Derek''s event analysis?

2009/2/11 Tom Carden <tom at tom-carden.co.uk>
> Derek Fowler wrote:
>
>> I think that the rule should be that for functionality to be in
>> mapstraction it has to be supported by all the "majority"
providers. As I''ve
>> said before there is no point extending provider implementations to
support
>> additional provider specific functionality because that goes against
the
>> whole point of mapstraction which is that you can code against it,
switch
>> provider and everything still works without you having to alter your
code.
>> If folks want feature x of provider y they should use provider y, not
>> mapstraction. What does everyone think about adopting this as a policy?
>>
>
> Speaking as one of the original developers, let me first say a big Thank
> You to everyone who''s been taking care of the library since I put
it down.
>  It''s great to see it being taken so seriously.
>
> Such a rule as you suggest does make sense. In terms of the original aims
> though, I always intended that we would write code to cover holes in the
> offerings from the big providers (when we started, Yahoo didn''t
have
> polylines and Microsoft didn''t support info bubbles, for example)
or that
> you could use base maps from provider x and routing/geocoding from provider
> y as needed.
> There are some features that can be added at the mapstraction level and
> applied equally to all providers that support a basic set of functionality,
> and there are some features that all-but-one provider will support... in
> that case the Mapstractionest thing to do is not to operate at the lowest
> common denominator but to patch the required features into the deficient
> provider and move on :)
>
> But really, you guys are on top of things already, I should just keep
> quiet.
>
> Cheers,
>
> Tom.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090211/fec9b7eb/attachment.htm>

On Wed, Feb 11, 2009 at 7:05 PM, Tom Carden <tom at tom-carden.co.uk>
wrote:
> Derek Fowler wrote:
>
>> I think that the rule should be that for functionality to be in
>> mapstraction it has to be supported by all the "majority"
providers. As I''ve
>> said before there is no point extending provider implementations to
support
>> additional provider specific functionality because that goes against
the
>> whole point of mapstraction which is that you can code against it,
switch
>> provider and everything still works without you having to alter your
code.
>> If folks want feature x of provider y they should use provider y, not
>> mapstraction. What does everyone think about adopting this as a policy?
>>
>
> Speaking as one of the original developers, let me first say a big Thank
> You to everyone who''s been taking care of the library since I put
it down.
>  It''s great to see it being taken so seriously.
>
> Such a rule as you suggest does make sense. In terms of the original aims
> though, I always intended that we would write code to cover holes in the
> offerings from the big providers (when we started, Yahoo didn''t
have
> polylines and Microsoft didn''t support info bubbles, for example)
or that
> you could use base maps from provider x and routing/geocoding from provider
> y as needed.
> There are some features that can be added at the mapstraction level and
> applied equally to all providers that support a basic set of functionality,
> and there are some features that all-but-one provider will support... in
> that case the Mapstractionest thing to do is not to operate at the lowest
> common denominator but to patch the required features into the deficient
> provider and move on :)
>
> But really, you guys are on top of things already, I should just keep
> quiet.
>
> Cheers,
>
> Tom.
>
>
Yes, I suppose a better way of putting it would be: features the
"majority"
providers support and that can be added easily for any providers missing
them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090211/60c855b5/attachment-0001.htm>

As Tom mentioned, I think it is beneficial for Mapstraction to not be  
the lowest common denominator. Instead, I''d like to see major features
implemented, even if they are only supported currently by one provider  
(for example: custom tiles, only available from Google). Other  
providers can be filled in as the provider supports them, or if they  
can be built up from the basic functionality.

Coupled with an up-to-date feature matrix, I don''t see a problem with  
incomplete coverage of some features.

--Adam
---
Adam DuVander
I like simple: http://adamduvander.com


On Feb 11, 2009, at 11:05 AM, Tom Carden wrote:
> Derek Fowler wrote:
>> I think that the rule should be that for functionality to be in  
>> mapstraction it has to be supported by all the "majority"  
>> providers. As I''ve said before there is no point extending
provider
>> implementations to support additional provider specific  
>> functionality because that goes against the whole point of  
>> mapstraction which is that you can code against it, switch provider  
>> and everything still works without you having to alter your code.  
>> If folks want feature x of provider y they should use provider y,  
>> not mapstraction. What does everyone think about adopting this as a  
>> policy?
>
> Speaking as one of the original developers, let me first say a big  
> Thank You to everyone who''s been taking care of the library since
I
> put it down.  It''s great to see it being taken so seriously.
>
> Such a rule as you suggest does make sense. In terms of the original  
> aims though, I always intended that we would write code to cover  
> holes in the offerings from the big providers (when we started,  
> Yahoo didn''t have polylines and Microsoft didn''t support
info
> bubbles, for example) or that you could use base maps from provider  
> x and routing/geocoding from provider y as needed.
> There are some features that can be added at the mapstraction level  
> and applied equally to all providers that support a basic set of  
> functionality, and there are some features that all-but-one provider  
> will support... in that case the Mapstractionest thing to do is not  
> to operate at the lowest common denominator but to patch the  
> required features into the deficient provider and move on :)
>
> But really, you guys are on top of things already, I should just  
> keep quiet.
>
> Cheers,
>
> Tom.
>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com

On Wed, Feb 11, 2009 at 2:05 PM, Tom Carden <tom at tom-carden.co.uk>
wrote:
> Derek Fowler wrote:
>>
>> I think that the rule should be that for functionality to be in
>> mapstraction it has to be supported by all the "majority"
providers. As I''ve
>> said before there is no point extending provider implementations to
support
>> additional provider specific functionality because that goes against
the
>> whole point of mapstraction which is that you can code against it,
switch
>> provider and everything still works without you having to alter your
code.
>> If folks want feature x of provider y they should use provider y, not
>> mapstraction. What does everyone think about adopting this as a policy?
>
> Speaking as one of the original developers, let me first say a big Thank
You
> to everyone who''s been taking care of the library since I put it
down.  It''s
> great to see it being taken so seriously.
Thank you Tom (& Steve & Mikel) as well for starting this great project.

> In terms of the original aims
> though, I always intended that we would write code to cover holes in the
> offerings from the big providers (when we started, Yahoo didn''t
have
> polylines and Microsoft didn''t support info bubbles, for example)
or that
> you could use base maps from provider x and routing/geocoding from provider
> y as needed.
Nominally I agree, however this is one of those "beware the ToS". Most
providers have explicit verbage that states using one of their
services combined with another''s is verboten.
> There are some features that can be added at the mapstraction level and
> applied equally to all providers that support a basic set of functionality,
> and there are some features that all-but-one provider will support... in
> that case the Mapstractionest thing to do is not to operate at the lowest
> common denominator but to patch the required features into the deficient
> provider and move on :)
I agree with what essentially everyone else here as agreed to as well,
that Mapstraction should aim to implement the majority of functions
that a majority of providers provide, provide gaps where some don''t,
and then provide some minor additional helpers (e.g. filtering) as
useful.

In fact, to summarize, let me spell out what I feel to be the core
guiding principles:

 - Support the current common mapping components that a developer may
expect from a mapping library.
 - Where not possible, or overly complicated, be graceful in failing
and notifying the developer via documentation and debug messages
 - Allow a developer to *get at* the proprietary map object. Sometimes
they want the 80% of Mapstraction, but then optional 20% custom code
for unique features that Mapstraction doesn''t currently support
(currently the getMap(); function)
 - Allow a developer to cleanly switch to any provider without having
to modify code, and even to do so on the fly

and some new ones that drive this re-architecture
 - Impose as minimal overhead in processing and file size as possible,
so as not to make the abstraction overly costly
 - Make it easy for a developer to maintain, add, and extend specific
provider modules

Please let me know if these sound good to everyone that is actively involved.
Andrew

That all sounds great, yeah. I didn''t know the map providers forbade
using their services in concert with another.

The only bit i''d like to clarify is the changing of provider on the
fly bit. I haven''t really looked at the code for this but is it the
case that this does a full map reload with the different provider and
doesn''t maintain a previously loaded API? I was thinking that it would
be possible by having a collection of container objects inside a
mapstraction one. You''d have one for each API to add its stuff too,
like proprietary_marker etc. I''m not really sure what benefit it would
give or if the swapping API feature is widely used enough to warrant
such a big change.

Also, regarding the marker manager, is this already done as if not i
added some filtering functionality for a previous project which worked
quite well.

Derek

On 2/13/09, Andrew Turner <andrew at highearthorbit.com>
wrote:
> On Wed, Feb 11, 2009 at 2:05 PM, Tom Carden <tom at tom-carden.co.uk>
wrote:
>> Derek Fowler wrote:
>>>
>>> I think that the rule should be that for functionality to be in
>>> mapstraction it has to be supported by all the "majority"
providers. As
>>> I''ve
>>> said before there is no point extending provider implementations to
>>> support
>>> additional provider specific functionality because that goes
against the
>>> whole point of mapstraction which is that you can code against it,
>>> switch
>>> provider and everything still works without you having to alter
your
>>> code.
>>> If folks want feature x of provider y they should use provider y,
not
>>> mapstraction. What does everyone think about adopting this as a
policy?
>>
>> Speaking as one of the original developers, let me first say a big
Thank
>> You
>> to everyone who''s been taking care of the library since I put
it down.
>> It''s
>> great to see it being taken so seriously.
>
> Thank you Tom (& Steve & Mikel) as well for starting this great
project.
>
>
>> In terms of the original aims
>> though, I always intended that we would write code to cover holes in
the
>> offerings from the big providers (when we started, Yahoo
didn''t have
>> polylines and Microsoft didn''t support info bubbles, for
example) or that
>> you could use base maps from provider x and routing/geocoding from
>> provider
>> y as needed.
>
> Nominally I agree, however this is one of those "beware the ToS".
Most
> providers have explicit verbage that states using one of their
> services combined with another''s is verboten.
>
>> There are some features that can be added at the mapstraction level and
>> applied equally to all providers that support a basic set of
>> functionality,
>> and there are some features that all-but-one provider will support...
in
>> that case the Mapstractionest thing to do is not to operate at the
lowest
>> common denominator but to patch the required features into the
deficient
>> provider and move on :)
>
> I agree with what essentially everyone else here as agreed to as well,
> that Mapstraction should aim to implement the majority of functions
> that a majority of providers provide, provide gaps where some
don''t,
> and then provide some minor additional helpers (e.g. filtering) as
> useful.
>
> In fact, to summarize, let me spell out what I feel to be the core
> guiding principles:
>
>  - Support the current common mapping components that a developer may
> expect from a mapping library.
>  - Where not possible, or overly complicated, be graceful in failing
> and notifying the developer via documentation and debug messages
>  - Allow a developer to *get at* the proprietary map object. Sometimes
> they want the 80% of Mapstraction, but then optional 20% custom code
> for unique features that Mapstraction doesn''t currently support
> (currently the getMap(); function)
>  - Allow a developer to cleanly switch to any provider without having
> to modify code, and even to do so on the fly
>
> and some new ones that drive this re-architecture
>  - Impose as minimal overhead in processing and file size as possible,
> so as not to make the abstraction overly costly
>  - Make it easy for a developer to maintain, add, and extend specific
> provider modules
>
> Please let me know if these sound good to everyone that is actively
> involved.
> Andrew
>
-- 
Sent from Google Mail for mobile | mobile.google.com

Derek Fowler
m. 07966 512 369
e. dezfowler at gmail.com

A couple of comments below...

Cheers,

Rob

2009/2/13 Andrew Turner <andrew at highearthorbit.com>
> On Wed, Feb 11, 2009 at 2:05 PM, Tom Carden <tom at tom-carden.co.uk>
wrote:
> > Derek Fowler wrote:
> >>
> >> I think that the rule should be that for functionality to be in
> >> mapstraction it has to be supported by all the
"majority" providers. As
> I''ve
> >> said before there is no point extending provider implementations
to
> support
> >> additional provider specific functionality because that goes
against the
> >> whole point of mapstraction which is that you can code against it,
> switch
> >> provider and everything still works without you having to alter
your
> code.
> >> If folks want feature x of provider y they should use provider y,
not
> >> mapstraction. What does everyone think about adopting this as a
policy?
> >
> > Speaking as one of the original developers, let me first say a big
Thank
> You
> > to everyone who''s been taking care of the library since I put
it down.
>  It''s
> > great to see it being taken so seriously.
>
> Thank you Tom (& Steve & Mikel) as well for starting this great
project.
>
Thanks from me, too :)
>
>
> > In terms of the original aims
> > though, I always intended that we would write code to cover holes in
the
> > offerings from the big providers (when we started, Yahoo
didn''t have
> > polylines and Microsoft didn''t support info bubbles, for
example) or that
> > you could use base maps from provider x and routing/geocoding from
> provider
> > y as needed.
>
> Nominally I agree, however this is one of those "beware the ToS".
Most
> providers have explicit verbage that states using one of their
> services combined with another''s is verboten.
>
> > There are some features that can be added at the mapstraction level
and
> > applied equally to all providers that support a basic set of
> functionality,
> > and there are some features that all-but-one provider will support...
in
> > that case the Mapstractionest thing to do is not to operate at the
lowest
> > common denominator but to patch the required features into the
deficient
> > provider and move on :)
>
> I agree with what essentially everyone else here as agreed to as well,
> that Mapstraction should aim to implement the majority of functions
> that a majority of providers provide, provide gaps where some
don''t,
> and then provide some minor additional helpers (e.g. filtering) as
> useful.
>
> In fact, to summarize, let me spell out what I feel to be the core
> guiding principles:
>
>  - Support the current common mapping components that a developer may
> expect from a mapping library.
>  - Where not possible, or overly complicated, be graceful in failing
> and notifying the developer via documentation and debug messages
>  - Allow a developer to *get at* the proprietary map object. Sometimes
> they want the 80% of Mapstraction, but then optional 20% custom code
> for unique features that Mapstraction doesn''t currently support
> (currently the getMap(); function)


I would say that his also goes for the proprietry objects, especially
markers for provider-specific extension.

>
>  - Allow a developer to cleanly switch to any provider without having
> to modify code, and even to do so on the fly


If on the fly is easy to implement, then great. But what circumstances would
this be used?

>
>
> and some new ones that drive this re-architecture
>  - Impose as minimal overhead in processing and file size as possible,
> so as not to make the abstraction overly costly
>  - Make it easy for a developer to maintain, add, and extend specific
> provider modules
>
> Please let me know if these sound good to everyone that is actively
> involved.
> Andrew
> _______________________________________________
> 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/20090213/65f203c5/attachment-0001.htm>

On Fri, Feb 13, 2009 at 4:04 AM, Derek Fowler <dezfowler at gmail.com>
wrote:
> That all sounds great, yeah. I didn''t know the map providers
forbade
> using their services in concert with another.
>
> The only bit i''d like to clarify is the changing of provider on
the
> fly bit. I haven''t really looked at the code for this but is it
the
> case that this does a full map reload with the different provider and
> doesn''t maintain a previously loaded API? I was thinking that it
would
> be possible by having a collection of container objects inside a
> mapstraction one. You''d have one for each API to add its stuff
too,
> like proprietary_marker etc. I''m not really sure what benefit it
would
> give or if the swapping API feature is widely used enough to warrant
> such a big change.
This is already a feature in Mapstraction. You can see it in the
Fullscreen demo (http://mapstraction.com/demo-fullscreen.html)

It''s useful for applications that want to allow their users to switch
to make the provider decision.
>
> Also, regarding the marker manager, is this already done as if not i
> added some filtering functionality for a previous project which worked
> quite well.
There is already filtering in current Mapstraction - but obviously
updates and cleaning up into an actual marker manager would be nice.
Potentially even optional utilization of the GMaps open-source marker
manager would be particularly interesting.
>
> Derek
>
> On 2/13/09, Andrew Turner <andrew at highearthorbit.com> wrote:
>> On Wed, Feb 11, 2009 at 2:05 PM, Tom Carden <tom at
tom-carden.co.uk> wrote:
>>> Derek Fowler wrote:
>>>>
>>>> I think that the rule should be that for functionality to be in
>>>> mapstraction it has to be supported by all the
"majority" providers. As
>>>> I''ve
>>>> said before there is no point extending provider
implementations to
>>>> support
>>>> additional provider specific functionality because that goes
against the
>>>> whole point of mapstraction which is that you can code against
it,
>>>> switch
>>>> provider and everything still works without you having to alter
your
>>>> code.
>>>> If folks want feature x of provider y they should use provider
y, not
>>>> mapstraction. What does everyone think about adopting this as a
policy?
>>>
>>> Speaking as one of the original developers, let me first say a big
Thank
>>> You
>>> to everyone who''s been taking care of the library since I
put it down.
>>> It''s
>>> great to see it being taken so seriously.
>>
>> Thank you Tom (& Steve & Mikel) as well for starting this great
project.
>>
>>
>>> In terms of the original aims
>>> though, I always intended that we would write code to cover holes
in the
>>> offerings from the big providers (when we started, Yahoo
didn''t have
>>> polylines and Microsoft didn''t support info bubbles, for
example) or that
>>> you could use base maps from provider x and routing/geocoding from
>>> provider
>>> y as needed.
>>
>> Nominally I agree, however this is one of those "beware the
ToS". Most
>> providers have explicit verbage that states using one of their
>> services combined with another''s is verboten.
>>
>>> There are some features that can be added at the mapstraction level
and
>>> applied equally to all providers that support a basic set of
>>> functionality,
>>> and there are some features that all-but-one provider will
support... in
>>> that case the Mapstractionest thing to do is not to operate at the
lowest
>>> common denominator but to patch the required features into the
deficient
>>> provider and move on :)
>>
>> I agree with what essentially everyone else here as agreed to as well,
>> that Mapstraction should aim to implement the majority of functions
>> that a majority of providers provide, provide gaps where some
don''t,
>> and then provide some minor additional helpers (e.g. filtering) as
>> useful.
>>
>> In fact, to summarize, let me spell out what I feel to be the core
>> guiding principles:
>>
>>  - Support the current common mapping components that a developer may
>> expect from a mapping library.
>>  - Where not possible, or overly complicated, be graceful in failing
>> and notifying the developer via documentation and debug messages
>>  - Allow a developer to *get at* the proprietary map object. Sometimes
>> they want the 80% of Mapstraction, but then optional 20% custom code
>> for unique features that Mapstraction doesn''t currently
support
>> (currently the getMap(); function)
>>  - Allow a developer to cleanly switch to any provider without having
>> to modify code, and even to do so on the fly
>>
>> and some new ones that drive this re-architecture
>>  - Impose as minimal overhead in processing and file size as possible,
>> so as not to make the abstraction overly costly
>>  - Make it easy for a developer to maintain, add, and extend specific
>> provider modules
>>
>> Please let me know if these sound good to everyone that is actively
>> involved.
>> Andrew
>>
>
> --
> Sent from Google Mail for mobile | mobile.google.com
>
> Derek Fowler
> m. 07966 512 369
> e. dezfowler at gmail.com
>


-- 
Andrew Turner
mobile: 248.982.3609
andrew at fortiusone.com
http://highearthorbit.com

http://geocommons.com           Helping build the Geospatial Web
Introduction to Neogeography - http://oreilly.com/catalog/neogeography

Rob a ?crit :
> A couple of comments below...
> 
> Cheers,
> 
> Rob
> 
> 2009/2/13 Andrew Turner <andrew at highearthorbit.com 
> <mailto:andrew at highearthorbit.com>>
> 
>     On Wed, Feb 11, 2009 at 2:05 PM, Tom Carden <tom at tom-carden.co.uk
>     <mailto:tom at tom-carden.co.uk>> wrote:
>      > Derek Fowler wrote:
>      >>
>      >> I think that the rule should be that for functionality to be
in
>      >> mapstraction it has to be supported by all the
"majority"
>     providers. As I''ve
>      >> said before there is no point extending provider
implementations
>     to support
>      >> additional provider specific functionality because that goes
>     against the
>      >> whole point of mapstraction which is that you can code
against
>     it, switch
>      >> provider and everything still works without you having to
alter
>     your code.
>      >> If folks want feature x of provider y they should use
provider
>     y, not
>      >> mapstraction. What does everyone think about adopting this as
a
>     policy?
>      >
>      > Speaking as one of the original developers, let me first say a
>     big Thank You
>      > to everyone who''s been taking care of the library since
I put it
>     down.  It''s
>      > great to see it being taken so seriously.
> 
>     Thank you Tom (& Steve & Mikel) as well for starting this great
project.
> 
> 
> Thanks from me, too :)
> 
> 
> 
>      > In terms of the original aims
>      > though, I always intended that we would write code to cover holes
>     in the
>      > offerings from the big providers (when we started, Yahoo
didn''t have
>      > polylines and Microsoft didn''t support info bubbles, for
example)
>     or that
>      > you could use base maps from provider x and routing/geocoding
>     from provider
>      > y as needed.
> 
>     Nominally I agree, however this is one of those "beware the
ToS". Most
>     providers have explicit verbage that states using one of their
>     services combined with another''s is verboten.
> 
>      > There are some features that can be added at the mapstraction
>     level and
>      > applied equally to all providers that support a basic set of
>     functionality,
>      > and there are some features that all-but-one provider will
>     support... in
>      > that case the Mapstractionest thing to do is not to operate at
>     the lowest
>      > common denominator but to patch the required features into the
>     deficient
>      > provider and move on :)
> 
>     I agree with what essentially everyone else here as agreed to as well,
>     that Mapstraction should aim to implement the majority of functions
>     that a majority of providers provide, provide gaps where some
don''t,
>     and then provide some minor additional helpers (e.g. filtering) as
>     useful.
> 
>     In fact, to summarize, let me spell out what I feel to be the core
>     guiding principles:
> 
>      - Support the current common mapping components that a developer may
>     expect from a mapping library.
>      - Where not possible, or overly complicated, be graceful in failing
>     and notifying the developer via documentation and debug messages
>      - Allow a developer to *get at* the proprietary map object. Sometimes
>     they want the 80% of Mapstraction, but then optional 20% custom code
>     for unique features that Mapstraction doesn''t currently
support
>     (currently the getMap(); function)
> 
> 
> 
> I would say that his also goes for the proprietry objects, especially 
> markers for provider-specific extension.
>  
> 
> 
>      - Allow a developer to cleanly switch to any provider without having
>     to modify code, and even to do so on the fly
> 
> 
> 
> If on the fly is easy to implement, then great. But what circumstances 
> would this be used?
I currently use this functionality in the project i''m involved :
http://www.gramps-project.org/

The default map is openstreetmap.
As you know, maps with OSM are not helpfull in some countries.
In this case I propose the possibility to swith to googlemaps, microsoft
maps, openlayers or yahoo maps.

This does not work correctly for me when I swicth from OSM to
googlemaps, then from googlemaps to OSM. The come back is broken.
perhaps I should file a bug. Where ?
>  
> 
> 
> 
>     and some new ones that drive this re-architecture
>      - Impose as minimal overhead in processing and file size as possible,
>     so as not to make the abstraction overly costly
>      - Make it easy for a developer to maintain, add, and extend specific
>     provider modules
> 
>     Please let me know if these sound good to everyone that is actively
>     involved.
>     Andrew