Hi all, I''ve juste pushed a small fix for mxn here : https://github.com/mapstraction/mxn/pull/56 This one prevent Firefox 4 to throw an error when using geocoder. I think we should release a new version of mxn soon but maybe we could put other stuffs before : 1) This small improvement of googlev3 geocoder : https://github.com/mapstraction/mxn/pull/55 2) My old implementation of addImageOverlay() for googlev3 : https://github.com/brunob/mxn/tree/googlev3_addimageoverlay 3) Last year we were talking about addJSON() and jo pointed that a patch was already proposed a year ago. http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/2010-September/001048.html Maybe we could implement this one too ? I will test it this week and pull it to github if it''s ok. What do you think about it ? ++ b_b
Thanks for this Bruno, I was looking for that addJSON patch a while back to get it into the codebase but couldn''t find it. As it happens I have a free evening so I''ll take a look at this stuff tonight. Derek On 23 March 2011 12:42, Bruno Bergot <brunobergot at gmail.com> wrote:> Hi all, > > I''ve juste pushed a small fix for mxn here : > > https://github.com/mapstraction/mxn/pull/56 > > This one prevent Firefox 4 to throw an error when using geocoder. > > I think we should release a new version of mxn soon but maybe we could put > other stuffs before : > > 1) This small improvement of googlev3 geocoder : > https://github.com/mapstraction/mxn/pull/55 > > 2) My old implementation of addImageOverlay() for googlev3 : > https://github.com/brunob/mxn/tree/googlev3_addimageoverlay > > 3) Last year we were talking about addJSON() and jo pointed that a patch > was already proposed a year ago. > > > http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/2010-September/001048.html > > Maybe we could implement this one too ? I will test it this week and pull > it to github if it''s ok. > > What do you think about it ? > > ++ > b_b > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20110323/587dc50c/attachment.htm>
Hi Derek, Le 23/03/2011 14:12, Derek Fowler a ?crit :> Thanks for this Bruno, I was looking for that addJSON patch a while back to > get it into the codebase but couldn''t find it.You''re welcome ;)> > As it happens I have a free evening so I''ll take a look at this stuff > tonight. >I''m working on it right now. I''ll be online tonight and i''m always connected to #mapstraction IRC channel on freenode. You can use freenode webchat to join here : http://webchat.freenode.net/?channels=%23mapstraction Maybe should we add a dns entry to mapstraction.com domain to redirect it like that : irc.mapstraction.com => http://webchat.freenode.net/?channels=%23mapstraction That''s what we are doing for SPIP project : http://www.spip.net/irc See you soon. ++ b_b
Hi Derek, I''ve pushed my work on addJSON here : https://github.com/brunob/mxn/tree/mxn_addjson I''ve simplified the code and the properties of each item of the geojson object use the same name as inside mxn (iconSize instead of incon_size). This break the compatibility with older versions of mxn so maybe we should keep addJSON to make it the "old" way and add a addGeoJSON() function (not really like this cause it''s a kind of redundancy). What do you think of it ? ++ b_b Le 23/03/2011 17:00, Bruno Bergot a ?crit :> Hi Derek, > > Le 23/03/2011 14:12, Derek Fowler a ?crit : >> Thanks for this Bruno, I was looking for that addJSON patch a while >> back to >> get it into the codebase but couldn''t find it. > > You''re welcome ;) > >> >> As it happens I have a free evening so I''ll take a look at this stuff >> tonight. >> > > I''m working on it right now. I''ll be online tonight and i''m always > connected to #mapstraction IRC channel on freenode. You can use freenode > webchat to join here : > > http://webchat.freenode.net/?channels=%23mapstraction > > Maybe should we add a dns entry to mapstraction.com domain to redirect > it like that : > > irc.mapstraction.com => > http://webchat.freenode.net/?channels=%23mapstraction > > That''s what we are doing for SPIP project : > > http://www.spip.net/irc > > See you soon. > > ++ > b_b
That''s an interesting one. I''d rather not have duplicate
functionality.
Maybe the best option would be to put a namespace in there for the new style
stuff like the atom properties in the examples on this page:
http://wiki.geojson.org/GeoJSON_draft_version_6
<http://wiki.geojson.org/GeoJSON_draft_version_6>If the namespace is
defined
e.g.
"@namespaces": {"":"http://geojson.org/ns#",
"mxn":"
http://www.mapstraction.com"},
we can then look for properties like so:
"properties": {
"mxn:iconUrl": "http://someicon.com/icon.jpg",
"mxn:iconAnchor": [100,100]
}
If the namespace isn''t present we can fallback to looking for the old
style
properties maybe.
Derek
On 24 March 2011 16:05, Bruno Bergot <brunobergot at gmail.com> wrote:
> Hi Derek,
>
> I''ve pushed my work on addJSON here :
>
> https://github.com/brunob/mxn/tree/mxn_addjson
>
> I''ve simplified the code and the properties of each item of the
geojson
> object use the same name as inside mxn (iconSize instead of incon_size).
> This break the compatibility with older versions of mxn so maybe we should
> keep addJSON to make it the "old" way and add a addGeoJSON()
function (not
> really like this cause it''s a kind of redundancy).
>
> What do you think of it ?
>
> ++
> b_b
>
> Le 23/03/2011 17:00, Bruno Bergot a ?crit :
>
> Hi Derek,
>>
>> Le 23/03/2011 14:12, Derek Fowler a ?crit :
>>
>>> Thanks for this Bruno, I was looking for that addJSON patch a while
>>> back to
>>> get it into the codebase but couldn''t find it.
>>>
>>
>> You''re welcome ;)
>>
>>
>>> As it happens I have a free evening so I''ll take a look at
this stuff
>>> tonight.
>>>
>>>
>> I''m working on it right now. I''ll be online tonight
and i''m always
>> connected to #mapstraction IRC channel on freenode. You can use
freenode
>> webchat to join here :
>>
>> http://webchat.freenode.net/?channels=%23mapstraction
>>
>> Maybe should we add a dns entry to mapstraction.com domain to redirect
>> it like that :
>>
>> irc.mapstraction.com =>
>> http://webchat.freenode.net/?channels=%23mapstraction
>>
>> That''s what we are doing for SPIP project :
>>
>> http://www.spip.net/irc
>>
>> See you soon.
>>
>> ++
>> b_b
>>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>
--
Derek Fowler
m. +44 (0) 7966 512 369
e. dezfowler at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20110324/f2c6aa1e/attachment.htm>
Hi Derek, Le 24/03/2011 17:45, Derek Fowler a ?crit :> That''s an interesting one. I''d rather not have duplicate functionality. > > Maybe the best option would be to put a namespace in there for the new style > stuff like the atom properties in the examples on this page: > > http://wiki.geojson.org/GeoJSON_draft_version_6 > > <http://wiki.geojson.org/GeoJSON_draft_version_6>If the namespace is defined > e.g. > > "@namespaces": {"":"http://geojson.org/ns#", "mxn":" > http://www.mapstraction.com"}, > > we can then look for properties like so: > > "properties": { > "mxn:iconUrl": "http://someicon.com/icon.jpg", > "mxn:iconAnchor": [100,100] > } >That sounds good technically but i also think it will force users to produce more "complicated" geojson code to add to their maps.> If the namespace isn''t present we can fallback to looking for the old style > properties maybe. >If we use it only for compatibility reasons maybe we could simply handle this in the addJSON function, like that : if the json object got properties => handle it like the new way else => handle it the old way I''ll try to commit this tonight or tomorrow. I think we have to do it only for case of Point cause the case of Polygon seems to not work in 2.0.15 and previous releases. The array of coordinates was not passed to the polyline = new Polyline(points); https://github.com/brunob/mxn/commit/913e5006238a1b02867b2fc3d95fc4a0b5495a33#L1L1011 ++ b_b
I vote on having a "addGeoJSON" function the name is more concise and tells what the function does. I also agree that namespaces might complicate the the json required. One other think I think firing an event would be helpfull especialy if the json being loaded is large. one might need an event in order to coordinate other tasks that need to be performed after the json is done processing I also second having the naming be the "mxn" way. If you do it now you save yourself a lot of headache down the road trying to maintain incompatibilities. A question, why was the multipolygon and multilinestring capabilities ommited? At one point I had also suggested and supplied a patch for supporting sub filters, is that something the community did not find usefull or was it procedural issue for requesting additional functionality to be added. Thank you.> Date: Thu, 24 Mar 2011 19:36:17 +0100 > From: brunobergot at gmail.com > To: dezfowler at gmail.com > CC: mapstraction at lists.mapstraction.com > Subject: Re: [Mapstraction] new pull request and other improvements > > Hi Derek, > > Le 24/03/2011 17:45, Derek Fowler a ?crit : > > That''s an interesting one. I''d rather not have duplicate functionality. > > > > Maybe the best option would be to put a namespace in there for the new style > > stuff like the atom properties in the examples on this page: > > > > http://wiki.geojson.org/GeoJSON_draft_version_6 > > > > <http://wiki.geojson.org/GeoJSON_draft_version_6>If the namespace is defined > > e.g. > > > > "@namespaces": {"":"http://geojson.org/ns#", "mxn":" > > http://www.mapstraction.com"}, > > > > we can then look for properties like so: > > > > "properties": { > > "mxn:iconUrl": "http://someicon.com/icon.jpg", > > "mxn:iconAnchor": [100,100] > > } > > > > That sounds good technically but i also think it will force users to > produce more "complicated" geojson code to add to their maps. > > > If the namespace isn''t present we can fallback to looking for the old style > > properties maybe. > > > > If we use it only for compatibility reasons maybe we could simply handle > this in the addJSON function, like that : > > if the json object got properties => handle it like the new way > else => handle it the old way > > I''ll try to commit this tonight or tomorrow. > > I think we have to do it only for case of Point cause the case of > Polygon seems to not work in 2.0.15 and previous releases. The array of > coordinates was not passed to the polyline = new Polyline(points); > > https://github.com/brunob/mxn/commit/913e5006238a1b02867b2fc3d95fc4a0b5495a33#L1L1011 > > ++ > b_b > _______________________________________________ > 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/20110324/c098e0d1/attachment.htm>
Hi Jo, Le 24/03/2011 19:56, Namith jo a ?crit :> > I vote on having a "addGeoJSON" function the name is more concise and tells what the function does.I''m not sure that''s a good idea to change the name of the function for compatibility reasons.> > A question, why was the multipolygon and multilinestring capabilities ommited?Cause i haven''t got time to make it yet ;) Don''t hesitate to post some code for it.> > At one point I had also suggested and supplied a patch for supporting sub filters, is that something the community did not find usefull > or was it procedural issue for requesting additional functionality to be added.Sorry i''ve missed this one, can you post it again please ? Or maybe you could fork the project on github and make pullrequest for your work. ++ b_b
Hello bruno On the multipolygon and linestring I only asked since their implementation were part of the previous conversation. Thank you.> Date: Fri, 25 Mar 2011 12:42:36 +0100 > From: brunobergot at gmail.com > To: mapstraction at lists.mapstraction.com > Subject: Re: [Mapstraction] new pull request and other improvements > > Hi Jo, > > Le 24/03/2011 19:56, Namith jo a ?crit : > > > > I vote on having a "addGeoJSON" function the name is more concise and tells what the function does. > > I''m not sure that''s a good idea to change the name of the function for > compatibility reasons. > > > > > A question, why was the multipolygon and multilinestring capabilities ommited? > > Cause i haven''t got time to make it yet ;) Don''t hesitate to post some > code for it. > > > > > At one point I had also suggested and supplied a patch for supporting sub filters, is that something the community did not find usefull > > or was it procedural issue for requesting additional functionality to be added. > > Sorry i''ve missed this one, can you post it again please ? Or maybe you > could fork the project on github and make pullrequest for your work. > > ++ > b_b > _______________________________________________ > 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/20110325/00d51c88/attachment.htm>
Hello Bruno> I''m not sure that''s a good idea to change the name of the function for > compatibility reasons.I did no mean to change the name of the existing function. Consider also that there are people out there who, like me, have already added this patch and are using it as named, leaving the old one as was. We could leave the old one as deprecated and develop the geoJson one moving forward with eventual aim of removing it all together. Thank you.> Date: Fri, 25 Mar 2011 12:42:36 +0100 > From: brunobergot at gmail.com > To: mapstraction at lists.mapstraction.com > Subject: Re: [Mapstraction] new pull request and other improvements > > Hi Jo, > > Le 24/03/2011 19:56, Namith jo a ?crit : > > > > I vote on having a "addGeoJSON" function the name is more concise and tells what the function does. > > I''m not sure that''s a good idea to change the name of the function for > compatibility reasons. > > > > > A question, why was the multipolygon and multilinestring capabilities ommited? > > Cause i haven''t got time to make it yet ;) Don''t hesitate to post some > code for it. > > > > > At one point I had also suggested and supplied a patch for supporting sub filters, is that something the community did not find usefull > > or was it procedural issue for requesting additional functionality to be added. > > Sorry i''ve missed this one, can you post it again please ? Or maybe you > could fork the project on github and make pullrequest for your work. > > ++ > b_b > _______________________________________________ > 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/20110325/55e0fa80/attachment-0001.htm>