You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
(26) |
Apr
(23) |
May
(5) |
Jun
(8) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
|
Nov
(15) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(6) |
Feb
(4) |
Mar
(1) |
Apr
(6) |
May
(27) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
(19) |
Oct
(12) |
Nov
|
Dec
|
2008 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Richard G. <ric...@gm...> - 2007-05-25 18:39:44
|
On 5/25/07, olivier.terral <oli...@ge...> wrote: > Richard Greenwood a =E9crit : > > On 5/25/07, olivier.terral <oli...@ge...> wrote: > >> Hi > >> > >> I forget dynamic loading for the moment so itr works now. > > > > You have it working in mapbuilder? > > > Yep if I load the necessary file in index.html > and I replace the inverse and forward function by cs_transform. I am very happy to hear that. Would you mind sending me the mapbuilder code that you modified to integrate cscs? --=20 Richard Greenwood ric...@gm... www.greenwoodmap.com |
From: olivier.terral <oli...@ge...> - 2007-05-25 13:30:15
|
Richard Greenwood a écrit : > On 5/25/07, olivier.terral <oli...@ge...> wrote: >> Hi >> >> I forget dynamic loading for the moment so itr works now. > > You have it working in mapbuilder? > Yep if I load the necessary file in index.html and I replace the inverse and forward function by cs_transform. > I have some code which does dynamically load EPSG definitions which I > will send this weekend. But it does not work with functions, only with > data. > >> I've a important question for define EPSG in cscs with proj4: >> >> What do you think is the best: use the mapserver proj4 def or PostGIS >> proj4 def (spatial_ref_sys_table)? >> because I've seen little difference between the 2 def , for example : >> >> # Monte Mario (Rome) / Italy zone 1 >> mapserver : +proj=tmerc +lat_0=0 +lon_0=-3.45233333333333 +k=0.999600 >> +x_0=1500000 +y_0=0 +ellps=intl +pm=rome +units=m > >> postgis : +proj=tmerc +lat_0=0 +lon_0=21.45233333333333 >> +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +pm=rome +units=m > > Looks like postgis has already corrected for the Rome Prime Meridian, > which is what we want. We want the lon_0 to be relative to Greenwich > in the EPSG definition so that we do not have to adjust it on the > browser. > |
From: Richard G. <ric...@gm...> - 2007-05-25 12:50:27
|
On 5/25/07, olivier.terral <oli...@ge...> wrote: > Hi > > I forget dynamic loading for the moment so itr works now. You have it working in mapbuilder? I have some code which does dynamically load EPSG definitions which I will send this weekend. But it does not work with functions, only with data. > I've a important question for define EPSG in cscs with proj4: > > What do you think is the best: use the mapserver proj4 def or PostGIS > proj4 def (spatial_ref_sys_table)? > because I've seen little difference between the 2 def , for example : > > # Monte Mario (Rome) / Italy zone 1 > mapserver : +proj=tmerc +lat_0=0 +lon_0=-3.45233333333333 +k=0.999600 > +x_0=1500000 +y_0=0 +ellps=intl +pm=rome +units=m > postgis : +proj=tmerc +lat_0=0 +lon_0=21.45233333333333 > +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +pm=rome +units=m Looks like postgis has already corrected for the Rome Prime Meridian, which is what we want. We want the lon_0 to be relative to Greenwich in the EPSG definition so that we do not have to adjust it on the browser. -- Richard Greenwood ric...@gm... www.greenwoodmap.com |
From: olivier.terral <oli...@ge...> - 2007-05-25 08:47:16
|
Hi I forget dynamic loading for the moment so itr works now. I've a important question for define EPSG in cscs with proj4: What do you think is the best: use the mapserver proj4 def or PostGIS proj4 def (spatial_ref_sys_table)? because I've seen little difference between the 2 def , for example : # Monte Mario (Rome) / Italy zone 1 mapserver : +proj=tmerc +lat_0=0 +lon_0=-3.45233333333333 +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +pm=rome +units=m postgis : +proj=tmerc +lat_0=0 +lon_0=21.45233333333333 +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +pm=rome +units=m In regard of WKT the difference between both seems to be postgis add Prime_Meridian and Central_meridian (I think it's the good way) and mapserver substract central_meridian and prime_meridian ROJCS["Monte Mario (Rome) / Italy zone 1", GEOGCS["Monte Mario (Rome)", DATUM["Monte_Mario_Rome", SPHEROID["International 1924", 6378388.0, 297.0, AUTHORITY["EPSG","7022"]], AUTHORITY["EPSG","6806"]], PRIMEM["Rome", 12.45233333333333, AUTHORITY["EPSG","8906"]], UNIT["degree", 0.017453292519943295], AXIS["Lon", EAST], AXIS["Lat", NORTH], AUTHORITY["EPSG","4806"]], PROJECTION["Transverse_Mercator"], PARAMETER["central_meridian", 9.0], PARAMETER["latitude_of_origin", 0.0], PARAMETER["scale_factor", 0.9996], PARAMETER["false_easting", 1500000.0], PARAMETER["false_northing", 0.0], UNIT["m", 1.0], AXIS["x", EAST], AXIS["y", NORTH], AUTHORITY["EPSG","26591"]] # Puerto Rico epsg:4139 mapserver : +proj=longlat +ellps=clrk66 postgis : +proj=longlat +ellps=clrk66 +towgs84=11,72,-101,0,0,0,0 (this def seems to be the good because of WKT) Projections expert, I need your lights. Richard Greenwood a écrit : > On 5/24/07, olivier.terral <oli...@ge...> wrote: >> I begin to integrate cscs.js : >> >> I choose the way : >> -load cscs.js file in mapbuilder.js like others (Sarissa,Util .....). >> - delete all lines in Proj.js and replace by loading script necessary to >> a specific srs in param like this: >> >> function Proj(srs) { >> var tmp = srs.split(":"); >> cs = tmp[0]+tmp[1]; >> //transform EPSG:27563 in EPSG27563 >> >> mapbuilder.loadScript(baseDir+"/util/cscs/lib/defs/"+cs+".js"); >> //load proj4 definition of srs >> var epsg =new CS(eval("csList."+cs)); >> //create th CS object >> epsg.srs=srs; >> //add a param 'srs', necessary for >> openlayers >> epsg.units="m"; >> //units param should be added in >> cscs.js file >> >> mapbuilder.loadScript(baseDir+"/util/cscs/lib/"+epsg.proj+".js"); >> //load projection script, in that case : lambert conformal conic >> return epsg; >> //retourne l'objet Proj . >> } >> >> Problem of this method, the function >> "mapbuilder.loadScript(baseDir+"/util/cscs/lib/defs/"+cs+".js");" insert >> script in the head of html page but cannot execute the contain of the >> js file. >> >> Anybody know another method to load a js file? > > > You could just load the js files statically. (This would require the > web application developer to know which files they needed at design > time.) I would at least start with that approach and get the function > calls working before worrying about dynamic loading. > > |
From: Richard G. <ric...@gm...> - 2007-05-24 18:29:59
|
On 5/24/07, olivier.terral <oli...@ge...> wrote: > I begin to integrate cscs.js : > > I choose the way : > -load cscs.js file in mapbuilder.js like others (Sarissa,Util .....). > - delete all lines in Proj.js and replace by loading script necessary to > a specific srs in param like this: > > function Proj(srs) { > var tmp = srs.split(":"); > cs = tmp[0]+tmp[1]; > //transform EPSG:27563 in EPSG27563 > > mapbuilder.loadScript(baseDir+"/util/cscs/lib/defs/"+cs+".js"); > //load proj4 definition of srs > var epsg =new CS(eval("csList."+cs)); > //create th CS object > epsg.srs=srs; > //add a param 'srs', necessary for openlayers > epsg.units="m"; > //units param should be added in cscs.js file > > mapbuilder.loadScript(baseDir+"/util/cscs/lib/"+epsg.proj+".js"); > //load projection script, in that case : lambert conformal conic > return epsg; > //retourne l'objet Proj . > } > > Problem of this method, the function > "mapbuilder.loadScript(baseDir+"/util/cscs/lib/defs/"+cs+".js");" insert > script in the head of html page but cannot execute the contain of the > js file. > > Anybody know another method to load a js file? You could just load the js files statically. (This would require the web application developer to know which files they needed at design time.) I would at least start with that approach and get the function calls working before worrying about dynamic loading. -- Richard Greenwood ric...@gm... www.greenwoodmap.com |
From: olivier.terral <oli...@ge...> - 2007-05-24 16:23:56
|
I begin to integrate cscs.js : I choose the way : -load cscs.js file in mapbuilder.js like others (Sarissa,Util .....). - delete all lines in Proj.js and replace by loading script necessary to a specific srs in param like this: function Proj(srs) { var tmp = srs.split(":"); cs = tmp[0]+tmp[1]; //transform EPSG:27563 in EPSG27563 mapbuilder.loadScript(baseDir+"/util/cscs/lib/defs/"+cs+".js"); //load proj4 definition of srs var epsg =new CS(eval("csList."+cs)); //create th CS object epsg.srs=srs; //add a param 'srs', necessary for openlayers epsg.units="m"; //units param should be added in cscs.js file mapbuilder.loadScript(baseDir+"/util/cscs/lib/"+epsg.proj+".js"); //load projection script, in that case : lambert conformal conic return epsg; //retourne l'objet Proj . } Problem of this method, the function "mapbuilder.loadScript(baseDir+"/util/cscs/lib/defs/"+cs+".js");" insert script in the head of html page but cannot execute the contain of the js file. Anybody know another method to load a js file? Richard Greenwood a écrit : > On 5/24/07, olivier.terral <oli...@ge...> wrote: > >> Hi Richard, >> >> I don't use projection who use Grid Shift but I would like to know which >> projection use it (for having an example of grid_shift use) ? >> > > Any projection with datum=NAD27 requires a grid shift transformation. > There are others, but I can not remember them. > > >> For integrate cssc into mapbuilder, do you know precisely what we must >> to do? >> > > You would need to replace the calls to the Proj.js functions with > calls to the cscs functions, and include the required cscs.js files. > But do not commit any changes to the core MapBuilder without > permission from the MB developers. They are reluctant to use cscs. > > |
From: Richard G. <ric...@gm...> - 2007-05-24 12:51:29
|
On 5/24/07, olivier.terral <oli...@ge...> wrote: > Hi Richard, > > I don't use projection who use Grid Shift but I would like to know which > projection use it (for having an example of grid_shift use) ? Any projection with datum=NAD27 requires a grid shift transformation. There are others, but I can not remember them. > For integrate cssc into mapbuilder, do you know precisely what we must > to do? You would need to replace the calls to the Proj.js functions with calls to the cscs functions, and include the required cscs.js files. But do not commit any changes to the core MapBuilder without permission from the MB developers. They are reluctant to use cscs. -- Richard Greenwood ric...@gm... www.greenwoodmap.com |
From: olivier.terral <oli...@ge...> - 2007-05-24 07:28:35
|
Richard Greenwood a écrit : > On 5/23/07, olivier.terral <oli...@ge...> wrote: >> Thks richard you have right I've find an proj4 definition in PostGis >> where the 2 parameteres are defined +lon_0 et +pm so we can forget the >> +pm param. >> For information we have added 2 params +lat_1 +lat_2 for standard >> parallels and uncommented the ellps param. >> >> But for the Grid Shift, do you know a projection we use this? > > I have not implemented the Grid Shift datum transformation yet. It > will be very hard to do on a browser because it requires large lookup > tables. What coordinate system are you working on that requires it? > > Rich > Hi Richard, I don't use projection who use Grid Shift but I would like to know which projection use it (for having an example of grid_shift use) ? For integrate cssc into mapbuilder, do you know precisely what we must to do? |
From: Richard G. <ric...@gm...> - 2007-05-23 15:46:14
|
On 5/23/07, olivier.terral <oli...@ge...> wrote: > Thks richard you have right I've find an proj4 definition in PostGis > where the 2 parameteres are defined +lon_0 et +pm so we can forget the > +pm param. > For information we have added 2 params +lat_1 +lat_2 for standard > parallels and uncommented the ellps param. > > But for the Grid Shift, do you know a projection we use this? I have not implemented the Grid Shift datum transformation yet. It will be very hard to do on a browser because it requires large lookup tables. What coordinate system are you working on that requires it? Rich -- Richard Greenwood ric...@gm... www.greenwoodmap.com |
From: olivier.terral <oli...@ge...> - 2007-05-23 13:09:06
|
Thks richard you have right I've find an proj4 definition in PostGis where the 2 parameteres are defined +lon_0 et +pm so we can forget the +pm param. For information we have added 2 params +lat_1 +lat_2 for standard parallels and uncommented the ellps param. But for the Grid Shift, do you know a projection we use this? Richard Greenwood a écrit : > On 5/23/07, olivier.terral <oli...@ge...> wrote: >> Hi >> >> After a difficult beginning, my student integrates projections into >> cscs (merc lcc stere ). >> I've commited merc proj and works fine. >> >> We have a problem with the param +pm=Paris in the proj4 definition of >> epsg:27563 (lcc projection) . >> Could it be possible the param +pm is the param for a grid shift datum >> transformation ? >> >> If not, anybody can explained me or give a link to explain grid shift >> datum? > > +pm=Paris means that the coordinate system is referenced to the Paris > Prime Meridian, rather than Greenwich. It is 2° 20' 14.025" east of > Greenwich. I do not plan to support the 'pm' parameter in cscs because > it would require a lookup table to be loaded to the browser. Instead I > propose adjusting the +lon_0 parameter accordingly. So for EPSG:27563, > lon_0=2.33722916667 > |
From: Richard G. <ric...@gm...> - 2007-05-23 13:02:07
|
On 5/23/07, olivier.terral <oli...@ge...> wrote: > Hi > > After a difficult beginning, my student integrates projections into > cscs (merc lcc stere ). > I've commited merc proj and works fine. > > We have a problem with the param +pm=3DParis in the proj4 definition of > epsg:27563 (lcc projection) . > Could it be possible the param +pm is the param for a grid shift datum > transformation ? > > If not, anybody can explained me or give a link to explain grid shift dat= um? +pm=3DParis means that the coordinate system is referenced to the Paris Prime Meridian, rather than Greenwich. It is 2=B0 20' 14.025" east of Greenwich. I do not plan to support the 'pm' parameter in cscs because it would require a lookup table to be loaded to the browser. Instead I propose adjusting the +lon_0 parameter accordingly. So for EPSG:27563, lon_0=3D2.33722916667 --=20 Richard Greenwood ric...@gm... www.greenwoodmap.com |
From: olivier.terral <oli...@ge...> - 2007-05-23 11:20:30
|
Hi After a difficult beginning, my student integrates projections into cscs (merc lcc stere ). I've commited merc proj and works fine. We have a problem with the param +pm=Paris in the proj4 definition of epsg:27563 (lcc projection) . Could it be possible the param +pm is the param for a grid shift datum transformation ? If not, anybody can explained me or give a link to explain grid shift datum? Thanks in advance |
From: Adair, M. <adair@NRCan.gc.ca> - 2007-05-14 17:29:33
|
=20 > -----Original Message----- > From: Richard Greenwood [mailto:ric...@gm...]=20 > Sent: Sunday, May 13, 2007 10:46 > To: Adair, Mike > Cc: olivier.terral; Cameron Shorter;=20 > map...@li...;=20 > map...@li... > Subject: Re: [Mapbuilder-devel] Mapbuilder projections and CSCS >=20 > Mike and I seem to have somewhat different visions of what=20 > cscs should be, and definitely have different priorities. I=20 > don't feel that I have been successful in communicating my=20 > position in previous posts, but I'll give it one last try=20 > here. This is long. >=20 > My vision for cscs: > 1. Client-side (web-browser) JavaScript coordinate=20 > transformation, including datum transformation. > 2. Based on Proj4 code. > 3. Modular, so that the client only has to load code required=20 > for their transformation(s). > 4. Server agnostic (no server-side requirements beyond=20 > serving static JavaScript files). I agree with all the above, with the exception that we can also add some (optional) server-side functionality to help with projection definitions. >=20 > My 'high' priorities, in order: > 1. Substitute cscs for Proj.js in MB. I'll come back to this later. > 2. Port all existing projection functions in Proj.js to cscs=20 > (I've only got Transverse Mercator in there now). > 3. Split all existing EPSG definitions into separate js files. > 4. Add additional projection functions from Proj4, and=20 > associated EPSG definitions. > 5. Add grid shift datum transformation support. (Currently only 3 and > 7 parameter transformations are in there) >=20 > My 'low' priorities, which keep coming up in these exchanges: > 1. JSON. I have nothing against this, but I don't see that it=20 > adds much meaningful functionality. It allows easy run-time=20 > transformation selection, but 99% of the time, the web-app=20 > developer will know what projections/transformations there=20 > app requires ahead of time. Is somebody asking for this? Is=20 > this holding up integration of cscs into MB? If somebody=20 > wants run-time coordinate system selection, we can very=20 > easily provide a single, huge js file containing everything=20 > that we have (same as Proj.js now, but with datum=20 > transformations thrown > in!) This could be part of the build script. Yes most of the time a developer knows what projections will be used and can include them statically, but how often do we get the "how do I get support for EPSG:xyz"? A simple lookup service will solve that problem. This doesn't have to hold up MB integration. > 2. Adopting an OL object style. Again, I have nothing against this. > I've never looked at the OL code, so I don't know what is=20 > really involved here. Can some discussion of this be added to=20 > the MB coding style page in Confluence? I hope this is not=20 > holding up integration of cscs into MB as there are only two=20 > functions that a client needs to call to access cscs=20 > functionality. I want cscs to be an independent library, and=20 > it does not need to adopt the object style du jour to do that. In my opinion, this does hold up MB integration (more than just OL coding style, but the object structure). To get the Proj.js equivalent, you need two cscs objects and there are differences in how the functions get called and it's not just a straightforward substitution as it stands. > 3. WKT coordinate system definitions. This would be a ton of work. > Personally I don't see the need to do it on the client. If=20 > somebody needs this, I think it would be better done on the=20 > server. Can you provide an example of how this would be used?=20 > Is somebody asking for it? Do they have money? Actually a JSON service to return proj4 command line settings is dead simple. And there is demand for this, c.f. the "how do I support EPSG:xyz" questions. Mike |
From: Richard G. <ric...@gm...> - 2007-05-14 13:05:30
|
On 5/13/07, Paul Spencer <pag...@gm...> wrote: > Just a comment ... there seems to be a general move away form having > to load many small js files in ajax applications primarily because of > performance reasons (multiple connections cause more overhead than > just jamming it all into a single file). I would highly recommend > that you provide a pre-minimized cscs.js file that has everything in > it, or a mechanism to build a cscs.js file that has what you need in > it (if the whole thing is too big). Dynamic loading is really nice > for development but I'm personally starting to realize the need for > minimizing connection overhead in deployed applications The web application developer can easily combine the necessary files into one if they choose to. It would be a very rare application in which the coordinate system(s) was not know until run time. Including every projection and transformation in one file would probably result in >3000 lines of unused code. Rich -- Richard Greenwood ric...@gm... www.greenwoodmap.com |
From: Cameron S. <cam...@gm...> - 2007-05-14 05:10:56
|
Paul, Yes, in general we should be minimising the files we download, but I think projections are a special case. There are thousands of projections or which we only need one. So the idea is that we download the core Projection code as part of the Mapbuilder compressed file, and one (or 2) extra small projection constants file. Paul Spencer wrote: > On 13-May-07, at 6:21 PM, Richard Greenwood wrote: > >>> In my head, JSON is the same as your suggestion of splitting each datum >>> into separate files. >>> JSON is a format to describe data in Javascript. Ie, it is Javascript >>> data without javascript functions. >>> My understanding is that CSCS should load 2 files: >>> 1. The JS functions like forward() and reverse() >>> 2. One JS transform file which contains parameters for a particular >>> projection. >>> Is this in line with what you are suggesting? >> >> Pretty much. You might end up loading more than 2 files, e.g. you >> always load cscs.js as this is the base. You'd load 1 or more for >> projection(s) you wish to work with, you might load the datum >> transformation code if you need it, and you'd load a 1 line file for >> each EPSG definition that you need. (Excluding long/lat which is >> included by default). I have comments in the test page that explpain >> this. > > Just a comment ... there seems to be a general move away form having > to load many small js files in ajax applications primarily because of > performance reasons (multiple connections cause more overhead than > just jamming it all into a single file). I would highly recommend > that you provide a pre-minimized cscs.js file that has everything in > it, or a mechanism to build a cscs.js file that has what you need in > it (if the whole thing is too big). Dynamic loading is really nice > for development but I'm personally starting to realize the need for > minimizing connection overhead in deployed applications > > Cheers > > Paul > > +-----------------------------------------------------------------+ > |Paul Spencer psp...@dm... | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 |
From: Paul S. <pag...@gm...> - 2007-05-14 04:11:05
|
On 13-May-07, at 6:21 PM, Richard Greenwood wrote: >> In my head, JSON is the same as your suggestion of splitting each >> datum >> into separate files. >> JSON is a format to describe data in Javascript. Ie, it is Javascript >> data without javascript functions. >> My understanding is that CSCS should load 2 files: >> 1. The JS functions like forward() and reverse() >> 2. One JS transform file which contains parameters for a particular >> projection. >> Is this in line with what you are suggesting? > > Pretty much. You might end up loading more than 2 files, e.g. you > always load cscs.js as this is the base. You'd load 1 or more for > projection(s) you wish to work with, you might load the datum > transformation code if you need it, and you'd load a 1 line file for > each EPSG definition that you need. (Excluding long/lat which is > included by default). I have comments in the test page that explpain > this. Just a comment ... there seems to be a general move away form having to load many small js files in ajax applications primarily because of performance reasons (multiple connections cause more overhead than just jamming it all into a single file). I would highly recommend that you provide a pre-minimized cscs.js file that has everything in it, or a mechanism to build a cscs.js file that has what you need in it (if the whole thing is too big). Dynamic loading is really nice for development but I'm personally starting to realize the need for minimizing connection overhead in deployed applications Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer psp...@dm... | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ |
From: Richard G. <ric...@gm...> - 2007-05-13 22:21:58
|
On 5/13/07, Cameron Shorter <cam...@gm...> wrote: > In my head, JSON is the same as your suggestion of splitting each datum > into separate files. > JSON is a format to describe data in Javascript. Ie, it is Javascript > data without javascript functions. > My understanding is that CSCS should load 2 files: > 1. The JS functions like forward() and reverse() > 2. One JS transform file which contains parameters for a particular > projection. > Is this in line with what you are suggesting? Pretty much. You might end up loading more than 2 files, e.g. you always load cscs.js as this is the base. You'd load 1 or more for projection(s) you wish to work with, you might load the datum transformation code if you need it, and you'd load a 1 line file for each EPSG definition that you need. (Excluding long/lat which is included by default). I have comments in the test page that explpain this. > If I understand correctly, the structure of the Proj code and how we use > it is a bit of a hack and Mike would like to clean this up. However, > Richard is right in thinking that plugging into the existing Proj code > should be easy. The Proj cleanup and switch to CSCS can be treated as > separate problems. cscs replaces Proj.js. There are basically two functions that get called: an initialization function, called once, and a transformation function called many times. Proj.js and cscs are essentially the same in this regard. So when I say I envision a couple hours work to switch MB from Proj.js to cscs, I mean to change the calls to these two functions. > The tasks that are required as I see it: > 1. Modify Proj.js so that it dynamically loads the correct CSCS projection. > We currently use Mapbuilder.loadScript() for dynamic loading however we > are deprecating this in favour of bundling Mapbuilder as one package. I > think that Projections are a special case and should still be > dynamically loaded. So we probably need to extract out the loadScript() > into the core CSCS code. (.5 to 1.5 days work) > An initial shortcut would be to load all projections. Ie write a script > to bundle all the projections together and modify the build file. (1 to > 1.5 days work) As I noted above, cscs completely would replace Proj.js. Before that should be done, all projections currently in Proj.js should be moved into cscs, which has a somewhat more OO structure. I know everyone is keen on dynamic loading, but what I was trying to say in by previous post is that >99% of the time, the web application developer knows what coordinate system(s) they will be working with, in which case they can load all the appropriate js files 'statically'. > 2. Build all the coordinate/datum shift files (containing parameters > only). One file for each EPSG code. These files are equivalent of a JSON > code. Mike noted before that these codes are available in PostGIS. > Richard, is this on track? Pretty much. There are a few Proj4 constructs that I don't think are logical to support on the client, e.g. "meridian" defines an offset from Greenwich which would require a lookup table on the client, so I'd adjust the long0 in the EPSG js file instead. I think there were a couple others, but it's been so long since I've looked at the code that I don't remember. Proj4 EPSG codes are in PostGIS, in text files in the Proj4 distribution, and in various formats directly from EPSG. Rich -- Richard Greenwood ric...@gm... www.greenwoodmap.com |
From: Cameron S. <cam...@gm...> - 2007-05-13 21:36:35
|
Thankyou Richard for your summary. You have me convinced. I've inserted comments below. Richard Greenwood wrote: > Mike and I seem to have somewhat different visions of what cscs should > be, and definitely have different priorities. I don't feel that I have > been successful in communicating my position in previous posts, but > I'll give it one last try here. This is long. > > My vision for cscs: > 1. Client-side (web-browser) JavaScript coordinate transformation, > including datum transformation. > 2. Based on Proj4 code. > 3. Modular, so that the client only has to load code required for > their transformation(s). > 4. Server agnostic (no server-side requirements beyond serving static > JavaScript files). > > My 'high' priorities, in order: > 1. Substitute cscs for Proj.js in MB. I'll come back to this later. > 2. Port all existing projection functions in Proj.js to cscs (I've > only got Transverse Mercator in there now). > 3. Split all existing EPSG definitions into separate js files. > 4. Add additional projection functions from Proj4, and associated EPSG > definitions. > 5. Add grid shift datum transformation support. (Currently only 3 and > 7 parameter transformations are in there) > > My 'low' priorities, which keep coming up in these exchanges: > 1. JSON. I have nothing against this, but I don't see that it adds > much meaningful functionality. It allows easy run-time transformation > selection, but 99% of the time, the web-app developer will know what > projections/transformations there app requires ahead of time. Is > somebody asking for this? Is this holding up integration of cscs into > MB? If somebody wants run-time coordinate system selection, we can > very easily provide a single, huge js file containing everything that > we have (same as Proj.js now, but with datum transformations thrown > in!) This could be part of the build script. In my head, JSON is the same as your suggestion of splitting each datum into separate files. JSON is a format to describe data in Javascript. Ie, it is Javascript data without javascript functions. My understanding is that CSCS should load 2 files: 1. The JS functions like forward() and reverse() 2. One JS transform file which contains parameters for a particular projection. Is this in line with what you are suggesting? > 2. Adopting an OL object style. Again, I have nothing against this. > I've never looked at the OL code, so I don't know what is really > involved here. Can some discussion of this be added to the MB coding > style page in Confluence? I hope this is not holding up integration of > cscs into MB as there are only two functions that a client needs to > call to access cscs functionality. I want cscs to be an independent > library, and it does not need to adopt the object style du jour to do > that. I agree, this is not required, but if we get it right up front it will save us rework later. Olivier should be able to help with example code here. > 3. WKT coordinate system definitions. This would be a ton of work. > Personally I don't see the need to do it on the client. If somebody > needs this, I think it would be better done on the server. Can you > provide an example of how this would be used? Is somebody asking for > it? Do they have money? Yes, I agree we don't need this initially. I take you word on the effort estimates. We can add this later if there is a need for it. > > Oliver has a wonderful offer on the table. Mike and Cameron need to > tell him if his student should be working in the cscs framework, or > the Proj.js framework, or somewhere else. I don't see that > substituting cscs in for Proj.js should take more than 2 hours. I've > been waiting to see that level of commitment before I do any more work > on cscs. The estimate of 3 days to integrate it, and the solicitation > for sponsorship funding has me pretty depressed. Do the 3 items I list > as 'low' priority have to be completed before you intend to > incorporate cscs? Do you guys see where Proj.js falls short and why I > see it as a dead end? Do you see the importance of datum > transformations? I can't see why we're having so much trouble getting > this thing off the ground. If I understand correctly, the structure of the Proj code and how we use it is a bit of a hack and Mike would like to clean this up. However, Richard is right in thinking that plugging into the existing Proj code should be easy. The Proj cleanup and switch to CSCS can be treated as separate problems. The tasks that are required as I see it: 1. Modify Proj.js so that it dynamically loads the correct CSCS projection. We currently use Mapbuilder.loadScript() for dynamic loading however we are deprecating this in favour of bundling Mapbuilder as one package. I think that Projections are a special case and should still be dynamically loaded. So we probably need to extract out the loadScript() into the core CSCS code. (.5 to 1.5 days work) An initial shortcut would be to load all projections. Ie write a script to bundle all the projections together and modify the build file. (1 to 1.5 days work) 2. Build all the coordinate/datum shift files (containing parameters only). One file for each EPSG code. These files are equivalent of a JSON code. Mike noted before that these codes are available in PostGIS. Richard, is this on track? I suspect that the best way to do this is to automate the process. Write a simple perl script of similar. (2 to 5 days work) == This is probably enough to get CSCS incorporated into Mapbuilder == 3. Identify the inheritance structure required by the CSCS code (based on OpenLayers) and apply to the core CSCS code. (1 to 1.5 days work) > > Rich > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 |
From: Richard G. <ric...@gm...> - 2007-05-13 14:46:01
|
Mike and I seem to have somewhat different visions of what cscs should be, and definitely have different priorities. I don't feel that I have been successful in communicating my position in previous posts, but I'll give it one last try here. This is long. My vision for cscs: 1. Client-side (web-browser) JavaScript coordinate transformation, including datum transformation. 2. Based on Proj4 code. 3. Modular, so that the client only has to load code required for their transformation(s). 4. Server agnostic (no server-side requirements beyond serving static JavaScript files). My 'high' priorities, in order: 1. Substitute cscs for Proj.js in MB. I'll come back to this later. 2. Port all existing projection functions in Proj.js to cscs (I've only got Transverse Mercator in there now). 3. Split all existing EPSG definitions into separate js files. 4. Add additional projection functions from Proj4, and associated EPSG definitions. 5. Add grid shift datum transformation support. (Currently only 3 and 7 parameter transformations are in there) My 'low' priorities, which keep coming up in these exchanges: 1. JSON. I have nothing against this, but I don't see that it adds much meaningful functionality. It allows easy run-time transformation selection, but 99% of the time, the web-app developer will know what projections/transformations there app requires ahead of time. Is somebody asking for this? Is this holding up integration of cscs into MB? If somebody wants run-time coordinate system selection, we can very easily provide a single, huge js file containing everything that we have (same as Proj.js now, but with datum transformations thrown in!) This could be part of the build script. 2. Adopting an OL object style. Again, I have nothing against this. I've never looked at the OL code, so I don't know what is really involved here. Can some discussion of this be added to the MB coding style page in Confluence? I hope this is not holding up integration of cscs into MB as there are only two functions that a client needs to call to access cscs functionality. I want cscs to be an independent library, and it does not need to adopt the object style du jour to do that. 3. WKT coordinate system definitions. This would be a ton of work. Personally I don't see the need to do it on the client. If somebody needs this, I think it would be better done on the server. Can you provide an example of how this would be used? Is somebody asking for it? Do they have money? Oliver has a wonderful offer on the table. Mike and Cameron need to tell him if his student should be working in the cscs framework, or the Proj.js framework, or somewhere else. I don't see that substituting cscs in for Proj.js should take more than 2 hours. I've been waiting to see that level of commitment before I do any more work on cscs. The estimate of 3 days to integrate it, and the solicitation for sponsorship funding has me pretty depressed. Do the 3 items I list as 'low' priority have to be completed before you intend to incorporate cscs? Do you guys see where Proj.js falls short and why I see it as a dead end? Do you see the importance of datum transformations? I can't see why we're having so much trouble getting this thing off the ground. Rich -- Richard Greenwood ric...@gm... www.greenwoodmap.com |
From: Adair, M. <adair@NRCan.gc.ca> - 2007-05-09 18:17:40
|
The ideas I have for this below: >=20 > now I would like to know what we must implemented : > 1) one file per projection , like in proj4, but using function > (init,forward,inverse) of our proj.js Yes I agree with this. I would like to add dynamic loading of the function definitions via JSON > 2) one file per EPSG with their proj4 def Yes this is good as is. Again, I would like to add dynamic lookup of the params via a JSON service, but we should still support static init files where the projections being used in the app are known beforehand. We might also consider encoding these using the WKT format, or using JSON, rather than the proj4 command line parameter format, although this makes it easy to compare the command-line C version of proj4 with the JS version. > 3) Other functions in cscs.js ? - I would suggest making the cs_*_transform (and any other methods required) to be methods of the CS object using .prototype etc. (ie. JS coding style like in Open Layers) - I would suggest that if the target CS object is not supplied, then the target transformation should default to EPSG4326 (WGS84) so we get behaviour like Proj.js in MB Mike |
From: olivier.terral <oli...@ge...> - 2007-05-09 15:15:52
|
Hi I begin to have a look to cscs, I've tested the page test.html and I see that it works good . I' ve understood cs2cs transform one coordinate system in another. now I would like to know what we must implemented : 1) one file per projection , like in proj4, but using function (init,forward,inverse) of our proj.js 2) one file per EPSG with their proj4 def 3) Other functions in cscs.js ? Richard , Mike, could you tell me more on the state of cscs? Adair, Mike a écrit : > Richard, > > Despair not. I think this library is too important to let drop. I plan > to start working on it again soon, after I get up to speed with the OL > work. > > Mike > > -----Original Message----- > From: map...@li... > [mailto:map...@li...] On Behalf Of > Richard Greenwood > Sent: April 26, 2007 10:01 PM > To: Cameron Shorter > Cc: Adair, Mike; map...@li...; > map...@li...; oli...@ge... > Subject: Re: [Mapbuilder-devel] Mapbuilder projections and CSCS > > I stopped working on cscs after our last email exchange 4 Feb 2007. > I'm pretty bummed by what I see as a lack of understanding and poor > communication. > > Rich > > > On 4/26/07, Cameron Shorter <cam...@gm...> wrote: > >> Richard, Mike, >> Olivier notes that he has a student that is about to add projections >> to Mapbuilder from Geoserver. >> >> I assume that it would be better to get the student to extend CSCS and >> > > >> then integrate CSCS into Mapbuilder in order to replace proj.js >> >> Richard, >> What is the state of CSCS? >> Does it support as many projections as the Proj.js file? >> >> Mike, >> What is involved in migrating CSCS into Proj? >> >> -- >> Cameron Shorter >> Systems Architect, http://lisasoft.com.au >> Tel: +61 (0)2 8570 5050 >> Mob: +61 (0)419 142 254 >> >> >> > > > -- > Richard Greenwood > ric...@gm... > www.greenwoodmap.com > > ------------------------------------------------------------------------ > - > This SF.net email is sponsored by DB2 Express Download DB2 Express C - > the FREE version of DB2 express and take control of your XML. No limits. > Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > mapbuilder-devel mailing list > map...@li... > https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel > > |
From: Adair, M. <adair@NRCan.gc.ca> - 2007-04-28 14:13:03
|
Richard, Despair not. I think this library is too important to let drop. I plan to start working on it again soon, after I get up to speed with the OL work. Mike=20 -----Original Message----- From: map...@li... [mailto:map...@li...] On Behalf Of Richard Greenwood Sent: April 26, 2007 10:01 PM To: Cameron Shorter Cc: Adair, Mike; map...@li...; map...@li...; oli...@ge... Subject: Re: [Mapbuilder-devel] Mapbuilder projections and CSCS I stopped working on cscs after our last email exchange 4 Feb 2007. I'm pretty bummed by what I see as a lack of understanding and poor communication. Rich On 4/26/07, Cameron Shorter <cam...@gm...> wrote: > Richard, Mike, > Olivier notes that he has a student that is about to add projections=20 > to Mapbuilder from Geoserver. > > I assume that it would be better to get the student to extend CSCS and > then integrate CSCS into Mapbuilder in order to replace proj.js > > Richard, > What is the state of CSCS? > Does it support as many projections as the Proj.js file? > > Mike, > What is involved in migrating CSCS into Proj? > > -- > Cameron Shorter > Systems Architect, http://lisasoft.com.au > Tel: +61 (0)2 8570 5050 > Mob: +61 (0)419 142 254 > > -- Richard Greenwood ric...@gm... www.greenwoodmap.com ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ mapbuilder-devel mailing list map...@li... https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel |
From: Richard G. <ric...@gm...> - 2007-04-27 02:01:25
|
I stopped working on cscs after our last email exchange 4 Feb 2007. I'm pretty bummed by what I see as a lack of understanding and poor communication. Rich On 4/26/07, Cameron Shorter <cam...@gm...> wrote: > Richard, Mike, > Olivier notes that he has a student that is about to add projections to > Mapbuilder from Geoserver. > > I assume that it would be better to get the student to extend CSCS and > then integrate CSCS into Mapbuilder in order to replace proj.js > > Richard, > What is the state of CSCS? > Does it support as many projections as the Proj.js file? > > Mike, > What is involved in migrating CSCS into Proj? > > -- > Cameron Shorter > Systems Architect, http://lisasoft.com.au > Tel: +61 (0)2 8570 5050 > Mob: +61 (0)419 142 254 > > -- Richard Greenwood ric...@gm... www.greenwoodmap.com |
From: Cameron S. <cam...@gm...> - 2007-04-26 12:17:59
|
Richard, Mike, Olivier notes that he has a student that is about to add projections to Mapbuilder from Geoserver. I assume that it would be better to get the student to extend CSCS and then integrate CSCS into Mapbuilder in order to replace proj.js Richard, What is the state of CSCS? Does it support as many projections as the Proj.js file? Mike, What is involved in migrating CSCS into Proj? -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 |
From:
<jor...@ho...> - 2007-04-18 15:08:45
|
Hi everyone: this is the first time I work with MapBuilder and I have one doubt. In MapBuilder, the Layers marked as 'hidden' still do a GetMap() call. It's possible configure MapBuilder or do some type of modification to avoid that call? The problem is that I have hundreds of Layers to display, and it would be great to avoid that behaviour. Thanks for all. _________________________________________________________________ Un amor, una aventura, compañía para un viaje. Regístrate gratis en MSN Amor & Amistad. http://match.msn.es/match/mt.cfm?pg=channel&tcid=162349 |