[OSGeo-Discuss] Geomajas Geometry Project
Hi everyone, for the Geomajas project, we are looking into separating the Geometry functionality into an independent project. In other words, I am talking about a Geometry project for the Web. This code would be written in Java for GWT and thus be available on Java backends as well as client environments (we intend to add a JavaScript wrapper around the GWT code). Now the problem that I'm facing here, is which model to follow On one hand there is the Simple Feature Specification which is clearly an Object Oriented model with the advantage that it is well known but is also more difficult to implement the JavaScript wrapper around. On the other hand we could follow a service based model (more like SFS for SQL) which is easier to get up and running, easier to create a JavaScript wrapper for and easier to translate into web services. As it's difficult for us to chose and as it's a pretty crucial decision for the future of the Geomajas project, I as wondering how you guys feel about this. Kind regards, Pieter De Graef ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Geomajas Geometry Project
Hi Pieter, this may not directly answer your question, but you could use the existing JSTS library: https://github.com/bjornharrtell/jsts - this is basically a port of the Java Topology Suite. The advantage would be that you don't need a JS wrapper - you could use JTS on the server and JSTS on the client. And if things you need are missing in JSTS, you could contribute them. Just my 2¢ - sorry if they are inappropriate. Andreas. On Wed, Jul 13, 2011 at 10:36 AM, Pieter De Graef pied...@gmail.com wrote: Hi everyone, for the Geomajas project, we are looking into separating the Geometry functionality into an independent project. In other words, I am talking about a Geometry project for the Web. This code would be written in Java for GWT and thus be available on Java backends as well as client environments (we intend to add a JavaScript wrapper around the GWT code). Now the problem that I'm facing here, is which model to follow On one hand there is the Simple Feature Specification which is clearly an Object Oriented model with the advantage that it is well known but is also more difficult to implement the JavaScript wrapper around. On the other hand we could follow a service based model (more like SFS for SQL) which is easier to get up and running, easier to create a JavaScript wrapper for and easier to translate into web services. As it's difficult for us to chose and as it's a pretty crucial decision for the future of the Geomajas project, I as wondering how you guys feel about this. Kind regards, Pieter De Graef ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Geomajas Geometry Project
Thanks for the tip. Basically I'm looking to make advantage of the GWT by having a single API that I can use on both client and server. We could indeed have 2 implementations (one using JTS one using JSTS), but what I'm mainly looking for, is what model should the API ideally follow. 2011/7/13 Andreas Hocevar ahoce...@opengeo.org Hi Pieter, this may not directly answer your question, but you could use the existing JSTS library: https://github.com/bjornharrtell/jsts - this is basically a port of the Java Topology Suite. The advantage would be that you don't need a JS wrapper - you could use JTS on the server and JSTS on the client. And if things you need are missing in JSTS, you could contribute them. Just my 2¢ - sorry if they are inappropriate. Andreas. On Wed, Jul 13, 2011 at 10:36 AM, Pieter De Graef pied...@gmail.com wrote: Hi everyone, for the Geomajas project, we are looking into separating the Geometry functionality into an independent project. In other words, I am talking about a Geometry project for the Web. This code would be written in Java for GWT and thus be available on Java backends as well as client environments (we intend to add a JavaScript wrapper around the GWT code). Now the problem that I'm facing here, is which model to follow On one hand there is the Simple Feature Specification which is clearly an Object Oriented model with the advantage that it is well known but is also more difficult to implement the JavaScript wrapper around. On the other hand we could follow a service based model (more like SFS for SQL) which is easier to get up and running, easier to create a JavaScript wrapper for and easier to translate into web services. As it's difficult for us to chose and as it's a pretty crucial decision for the future of the Geomajas project, I as wondering how you guys feel about this. Kind regards, Pieter De Graef ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Geomajas Geometry Project
There is a third model; the ISO19107 model that deals with a few more things; it is however object oriented in nature -- Jody Garnett On Wednesday, 13 July 2011 at 6:36 PM, Pieter De Graef wrote: Hi everyone, for the Geomajas project, we are looking into separating the Geometry functionality into an independent project. In other words, I am talking about a Geometry project for the Web. This code would be written in Java for GWT and thus be available on Java backends as well as client environments (we intend to add a JavaScript wrapper around the GWT code). Now the problem that I'm facing here, is which model to follow On one hand there is the Simple Feature Specification which is clearly an Object Oriented model with the advantage that it is well known but is also more difficult to implement the JavaScript wrapper around. On the other hand we could follow a service based model (more like SFS for SQL) which is easier to get up and running, easier to create a JavaScript wrapper for and easier to translate into web services. As it's difficult for us to chose and as it's a pretty crucial decision for the future of the Geomajas project, I as wondering how you guys feel about this. Kind regards, Pieter De Graef ___ Discuss mailing list Discuss@lists.osgeo.org (mailto:Discuss@lists.osgeo.org) http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Geomajas Geometry Project
Hi Jody, that's the GeoApi specification no? At first we would be using it on the GWT client we where hoping to also include curves, as those can be directly drawn in SVG/VML. At a later stage we could switch the backend to make use of it as well. Jody, you have been looking into creating you own Geometry library for some time now I understand. How would you approach this? I was hoping to start with something simple, that can grow at it's own pace. Important for me is that I can use the same objects on both client and server (meaning Java with some GWT restrictions). I am also afraid to be re-inventing the wheel, but using 2 different libraries on client and server would be a shame when using GWT... 2011/7/13 Jody Garnett jody.garn...@gmail.com There is a third model; the ISO19107 model that deals with a few more things; it is however object oriented in nature -- Jody Garnett On Wednesday, 13 July 2011 at 6:36 PM, Pieter De Graef wrote: Hi everyone, for the Geomajas project, we are looking into separating the Geometry functionality into an independent project. In other words, I am talking about a Geometry project for the Web. This code would be written in Java for GWT and thus be available on Java backends as well as client environments (we intend to add a JavaScript wrapper around the GWT code). Now the problem that I'm facing here, is which model to follow On one hand there is the Simple Feature Specification which is clearly an Object Oriented model with the advantage that it is well known but is also more difficult to implement the JavaScript wrapper around. On the other hand we could follow a service based model (more like SFS for SQL) which is easier to get up and running, easier to create a JavaScript wrapper for and easier to translate into web services. As it's difficult for us to chose and as it's a pretty crucial decision for the future of the Geomajas project, I as wondering how you guys feel about this. Kind regards, Pieter De Graef ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Geomajas Geometry Project
On Wed, Jul 13, 2011 at 1:36 AM, Pieter De Graef pied...@gmail.com wrote: On one hand there is the Simple Feature Specification which is clearly an Object Oriented model with the advantage that it is well known but is also more difficult to implement the JavaScript wrapper around. On the other hand we could follow a service based model (more like SFS for SQL) which is easier to get up and running, easier to create a JavaScript wrapper for and easier to translate into web services. As it's difficult for us to chose and as it's a pretty crucial decision for the future of the Geomajas project, I as wondering how you guys feel about this. Pieter, I'm afraid I don't quite grasp what you mean by a service based model. SFS for SQL is presumably Simple Features for SQL, is that right? If so, how is that a different data model than simple features? Without my understanding the distinction you are trying to make it is hard to give helpful advice. But I will say that I feel strongly that in this day and age any geometry model you use in the geospatial field should have a clean mapping onto OGC Simple Features. You might need to extend it or even put off implementing some types but it would be unwise to take a significantly different approach. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Software Developer ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] MapServer 6.0.1, 5.6.7 and 4.10.7 releases with security fixes
The MapServer team announces the release of MapServer versions 6.0.1, 5.6.7 and 4.10.7. No new functionality has been added. 6.0.1 is a maintence release that fixes a few issues including recently discovered security vulnerabilities. The list of fixes since 6.0.0 is included at the end of this message. Versions 5.6.7 and 4.10.7 include fixes for the security vulnerabilities described below plus a few bug fixes that may have occurred since the last official release. See the respective HISTORY.TXT files for additional information. IMPORTANT SECURITY FIXES: - MapServer developers have discovered flaws in the OGC filter support in MapServer. That code is used in support of WFS, WMS-SLD and SOS specifications. All versions may be susceptible to SQL injection under certain circumstances. The extent of the vulnerability depends on the MapServer version, relational database and mapfile configuration being used. All users are ** strongly encouraged ** to upgrade to these latest releases. The 5.6.7 and 4.10.7 releases also address one significant potentially exploitable buffer overflow (6.0 branch is not vulneralble). These fixes do not affect the functionality of MapServer and no changes will be necessary for configurations/applications using the same base branch (e.g. 5.6). Even though we release 6.0.1, 5.6.7 and 4.10.7 today, these security fixes have also been backported to all stable branches (going back to 4.10) in MapServer's Subversion (SVN) source code repository, so if you work from source and would like to patch your local MapServer source tree, the changeset (i.e. patch file) for each stable release can be obtained through the following Trac ticket: - http://trac.osgeo.org/mapserver/ticket/3903 Special thanks to Even Rouault for his work identifying the issues and the subsequent patching and testing he did. Source and binary downloads: The source code is available at: http://mapserver.org/download.html The binary distributions listed in the download page should be updated with binaries for the new 6.0.1 release (and in some cases 5.6.7) in the next few hours, if not already done. We have also submitted security patches to the Ubuntu and Debian supported distributions that are in the process of being reviewed. The MapServer Team Version 6.0.1 (2011-07-12): --- IMPORTANT SECURITY FIXES: - Fixes to prevent SQL injections through OGC filter encoding (in WMS, WFS and SOS), as well as a potential SQL injection in WMS time support. Your system may be vulnerable if it has MapServer with OGC protocols enabled, with layers connecting to an SQL RDBMS backend, either natively or via OGR (#3903) - Applied patch for ticket (symbol writing issues) (#3589) - Fix performance issue with Oracle and scrollable cursors (#3905) - Fix attribute binding for layer styles (#3941) - Added missing fclose() when writing query files (#3943) - Fix double-free in msAddImageSymbol() when filename is a http resource (#3939) - Fix rendering of lines with outlinewidth set if not on first style (#3935) - Added writing of cluster object when saving map. Also improved handling of cluster parsing errors (#3934) - Fix for the cluster processing if the shape bounds doesn't overlap with the given extent (#3913) - OGC Filter: fix segfault when a ows_varname_type or wfs_varname_type is defined but not a gml_varname_type (#3902) - Fix regression of MapServer 6.0.0 when specifying a time range in WMS time requests on a Postgis layer (#3909) - Fixed order of metadata lookup for WMS GML GetFeatureInfo. 'ows' should come last, not first (#3636). - Fixed mssql2008 to return correct geometries with chart layer type (#3894) - Write SYMBOLSET/END tags when saving a symbol file (#3885) - Make java threadtests work again (#3887) - Fix segfault on malformed PropertyIsLike filters (#3888) - Fixed the query handling problem with the Oracle spatial driver (#3878) - Fixed potential crash with AVERAGE resampling and crazy reprojection (#3886) - Fix for the warnings in mapunion.c (#3880) - Fixed the build problem in mapunion.c (#3877) - Union layer: Fixed the crash when styling source layers using attributes (#3870) - Improve rangeset item checking so that Bands=1,2,3 is supported with WCS 1.0 (#3919). - Fix GetMapserverUnitUsingProj() for proj=latlong (#3883) ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Geomajas Geometry Project [SEC=UNCLASSIFIED]
Pieter, I agree with Jody. I'm seeing increasing demand for clients that can utilise vector data constrained by an application schema. Europe is probably most advanced in this work with Inspire. In Australia we have a lot of work currently at research and at implementation stage trying to work with Simple Features 1 (aka Complex Features). Some examples are WaterML 2.0 and GeoSciML. We will also be looking seriously at CSML 3.0. Bruce Bannerman On 13/07/11 10:52 PM, Jody Garnett jody.garn...@gmail.com wrote: It is the ISO 19107 specification; the same one that lurks behind GML Ready to leap out from under a surface and foist trans finite set on an unsuspecting world. It is worth while getting the ISO 19107 document (ie pay for it) as it is much easier to read and follow then learning this information second hand. We had a brief code sprint with deegree (compatible LGPL license) in order to see if multiple project would be interested in attacking the problem. GeoAPI was the first attempt (which has now been released last month), we have a couple of implementations in GeoTools (mostly ports or wrappers of JTS). deegree has an implementation that is closer to the GML constructs etc If you are interested in pursuing this I recommend talking to Tisham who has been more active research. I am afraid I am interested in using a Geometry library and enthusiasm goes as far as setting one up with a good design so that it can be completed successfully. -- Jody Garnett On Wednesday, 13 July 2011 at 9:54 PM, Pieter De Graef wrote: Hi Jody, that's the GeoApi specification no? At first we would be using it on the GWT client we where hoping to also include curves, as those can be directly drawn in SVG/VML. At a later stage we could switch the backend to make use of it as well. Jody, you have been looking into creating you own Geometry library for some time now I understand. How would you approach this? I was hoping to start with something simple, that can grow at it's own pace. Important for me is that I can use the same objects on both client and server (meaning Java with some GWT restrictions). I am also afraid to be re-inventing the wheel, but using 2 different libraries on client and server would be a shame when using GWT... 2011/7/13 Jody Garnett jody.garn...@gmail.com There is a third model; the ISO19107 model that deals with a few more things; it is however object oriented in nature -- Jody Garnett On Wednesday, 13 July 2011 at 6:36 PM, Pieter De Graef wrote: Hi everyone, for the Geomajas project, we are looking into separating the Geometry functionality into an independent project. In other words, I am talking about a Geometry project for the Web. This code would be written in Java for GWT and thus be available on Java backends as well as client environments (we intend to add a JavaScript wrapper around the GWT code). Now the problem that I'm facing here, is which model to follow On one hand there is the Simple Feature Specification which is clearly an Object Oriented model with the advantage that it is well known but is also more difficult to implement the JavaScript wrapper around. On the other hand we could follow a service based model (more like SFS for SQL) which is easier to get up and running, easier to create a JavaScript wrapper for and easier to translate into web services. As it's difficult for us to chose and as it's a pretty crucial decision for the future of the Geomajas project, I as wondering how you guys feel about this. Kind regards, Pieter De Graef ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
