mapbuilder-proj — Discussion related to the Javascript projection module

[Mapbuilder-proj] rookverd

[LJ m. <LJm...@LI...>]

Rumor News:
Oncology Med. Inc.  (OTC: ONCO) a Cancer Treatment Solutions Group is said to have
experienced over a 1000% increase in revenues for the fiscal 3rd quarter ending July,
2007 compared with the prior year while fiscal fourth quarter results for 2007 are on
track to exceed this year’s third quarter results.

ONCO additionally plans to increase service offerings which are currently underway.
Don’t wait for the news to come out and lose the opportunity to get in front of the
general investing public.  Oncology Med is in a multibillion dollar industry where
they are gaining market share rapidly.

Call your broker now for ONCO.

Re: [Mapbuilder-proj] cscs/Proj4js

[Mike A. <ma...@dm...>]

Richard,

Yes the demo is for the projection library and I see Proj4js/CSCS as one 
and the same thing.  It looks like I'm scheduled for 2:30 on Wed.  I 
would gladly accept your participation.  I'll talk to you off the list 
to discuss what we can show.

Mike

Richard Greenwood wrote:
> Mike,
>
> Is this demo next week specifically for the JavaScript projection
> library? When & where? Might I participate? Or do you see the Proj4js
> library as separate from cscs?
>
> Regarding the API:
>
> 1. "Just" going from lat/long to a projected cs is still effected by
> datum. I started this project in response to Radim Blazek's problems
> going between lat/long WGS84 and an Italian grid on the International
> ellipsoid. That is why I would like a single transform function. The
> way I had it setup was REALLY easy. WGS84 lat/long was the default cs
> when you created a new cs object. It's like one more step, but it can
> keep people out of trouble. And it makes it easier to port someone
> else's code into your project without having to know that you need to
> call a completely different method because your cs's aren't both on
> the same datum.
>   
Agreed.  And transform() will still be identical to the way you had it 
once I finish the datum code.  But I still think forward() and inverse() 
methods are useful to expose.

> 2. I've got a project that has been using the cscs code for a year
> now. It uses the from:
>    cs_transform(source, destination, point);
> I can see the value of adding the namespace, but I'd like to see
> things like parameter order remain the same lacking a compelling
> reason to the contrary.
>   
OK with me.

> 3. Aliases - same as I said previously, your example:
>    xyPoint = sourceProj.lonLatToMapXY(llPoint);
> assume that xyPoint and llPoint are both on the same datum. What's so
> hard about:
>    cs_transform(UTM13, lonLat, point);
> all you have to remember is that source comes first, destination second.
>
> Rich
>
>
>
> On 9/19/07, Mike Adair <ma...@dm...> wrote:
>   
>> Richard,
>>
>> Great, this sounds like a better dialog.  It seems like the only issues
>> to be decided are the name and the API.  (Datums are disabled for the
>> moment only because I haven't had time to convert that code over to the
>> new format.)
>>
>> For the API, I can be convinced that transform() could be a 'global'
>> method since it depends equally on a source and destination proj
>> object.  I think the individual proj objects should still expose
>> forward() and inverse(), since they will always be there and are very
>> useful in themselves, but I also like the aliases because I can never
>> remember which one goes to lon/lat and vice versa.  Using XYZ as the
>> project name, the API would look like this:
>>
>> sourceProj = new XYZ.Proj(projCode1);
>> destProj = new XYZ.Proj(projCode2);
>> XYZ.transform(sourceProj, point, destProj);    <- the alternative is
>> sourceProj.transform(point, destProj);
>> lonlat = sourceProj.mapXYToLonLat(XYpoint);
>> xyPoint = sourceProj.lonLatToMapXY(llPoint);
>>
>> For the name issue, I'm really not sure what to say. I know that it is
>> more technically correct to call these objects coordinate systems, but
>> with my (limited) marketing hat on, CSCS just doesn't mean anything to
>> me, and I suspect it would be the same  for the large majority of users,
>> these are just called projections in the common terminology.  I think we
>> would get much more uptake of this library with a better name than CSCS.
>>
>> Anyone have another suggestions?  Maybe I should ask for a show of hands
>> at the demo next week?  I hope you will be in attendance.
>>
>> Mike
>>
>>
>> Richard Greenwood wrote:
>>     
>>> Mike,
>>>
>>> The project rename and major structural changes certainly leaves me
>>> feeling disenfranchised. One man's refactroing may be another man's
>>> hostile take over.
>>>
>>> I prefer the term "coordinate system" over "projection" because a
>>> coordinate system is made up of both a projection and a datum. Adding
>>> support for datum transformations was the impetus for me to start the
>>> project.
>>>
>>> I think a single entry point is preferable (transform()) to exposing
>>> forward() and inverse() and aliases thereof. Encouraging the use of
>>> forward() is going to perpetuate the issues that were coming up on the
>>> list with the use of proj.js: users will attempt to project WGS84
>>> lat/long into their local grid, which in many parts of the world is
>>> not on WGS84, and then be frustrated when they get incorrect results.
>>>
>>> You've disabled datum transformation in Proj4.js. As a minimum there
>>> should be an alert if you're going to encourage people to test and
>>> integrate the library.
>>>
>>> Making transform() a method of a cs does not make sense to me. To
>>> transform a point you use a method of a cs and then pass another cs as
>>> a parameter. Kind of reminds me of the ArcView 3.2 transformer. What's
>>> wrong with transform(src, dest, pt)? If you're determined that
>>> transform must be a method of something, then making it a method of a
>>> point seems more logical, e.g. p2 = p1.transform(); Or better,
>>> overload the equals, e.g. p1 = p2; where a point is comprised of X,Y,
>>> cs.
>>>
>>> I am in favor of putting it into its own namespace.
>>>
>>> Dynamic loading of defs and projection class code: I am in favor of
>>> this. I had the definitions loading dynamically but did not commit it
>>> because I doubted that my method was consistent with MapBuilder's. I
>>> had asked about dynamically loading the projection code but didn't get
>>> an answer. Are you dynamically loading the functions? If so, is there
>>> an example?
>>>
>>> I've never felt like the destination between cs definitions and
>>> functions was fully respected. Looking up a definition is no big, it's
>>> just a bunch of ASCII. But spatialreference.org, PostGIS, etc. don't
>>> provide the functions in JavaScript run by the browser. That's what
>>> this project is about. By saying that any projection can be handled by
>>> looking it up in some existent location isn't quite accurate.
>>>
>>> Rich
>>>
>>> On 9/18/07, Mike Adair <ma...@dm...> wrote:
>>>
>>>       
>>>> (Moving this to the mapbuilder-proj list with a proper subject line.
>>>> Please reply to that list only)
>>>>
>>>> Richard,
>>>>
>>>> I really hope we can resolve your concerns over the recent work done on
>>>> this project.  I have no intention of "duking it out", I only want to
>>>> end up with a solid coordinate transformation library, with a small
>>>> footprint and one that makes it as easy as possible for the end-user to
>>>> do coordinate transformations in the browser.  This piece is too
>>>> important for the whole JS client community to let it flounder in an
>>>> argument like this.
>>>>
>>>> The work that you and others have done to date to get cscs where it is,
>>>> is great and in fact I haven't touched the actual code within the
>>>> various methods, all I've done is to change the way the various objects
>>>> are structured to use modern JavaScript techniques.
>>>>
>>>> Perhaps by listing the issues (as I see them) we can resolve them
>>>> together.  Feel free to add your own issues to the list:
>>>>
>>>> 1. The name of the project:  just about anyone I talk to about this has
>>>> no idea what 'cscs' is.  I think that Proj4js is a much more descriptive
>>>> name in  that it tells where it came from (Proj4), it deals with
>>>> Projections, and it is a JS library for browser clients.  I can live
>>>> with  'cscs' as the name , but I feel that we would loose many potential
>>>> end-users because no one really knows what 'cscs' is.
>>>>
>>>> 2. Object-oriented-ness:  Any external library like this that is to be
>>>> included in other projects should use it's own namespace so that you
>>>> avoid naming collisions and re-defining functions and properties
>>>> accidentally.  This also allows us to define things like Proj4js.const
>>>> which includes library-wide constants and methods that get used over and
>>>> over (e.g. all the msfnz, tsfnz, etc. methods that are repeated in every
>>>> projection class code).  I think this should be done no matter what the
>>>> project is called because it is just good programming technique.
>>>>
>>>> 3. dynamic loading of defs and projection class code: this is something
>>>> I had always intended to implement, no matter what the project is
>>>> called.  The issue is that in cscs, you always need to specify the
>>>> cslist.defs files and projection code (e.g. lcc.js) when an application
>>>> is being created.  That is fine if you know beforehand what projections
>>>> your application is dealing with, but in my experience, there are many
>>>> cases where you don't know that beforehand.  Dynamic loading of this
>>>> information allows the library to handle practically any projection,
>>>> which is a huge bonus in my opinion.
>>>>
>>>> 4. Proj objects: I feel that the changes I made to the Proj objects make
>>>> a lot of sense.  You still have the transform() method available,
>>>> passing in a second Proj object, but in a lot of cases the coord
>>>> transformation required is simply a MapXY to Lon/Lat and vice versa,
>>>> without creating a second Proj object.  I've also defined aliases for
>>>> forward()/inverse() methods as mapXYToLonLat() and lonLatToMapXY() to
>>>> make them easier to understand.
>>>>
>>>> Like I said above, my intention here is to end up with the best
>>>> coordinate transformation library possible, and I think these are some
>>>> of the steps needed to move cscs to get there.  The work you have done
>>>> on cscs to date is invaluable, so I really hope your contributions to
>>>> this project continue. Maybe all it will take is for us to sit down over
>>>> a beer and a scratch pad at FOSS4G next week, but hopefully we can come
>>>> to an agreement sooner than that.  Comments from the community are also
>>>> welcome.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> Richard Greenwood wrote:
>>>>
>>>>         
>>>>> On 9/17/07, Mike Adair <ma...@dm...> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Yes cscs did have that problem.  However the Proj4js version loads only
>>>>>> the projection class code required based on the projection definition so
>>>>>> you never need to worry about that.   If you know beforehand what
>>>>>> projections your app will be dealing with, you can also load the code
>>>>>> statically.
>>>>>>
>>>>>>
>>>>>>             
>>>>> cscs does not "have that problem" if you are referring to functions
>>>>> being duplicated. cscs transformation functions are only defined once.
>>>>> It's a bummer that cscs and Proj4js have split so early in their
>>>>> respective development. And it's a bummer that we need to "duke it
>>>>> out" next week. Seems like we'd get a lot further by working together.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> The advantage of the Proj4js approach is that as long as the Proj4
>>>>>> initialization parameters are available somewhere (statically on disk,
>>>>>> or in a Web Service like spatialreference.org, or a local interface to
>>>>>> PostGIS) any projection can be handled.
>>>>>>
>>>>>>
>>>>>>             
>>>>> There's a lot more to a coordinate system transformation than its
>>>>> Proj4 initialization parameters. You need the forward/inverse
>>>>> functions, and you need the appropriate datum transformation
>>>>> functions. And they need to be in JavaScript if you're going to do it
>>>>> on the client.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>
>>>       
>>     
>
>
>   

[Mapbuilder-proj] nuuttets

[Reynan m. <Rey...@mi...>]

Greeting mapbuilder-proj
wishing you had a bigger one-eyed wonder? and do something about it

Reynan moallemi
http://citibpyz.com/

Re: [Mapbuilder-proj] cscs/Proj4js

[Richard G. <ric...@gm...>]

I don't think it's a stalemate. I don't care what it's called. I mean
I do, but I'm not forcing the issue. I'm much more interested in a
discussion of the functional issues. The API is an important issue for
me. Datums transforms are, as if I haven't said it a million times, a
really important issue.

R

On 9/19/07, Cameron Shorter <cam...@gm...> wrote:
> Frank,
> Thanks for joining in on this naming thread which has reached a stalemate.
> I'm personally reluctant to venture an opinion due to my limited
> knowledge of projections.
>
> I hope you can help facilitate a successful conclusion to this.
>
> Frank Warmerdam wrote:
> > Mike Adair wrote:
> >
> >> For the name issue, I'm really not sure what to say. I know that it is
> >> more technically correct to call these objects coordinate systems, but
> >> with my (limited) marketing hat on, CSCS just doesn't mean anything to
> >> me, and I suspect it would be the same  for the large majority of users,
> >> these are just called projections in the common terminology.  I think we
> >> would get much more uptake of this library with a better name than CSCS.
> >>
> >> Anyone have another suggestions?  Maybe I should ask for a show of hands
> >> at the demo next week?  I hope you will be in attendance.
> >>
> >
> > Mike,
> >
> > In my opinion it is not great to refer to a project that does datum shifts
> > and other general coordinate system transformation actions as "Proj".  In
> > the case of PROJ.4 this is already a misnomer, and I'll likely change the
> > project name when it is refactored to use Gerald's libproj library for
> > lower level projections, and I focus on other coordinate system issues.
> >
> > Perhaps "cs4js - the projections and coordinate system library for javascript"?
> > Or "cscs4js"?
> >
> > Personally I think naming is an area where the originating author should
> > be given his some leeway.
> >
> > Best regards,
> >
>
>
> --
> Cameron Shorter
> Systems Architect, http://lisasoft.com.au
> Tel: +61 (0)2 8570 5050
> Mob: +61 (0)419 142 254
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mapbuilder-proj mailing list
> Map...@li...
> https://lists.sourceforge.net/lists/listinfo/mapbuilder-proj
>


-- 
Richard Greenwood
ric...@gm...
www.greenwoodmap.com

Re: [Mapbuilder-proj] cscs/Proj4js

[Cameron S. <cam...@gm...>]

Frank,
Thanks for joining in on this naming thread which has reached a stalemate.
I'm personally reluctant to venture an opinion due to my limited 
knowledge of projections.

I hope you can help facilitate a successful conclusion to this.

Frank Warmerdam wrote:
> Mike Adair wrote:
>   
>> For the name issue, I'm really not sure what to say. I know that it is 
>> more technically correct to call these objects coordinate systems, but 
>> with my (limited) marketing hat on, CSCS just doesn't mean anything to 
>> me, and I suspect it would be the same  for the large majority of users, 
>> these are just called projections in the common terminology.  I think we 
>> would get much more uptake of this library with a better name than CSCS.
>>
>> Anyone have another suggestions?  Maybe I should ask for a show of hands 
>> at the demo next week?  I hope you will be in attendance.
>>     
>
> Mike,
>
> In my opinion it is not great to refer to a project that does datum shifts
> and other general coordinate system transformation actions as "Proj".  In
> the case of PROJ.4 this is already a misnomer, and I'll likely change the
> project name when it is refactored to use Gerald's libproj library for
> lower level projections, and I focus on other coordinate system issues.
>
> Perhaps "cs4js - the projections and coordinate system library for javascript"?
> Or "cscs4js"?
>
> Personally I think naming is an area where the originating author should
> be given his some leeway.
>
> Best regards,
>   


-- 
Cameron Shorter
Systems Architect, http://lisasoft.com.au
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Re: [Mapbuilder-proj] cscs/Proj4js

[Richard G. <ric...@gm...>]

Mike,

Is this demo next week specifically for the JavaScript projection
library? When & where? Might I participate? Or do you see the Proj4js
library as separate from cscs?

Regarding the API:

1. "Just" going from lat/long to a projected cs is still effected by
datum. I started this project in response to Radim Blazek's problems
going between lat/long WGS84 and an Italian grid on the International
ellipsoid. That is why I would like a single transform function. The
way I had it setup was REALLY easy. WGS84 lat/long was the default cs
when you created a new cs object. It's like one more step, but it can
keep people out of trouble. And it makes it easier to port someone
else's code into your project without having to know that you need to
call a completely different method because your cs's aren't both on
the same datum.

2. I've got a project that has been using the cscs code for a year
now. It uses the from:
   cs_transform(source, destination, point);
I can see the value of adding the namespace, but I'd like to see
things like parameter order remain the same lacking a compelling
reason to the contrary.

3. Aliases - same as I said previously, your example:
   xyPoint = sourceProj.lonLatToMapXY(llPoint);
assume that xyPoint and llPoint are both on the same datum. What's so
hard about:
   cs_transform(UTM13, lonLat, point);
all you have to remember is that source comes first, destination second.

Rich



On 9/19/07, Mike Adair <ma...@dm...> wrote:
> Richard,
>
> Great, this sounds like a better dialog.  It seems like the only issues
> to be decided are the name and the API.  (Datums are disabled for the
> moment only because I haven't had time to convert that code over to the
> new format.)
>
> For the API, I can be convinced that transform() could be a 'global'
> method since it depends equally on a source and destination proj
> object.  I think the individual proj objects should still expose
> forward() and inverse(), since they will always be there and are very
> useful in themselves, but I also like the aliases because I can never
> remember which one goes to lon/lat and vice versa.  Using XYZ as the
> project name, the API would look like this:
>
> sourceProj = new XYZ.Proj(projCode1);
> destProj = new XYZ.Proj(projCode2);
> XYZ.transform(sourceProj, point, destProj);    <- the alternative is
> sourceProj.transform(point, destProj);
> lonlat = sourceProj.mapXYToLonLat(XYpoint);
> xyPoint = sourceProj.lonLatToMapXY(llPoint);
>
> For the name issue, I'm really not sure what to say. I know that it is
> more technically correct to call these objects coordinate systems, but
> with my (limited) marketing hat on, CSCS just doesn't mean anything to
> me, and I suspect it would be the same  for the large majority of users,
> these are just called projections in the common terminology.  I think we
> would get much more uptake of this library with a better name than CSCS.
>
> Anyone have another suggestions?  Maybe I should ask for a show of hands
> at the demo next week?  I hope you will be in attendance.
>
> Mike
>
>
> Richard Greenwood wrote:
> > Mike,
> >
> > The project rename and major structural changes certainly leaves me
> > feeling disenfranchised. One man's refactroing may be another man's
> > hostile take over.
> >
> > I prefer the term "coordinate system" over "projection" because a
> > coordinate system is made up of both a projection and a datum. Adding
> > support for datum transformations was the impetus for me to start the
> > project.
> >
> > I think a single entry point is preferable (transform()) to exposing
> > forward() and inverse() and aliases thereof. Encouraging the use of
> > forward() is going to perpetuate the issues that were coming up on the
> > list with the use of proj.js: users will attempt to project WGS84
> > lat/long into their local grid, which in many parts of the world is
> > not on WGS84, and then be frustrated when they get incorrect results.
> >
> > You've disabled datum transformation in Proj4.js. As a minimum there
> > should be an alert if you're going to encourage people to test and
> > integrate the library.
> >
> > Making transform() a method of a cs does not make sense to me. To
> > transform a point you use a method of a cs and then pass another cs as
> > a parameter. Kind of reminds me of the ArcView 3.2 transformer. What's
> > wrong with transform(src, dest, pt)? If you're determined that
> > transform must be a method of something, then making it a method of a
> > point seems more logical, e.g. p2 = p1.transform(); Or better,
> > overload the equals, e.g. p1 = p2; where a point is comprised of X,Y,
> > cs.
> >
> > I am in favor of putting it into its own namespace.
> >
> > Dynamic loading of defs and projection class code: I am in favor of
> > this. I had the definitions loading dynamically but did not commit it
> > because I doubted that my method was consistent with MapBuilder's. I
> > had asked about dynamically loading the projection code but didn't get
> > an answer. Are you dynamically loading the functions? If so, is there
> > an example?
> >
> > I've never felt like the destination between cs definitions and
> > functions was fully respected. Looking up a definition is no big, it's
> > just a bunch of ASCII. But spatialreference.org, PostGIS, etc. don't
> > provide the functions in JavaScript run by the browser. That's what
> > this project is about. By saying that any projection can be handled by
> > looking it up in some existent location isn't quite accurate.
> >
> > Rich
> >
> > On 9/18/07, Mike Adair <ma...@dm...> wrote:
> >
> >> (Moving this to the mapbuilder-proj list with a proper subject line.
> >> Please reply to that list only)
> >>
> >> Richard,
> >>
> >> I really hope we can resolve your concerns over the recent work done on
> >> this project.  I have no intention of "duking it out", I only want to
> >> end up with a solid coordinate transformation library, with a small
> >> footprint and one that makes it as easy as possible for the end-user to
> >> do coordinate transformations in the browser.  This piece is too
> >> important for the whole JS client community to let it flounder in an
> >> argument like this.
> >>
> >> The work that you and others have done to date to get cscs where it is,
> >> is great and in fact I haven't touched the actual code within the
> >> various methods, all I've done is to change the way the various objects
> >> are structured to use modern JavaScript techniques.
> >>
> >> Perhaps by listing the issues (as I see them) we can resolve them
> >> together.  Feel free to add your own issues to the list:
> >>
> >> 1. The name of the project:  just about anyone I talk to about this has
> >> no idea what 'cscs' is.  I think that Proj4js is a much more descriptive
> >> name in  that it tells where it came from (Proj4), it deals with
> >> Projections, and it is a JS library for browser clients.  I can live
> >> with  'cscs' as the name , but I feel that we would loose many potential
> >> end-users because no one really knows what 'cscs' is.
> >>
> >> 2. Object-oriented-ness:  Any external library like this that is to be
> >> included in other projects should use it's own namespace so that you
> >> avoid naming collisions and re-defining functions and properties
> >> accidentally.  This also allows us to define things like Proj4js.const
> >> which includes library-wide constants and methods that get used over and
> >> over (e.g. all the msfnz, tsfnz, etc. methods that are repeated in every
> >> projection class code).  I think this should be done no matter what the
> >> project is called because it is just good programming technique.
> >>
> >> 3. dynamic loading of defs and projection class code: this is something
> >> I had always intended to implement, no matter what the project is
> >> called.  The issue is that in cscs, you always need to specify the
> >> cslist.defs files and projection code (e.g. lcc.js) when an application
> >> is being created.  That is fine if you know beforehand what projections
> >> your application is dealing with, but in my experience, there are many
> >> cases where you don't know that beforehand.  Dynamic loading of this
> >> information allows the library to handle practically any projection,
> >> which is a huge bonus in my opinion.
> >>
> >> 4. Proj objects: I feel that the changes I made to the Proj objects make
> >> a lot of sense.  You still have the transform() method available,
> >> passing in a second Proj object, but in a lot of cases the coord
> >> transformation required is simply a MapXY to Lon/Lat and vice versa,
> >> without creating a second Proj object.  I've also defined aliases for
> >> forward()/inverse() methods as mapXYToLonLat() and lonLatToMapXY() to
> >> make them easier to understand.
> >>
> >> Like I said above, my intention here is to end up with the best
> >> coordinate transformation library possible, and I think these are some
> >> of the steps needed to move cscs to get there.  The work you have done
> >> on cscs to date is invaluable, so I really hope your contributions to
> >> this project continue. Maybe all it will take is for us to sit down over
> >> a beer and a scratch pad at FOSS4G next week, but hopefully we can come
> >> to an agreement sooner than that.  Comments from the community are also
> >> welcome.
> >>
> >> Mike
> >>
> >>
> >>
> >> Richard Greenwood wrote:
> >>
> >>> On 9/17/07, Mike Adair <ma...@dm...> wrote:
> >>>
> >>>
> >>>> Yes cscs did have that problem.  However the Proj4js version loads only
> >>>> the projection class code required based on the projection definition so
> >>>> you never need to worry about that.   If you know beforehand what
> >>>> projections your app will be dealing with, you can also load the code
> >>>> statically.
> >>>>
> >>>>
> >>> cscs does not "have that problem" if you are referring to functions
> >>> being duplicated. cscs transformation functions are only defined once.
> >>> It's a bummer that cscs and Proj4js have split so early in their
> >>> respective development. And it's a bummer that we need to "duke it
> >>> out" next week. Seems like we'd get a lot further by working together.
> >>>
> >>>
> >>>
> >>>> The advantage of the Proj4js approach is that as long as the Proj4
> >>>> initialization parameters are available somewhere (statically on disk,
> >>>> or in a Web Service like spatialreference.org, or a local interface to
> >>>> PostGIS) any projection can be handled.
> >>>>
> >>>>
> >>> There's a lot more to a coordinate system transformation than its
> >>> Proj4 initialization parameters. You need the forward/inverse
> >>> functions, and you need the appropriate datum transformation
> >>> functions. And they need to be in JavaScript if you're going to do it
> >>> on the client.
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>


-- 
Richard Greenwood
ric...@gm...
www.greenwoodmap.com

Re: [Mapbuilder-proj] cscs/Proj4js

[Frank W. <war...@po...>]

Mike Adair wrote:
> For the name issue, I'm really not sure what to say. I know that it is 
> more technically correct to call these objects coordinate systems, but 
> with my (limited) marketing hat on, CSCS just doesn't mean anything to 
> me, and I suspect it would be the same  for the large majority of users, 
> these are just called projections in the common terminology.  I think we 
> would get much more uptake of this library with a better name than CSCS.
> 
> Anyone have another suggestions?  Maybe I should ask for a show of hands 
> at the demo next week?  I hope you will be in attendance.

Mike,

In my opinion it is not great to refer to a project that does datum shifts
and other general coordinate system transformation actions as "Proj".  In
the case of PROJ.4 this is already a misnomer, and I'll likely change the
project name when it is refactored to use Gerald's libproj library for
lower level projections, and I focus on other coordinate system issues.

Perhaps "cs4js - the projections and coordinate system library for javascript"?
Or "cscs4js"?

Personally I think naming is an area where the originating author should
be given his some leeway.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, war...@po...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

Re: [Mapbuilder-proj] cscs/Proj4js

[Mike A. <ma...@dm...>]

Richard,

Great, this sounds like a better dialog.  It seems like the only issues 
to be decided are the name and the API.  (Datums are disabled for the 
moment only because I haven't had time to convert that code over to the 
new format.)

For the API, I can be convinced that transform() could be a 'global' 
method since it depends equally on a source and destination proj 
object.  I think the individual proj objects should still expose 
forward() and inverse(), since they will always be there and are very 
useful in themselves, but I also like the aliases because I can never 
remember which one goes to lon/lat and vice versa.  Using XYZ as the 
project name, the API would look like this:

sourceProj = new XYZ.Proj(projCode1);
destProj = new XYZ.Proj(projCode2);
XYZ.transform(sourceProj, point, destProj);    <- the alternative is 
sourceProj.transform(point, destProj);
lonlat = sourceProj.mapXYToLonLat(XYpoint);
xyPoint = sourceProj.lonLatToMapXY(llPoint);

For the name issue, I'm really not sure what to say. I know that it is 
more technically correct to call these objects coordinate systems, but 
with my (limited) marketing hat on, CSCS just doesn't mean anything to 
me, and I suspect it would be the same  for the large majority of users, 
these are just called projections in the common terminology.  I think we 
would get much more uptake of this library with a better name than CSCS.

Anyone have another suggestions?  Maybe I should ask for a show of hands 
at the demo next week?  I hope you will be in attendance.

Mike


Richard Greenwood wrote:
> Mike,
>
> The project rename and major structural changes certainly leaves me
> feeling disenfranchised. One man's refactroing may be another man's
> hostile take over.
>
> I prefer the term "coordinate system" over "projection" because a
> coordinate system is made up of both a projection and a datum. Adding
> support for datum transformations was the impetus for me to start the
> project.
>
> I think a single entry point is preferable (transform()) to exposing
> forward() and inverse() and aliases thereof. Encouraging the use of
> forward() is going to perpetuate the issues that were coming up on the
> list with the use of proj.js: users will attempt to project WGS84
> lat/long into their local grid, which in many parts of the world is
> not on WGS84, and then be frustrated when they get incorrect results.
>
> You've disabled datum transformation in Proj4.js. As a minimum there
> should be an alert if you're going to encourage people to test and
> integrate the library.
>
> Making transform() a method of a cs does not make sense to me. To
> transform a point you use a method of a cs and then pass another cs as
> a parameter. Kind of reminds me of the ArcView 3.2 transformer. What's
> wrong with transform(src, dest, pt)? If you're determined that
> transform must be a method of something, then making it a method of a
> point seems more logical, e.g. p2 = p1.transform(); Or better,
> overload the equals, e.g. p1 = p2; where a point is comprised of X,Y,
> cs.
>
> I am in favor of putting it into its own namespace.
>
> Dynamic loading of defs and projection class code: I am in favor of
> this. I had the definitions loading dynamically but did not commit it
> because I doubted that my method was consistent with MapBuilder's. I
> had asked about dynamically loading the projection code but didn't get
> an answer. Are you dynamically loading the functions? If so, is there
> an example?
>
> I've never felt like the destination between cs definitions and
> functions was fully respected. Looking up a definition is no big, it's
> just a bunch of ASCII. But spatialreference.org, PostGIS, etc. don't
> provide the functions in JavaScript run by the browser. That's what
> this project is about. By saying that any projection can be handled by
> looking it up in some existent location isn't quite accurate.
>
> Rich
>
> On 9/18/07, Mike Adair <ma...@dm...> wrote:
>   
>> (Moving this to the mapbuilder-proj list with a proper subject line.
>> Please reply to that list only)
>>
>> Richard,
>>
>> I really hope we can resolve your concerns over the recent work done on
>> this project.  I have no intention of "duking it out", I only want to
>> end up with a solid coordinate transformation library, with a small
>> footprint and one that makes it as easy as possible for the end-user to
>> do coordinate transformations in the browser.  This piece is too
>> important for the whole JS client community to let it flounder in an
>> argument like this.
>>
>> The work that you and others have done to date to get cscs where it is,
>> is great and in fact I haven't touched the actual code within the
>> various methods, all I've done is to change the way the various objects
>> are structured to use modern JavaScript techniques.
>>
>> Perhaps by listing the issues (as I see them) we can resolve them
>> together.  Feel free to add your own issues to the list:
>>
>> 1. The name of the project:  just about anyone I talk to about this has
>> no idea what 'cscs' is.  I think that Proj4js is a much more descriptive
>> name in  that it tells where it came from (Proj4), it deals with
>> Projections, and it is a JS library for browser clients.  I can live
>> with  'cscs' as the name , but I feel that we would loose many potential
>> end-users because no one really knows what 'cscs' is.
>>
>> 2. Object-oriented-ness:  Any external library like this that is to be
>> included in other projects should use it's own namespace so that you
>> avoid naming collisions and re-defining functions and properties
>> accidentally.  This also allows us to define things like Proj4js.const
>> which includes library-wide constants and methods that get used over and
>> over (e.g. all the msfnz, tsfnz, etc. methods that are repeated in every
>> projection class code).  I think this should be done no matter what the
>> project is called because it is just good programming technique.
>>
>> 3. dynamic loading of defs and projection class code: this is something
>> I had always intended to implement, no matter what the project is
>> called.  The issue is that in cscs, you always need to specify the
>> cslist.defs files and projection code (e.g. lcc.js) when an application
>> is being created.  That is fine if you know beforehand what projections
>> your application is dealing with, but in my experience, there are many
>> cases where you don't know that beforehand.  Dynamic loading of this
>> information allows the library to handle practically any projection,
>> which is a huge bonus in my opinion.
>>
>> 4. Proj objects: I feel that the changes I made to the Proj objects make
>> a lot of sense.  You still have the transform() method available,
>> passing in a second Proj object, but in a lot of cases the coord
>> transformation required is simply a MapXY to Lon/Lat and vice versa,
>> without creating a second Proj object.  I've also defined aliases for
>> forward()/inverse() methods as mapXYToLonLat() and lonLatToMapXY() to
>> make them easier to understand.
>>
>> Like I said above, my intention here is to end up with the best
>> coordinate transformation library possible, and I think these are some
>> of the steps needed to move cscs to get there.  The work you have done
>> on cscs to date is invaluable, so I really hope your contributions to
>> this project continue. Maybe all it will take is for us to sit down over
>> a beer and a scratch pad at FOSS4G next week, but hopefully we can come
>> to an agreement sooner than that.  Comments from the community are also
>> welcome.
>>
>> Mike
>>
>>
>>
>> Richard Greenwood wrote:
>>     
>>> On 9/17/07, Mike Adair <ma...@dm...> wrote:
>>>
>>>       
>>>> Yes cscs did have that problem.  However the Proj4js version loads only
>>>> the projection class code required based on the projection definition so
>>>> you never need to worry about that.   If you know beforehand what
>>>> projections your app will be dealing with, you can also load the code
>>>> statically.
>>>>
>>>>         
>>> cscs does not "have that problem" if you are referring to functions
>>> being duplicated. cscs transformation functions are only defined once.
>>> It's a bummer that cscs and Proj4js have split so early in their
>>> respective development. And it's a bummer that we need to "duke it
>>> out" next week. Seems like we'd get a lot further by working together.
>>>
>>>
>>>       
>>>> The advantage of the Proj4js approach is that as long as the Proj4
>>>> initialization parameters are available somewhere (statically on disk,
>>>> or in a Web Service like spatialreference.org, or a local interface to
>>>> PostGIS) any projection can be handled.
>>>>
>>>>         
>>> There's a lot more to a coordinate system transformation than its
>>> Proj4 initialization parameters. You need the forward/inverse
>>> functions, and you need the appropriate datum transformation
>>> functions. And they need to be in JavaScript if you're going to do it
>>> on the client.
>>>
>>>
>>>       
>>     
>
>
>   

Re: [Mapbuilder-proj] cscs/Proj4js

[Richard G. <ric...@gm...>]

Mike,

The project rename and major structural changes certainly leaves me
feeling disenfranchised. One man's refactroing may be another man's
hostile take over.

I prefer the term "coordinate system" over "projection" because a
coordinate system is made up of both a projection and a datum. Adding
support for datum transformations was the impetus for me to start the
project.

I think a single entry point is preferable (transform()) to exposing
forward() and inverse() and aliases thereof. Encouraging the use of
forward() is going to perpetuate the issues that were coming up on the
list with the use of proj.js: users will attempt to project WGS84
lat/long into their local grid, which in many parts of the world is
not on WGS84, and then be frustrated when they get incorrect results.

You've disabled datum transformation in Proj4.js. As a minimum there
should be an alert if you're going to encourage people to test and
integrate the library.

Making transform() a method of a cs does not make sense to me. To
transform a point you use a method of a cs and then pass another cs as
a parameter. Kind of reminds me of the ArcView 3.2 transformer. What's
wrong with transform(src, dest, pt)? If you're determined that
transform must be a method of something, then making it a method of a
point seems more logical, e.g. p2 = p1.transform(); Or better,
overload the equals, e.g. p1 = p2; where a point is comprised of X,Y,
cs.

I am in favor of putting it into its own namespace.

Dynamic loading of defs and projection class code: I am in favor of
this. I had the definitions loading dynamically but did not commit it
because I doubted that my method was consistent with MapBuilder's. I
had asked about dynamically loading the projection code but didn't get
an answer. Are you dynamically loading the functions? If so, is there
an example?

I've never felt like the destination between cs definitions and
functions was fully respected. Looking up a definition is no big, it's
just a bunch of ASCII. But spatialreference.org, PostGIS, etc. don't
provide the functions in JavaScript run by the browser. That's what
this project is about. By saying that any projection can be handled by
looking it up in some existent location isn't quite accurate.

Rich

On 9/18/07, Mike Adair <ma...@dm...> wrote:
> (Moving this to the mapbuilder-proj list with a proper subject line.
> Please reply to that list only)
>
> Richard,
>
> I really hope we can resolve your concerns over the recent work done on
> this project.  I have no intention of "duking it out", I only want to
> end up with a solid coordinate transformation library, with a small
> footprint and one that makes it as easy as possible for the end-user to
> do coordinate transformations in the browser.  This piece is too
> important for the whole JS client community to let it flounder in an
> argument like this.
>
> The work that you and others have done to date to get cscs where it is,
> is great and in fact I haven't touched the actual code within the
> various methods, all I've done is to change the way the various objects
> are structured to use modern JavaScript techniques.
>
> Perhaps by listing the issues (as I see them) we can resolve them
> together.  Feel free to add your own issues to the list:
>
> 1. The name of the project:  just about anyone I talk to about this has
> no idea what 'cscs' is.  I think that Proj4js is a much more descriptive
> name in  that it tells where it came from (Proj4), it deals with
> Projections, and it is a JS library for browser clients.  I can live
> with  'cscs' as the name , but I feel that we would loose many potential
> end-users because no one really knows what 'cscs' is.
>
> 2. Object-oriented-ness:  Any external library like this that is to be
> included in other projects should use it's own namespace so that you
> avoid naming collisions and re-defining functions and properties
> accidentally.  This also allows us to define things like Proj4js.const
> which includes library-wide constants and methods that get used over and
> over (e.g. all the msfnz, tsfnz, etc. methods that are repeated in every
> projection class code).  I think this should be done no matter what the
> project is called because it is just good programming technique.
>
> 3. dynamic loading of defs and projection class code: this is something
> I had always intended to implement, no matter what the project is
> called.  The issue is that in cscs, you always need to specify the
> cslist.defs files and projection code (e.g. lcc.js) when an application
> is being created.  That is fine if you know beforehand what projections
> your application is dealing with, but in my experience, there are many
> cases where you don't know that beforehand.  Dynamic loading of this
> information allows the library to handle practically any projection,
> which is a huge bonus in my opinion.
>
> 4. Proj objects: I feel that the changes I made to the Proj objects make
> a lot of sense.  You still have the transform() method available,
> passing in a second Proj object, but in a lot of cases the coord
> transformation required is simply a MapXY to Lon/Lat and vice versa,
> without creating a second Proj object.  I've also defined aliases for
> forward()/inverse() methods as mapXYToLonLat() and lonLatToMapXY() to
> make them easier to understand.
>
> Like I said above, my intention here is to end up with the best
> coordinate transformation library possible, and I think these are some
> of the steps needed to move cscs to get there.  The work you have done
> on cscs to date is invaluable, so I really hope your contributions to
> this project continue. Maybe all it will take is for us to sit down over
> a beer and a scratch pad at FOSS4G next week, but hopefully we can come
> to an agreement sooner than that.  Comments from the community are also
> welcome.
>
> Mike
>
>
>
> Richard Greenwood wrote:
> > On 9/17/07, Mike Adair <ma...@dm...> wrote:
> >
> >> Yes cscs did have that problem.  However the Proj4js version loads only
> >> the projection class code required based on the projection definition so
> >> you never need to worry about that.   If you know beforehand what
> >> projections your app will be dealing with, you can also load the code
> >> statically.
> >>
> >
> > cscs does not "have that problem" if you are referring to functions
> > being duplicated. cscs transformation functions are only defined once.
> > It's a bummer that cscs and Proj4js have split so early in their
> > respective development. And it's a bummer that we need to "duke it
> > out" next week. Seems like we'd get a lot further by working together.
> >
> >
> >> The advantage of the Proj4js approach is that as long as the Proj4
> >> initialization parameters are available somewhere (statically on disk,
> >> or in a Web Service like spatialreference.org, or a local interface to
> >> PostGIS) any projection can be handled.
> >>
> >
> > There's a lot more to a coordinate system transformation than its
> > Proj4 initialization parameters. You need the forward/inverse
> > functions, and you need the appropriate datum transformation
> > functions. And they need to be in JavaScript if you're going to do it
> > on the client.
> >
> >
>
>


-- 
Richard Greenwood
ric...@gm...
www.greenwoodmap.com

Re: [Mapbuilder-proj] cscs/Proj4js

[Mike A. <ma...@dm...>]

Cameron,

Yes the license is an issue to be decided, but I believe the intention 
is for this library to used by whatever project would like to use it.  
So a license that will make that possible would be best.

It may also be time for this sub-project to move out of mapbuilder and 
into a project of it's own, but then there are the usual questions such 
as where does it live, SVN, Trac, mailing lists, PSC, etc.  I would 
suggest as an OSGeo project, to eventually get into incubation.

Mike

Cameron Shorter wrote:
> Mike,
> It is great to see some life being breathed back into the projection 
> library.
>
> From my outsiders view, your design drivers seem solid.
>
> A few larger issues we should consider:
> * Can the library be used by other JS projects? In particular, 
> Mapbender and Openlayers.
> I suspect that we will need to change the LGPL license to the BSD 
> license if Openlayers is to incorporate it into their codebase.
>
> * Are you using the same JS coding standards (for inheritance etc) as 
> Openlayers? This would be my suggestion.
>
> Mike Adair wrote:
>> Having trouble sending this, apologies if you get this twice.
>> Mike
>>
>>
>>
>> Mike Adair wrote:
>>  
>>> (Moving this to the mapbuilder-proj list with a proper subject 
>>> line.  Please reply to that list only)
>>>
>>> Richard,
>>>
>>> I really hope we can resolve your concerns over the recent work done 
>>> on this project.  I have no intention of "duking it out", I only 
>>> want to end up with a solid coordinate transformation library, with 
>>> a small footprint and one that makes it as easy as possible for the 
>>> end-user to do coordinate transformations in the browser.  This 
>>> piece is too important for the whole JS client community to let it 
>>> flounder in an argument like this.
>>>
>>> The work that you and others have done to date to get cscs where it 
>>> is, is great and in fact I haven't touched the actual code within 
>>> the various methods, all I've done is to change the way the various 
>>> objects are structured to use modern JavaScript techniques.
>>> Perhaps by listing the issues (as I see them) we can resolve them 
>>> together.  Feel free to add your own issues to the list:
>>>
>>> 1. The name of the project:  just about anyone I talk to about this 
>>> has no idea what 'cscs' is.  I think that Proj4js is a much more 
>>> descriptive name in  that it tells where it came from (Proj4), it 
>>> deals with Projections, and it is a JS library for browser clients.  
>>> I can live with  'cscs' as the name , but I feel that we would loose 
>>> many potential end-users because no one really knows what 'cscs' is.
>>>
>>> 2. Object-oriented-ness:  Any external library like this that is to 
>>> be included in other projects should use it's own namespace so that 
>>> you avoid naming collisions and re-defining functions and properties 
>>> accidentally.  This also allows us to define things like 
>>> Proj4js.const which includes library-wide constants and methods that 
>>> get used over and over (e.g. all the msfnz, tsfnz, etc. methods that 
>>> are repeated in every projection class code).  I think this should 
>>> be done no matter what the project is called because it is just good 
>>> programming technique.
>>>
>>> 3. dynamic loading of defs and projection class code: this is 
>>> something I had always intended to implement, no matter what the 
>>> project is called.  The issue is that in cscs, you always need to 
>>> specify the cslist.defs files and projection code (e.g. lcc.js) when 
>>> an application is being created.  That is fine if you know 
>>> beforehand what projections your application is dealing with, but in 
>>> my experience, there are many cases where you don't know that 
>>> beforehand.  Dynamic loading of this information allows the library 
>>> to handle practically any projection, which is a huge bonus in my 
>>> opinion.
>>>
>>> 4. Proj objects: I feel that the changes I made to the Proj objects 
>>> make a lot of sense.  You still have the transform() method 
>>> available, passing in a second Proj object, but in a lot of cases 
>>> the coord transformation required is simply a MapXY to Lon/Lat and 
>>> vice versa, without creating a second Proj object.  I've also 
>>> defined aliases for forward()/inverse() methods as mapXYToLonLat() 
>>> and lonLatToMapXY() to make them easier to understand.
>>>
>>> Like I said above, my intention here is to end up with the best 
>>> coordinate transformation library possible, and I think these are 
>>> some of the steps needed to move cscs to get there.  The work you 
>>> have done on cscs to date is invaluable, so I really hope your 
>>> contributions to this project continue. Maybe all it will take is 
>>> for us to sit down over a beer and a scratch pad at FOSS4G next 
>>> week, but hopefully we can come to an agreement sooner than that.  
>>> Comments from the community are also welcome.
>>>
>>> Mike
>>>
>>>
>>>
>>> Richard Greenwood wrote:
>>>      
>>>> On 9/17/07, Mike Adair <ma...@dm...> wrote:
>>>>            
>>>>> Yes cscs did have that problem.  However the Proj4js version loads 
>>>>> only
>>>>> the projection class code required based on the projection 
>>>>> definition so
>>>>> you never need to worry about that.   If you know beforehand what
>>>>> projections your app will be dealing with, you can also load the code
>>>>> statically.
>>>>>                   
>>>> cscs does not "have that problem" if you are referring to functions
>>>> being duplicated. cscs transformation functions are only defined once.
>>>> It's a bummer that cscs and Proj4js have split so early in their
>>>> respective development. And it's a bummer that we need to "duke it
>>>> out" next week. Seems like we'd get a lot further by working together.
>>>>
>>>>            
>>>>> The advantage of the Proj4js approach is that as long as the Proj4
>>>>> initialization parameters are available somewhere (statically on 
>>>>> disk,
>>>>> or in a Web Service like spatialreference.org, or a local 
>>>>> interface to
>>>>> PostGIS) any projection can be handled.
>>>>>                   
>>>> There's a lot more to a coordinate system transformation than its
>>>> Proj4 initialization parameters. You need the forward/inverse
>>>> functions, and you need the appropriate datum transformation
>>>> functions. And they need to be in JavaScript if you're going to do it
>>>> on the client.
>>>>
>>>>             
>>> _______________________________________________
>>> Users mailing list
>>> Us...@op...
>>> http://openlayers.org/mailman/listinfo/users
>>>
>>>
>>>       
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Mapbuilder-proj mailing list
>> Map...@li...
>> https://lists.sourceforge.net/lists/listinfo/mapbuilder-proj
>>
>>   
>
>

Re: [Mapbuilder-proj] cscs/Proj4js

[Cameron S. <cam...@gm...>]

Mike,
It is great to see some life being breathed back into the projection 
library.

 From my outsiders view, your design drivers seem solid.

A few larger issues we should consider:
* Can the library be used by other JS projects? In particular, Mapbender 
and Openlayers.
I suspect that we will need to change the LGPL license to the BSD 
license if Openlayers is to incorporate it into their codebase.

* Are you using the same JS coding standards (for inheritance etc) as 
Openlayers? This would be my suggestion.

Mike Adair wrote:
> Having trouble sending this, apologies if you get this twice.
> Mike
>
>
>
> Mike Adair wrote:
>   
>> (Moving this to the mapbuilder-proj list with a proper subject line.  
>> Please reply to that list only)
>>
>> Richard,
>>
>> I really hope we can resolve your concerns over the recent work done on 
>> this project.  I have no intention of "duking it out", I only want to 
>> end up with a solid coordinate transformation library, with a small 
>> footprint and one that makes it as easy as possible for the end-user to 
>> do coordinate transformations in the browser.  This piece is too 
>> important for the whole JS client community to let it flounder in an 
>> argument like this.
>>
>> The work that you and others have done to date to get cscs where it is, 
>> is great and in fact I haven't touched the actual code within the 
>> various methods, all I've done is to change the way the various objects 
>> are structured to use modern JavaScript techniques. 
>>
>> Perhaps by listing the issues (as I see them) we can resolve them 
>> together.  Feel free to add your own issues to the list:
>>
>> 1. The name of the project:  just about anyone I talk to about this has 
>> no idea what 'cscs' is.  I think that Proj4js is a much more descriptive 
>> name in  that it tells where it came from (Proj4), it deals with 
>> Projections, and it is a JS library for browser clients.  I can live 
>> with  'cscs' as the name , but I feel that we would loose many potential 
>> end-users because no one really knows what 'cscs' is.
>>
>> 2. Object-oriented-ness:  Any external library like this that is to be 
>> included in other projects should use it's own namespace so that you 
>> avoid naming collisions and re-defining functions and properties 
>> accidentally.  This also allows us to define things like Proj4js.const 
>> which includes library-wide constants and methods that get used over and 
>> over (e.g. all the msfnz, tsfnz, etc. methods that are repeated in every 
>> projection class code).  I think this should be done no matter what the 
>> project is called because it is just good programming technique.
>>
>> 3. dynamic loading of defs and projection class code: this is something 
>> I had always intended to implement, no matter what the project is 
>> called.  The issue is that in cscs, you always need to specify the 
>> cslist.defs files and projection code (e.g. lcc.js) when an application 
>> is being created.  That is fine if you know beforehand what projections 
>> your application is dealing with, but in my experience, there are many 
>> cases where you don't know that beforehand.  Dynamic loading of this 
>> information allows the library to handle practically any projection, 
>> which is a huge bonus in my opinion.
>>
>> 4. Proj objects: I feel that the changes I made to the Proj objects make 
>> a lot of sense.  You still have the transform() method available, 
>> passing in a second Proj object, but in a lot of cases the coord 
>> transformation required is simply a MapXY to Lon/Lat and vice versa, 
>> without creating a second Proj object.  I've also defined aliases for 
>> forward()/inverse() methods as mapXYToLonLat() and lonLatToMapXY() to 
>> make them easier to understand.
>>
>> Like I said above, my intention here is to end up with the best 
>> coordinate transformation library possible, and I think these are some 
>> of the steps needed to move cscs to get there.  The work you have done 
>> on cscs to date is invaluable, so I really hope your contributions to 
>> this project continue. Maybe all it will take is for us to sit down over 
>> a beer and a scratch pad at FOSS4G next week, but hopefully we can come 
>> to an agreement sooner than that.  Comments from the community are also 
>> welcome.
>>
>> Mike
>>
>>
>>
>> Richard Greenwood wrote:
>>   
>>     
>>> On 9/17/07, Mike Adair <ma...@dm...> wrote:
>>>   
>>>     
>>>       
>>>> Yes cscs did have that problem.  However the Proj4js version loads only
>>>> the projection class code required based on the projection definition so
>>>> you never need to worry about that.   If you know beforehand what
>>>> projections your app will be dealing with, you can also load the code
>>>> statically.
>>>>     
>>>>       
>>>>         
>>> cscs does not "have that problem" if you are referring to functions
>>> being duplicated. cscs transformation functions are only defined once.
>>> It's a bummer that cscs and Proj4js have split so early in their
>>> respective development. And it's a bummer that we need to "duke it
>>> out" next week. Seems like we'd get a lot further by working together.
>>>
>>>   
>>>     
>>>       
>>>> The advantage of the Proj4js approach is that as long as the Proj4
>>>> initialization parameters are available somewhere (statically on disk,
>>>> or in a Web Service like spatialreference.org, or a local interface to
>>>> PostGIS) any projection can be handled.
>>>>     
>>>>       
>>>>         
>>> There's a lot more to a coordinate system transformation than its
>>> Proj4 initialization parameters. You need the forward/inverse
>>> functions, and you need the appropriate datum transformation
>>> functions. And they need to be in JavaScript if you're going to do it
>>> on the client.
>>>
>>>   
>>>     
>>>       
>> _______________________________________________
>> Users mailing list
>> Us...@op...
>> http://openlayers.org/mailman/listinfo/users
>>
>>
>>   
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mapbuilder-proj mailing list
> Map...@li...
> https://lists.sourceforge.net/lists/listinfo/mapbuilder-proj
>
>   


-- 
Cameron Shorter
Systems Architect, http://lisasoft.com.au
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

[Mapbuilder-proj] cscs/Proj4js

[Mike A. <ma...@dm...>]

Having trouble sending this, apologies if you get this twice.
Mike



Mike Adair wrote:
> (Moving this to the mapbuilder-proj list with a proper subject line.  
> Please reply to that list only)
>
> Richard,
>
> I really hope we can resolve your concerns over the recent work done on 
> this project.  I have no intention of "duking it out", I only want to 
> end up with a solid coordinate transformation library, with a small 
> footprint and one that makes it as easy as possible for the end-user to 
> do coordinate transformations in the browser.  This piece is too 
> important for the whole JS client community to let it flounder in an 
> argument like this.
>
> The work that you and others have done to date to get cscs where it is, 
> is great and in fact I haven't touched the actual code within the 
> various methods, all I've done is to change the way the various objects 
> are structured to use modern JavaScript techniques. 
>
> Perhaps by listing the issues (as I see them) we can resolve them 
> together.  Feel free to add your own issues to the list:
>
> 1. The name of the project:  just about anyone I talk to about this has 
> no idea what 'cscs' is.  I think that Proj4js is a much more descriptive 
> name in  that it tells where it came from (Proj4), it deals with 
> Projections, and it is a JS library for browser clients.  I can live 
> with  'cscs' as the name , but I feel that we would loose many potential 
> end-users because no one really knows what 'cscs' is.
>
> 2. Object-oriented-ness:  Any external library like this that is to be 
> included in other projects should use it's own namespace so that you 
> avoid naming collisions and re-defining functions and properties 
> accidentally.  This also allows us to define things like Proj4js.const 
> which includes library-wide constants and methods that get used over and 
> over (e.g. all the msfnz, tsfnz, etc. methods that are repeated in every 
> projection class code).  I think this should be done no matter what the 
> project is called because it is just good programming technique.
>
> 3. dynamic loading of defs and projection class code: this is something 
> I had always intended to implement, no matter what the project is 
> called.  The issue is that in cscs, you always need to specify the 
> cslist.defs files and projection code (e.g. lcc.js) when an application 
> is being created.  That is fine if you know beforehand what projections 
> your application is dealing with, but in my experience, there are many 
> cases where you don't know that beforehand.  Dynamic loading of this 
> information allows the library to handle practically any projection, 
> which is a huge bonus in my opinion.
>
> 4. Proj objects: I feel that the changes I made to the Proj objects make 
> a lot of sense.  You still have the transform() method available, 
> passing in a second Proj object, but in a lot of cases the coord 
> transformation required is simply a MapXY to Lon/Lat and vice versa, 
> without creating a second Proj object.  I've also defined aliases for 
> forward()/inverse() methods as mapXYToLonLat() and lonLatToMapXY() to 
> make them easier to understand.
>
> Like I said above, my intention here is to end up with the best 
> coordinate transformation library possible, and I think these are some 
> of the steps needed to move cscs to get there.  The work you have done 
> on cscs to date is invaluable, so I really hope your contributions to 
> this project continue. Maybe all it will take is for us to sit down over 
> a beer and a scratch pad at FOSS4G next week, but hopefully we can come 
> to an agreement sooner than that.  Comments from the community are also 
> welcome.
>
> Mike
>
>
>
> Richard Greenwood wrote:
>   
>> On 9/17/07, Mike Adair <ma...@dm...> wrote:
>>   
>>     
>>> Yes cscs did have that problem.  However the Proj4js version loads only
>>> the projection class code required based on the projection definition so
>>> you never need to worry about that.   If you know beforehand what
>>> projections your app will be dealing with, you can also load the code
>>> statically.
>>>     
>>>       
>> cscs does not "have that problem" if you are referring to functions
>> being duplicated. cscs transformation functions are only defined once.
>> It's a bummer that cscs and Proj4js have split so early in their
>> respective development. And it's a bummer that we need to "duke it
>> out" next week. Seems like we'd get a lot further by working together.
>>
>>   
>>     
>>> The advantage of the Proj4js approach is that as long as the Proj4
>>> initialization parameters are available somewhere (statically on disk,
>>> or in a Web Service like spatialreference.org, or a local interface to
>>> PostGIS) any projection can be handled.
>>>     
>>>       
>> There's a lot more to a coordinate system transformation than its
>> Proj4 initialization parameters. You need the forward/inverse
>> functions, and you need the appropriate datum transformation
>> functions. And they need to be in JavaScript if you're going to do it
>> on the client.
>>
>>   
>>     
>
> _______________________________________________
> Users mailing list
> Us...@op...
> http://openlayers.org/mailman/listinfo/users
>
>
>   

[Mapbuilder-proj] Fwd: [Proj] Dutch coordinate system

[Richard G. <ric...@gm...>]

---------- Forwarded message ----------
From: Jan Hartmann <j.l...@uv...>
Date: Aug 25, 2007 4:28 AM
Subject: Re: [Proj] Dutch coordinate system
To: "PROJ.4 and general Projections Discussions" <pr...@li...>


Dag Paul,

Please see

http://lists.maptools.org/pipermail/proj/2006-March/002168.html

for a working example of the parameters. Note that proj does not use
datum shifts. you *have* to use cs2cs for that.

Vriendelijke groeten,

Jan Hartmann

Dr. J. Hartmann
Afdeling Geografie
Universiteit van Amsterdam

Paul van der Linden wrote:
> Hi all,
> I'm having trouble with coordinate conversion from and to wgs84.
> I have tried the various ways which I found here, but none of them seem to work.
>
> The cs2cs example does not work with me (get an projection initialization
> failure
> cause: unknown projection id
> program abnormally terminated
>
> with this parameters:
> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079
> +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.040,49.910,465.840,-
> 0.40939,0.35971,-1.86849,4.0772 +units=m +no_defs)
>
> proj gives similar messages.
>
> I also tried
>   Projwgs:=TCoordinateTranslator.Create('..\nad');
>   Projwgs.Open('+proj=latlong +ellps=WGS84');
>   Projrd:=TCoordinateTranslator.Create('..\nad');
>   Projrd.Open('+init=epsg:28992');
>   x := 5.5*DEG_TO_RAD;
>   y := 51.5*DEG_TO_RAD;
>   res := _pj_transform(ProjWgs.Pjj,projrd.pjj, 1,0,@x,@y,@z);
> but I keep getting
> wgs:5.5,51.5 rd:162801,390015
>
> while the correct result should be rd: 162832,390115, according to pctrans,fme,
> software based on rdnap.
>
> Can you clarify this for me?
>
> Thanx
>
> _______________________________________________
> Proj mailing list
> Pr...@li...
> http://lists.maptools.org/mailman/listinfo/proj
>
_______________________________________________
Proj mailing list
Pr...@li...
http://lists.maptools.org/mailman/listinfo/proj


-- 
Richard Greenwood
ric...@gm...
www.greenwoodmap.com

Re: [Mapbuilder-proj] Fixed, new projection EPSG26986

[Cameron S. <cam...@gm...>]

Nice work HuaiNing.
Could you please raise a JIRA issue here: 
http://jira.codehaus.org/browse/MAP
Describe the issue and how to test it once fixed, and attach your patch.
Then email us to let us know the JIRA issue number.

HuaiNing Zhu wrote:
> Hi, Cameron,
>
> I fixed the bug by add the projection file EPSG26986.js to fold 
> "..\lib\util\cscs\lib\defs\".
>
> And the contents of EPSG26986.js is as follows.  Can you help to add 
> this file to the Mapbuilder package?  Many thanks for all your help.
>
> HuaiNing
>
> //# NAD83 / Massachusetts Mainland, United States (USA) - 
> Massachusetts - SPCS - mainland
>
> //+proj=lcc +lat_1=42.68333333333333 +lat_2=41.71666666666667 
> +lat_0=41 +lon_0=-71.5 +x_0=200000 +y_0=750000 +ellps=GRS80 
> +datum=NAD83 +units=m +no_defs  <>
>
>
> csList.EPSG26986 = "\
>  +title=NAD 1983 StatePlane Wyoming West Central FIPS 4903 Feet\
>  +proj=lcc \
>  +lat_1=42.68333333333333 +lat_2=41.71666666666667 +lat_0=41 
> +lon_0=-71.5 \
>  +x_0=200000 +y_0=750000 \
>  +ellps=GRS80  \
>  +units=m +no_defs \
> ";
>
>
>
> -----Original Message-----
> From: Cameron Shorter [mailto:cam...@gm...]
> Sent: Wednesday, August 22, 2007 7:16 PM
> To: Zhu, Huaining (DEP)
> Subject: Re: [Mapbuilder-users] Error, status=404
>
>
> I suggest you run these responses past the email list. Unfortunately, 
> I don't have time to debug each query unless the query is coming from 
> someone on a support contract.
>
> As a first step, I suggest you try and reproduce the problem in one of 
> the existing demos.
> If it works in the demo, then change the demo line by line until it is 
> the same as your example.
>
> Note that 1.5alpha2 has deprecated some widgets from 1.5alpha1. So you 
> may find old config.xml files don't work any more.
>
>
>


-- 
Cameron Shorter
Systems Architect, http://lisasoft.com.au
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Re: [Mapbuilder-proj] re-factoring cscs

[Richard G. <ric...@gm...>]

Don't let me hold you back, but I don't really see where you're going.
It seems like a big step backward to expose forward and inverse. I
think you're missing the universality of cs2cs, which provides a
single, bi-directional API for conversion between arbitrary coordinate
systems. I feel like I'm beating a dead horse.

I haven't been getting any pleasure out of this project so I don't
think be working on it.

Rich

On 8/9/07, Mike Adair <ma...@dm...> wrote:
> I've got an initial refactoring of cscs checked in for comment as
> cscs/lib/proj4js.js.  It is mostly jjust re-arranging things to be a
> little more object-oriented using Prototype.js - all the actual
> calculations are the same.
>
> Highlights:
> - uses it's own namespace called Proj4js - I can live with cscs as the
> library name but I will make an impassioned plea to change the name of
> this library to Proj4js because I think it is much more descriptive of
> what it does and where it came from
> - look up projection definitions from memory, loaded in from disk, or
> failing that then it uses the new spatialreference.org lookup service
> with an Ajax request.  This part is really cool because it means you
> don't necessarily have to know the proj parameters beforehand.
> - will dynamically load projection class code from disk, e.g. lcc.js or
> these may also be loaded in your application HTML HEAD element
> - offers the following API (this is a rough sketch, I would like to
> document this for NaturalDocs)
>
> Proj4js            //global Namespace object, with some init properties
> Proj4js.defs.   //hash of all the proj definitions loaded, as Proj4
> command line options
>                       //this could also use JSON, WKT,  etc. formats
> eventually
> Proj4js.defs.EPSG4326   //for example
>
> Proj4js.proj   //abstract proj object, constructor takes single srsCode
> argument
>                         //which offers the following methods
> Proj4js.proj.transform(point, dest)   //transform point from this proj
> into the dest proj
> Proj4js.proj.forward(point)               //transform point from lon,lat
> to proj x,y
> Proj4js.proj.inverse(point)               //transform point from proj
> x,y to lon,lat
>
> Proj4js.proj.lcc  //class containing the actual code for LCC projection,
> one for each projection type, etc.
>
> Proj4js.datums   //not yet completed, but will handle datum transformations
>
> To use a Proj4js object:
> var myProj = new Proj4js.proj(srsCode) ;
> var newPoint  = myProj.transform(point, yourProj) ;
>
> The implementation is a little weird in that your will always request a
> Proj4js.proj object, but what you get back is actually Proj4js.proj.lcc
> if you ask for a LCC projection for example.  I think this is OK because
> they all offer transform(), forward() and inverse() methods.
>
> I haven't checked in a working example in SVN yet, but I do have it
> running on my machine and it works well.  I will wait for comments on
> thee naming issue and if this API seems to be acceptable to everyone.
>
> Mike
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Mapbuilder-proj mailing list
> Map...@li...
> https://lists.sourceforge.net/lists/listinfo/mapbuilder-proj
>


-- 
Richard Greenwood
ric...@gm...
www.greenwoodmap.com

Re: [Mapbuilder-proj] [Mapbuilder-devel] re-factoring cscs

[Andreas H. <and...@gm...>]

Mike,

just one word: PERFECT! Great work, I am eager to see this running.
And I 100% agree with the proposed API. I have no strong opinion of
the name of the library, but Proj4js seems logical to me.

Now I also know why you have been so quiet for the last days :-)

Thanks!
Andreas.

On 8/9/07, Mike Adair <ma...@dm...> wrote:
> I've got an initial refactoring of cscs checked in for comment as
> cscs/lib/proj4js.js.  It is mostly jjust re-arranging things to be a
> little more object-oriented using Prototype.js - all the actual
> calculations are the same.
>
> Highlights:
> - uses it's own namespace called Proj4js - I can live with cscs as the
> library name but I will make an impassioned plea to change the name of
> this library to Proj4js because I think it is much more descriptive of
> what it does and where it came from
> - look up projection definitions from memory, loaded in from disk, or
> failing that then it uses the new spatialreference.org lookup service
> with an Ajax request.  This part is really cool because it means you
> don't necessarily have to know the proj parameters beforehand.
> - will dynamically load projection class code from disk, e.g. lcc.js or
> these may also be loaded in your application HTML HEAD element
> - offers the following API (this is a rough sketch, I would like to
> document this for NaturalDocs)
>
> Proj4js            //global Namespace object, with some init properties
> Proj4js.defs.   //hash of all the proj definitions loaded, as Proj4
> command line options
>                       //this could also use JSON, WKT,  etc. formats
> eventually
> Proj4js.defs.EPSG4326   //for example
>
> Proj4js.proj   //abstract proj object, constructor takes single srsCode
> argument
>                         //which offers the following methods
> Proj4js.proj.transform(point, dest)   //transform point from this proj
> into the dest proj
> Proj4js.proj.forward(point)               //transform point from lon,lat
> to proj x,y
> Proj4js.proj.inverse(point)               //transform point from proj
> x,y to lon,lat
>
> Proj4js.proj.lcc  //class containing the actual code for LCC projection,
> one for each projection type, etc.
>
> Proj4js.datums   //not yet completed, but will handle datum transformations
>
> To use a Proj4js object:
> var myProj = new Proj4js.proj(srsCode) ;
> var newPoint  = myProj.transform(point, yourProj) ;
>
> The implementation is a little weird in that your will always request a
> Proj4js.proj object, but what you get back is actually Proj4js.proj.lcc
> if you ask for a LCC projection for example.  I think this is OK because
> they all offer transform(), forward() and inverse() methods.
>
> I haven't checked in a working example in SVN yet, but I do have it
> running on my machine and it works well.  I will wait for comments on
> thee naming issue and if this API seems to be acceptable to everyone.
>
> Mike
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> mapbuilder-devel mailing list
> map...@li...
> https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
>

[Mapbuilder-proj] re-factoring cscs

[Mike A. <ma...@dm...>]

I've got an initial refactoring of cscs checked in for comment as 
cscs/lib/proj4js.js.  It is mostly jjust re-arranging things to be a 
little more object-oriented using Prototype.js - all the actual 
calculations are the same.

Highlights:
- uses it's own namespace called Proj4js - I can live with cscs as the 
library name but I will make an impassioned plea to change the name of 
this library to Proj4js because I think it is much more descriptive of 
what it does and where it came from
- look up projection definitions from memory, loaded in from disk, or 
failing that then it uses the new spatialreference.org lookup service 
with an Ajax request.  This part is really cool because it means you 
don't necessarily have to know the proj parameters beforehand.
- will dynamically load projection class code from disk, e.g. lcc.js or 
these may also be loaded in your application HTML HEAD element
- offers the following API (this is a rough sketch, I would like to 
document this for NaturalDocs)

Proj4js            //global Namespace object, with some init properties
Proj4js.defs.   //hash of all the proj definitions loaded, as Proj4 
command line options
                      //this could also use JSON, WKT,  etc. formats 
eventually
Proj4js.defs.EPSG4326   //for example

Proj4js.proj   //abstract proj object, constructor takes single srsCode 
argument
                        //which offers the following methods
Proj4js.proj.transform(point, dest)   //transform point from this proj 
into the dest proj
Proj4js.proj.forward(point)               //transform point from lon,lat 
to proj x,y
Proj4js.proj.inverse(point)               //transform point from proj 
x,y to lon,lat

Proj4js.proj.lcc  //class containing the actual code for LCC projection, 
one for each projection type, etc.

Proj4js.datums   //not yet completed, but will handle datum transformations

To use a Proj4js object:
var myProj = new Proj4js.proj(srsCode) ;
var newPoint  = myProj.transform(point, yourProj) ;

The implementation is a little weird in that your will always request a 
Proj4js.proj object, but what you get back is actually Proj4js.proj.lcc 
if you ask for a LCC projection for example.  I think this is OK because 
they all offer transform(), forward() and inverse() methods.

I haven't checked in a working example in SVN yet, but I do have it 
running on my machine and it works well.  I will wait for comments on 
thee naming issue and if this API seems to be acceptable to everyone.

Mike

[Mapbuilder-proj] Man Lebt nur einmal - probiers aus ! that I have been -- You're not

[Flora M. <jb...@so...>]

Haben Sie endlich wieder Spass am Leben!

Preise die keine Konkurrenz kennen 

- Kein peinlicher Arztbesuch erforderlicht
- Bequem und diskret online bestellen.
- Diskrete Verpackung und Zahlung
- Kostenlose, arztliche Telefon-Beratung
- Kein langes Warten - Auslieferung innerhalb von 2-3 Tagen
- Visa verifizierter Onlineshop
- keine versteckte Kosten


Nur fur kurze Zeit - vier Pillen umsonst erhalten
http://wxnoho.dropthird.hk/?265195613325

Re: [Mapbuilder-proj] [Mapbuilder-devel] Mapbuilder projections and CSCS

[Richard G. <ric...@gm...>]

On 5/31/07, olivier.terral <oli...@ge...> wrote:
> Thanks Richard for the big work you've done on cscs,
>
> With your script and some little modifications , it works perfectly EPSG
> definition  and projections are loaded dynamically.
>
> I've pleasure to say: cscs is integrated to mapbuilder, I've tested it
> on FF 1.5 and IE 6 on windows.
>
> Thanks to Yass to having implemented all the projections of  GCTCP
> library : lcc, merc, tmerc,stere works but
> for the others : aea,aeqd,laea,mill,moll,sinu,vandg it seems they work
> but we couldn't verified.

Olivier,

Thank you very much for your work on this. You have given cscs the
boost that I was unable to. I hope we have the opportunity to meet
some day.

Rich

-- 
Richard Greenwood
ric...@gm...
www.greenwoodmap.com

Re: [Mapbuilder-proj] [Mapbuilder-devel] Mapbuilder projections and CSCS

[Andreas H. <and...@gm...>]

Great work! Don't hesitate to commit.

Thanks!
Andreas.

On 5/31/07, olivier.terral <oli...@ge...> wrote:
> Thanks Richard for the big work you've done on cscs,
>
> With your script and some little modifications , it works perfectly EPSG
> definition  and projections are loaded dynamically.
>
> I've pleasure to say: cscs is integrated to mapbuilder, I've tested it
> on FF 1.5 and IE 6 on windows.
>
> Thanks to Yass to having implemented all the projections of  GCTCP
> library : lcc, merc, tmerc,stere works but
> for the others : aea,aeqd,laea,mill,moll,sinu,vandg it seems they work
> but we couldn't verified.
>
>
> To all the MD devs : I wait your permission to commit the changes
>
>  for the moment I commit just the library with test.html to test
> projection in lib/util/cscs/.
>
>
>
>
>
> Richard Greenwood a =E9crit :
> > On 5/31/07, olivier.terral <oli...@ge...> wrote:
> >
> >> Hi Richard,
> >>
> >> When you can send your code for dynamic load EPSG? because after this
> >> week
> >> I'm not sure to have enough time  to work more on cscs
> >
> > I have attached it. I am sorry I did not have a chance to clean it up
> > more, but have a look at it.
> >
> > Rich
> >
>
>
> -------------------------------------------------------------------------
> 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
>


--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PRISMA solutions
Dipl.-Ing. Andreas Hocevar
-----------------------------------------------
Telefon: +43 2236 47975 27
-----------------------------------------------
PRISMA solutions EDV-Dienstleistungen GmbH
Adresse: Klostergasse 18, 2340 M=F6dling, Austria
http://www.prisma-solutions.at/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: [Mapbuilder-proj] [Mapbuilder-devel] Mapbuilder projections and CSCS

[Adair, M. <ad...@NR...>]

Olivier, Richard,

Good work on this.  Please don't hesitate to commit on my account.  =
People actually willing to do the work trumps hot air design ideas every =
time.  I may try to add in my JSON ideas later if it's needed.

Mike

> -----Original Message-----
> From: map...@li...=20
> [mailto:map...@li...] On=20
> Behalf Of olivier.terral
> Sent: Thursday, May 31, 2007 13:05
> To: Richard Greenwood
> Cc: map...@li...; Paul Spencer;=20
> map...@li...
> Subject: Re: [Mapbuilder-devel] [Mapbuilder-proj] Mapbuilder=20
> projections and CSCS
>=20
> Thanks Richard for the big work you've done on cscs,
>=20
> With your script and some little modifications , it works=20
> perfectly EPSG definition  and projections are loaded dynamically.
>=20
> I've pleasure to say: cscs is integrated to mapbuilder, I've=20
> tested it on FF 1.5 and IE 6 on windows.
>=20
> Thanks to Yass to having implemented all the projections of =20
> GCTCP library : lcc, merc, tmerc,stere works but for the=20
> others : aea,aeqd,laea,mill,moll,sinu,vandg it seems they=20
> work but we couldn't verified.
>=20
> =20
> To all the MD devs : I wait your permission to commit the changes
>=20
>  for the moment I commit just the library with test.html to=20
> test projection in lib/util/cscs/.
>=20
>=20
>=20
>=20
>=20
> Richard Greenwood a =E9crit :
> > On 5/31/07, olivier.terral <oli...@ge...> wrote:
> >
> >> Hi Richard,
> >>
> >> When you can send your code for dynamic load EPSG? because=20
> after this=20
> >> week
> >> I'm not sure to have enough time  to work more on cscs
> >
> > I have attached it. I am sorry I did not have a chance to=20
> clean it up
> > more, but have a look at it.
> >
> > Rich
> >
>=20
>=20
> --------------------------------------------------------------
> -----------
> 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
>=20

Re: [Mapbuilder-proj] [Mapbuilder-devel] Mapbuilder projections and CSCS

[olivier.terral <oli...@ge...>]

Thanks Richard for the big work you've done on cscs,

With your script and some little modifications , it works perfectly EPSG 
definition  and projections are loaded dynamically.

I've pleasure to say: cscs is integrated to mapbuilder, I've tested it 
on FF 1.5 and IE 6 on windows.

Thanks to Yass to having implemented all the projections of  GCTCP 
library : lcc, merc, tmerc,stere works but
for the others : aea,aeqd,laea,mill,moll,sinu,vandg it seems they work  
but we couldn't verified.

 
To all the MD devs : I wait your permission to commit the changes

 for the moment I commit just the library with test.html to test 
projection in lib/util/cscs/.





Richard Greenwood a écrit :
> On 5/31/07, olivier.terral <oli...@ge...> wrote:
>
>> Hi Richard,
>>
>> When you can send your code for dynamic load EPSG? because after this 
>> week
>> I'm not sure to have enough time  to work more on cscs
>
> I have attached it. I am sorry I did not have a chance to clean it up
> more, but have a look at it.
>
> Rich
>

Re: [Mapbuilder-proj] [Mapbuilder-devel] Mapbuilder projections and CSCS

[Richard G. <ric...@gm...>]

On 5/31/07, olivier.terral <oli...@ge...> wrote:

> Hi Richard,
>
> When you can send your code for dynamic load EPSG? because after this week
> I'm not sure to have enough time  to work more on cscs


I have attached it. I am sorry I did not have a chance to clean it up
more, but have a look at it.

Rich

-- 
Richard Greenwood
ric...@gm...
www.greenwoodmap.com

Re: [Mapbuilder-proj] [Mapbuilder-devel] Mapbuilder projections and CSCS

[olivier.terral <oli...@ge...>]

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?
>
> 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.
Hi Richard,

When you can send your code for dynamic load EPSG? because after this week
I'm not sure to have enough time  to work more on cscs
.

Bye

Re: [Mapbuilder-proj] [Mapbuilder-devel] Mapbuilder projections and CSCS

[olivier.terral <oli...@ge...>]

Richard Greenwood a écrit :
> On 5/25/07, olivier.terral <oli...@ge...> wrote:
>> 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 am very happy to hear that. Would you mind sending me the mapbuilder
> code that you modified to integrate cscs?
>
No problem richard, I commit a version in my sandbox.
In first time, I've tested cscs with the Cursor Track widget in the demo 
i18n.
I've modified, Proj.js and CursorTrack.js and now I modified Graticule 
widget.

Have look, I wait your observations and comments,

I'm very happy to work on it with you :)