From cameron.shorter at gmail.com Sat Jul 1 07:21:28 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:41 2006 Subject: [webmap-discuss] zoomlevels in OWSContext? In-Reply-To: <44A52BD6.4080809@mapgears.com> References: <44A51128.1060201@geodan.nl> <44A52BD6.4080809@mapgears.com> Message-ID: <44A65AB8.1010307@gmail.com> Daniel, Tom, Who should we talk to if we want to join in the OWSContext schema discussions? OWSContext is core to Mapbuilder's design, and it would be good if we could contribute to this. Daniel Morissette wrote: > Steven M. Ottens wrote: > >> >> Currently we store out layers in a WMC document, but we're switching to >> OWSContext to allow for more types of layers then just WMS layers. Since >> the zoom levels are depending on the server, it makes sense to me to >> store these levels in OWSContext. >> Are there any OWSContext experts around who can tell me if that's >> already in the standard, > > > No, that's not part of the OWSContext schema. I participated in the OWS > Context IE and don't remember the question of storing multiple zoom > levels even being raised at all. Note that WMS doesn't support the > concept of fixed zoom levels either, so before multiple zoom levels can > be added to OWS Context some work will be required upstream in WMS. > >> if not, what would be a proper place and name >> for such a thing? >> > > If I remember correctly an extension mechanism was included in the > schema that could possibly be used for that. I think Tom Kralidis would > be the best one to answer on this. I CC'd him in case he is not on this > list. > > Daniel -- Cameron Shorter http://cameron.shorter.net From cameron.shorter at gmail.com Mon Jul 3 17:35:10 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:41 2006 Subject: Thinking about integration between Mapbuilder and OpenLayers Message-ID: <44A98D8E.9070903@gmail.com> (It is my intent that the email thread move only to webmap-discuss, so if you want to join in, I suggest joining this list). I've been having a look at the OpenLayers code and I can see both technical and political issues to address. Technical: ========== In the trunk version of Mapbuilder we use a Layer Factory to create new layers for a MapPane. This layer factory would be a simple place to replace our Mapbuilder code with OpenLayers code. We will run into issues where Mapbuilder provides functionality not yet provided by OpenLayers. Eg: WMS time series. I think we have 2 options here: 1. We continue using existing Mapbuilder code. 2. We port Mapbuilder code into OpenLayers. Mapbuilder can still use the Model/View/Controller framework for XML data sources to drive various widgets. Also, our graphics library, used for rendering lines polygons and points across browsers should be of use for OpenLayers if incorporated into the Openlayers framework. There are sure to be some technical issues we need to address and I'm interested to hear thoughts from others. Political: ========== By switching to use a significant potion of code from OpenLayers, Mapbuilder developers will be loosing an element of control over the project. How is OpenLayers controlled? It seems like Metacarta has the last say over all major decisions. Is this right? Have you considered setting up a Project Management Committee similar other OSGeo projects? -- Cameron Shorter http://cameron.shorter.net From steven.ottens at geodan.nl Tue Jul 4 04:54:30 2006 From: steven.ottens at geodan.nl (Steven M. Ottens) Date: Fri Dec 22 15:49:41 2006 Subject: [Fwd: Re: [webmap-discuss] zoomlevels in OWSContext?] In-Reply-To: <2576812186CDD411BF1500508B6DCE950F0090BB@ecnwri1.ontario.int.ec.gc.ca> References: <2576812186CDD411BF1500508B6DCE950F0090BB@ecnwri1.ontario.int.ec.gc.ca> Message-ID: <44AA2CC6.5060506@geodan.nl> Hi all, As Tom said, we've to decide for ourselves what the extension should look like. From what I understood is the following extension correct, so I propose we use it: 128,64,32,16,8,4,2,1 where xmlns:wms-c="http://wiki.osgeo.org/index.php/WMS_Tile_Caching" Note that the zoomLevels go from big to small numbers. Also is a child of regards, Steven Kralidis,Tom [Burlington] wrote: > (Thanks Daniel for forwarding this to me, I'm now a part of this list > again :)) > > > >> Steven M. Ottens wrote: >> >>> Currently we store out layers in a WMC document, but we're >>> >> switching >> >>> to OWSContext to allow for more types of layers then just >>> >> WMS layers. >> >>> Since the zoom levels are depending on the server, it makes >>> >> sense to >> >>> me to store these levels in OWSContext. Are there any OWSContext >>> experts around who can tell me if that's already in the standard, >>> >> No, that's not part of the OWSContext schema. I participated >> in the OWS Context IE and don't remember the question of >> storing multiple zoom levels even being raised at all. Note >> that WMS doesn't support the concept of fixed zoom levels >> either, so before multiple zoom levels can be added to OWS >> Context some work will be required upstream in WMS. >> >> > > Correct. Since OWSContext is based on OGC specifications, this doesn't > apply. > > >>> if not, what would be a proper place and name >>> for such a thing? >>> >>> >> If I remember correctly an extension mechanism was included >> in the schema that could possibly be used for that. I think >> Tom Kralidis would be the best one to answer on this. I CC'd >> him in case he is not on this list. >> >> > > There is an extension element in the OWSContext schemas (schema chunk > below) which allows this: > > > > This allows additional > elements to be added to support non WMS Layer > services. > > > processContents="lax"/> > > > > Yes, fairy dust :) > > The basic approach is to define your own namespace in the root element > of the OWSContext instance doc (i.e. xmlns:foo="http://foo/foo"), and > then use that prefix within the document when applying your own > constructs, i.e.: > > 1,2,4,8,16,32,64 > > Having said this, if you are going to be adding extensions, I would > suggest that these be agreed upon in some way, so at the least the > extensions are defacto; so it's great that it's being discussed here. > > ..Tom > > > >> Daniel >> -- >> Daniel Morissette >> http://www.mapgears.com/ >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > -- Geodan S&R Amsterdam ------------------------------------- Geodan S&R President Kennedylaan 1 1079 MB Amsterdam (NL) ------------------------------------- Tel: +31 (0)20 - 5711 311 Fax: +31 (0)20 - 5711 333 ------------------------------------- E-mail: steven.ottens@geodan.nl Website: www.geodan.nl Disclaimer: www.geodan.nl/disclaimer ------------------------------------- From Tom.Kralidis at ec.gc.ca Wed Jul 5 09:19:34 2006 From: Tom.Kralidis at ec.gc.ca (Kralidis,Tom [Burlington]) Date: Fri Dec 22 15:49:41 2006 Subject: [webmap-discuss] zoomlevels in OWSContext? References: <44A51128.1060201@geodan.nl> <44A52BD6.4080809@mapgears.com> <44A65AB8.1010307@gmail.com> Message-ID: <2576812186CDD411BF1500508B6DCE950D17F3EA@ecnwri1.ontario.int.ec.gc.ca> Hi Cameron, The OWSContext discussions are (formally) a bit dormant these days. I have cc'd Carl for advisory on how to work on this in OGC (Cameron: are you / your group OGC members?). ..Tom -----Original Message----- From: Cameron Shorter [mailto:cameron.shorter@gmail.com] Sent: Sat 01-Jul-06 07:21 To: webmap-discuss@mail.osgeo.org; Kralidis,Tom [Burlington] Cc: Subject: Re: [webmap-discuss] zoomlevels in OWSContext? Daniel, Tom, Who should we talk to if we want to join in the OWSContext schema discussions? OWSContext is core to Mapbuilder's design, and it would be good if we could contribute to this. Daniel Morissette wrote: > Steven M. Ottens wrote: > >> >> Currently we store out layers in a WMC document, but we're switching to >> OWSContext to allow for more types of layers then just WMS layers. Since >> the zoom levels are depending on the server, it makes sense to me to >> store these levels in OWSContext. >> Are there any OWSContext experts around who can tell me if that's >> already in the standard, > > > No, that's not part of the OWSContext schema. I participated in the OWS > Context IE and don't remember the question of storing multiple zoom > levels even being raised at all. Note that WMS doesn't support the > concept of fixed zoom levels either, so before multiple zoom levels can > be added to OWS Context some work will be required upstream in WMS. > >> if not, what would be a proper place and name >> for such a thing? >> > > If I remember correctly an extension mechanism was included in the > schema that could possibly be used for that. I think Tom Kralidis would > be the best one to answer on this. I CC'd him in case he is not on this > list. > > Daniel -- Cameron Shorter http://cameron.shorter.net --------------------------------------------------------------------- To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 5978 bytes Desc: not available Url : http://lists.osgeo.org/pipermail/mail_webmap-discuss/attachments/20060705/471b2e61/attachment.bin From cameron.shorter at gmail.com Wed Jul 5 17:01:12 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:41 2006 Subject: [webmap-discuss] zoomlevels in OWSContext? In-Reply-To: <2576812186CDD411BF1500508B6DCE950D17F3EA@ecnwri1.ontario.int.ec.gc.ca> References: <44A51128.1060201@geodan.nl> <44A52BD6.4080809@mapgears.com> <44A65AB8.1010307@gmail.com> <2576812186CDD411BF1500508B6DCE950D17F3EA@ecnwri1.ontario.int.ec.gc.ca> Message-ID: <44AC2898.5080907@gmail.com> My employer, ADI Limited, is an OGC Member and there are some other developers on the list who are likewise OGC Members. It would be good if an Open Source project like Mapbuilder could be given an OGC member status, which would give developers on that project access to the OGC resources they need. Kralidis,Tom [Burlington] wrote: > > Hi Cameron, > > The OWSContext discussions are (formally) a bit dormant these days. I have cc'd Carl for advisory on how to work on this in OGC (Cameron: are you / your group OGC members?). > > ..Tom > > -----Original Message----- > From: Cameron Shorter [mailto:cameron.shorter@gmail.com] > Sent: Sat 01-Jul-06 07:21 > To: webmap-discuss@mail.osgeo.org; Kralidis,Tom [Burlington] > Cc: > Subject: Re: [webmap-discuss] zoomlevels in OWSContext? > > > > Daniel, Tom, > Who should we talk to if we want to join in the OWSContext schema > discussions? OWSContext is core to Mapbuilder's design, and it would be > good if we could contribute to this. > > Daniel Morissette wrote: > > Steven M. Ottens wrote: > > > >> > >> Currently we store out layers in a WMC document, but we're switching to > >> OWSContext to allow for more types of layers then just WMS layers. Since > >> the zoom levels are depending on the server, it makes sense to me to > >> store these levels in OWSContext. > >> Are there any OWSContext experts around who can tell me if that's > >> already in the standard, > > > > > > No, that's not part of the OWSContext schema. I participated in the OWS > > Context IE and don't remember the question of storing multiple zoom > > levels even being raised at all. Note that WMS doesn't support the > > concept of fixed zoom levels either, so before multiple zoom levels can > > be added to OWS Context some work will be required upstream in WMS. > > > >> if not, what would be a proper place and name > >> for such a thing? > >> > > > > If I remember correctly an extension mechanism was included in the > > schema that could possibly be used for that. I think Tom Kralidis would > > be the best one to answer on this. I CC'd him in case he is not on this > > list. > > > > Daniel > > > -- > Cameron Shorter > http://cameron.shorter.net > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > > > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org -- Cameron Shorter http://cameron.shorter.net From cameron.shorter at gmail.com Wed Jul 5 17:25:59 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:41 2006 Subject: [OpenLayers-Dev] Thinking about integration between Mapbuilder and OpenLayers In-Reply-To: <20060705211203.GF29329@metacarta.com> References: <44A98D8E.9070903@gmail.com> <20060705211203.GF29329@metacarta.com> Message-ID: <44AC2E67.8070502@gmail.com> Schuyler Erle wrote: >>Also, our graphics library, used for rendering lines polygons and points >>across browsers should be of use for OpenLayers if incorporated into the >>Openlayers framework. > > > For example. That sounds great! (Although we should talk about using > SVG/VML versus Zorn...) Patrice has already written code for SVG/VML/Zorn depending on what browser you use, and I'm about to extend that further for the OWS4 Testbed. > > >>Political: >>========== >>How is OpenLayers controlled? It seems like Metacarta has the last >>say over all major decisions. Is this right? Have you considered >>setting up a Project Management Committee similar other OSGeo >>projects? > > > In fact, this is exactly what we are doing. Although MetaCarta has > funded developers to bootstrap OpenLayers development, MetaCarta does > not want to own the code in a literal or figurative sense. > > In the interests of good governance, and to accelerate the possibility > of OSGeo incubation, we plan very shortly to propose a formal Project > Steering Committee to the OpenLayers mailing lists, patterned on the > consensus-based PMC/PSC models already adopted by MapServer, GDAL, > Mapbuilder, et al. > > Our intention is that the membership of the PSC should be open to > including representatives of other F/OSS projects that take a > substantial stake in the future of OpenLayers development. > > How does that sound? Sounds pretty good. I'll start throwing these ideas around amongst the Mapbuilder developers - and our team meeting and the like. We are about to plan for our next release and this is useful information to feed into these discussions. -- Cameron Shorter http://cameron.shorter.net From cameron.shorter at gmail.com Wed Jul 5 18:35:25 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:41 2006 Subject: [webmap-discuss] OGC Membership for Open Source developers In-Reply-To: <017601c6a07a$ca67eaa0$6401a8c0@SusieandCarl> References: <44A51128.1060201@geodan.nl> <44A52BD6.4080809@mapgears.com> <44A65AB8.1010307@gmail.com> <2576812186CDD411BF1500508B6DCE950D17F3EA@ecnwri1.ontario.int.ec.gc.ca> <44AC2898.5080907@gmail.com> <017601c6a07a$ca67eaa0$6401a8c0@SusieandCarl> Message-ID: <44AC3EAD.6050903@gmail.com> Carl, I'm CCing the OSGeo discussion list as there are a number of other open source GIS projects who are likely to have an interest. Open Source developers often are self funded and are not prepared to pay for membership, however they do contribute significant amounts of code. So the goal here is for the developers to get access to OGC documents (like draft specificatons) and in return they will provide code. Membership for an OS developer should be free. An OS developer could be defined as a developer with write access to the repository of specified OS projects. We define our roles here: http://docs.codehaus.org/display/MAP/Contributers+Guide You might also want to specify that the developer must be working on a OGC spec or similar. From an OGC point of view, what are you trying to protect? IP? Are you trying to prevent specifications being used before they are fully developed? Carl Reed OGC Account wrote: > Cameron - > > Good question and suggestions. > > Question back: How would such a membership be structured? For example, I > am currently working a MOU with the web/3D (X3D) consortium. Membership > is between the organizations. There will be a membership swap. The > agreement will allow key staff of W3D to access OGC member documents and > provide key OGC staff access to in progress X3D documents. Members of > the OGC will not have access to members only documents the W3C and > visa-versa. There are reasons for this approach which have nothing to > do about exclusionary or discriminatory behavior. The primary reasons > have to do with intellectual property, copyright, member benefits, and > potential membership erosion. > > That said, the OGC is looking at providing an individual membership > level (like OASIS does) at a reasonable fee. > > SO, we are not opposed to such a liaison relationship. Any thoughts > would be appreciated. > > Regards > > Carl > > ----- Original Message ----- From: "Cameron Shorter" > > To: > Cc: > Sent: Wednesday, July 05, 2006 3:01 PM > Subject: Re: [webmap-discuss] zoomlevels in OWSContext? > > >> My employer, ADI Limited, is an OGC Member and there are some other >> developers on the list who are likewise OGC Members. >> >> It would be good if an Open Source project like Mapbuilder could be >> given an OGC member status, which would give developers on that >> project access to the OGC resources they need. -- Cameron Shorter http://cameron.shorter.net From cameron.shorter at gmail.com Fri Jul 7 17:41:57 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:41 2006 Subject: Mapbuilder is ready for OSGeo Graduation - and project merging In-Reply-To: References: Message-ID: <44AED525.1000806@gmail.com> Steve Lime wrote: > One question in my mind is what all the talk of project merging (OpenLayers, ka-map, > MapBuilder and so on) really means. Is there a chance that in the near future there > really will be a single project comprised of the best of all of the participating client > environments, and if so then how should that be taken into account as part of > incubation. Do we graduate a project that may substantial change near term? If > projects do merge and one is "officially OSGeo" is the merged project now official? > > I know you've started those discussions but it's not clear where they sit. Steve, Mapbuilder are likely to start using OpenLayers as a rendering engine, which will effectively mean Mapbuilder would be using OpenLayers as a library. So technically, we would be able to be an OSGeo member without bringing OpenLayers in as an OSGeo member. Mapbuilder would add value primarilly by providing a Model/View/Controller design pattern which allows numerous types of widgets to render one, or many XML documents. I'd imagine it will be at least 6 months before there is a Mapbuilder release which uses OpenLayers. While I'm very keen to see all the webmapping developers working on the same project, in practice I suspect it will take a year or two for the projects to grow into the same product. The OpenLayers folks have made noises about applying for OSGeo membership - but I'll let them talk to that point. Mapbuilder is not currently planning to merge with kamap directly, but are likely to be connected by an OpenLayer/kamap merge. -- Cameron Shorter http://cameron.shorter.net From crschmidt at crschmidt.net Fri Jul 7 17:51:55 2006 From: crschmidt at crschmidt.net (Christopher Schmidt) Date: Fri Dec 22 15:49:41 2006 Subject: [webmap-discuss] Re: Mapbuilder is ready for OSGeo Graduation - and project merging In-Reply-To: <44AED525.1000806@gmail.com> References: <44AED525.1000806@gmail.com> Message-ID: <20060707215155.GD19562@crschmidt.net> On Sat, Jul 08, 2006 at 07:41:57AM +1000, Cameron Shorter wrote: > Steve Lime wrote: > > > >One question in my mind is what all the talk of project merging > >(OpenLayers, ka-map, > >MapBuilder and so on) really means. Is there a chance that in the near > >future there really will be a single project comprised of the best of all > >of the participating client > >environments, and if so then how should that be taken into account as part > >of incubation. Do we graduate a project that may substantial change near > >term? If > >projects do merge and one is "officially OSGeo" is the merged project now > >official? > > > >I know you've started those discussions but it's not clear where they sit. > > Steve, > Mapbuilder are likely to start using OpenLayers as a rendering engine, > which will effectively mean Mapbuilder would be using OpenLayers as a > library. So technically, we would be able to be an OSGeo member without > bringing OpenLayers in as an OSGeo member. I think that this will be the ideal situation for Mapbuilder and for OpenLayers in this situation -- Any changes to move towards further integration with OpenLayers will be in the form of using OpenLayers as a library while still having Mapbuilder as a seperately developed project. This may be the case for more tools which currently use a self-spanwed map rendering engine: the core application would stay the same, but OpenLayers would act as a renderer for the image data delivered from the server. Given this, I do not think that there is any concern with MapBuilder no longer be a viable project within OSGeo: Mapbuilder has, and will continue to, act as an application framework around a map renderer. It's simply possible that OpenLayers will take over the 'map renderer' aspect of MapBuilder at some point in the future. -- Christopher Schmidt Web Developer From schuyler at nocat.net Fri Jul 7 23:02:03 2006 From: schuyler at nocat.net (Schuyler Erle) Date: Fri Dec 22 15:49:41 2006 Subject: [webmap-discuss] Re: Mapbuilder is ready for OSGeo Graduation - and project merging In-Reply-To: <44AED525.1000806@gmail.com> References: <44AED525.1000806@gmail.com> Message-ID: <20060708030203.GS18923@vishnu.tridity.org> * On 7-Jul-2006 at 2:42PM PDT, Cameron Shorter said: > > The OpenLayers folks have made noises about applying for OSGeo > membership - but I'll let them talk to that point. For the record, the OpenLayers project plans to apply for OSGeo incubation just as soon as the Incubation Committee will let us. :) SDE From Steve.Lime at dnr.state.mn.us Sat Jul 8 01:41:34 2006 From: Steve.Lime at dnr.state.mn.us (Steve Lime) Date: Fri Dec 22 15:49:41 2006 Subject: [webmap-discuss] Re: Mapbuilder is ready for OSGeo Graduation - and project merging Message-ID: I think it will be helpful for users (new and old) to clearly understand where any particular project sits in the OS stack and especially in relationship to projects with (at least outwordly) similar scope. Perhaps via diagrams, roadmaps and such. That would be an excellent starting point for integration even if it were never to happen at the code level. Steve >>> cameron.shorter@gmail.com 07/07/06 4:41 PM >>> Steve Lime wrote: > One question in my mind is what all the talk of project merging (OpenLayers, ka-map, > MapBuilder and so on) really means. Is there a chance that in the near future there > really will be a single project comprised of the best of all of the participating client > environments, and if so then how should that be taken into account as part of > incubation. Do we graduate a project that may substantial change near term? If > projects do merge and one is "officially OSGeo" is the merged project now official? > > I know you've started those discussions but it's not clear where they sit. Steve, Mapbuilder are likely to start using OpenLayers as a rendering engine, which will effectively mean Mapbuilder would be using OpenLayers as a library. So technically, we would be able to be an OSGeo member without bringing OpenLayers in as an OSGeo member. Mapbuilder would add value primarilly by providing a Model/View/Controller design pattern which allows numerous types of widgets to render one, or many XML documents. I'd imagine it will be at least 6 months before there is a Mapbuilder release which uses OpenLayers. While I'm very keen to see all the webmapping developers working on the same project, in practice I suspect it will take a year or two for the projects to grow into the same product. The OpenLayers folks have made noises about applying for OSGeo membership - but I'll let them talk to that point. Mapbuilder is not currently planning to merge with kamap directly, but are likely to be connected by an OpenLayer/kamap merge. -- Cameron Shorter http://cameron.shorter.net --------------------------------------------------------------------- To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org From richard.greenwood at gmail.com Mon Jul 24 22:08:11 2006 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Fri Dec 22 15:49:41 2006 Subject: Coordinate System Transformation demo Message-ID: I have been working on a port of the Proj.4 cs2cs program to JavaScript for use in web map clients. The source is at: http://svn.codehaus.org/mapbuilder/cscs/trunk/cscs/ and mailing list: mapbuilder-proj@lists.sourceforge.net I put a demo at: http://www2.tetonwyo.org/mapserver/tcd.html which uses Steve Lime's dBox client. The project is nowhere near finished, but I want to make people aware of it. Rich -- Richard Greenwood richard.greenwood@gmail.com www.greenwoodmap.com From aaronkoning at gmail.com Tue Jul 25 01:47:14 2006 From: aaronkoning at gmail.com (Aaron Koning) Date: Fri Dec 22 15:49:42 2006 Subject: Client side coordinate transformation library - Call to developers/testers Message-ID: <1319fbba0607242247k1a64d1c3q3776e70369326efe@mail.gmail.com> Hello All, A while ago I created a client side coordinate transformation library called GCTP-JS (Open Source, GPL licence). More accurately, I ported files directly from the General Cartographic Transformation System (GCTP) C-code to JavaScript. http://datashare.gis.unbc.ca/gctp-js/ Simple example application: http://datashare.gis.unbc.ca/gctp-js/examples.php Implemented easily and successfully in the Flexible Internet Spatial Template (FIST) web mapping application: http://fist-mapping.org Currently the 'port' is not complete (UTM, Albers, and Lambert projection files have been ported). What I would like to see is a complete port of the GCTP to JavaScript. Porting each projection file takes a few hours to a few days depending on experience level (pretty quick I think). Then the projection file must be tested, which is best done by someone who uses that particular projection often. The best reasons to get involved are: - porting and testing can be done file by file; - porting a file doesn't take very long; - only work on the projections you want or the whole library; - very little planning is needed since it is a straightforward porting exercise; - there is a definite and achievable end goal! Therefore, I would like all interested parties to contact me at the address below and start porting and testing projection files as soon as possible. I am eager to get going and help make this a success! aaronkoning@gmail.com The GCTP C-code can be downloaded at: http://edcftp.cr.usgs.gov/pub//software/gctpc/gctpc_src.tar Thank you for your time, Aaron +-------------------------------------------- | Aaron Koning | Information Technologist | Prince George, BC, Canada. +-------------------------------------------- | http://datashare.gis.unbc.ca/fist/ | http://datashare.gis.unbc.ca/gctp-js/ +-------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/mail_webmap-discuss/attachments/20060724/3d2ac15b/attachment.html From steven.ottens at geodan.nl Tue Jul 25 04:11:24 2006 From: steven.ottens at geodan.nl (Steven M. Ottens) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Client side coordinate transformation library - Call to developers/testers In-Reply-To: <1319fbba0607242247k1a64d1c3q3776e70369326efe@mail.gmail.com> References: <1319fbba0607242247k1a64d1c3q3776e70369326efe@mail.gmail.com> Message-ID: <44C5D22C.50000@geodan.nl> Hi Aaron, Just for your information; Mapbuilder has a proj lib based on gtcp, it is still there but we've decided to move away from GTCP and towards proj.4 for various reasons. You can have a look at our GTCP code, several transformations are supported. For more information on the reasons I advise to contact Richard Greenwood (from the cst demo mail a few hours ago) Regards, Steven Aaron Koning wrote: > Hello All, > > A while ago I created a client side coordinate transformation library > called GCTP-JS (Open Source, GPL licence). More accurately, I ported > files directly from the General Cartographic Transformation System > (GCTP) C-code to JavaScript. > http://datashare.gis.unbc.ca/gctp-js/ > > > Simple example application: > http://datashare.gis.unbc.ca/gctp-js/examples.php > > Implemented easily and successfully in the Flexible Internet Spatial > Template (FIST) web mapping application: > http://fist-mapping.org > > Currently the 'port' is not complete (UTM, Albers, and Lambert > projection files have been ported). What I would like to see is a > complete port of the GCTP to JavaScript. Porting each projection file > takes a few hours to a few days depending on experience level (pretty > quick I think). Then the projection file must be tested, which is best > done by someone who uses that particular projection often. > > The best reasons to get involved are: > - porting and testing can be done file by file; > - porting a file doesn't take very long; > - only work on the projections you want or the whole library; > - very little planning is needed since it is a straightforward > porting exercise; > - there is a definite and achievable end goal! > > Therefore, I would like all interested parties to contact me at the > address below and start porting and testing projection files as soon > as possible. I am eager to get going and help make this a success! > aaronkoning@gmail.com > > The GCTP C-code can be downloaded at: > http://edcftp.cr.usgs.gov/pub//software/gctpc/gctpc_src.tar > > > Thank you for your time, > Aaron > > +-------------------------------------------- > | Aaron Koning > | Information Technologist > | Prince George, BC, Canada. > +-------------------------------------------- > | http://datashare.gis.unbc.ca/fist/ > | http://datashare.gis.unbc.ca/gctp-js/ > > +-------------------------------------------- -- Geodan S&R Amsterdam ------------------------------------- Geodan S&R President Kennedylaan 1 1079 MB Amsterdam (NL) ------------------------------------- Tel: +31 (0)20 - 5711 311 Fax: +31 (0)20 - 5711 333 ------------------------------------- E-mail: steven.ottens@geodan.nl Website: www.geodan.nl Disclaimer: www.geodan.nl/disclaimer ------------------------------------- From richard.greenwood at gmail.com Tue Jul 25 15:33:04 2006 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Client side coordinate transformation library - Call to developers/testers In-Reply-To: <1319fbba0607242247k1a64d1c3q3776e70369326efe@mail.gmail.com> References: <1319fbba0607242247k1a64d1c3q3776e70369326efe@mail.gmail.com> Message-ID: On 7/24/06, Aaron Koning wrote: > Hello All, > > A while ago I created a client side coordinate transformation library called > GCTP-JS (Open Source, GPL licence). More accurately, I ported files directly > from the General Cartographic Transformation System (GCTP) C-code to > JavaScript. > http://datashare.gis.unbc.ca/gctp-js/ > > Simple example application: > http://datashare.gis.unbc.ca/gctp-js/examples.php > > Implemented easily and successfully in the Flexible Internet Spatial > Template (FIST) web mapping application: > http://fist-mapping.org > > Currently the 'port' is not complete (UTM, Albers, and Lambert projection > files have been ported). What I would like to see is a complete port of the > GCTP to JavaScript. Porting each projection file takes a few hours to a few > days depending on experience level (pretty quick I think). Then the > projection file must be tested, which is best done by someone who uses that > particular projection often. > > The best reasons to get involved are: > - porting and testing can be done file by file; > - porting a file doesn't take very long; > - only work on the projections you want or the whole library; > - very little planning is needed since it is a straightforward porting > exercise; > - there is a definite and achievable end goal! > > Therefore, I would like all interested parties to contact me at the address > below and start porting and testing projection files as soon as possible. I > am eager to get going and help make this a success! > aaronkoning@gmail.com > > The GCTP C-code can be downloaded at: > > http://edcftp.cr.usgs.gov/pub//software/gctpc/gctpc_src.tar > > Thank you for your time, > Aaron > > +-------------------------------------------- > | Aaron Koning > | Information Technologist > | Prince George, BC, Canada. > +-------------------------------------------- > | http://datashare.gis.unbc.ca/fist/ > | http://datashare.gis.unbc.ca/gctp-js/ > +-------------------------------------------- Aaron, We must be on the same wavelength! Just yesterday I sent an eamil to a couple lists regarding the work that I have been doing toward porting the Proj.4 cs2cs program to Javascript. I went with Proj.4 over GCTP primarily because Proj.4 has support for datum transformations. Is the GCTP license Open Source? Would you be interested in combining our projects? Rich -- Richard Greenwood richard.greenwood@gmail.com www.greenwoodmap.com From aaronkoning at gmail.com Tue Jul 25 17:41:22 2006 From: aaronkoning at gmail.com (Aaron Koning) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Client side coordinate transformation library - Call to developers/testers In-Reply-To: References: <1319fbba0607242247k1a64d1c3q3776e70369326efe@mail.gmail.com> Message-ID: <1319fbba0607251441l37de114du9c62d7e4a6bbea7c@mail.gmail.com> Hi Richard, Its good to hear from you again. I am mostly interested in porting GCTP to JavaScript. I have not had much use for datum conversions on the client side, but I'd be interested to hear from anyone who has. Right now the GCTP-JS port has the three most important projections for my region (Albers, Lambert, UTM) and it works very well, so I am hesitant to get involved with recreating this functionality. In addition, I believe that the GCTP can be ported much quicker than Proj4 since it has less than half the files of Proj4 and since many of the GCTP files contain only a few lines that need to be converted. Perhaps there are more compelling reasons to redirect efforts? Aaron On 7/25/06, Richard Greenwood wrote: > > On 7/24/06, Aaron Koning wrote: > > Hello All, > > > > A while ago I created a client side coordinate transformation library > called > > GCTP-JS (Open Source, GPL licence). More accurately, I ported files > directly > > from the General Cartographic Transformation System (GCTP) C-code to > > JavaScript. > > http://datashare.gis.unbc.ca/gctp-js/ > > > > Simple example application: > > http://datashare.gis.unbc.ca/gctp-js/examples.php > > > > Implemented easily and successfully in the Flexible Internet Spatial > > Template (FIST) web mapping application: > > http://fist-mapping.org > > > > Currently the 'port' is not complete (UTM, Albers, and Lambert > projection > > files have been ported). What I would like to see is a complete port of > the > > GCTP to JavaScript. Porting each projection file takes a few hours to a > few > > days depending on experience level (pretty quick I think). Then the > > projection file must be tested, which is best done by someone who uses > that > > particular projection often. > > > > The best reasons to get involved are: > > - porting and testing can be done file by file; > > - porting a file doesn't take very long; > > - only work on the projections you want or the whole library; > > - very little planning is needed since it is a straightforward > porting > > exercise; > > - there is a definite and achievable end goal! > > > > Therefore, I would like all interested parties to contact me at the > address > > below and start porting and testing projection files as soon as > possible. I > > am eager to get going and help make this a success! > > aaronkoning@gmail.com > > > > The GCTP C-code can be downloaded at: > > > > http://edcftp.cr.usgs.gov/pub//software/gctpc/gctpc_src.tar > > > > Thank you for your time, > > Aaron > > > > +-------------------------------------------- > > | Aaron Koning > > | Information Technologist > > | Prince George, BC, Canada. > > +-------------------------------------------- > > | http://datashare.gis.unbc.ca/fist/ > > | http://datashare.gis.unbc.ca/gctp-js/ > > +-------------------------------------------- > > > Aaron, > > We must be on the same wavelength! Just yesterday I sent an eamil to a > couple lists regarding the work that I have been doing toward porting > the Proj.4 cs2cs program to Javascript. > > I went with Proj.4 over GCTP primarily because Proj.4 has support for > datum transformations. Is the GCTP license Open Source? > > Would you be interested in combining our projects? > > Rich > > -- > Richard Greenwood > richard.greenwood@gmail.com > www.greenwoodmap.com > -- +-------------------------------------------- | Aaron Koning | Information Technologist | Prince George, BC, Canada. +-------------------------------------------- | http://datashare.gis.unbc.ca/fist/ | http://datashare.gis.unbc.ca/gctp-js/ +-------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/mail_webmap-discuss/attachments/20060725/a73c9f46/attachment.html From richard.greenwood at gmail.com Tue Jul 25 21:21:27 2006 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Client side coordinate transformation library - Call to developers/testers In-Reply-To: <1319fbba0607251441l37de114du9c62d7e4a6bbea7c@mail.gmail.com> References: <1319fbba0607242247k1a64d1c3q3776e70369326efe@mail.gmail.com> <1319fbba0607251441l37de114du9c62d7e4a6bbea7c@mail.gmail.com> Message-ID: On 7/25/06, Aaron Koning wrote: > Hi Richard, > > Its good to hear from you again. I am mostly interested in porting GCTP to > JavaScript. I have not had much use for datum conversions on the client > side, but I'd be interested to hear from anyone who has. Right now the > GCTP-JS port has the three most important projections for my region (Albers, > Lambert, UTM) and it works very well, so I am hesitant to get involved with > recreating this functionality. In addition, I believe that the GCTP can be > ported much quicker than Proj4 since it has less than half the files of > Proj4 and since many of the GCTP files contain only a few lines that need to > be converted. Perhaps there are more compelling reasons to redirect efforts? > > Aaron No, I have no terribly compelling arguments for combining the projects at this time, but let's keep in touch. The Mapbuilder Proj.js code does have the GCTP Polar Stereographic projection converted, which may be of interest to you. Top of my projection list is the Mercator (not transverse Mercator) because it is used by Google and everybody is keen on Google. If you get to it before I do, would you drop me a line? I trust that you would not mind if I incorporated projections that you have port into my work? And do you know if GCTP is open source? I know Cameron Shorter was wondering about this recently. Rich -- Richard Greenwood richard.greenwood@gmail.com www.greenwoodmap.com From cameron.shorter at gmail.com Tue Jul 25 23:43:55 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Client side coordinate transformation library - Call to developers/testers In-Reply-To: References: <1319fbba0607242247k1a64d1c3q3776e70369326efe@mail.gmail.com> <1319fbba0607251441l37de114du9c62d7e4a6bbea7c@mail.gmail.com> Message-ID: <44C6E4FB.5000900@gmail.com> Richard, Aaron, You guys are both doing good stuff with regards to Javascript Projections. I know that in the short term it is easier and faster to update your personal codebase rather than merge your codebase with another library. However, in the long run the advantages of having twice the number of developers on the same codebase should outweigh the initial merging cost. Your projects have the advantage that they are relatively young and the momentum required for a merge will be much less than will be required in a year or two. Aaron, Your licence is GPL? Would you consider changing to LGPL? Mapbuilder would have a problem incorporating your library because we are a LGPL library which means we wouldn't be able to use your codebase. Richard Greenwood wrote: > On 7/25/06, Aaron Koning wrote: > >> Hi Richard, >> >> Its good to hear from you again. I am mostly interested in porting >> GCTP to >> JavaScript. I have not had much use for datum conversions on the client >> side, but I'd be interested to hear from anyone who has. Right now the >> GCTP-JS port has the three most important projections for my region >> (Albers, >> Lambert, UTM) and it works very well, so I am hesitant to get involved >> with >> recreating this functionality. In addition, I believe that the GCTP >> can be >> ported much quicker than Proj4 since it has less than half the files of >> Proj4 and since many of the GCTP files contain only a few lines that >> need to >> be converted. Perhaps there are more compelling reasons to redirect >> efforts? >> >> Aaron > > > No, I have no terribly compelling arguments for combining the projects > at this time, but let's keep in touch. The Mapbuilder Proj.js code > does have the GCTP Polar Stereographic projection converted, which may > be of interest to you. > > Top of my projection list is the Mercator (not transverse Mercator) > because it is used by Google and everybody is keen on Google. If you > get to it before I do, would you drop me a line? > > I trust that you would not mind if I incorporated projections that you > have port into my work? > > And do you know if GCTP is open source? I know Cameron Shorter was > wondering about this recently. > > Rich > -- Cameron Shorter http://cameron.shorter.net From aaronkoning at gmail.com Sun Jul 30 15:26:55 2006 From: aaronkoning at gmail.com (Aaron Koning) Date: Fri Dec 22 15:49:42 2006 Subject: [webmap-discuss] Client side coordinate transformation library - Call to developers/testers In-Reply-To: <44C6E4FB.5000900@gmail.com> References: <1319fbba0607242247k1a64d1c3q3776e70369326efe@mail.gmail.com> <1319fbba0607251441l37de114du9c62d7e4a6bbea7c@mail.gmail.com> <44C6E4FB.5000900@gmail.com> Message-ID: <1319fbba0607301226w4657baa0o253f07df3dc8ba6b@mail.gmail.com> Yes, I would consider changing the licence to LGPL. Currently, no one is helping develop the library for use with LGPL apps, so there is no desire to switch. If the mapbuilder folks start contributing to this library, then the licence can certainly be changed. Aaron On 7/25/06, Cameron Shorter wrote: > > Richard, Aaron, > You guys are both doing good stuff with regards to Javascript Projections. > > I know that in the short term it is easier and faster to update your > personal codebase rather than merge your codebase with another library. > However, in the long run the advantages of having twice the number of > developers on the same codebase should outweigh the initial merging cost. > > Your projects have the advantage that they are relatively young and the > momentum required for a merge will be much less than will be required in > a year or two. > > Aaron, > Your licence is GPL? Would you consider changing to LGPL? Mapbuilder > would have a problem incorporating your library because we are a LGPL > library which means we wouldn't be able to use your codebase. > > Richard Greenwood wrote: > > On 7/25/06, Aaron Koning wrote: > > > >> Hi Richard, > >> > >> Its good to hear from you again. I am mostly interested in porting > >> GCTP to > >> JavaScript. I have not had much use for datum conversions on the client > >> side, but I'd be interested to hear from anyone who has. Right now the > >> GCTP-JS port has the three most important projections for my region > >> (Albers, > >> Lambert, UTM) and it works very well, so I am hesitant to get involved > >> with > >> recreating this functionality. In addition, I believe that the GCTP > >> can be > >> ported much quicker than Proj4 since it has less than half the files of > >> Proj4 and since many of the GCTP files contain only a few lines that > >> need to > >> be converted. Perhaps there are more compelling reasons to redirect > >> efforts? > >> > >> Aaron > > > > > > No, I have no terribly compelling arguments for combining the projects > > at this time, but let's keep in touch. The Mapbuilder Proj.js code > > does have the GCTP Polar Stereographic projection converted, which may > > be of interest to you. > > > > Top of my projection list is the Mercator (not transverse Mercator) > > because it is used by Google and everybody is keen on Google. If you > > get to it before I do, would you drop me a line? > > > > I trust that you would not mind if I incorporated projections that you > > have port into my work? > > > > And do you know if GCTP is open source? I know Cameron Shorter was > > wondering about this recently. > > > > Rich > > > > > -- > Cameron Shorter > http://cameron.shorter.net > -- +-------------------------------------------- | Aaron Koning | Information Technologist | Prince George, BC, Canada. +-------------------------------------------- | http://datashare.gis.unbc.ca/fist/ | http://datashare.gis.unbc.ca/gctp-js/ +-------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/mail_webmap-discuss/attachments/20060730/ba107902/attachment.html