[Geotools-gt2-users] State of WPS module
As far as I can tell, said module is empty (well, the pom.xml is there): could someone shed some light on its state ? Regards, Luca Morandini www.lucamorandini.it - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
[Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
Dear colleagues, Looking at geotools GML code its not clear to me how it uses the srid and userData fields of the com.vividsolutions.jts.geom.Geometry class. What are these fields set to when a JTS Geometry is stored after being mapped from a GML geomtery? What are these fields set to when a JTS Geometry is read back before being converted to a GML Geometry? Specifically: Does the persistent JTS Geomtery object's always have srid defined? Is there a userObject always specified to stored the srsName? Does the srid and srsName refer to the CRS used by GML representation? Why do we need need to store both srid and srsName? Thanks for any guidance. -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
[Geotools-gt2-users] CoordinateReferenceSystem and DefaultGeographicCRS question
I am unclear on how DefaultGeographicCRS implementation of CoordinateReferenceSystem works and whether what I am observing is correct behavior. I have the following code: String srsName = urn:ogc:def:crs:EPSG:6.0:4277; CoordinateReferenceSystem crs = CRS.decode(srsName); String srsName1 = crs.getName().toString(); What I was expecting is that srsName1 would be the same as srsName that was used to create the CoordinateReferenceSystem. What I am observing is that srsName1 is EPSG:OSGB 1936. Why is the behavior the way it is? Where in a CoordinateReferenceSystem instance can I find the name that was used to decode the CoordinateReferenceSystem? TIA for explaining this. -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] CoordinateReferenceSystem and DefaultGeographicCRS question
Farrukh Najmi a écrit : I have the following code: String srsName = urn:ogc:def:crs:EPSG:6.0:4277; CoordinateReferenceSystem crs = CRS.decode(srsName); String srsName1 = crs.getName().toString(); What I was expecting is that srsName1 would be the same as srsName that was used to create the CoordinateReferenceSystem. What I am observing is that srsName1 is EPSG:OSGB 1936. In the EPSG database, CRS name are often human-readable like NTF (Paris) / Lambert zone II. What you are looking for is rather stored as the CRS identifier. See CoordinateReferenceSystem.getIdentifiers(). In the particular case of GeoTools implementation, you can use the following convenience method (the same CRS can have different identifier for different authorities, e.g. a different identifier for the EPSG database than ESRI). crs.getIdentifier(Citations.EPSG).getCode(); Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
Farrukh Najmi wrote: Dear colleagues, Looking at geotools GML code its not clear to me how it uses the srid and userData fields of the com.vividsolutions.jts.geom.Geometry class. Which GML code did are you looking at specifically? - SAX parser? I think it sets the srsName to the userData object - DOM parser? - XDO parser? - XSD-XML parser? In general I don't know what these parsers do for a JTS Geometry object; because the CRS information is stored at the Feature level in GeoTools right now (there is no set convention for how to handle JTS Geometry srid name and userData object; because that convention would be for a specific application.) What are these fields set to when a JTS Geometry is stored after being mapped from a GML geomtery? GML Geometry comes back as a JTS Geometry with the correct coordinates What are these fields set to when a JTS Geometry is read back before being converted to a GML Geometry? Specifically: Does the persistent JTS Geomtery object's always have srid defined? no it does not. Is there a userObject always specified to stored the srsName? no it does not. Does the srid and srsName refer to the CRS used by GML representation? The GML specification only talks about srsName; we have chosen to convert this information into a CoordinateReferenceSystem and hold it as part of the FeatureType information. Why do we need need to store both srid and srsName? We don't need to store either. Thanks for any guidance. I am sorry this is such a muddle for your; JTS Geometry is defined by the Simple Feature for SQL specification and does not really line up with GML in any way (literally they are a different model at a very technical level; JTS has LineStrings, GML has Curves made up of LineStrings). We are faking this mapping for you because JTS is available now and works - some information (like GML srsName) is lost along the way. Now if you would like the srsName to be saved as the userData object by each and every parser; that may be a good idea - and we can take it up with the developers list. Jody - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
Jody Garnett wrote: Farrukh Najmi wrote: Dear colleagues, Looking at geotools GML code its not clear to me how it uses the srid and userData fields of the com.vividsolutions.jts.geom.Geometry class. Which GML code did are you looking at specifically? - SAX parser? I think it sets the srsName to the userData object - DOM parser? - XDO parser? - XSD-XML parser? I was looking at trunk/modules/library/main/src/main/java/org/geotools/gml/SubHandlerPolygon.java and other classes there. In general I don't know what these parsers do for a JTS Geometry object; because the CRS information is stored at the Feature level in GeoTools right now (there is no set convention for how to handle JTS Geometry srid name and userData object; because that convention would be for a specific application.) In other words its left up to the application? What are these fields set to when a JTS Geometry is stored after being mapped from a GML geomtery? GML Geometry comes back as a JTS Geometry with the correct coordinates This is where my mental block is. What CRS are these correct coordinates in? I am assuming in the CRS for the Feature in question. Based on a past thread I recall you saying that geometries are stored in a normalized CRS (ie. all stored geometries are in the same CRS.). If so what is that CRS and where in the code is the conversion between Feature specific CRS and normalized CRS? What are these fields set to when a JTS Geometry is read back before being converted to a GML Geometry? Specifically: Does the persistent JTS Geomtery object's always have srid defined? no it does not. Is there a userObject always specified to stored the srsName? no it does not. Does the srid and srsName refer to the CRS used by GML representation? The GML specification only talks about srsName; we have chosen to convert this information into a CoordinateReferenceSystem and hold it as part of the FeatureType information. Why do we need need to store both srid and srsName? We don't need to store either. Thanks for any guidance. I am sorry this is such a muddle for your; JTS Geometry is defined by the Simple Feature for SQL specification and does not really line up with GML in any way (literally they are a different model at a very technical level; JTS has LineStrings, GML has Curves made up of LineStrings). We are faking this mapping for you because JTS is available now and works - some information (like GML srsName) is lost along the way. My apologies for asking some pretty low level questions and with a relatively limited knowledge of the code base. Now if you would like the srsName to be saved as the userData object by each and every parser; that may be a good idea - and we can take it up with the developers list. First we need to determine if that is necessary. I though it was necessary because I cannot see how else one could store geometry instances in a normalized CRS and read it back in an app specific (or is that feature-type specific?) CRS. I suspect I have a fundemental lack of undertstanding still of how geometries are stored and read back. Just to be clear. I am (most likely incorrectly) assuming that all geometries for all features are stored in a normalize CRS and that when they are read as part of reading of features they are converted to an app-specific CRS. A different possibility could be that geometries are stored in app-specific CRS and it is up to the app to convert it to whatever app-specific crs when needed. This possibility seems to be questionable because it prevents the ability to do global spatial queries across data from different feature types. It would go a long way if you could clear up some of these fundamental understanding issues perhaps by way of a simple example. I am very aware and grateful for the time it takes for you and other dev team members to clear up these understanding issues. Once my understanding is clear I could write some content for consideration in the manual. Thanks again. -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
Farrukh Najmi wrote: I was looking at trunk/modules/library/main/src/main/java/org/geotools/gml/SubHandlerPolygon.java and other classes there. I think that is the SAX parser; it does GML2 as I understand it. In general I don't know what these parsers do for a JTS Geometry object; because the CRS information is stored at the Feature level in GeoTools right now (there is no set convention for how to handle JTS Geometry srid name and userData object; because that convention would be for a specific application.) In other words its left up to the application? correct What are these fields set to when a JTS Geometry is stored after being mapped from a GML geomtery? GML Geometry comes back as a JTS Geometry with the correct coordinates This is where my mental block is. What CRS are these correct coordinates in? I am assuming in the CRS for the Feature in question. Yes. The JTS Geometry (and its coordiantes) don't care; it is the Feature that cares about the CRS. Based on a past thread I recall you saying that geometries are stored in a normalized CRS (ie. all stored geometries are in the same CRS.). No they are not; what is stored is the data as it was read in. And the FeatureType stores the CRS. Those two bits of information is enough for you to do your work. You cannot use a Geometry on its own. If so what is that CRS and where in the code is the conversion between Feature specific CRS and normalized CRS? Let me try writing a code example from memory FeatureType schema = feature.getFeatureType(); Geometry geometry = (Geometry) feature.getDefaultGeometry(); CoordianteReferenceSystem crs = schema .getDefaultGeometry().getCoordianteReferenceSystem(); My apologies for asking some pretty low level questions and with a relatively limited knowledge of the code base. Heh; so lets focus on getting you going; no more appologizes on either side - we need to make it work for you. Now if you would like the srsName to be saved as the userData object by each and every parser; that may be a good idea - and we can take it up with the developers list. First we need to determine if that is necessary. I though it was necessary because I cannot see how else one could store geometry instances in a normalized CRS and read it back in an app specific (or is that feature-type specific?) CRS. I suspect I have a fundemental lack of undertstanding still of how geometries are stored and read back. I hope the above clarification helps; the geometries are stored as is; the data about what they mean (the CRS) is stored in the FeatureType. Just to be clear. I am (most likely incorrectly) assuming that all geometries for all features are stored in a normalize CRS and that when they are read as part of reading of features they are converted to an app-specific CRS. that is the wrong assumption. A different possibility could be that geometries are stored in app-specific CRS and it is up to the app to convert it to whatever app-specific crs when needed. That is close but also not the right assumption. Geometries are stored in a CRS according to their data format; the application can transform from this representation to what the application is using when needed. This possibility seems to be questionable because it prevents the ability to do global spatial queries across data from different feature types. It does not; the application knows enough to modify its request into the data CRS and make the query. Can you download the following application that I am working on and give it a go; http://udig.refractions.net/ You can load up shapefiles and WFS from different locations with different CoordinateReferenceSystems and see how it works. It would go a long way if you could clear up some of these fundamental understanding issues perhaps by way of a simple example. I am very aware and grateful for the time it takes for you and other dev team members to clear up these understanding issues. Once my understanding is clear I could write some content for consideration in the manual. Not to worry; we need these conversations in order to get our user guide in order. Jody - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
[Geotools-gt2-users] epsg in postgres 8.3.1
Hey all, I've upgrade my postgresql version to 8.3.1 (from 8.2.x), and loaded it with the EPGS data, for using in geotools. While this used to work with version 8.2, this doesn't with the new version. This is the error i receive: Caused by: org.postgresql.util.PSQLException: ERROR: operator does not exist: integer = character varying at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:351) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:255) at org.geotools.referencing.factory.epsg.DirectEpsgFactory.createCoordinateReferenceSystem(DirectEpsgFactory.java:1847) Looks like Geotools is comparing a string with an integer. The string is my case '4326', and the integer is the same. This is the error in my postgres logfile: STATEMENT: SELECT COORD_REF_SYS_CODE, COORD_REF_SYS_NAME, AREA_OF_USE_CODE, CRS_SCOPE, REMARKS, COORD_REF_SYS_KIND, COORD_SYS_CODE, DATUM_CODE, SOURCE_GEOGCRS_CODE, PROJECTION_CONV_CODE, CMPD_HORIZCRS_CODE, CMPD_VERTCRS_CODE FROM epsg_coordinatereferencesystem WHERE COORD_REF_SYS_CODE = $1 ERROR: operator does not exist: integer = character varying at character 276 HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. Do you guys have any clues or solutions? grtz and thanks! Wouter Schaubroeck - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] State of WPS module
Graham Davis is working on it; as an unsupported module it is not really ready for users yet; stay tuned to the weekly IRC meetings for updates. If you want to explore some of the ideas today start writing your own implementations of Process; see unsupported/process for details. The idea is that any implementation you right would be made available via a GeoServer community module. And hopefully the 52N WPS if I can manage to talk to their developers again. Cheers, Jody Luca Morandini wrote: As far as I can tell, said module is empty (well, the pom.xml is there): could someone shed some light on its state ? Regards, Luca Morandini www.lucamorandini.it - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] epsg in postgres 8.3.1
2008/5/28 Wouter Schaubroeck [EMAIL PROTECTED]: Hey all, I've upgrade my postgresql version to 8.3.1 (from 8.2.x), and loaded it with the EPGS data, for using in geotools. While this used to work with version 8.2, this doesn't with the new version. This is the error i receive: Caused by: org.postgresql.util.PSQLException: ERROR: operator does not exist: integer = character varying at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:351) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:255) at org.geotools.referencing.factory.epsg.DirectEpsgFactory.createCoordinateReferenceSystem(DirectEpsgFactory.java:1847) Looks like Geotools is comparing a string with an integer. The string is my case '4326', and the integer is the same. This is the error in my postgres logfile: STATEMENT: SELECT COORD_REF_SYS_CODE, COORD_REF_SYS_NAME, AREA_OF_USE_CODE, CRS_SCOPE, REMARKS, COORD_REF_SYS_KIND, COORD_SYS_CODE, DATUM_CODE, SOURCE_GEOGCRS_CODE, PROJECTION_CONV_CODE, CMPD_HORIZCRS_CODE, CMPD_VERTCRS_CODE FROM epsg_coordinatereferencesystem WHERE COORD_REF_SYS_CODE = $1 ERROR: operator does not exist: integer = character varying at character 276 HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. Do you guys have any clues or solutions? grtz and thanks! Wouter Schaubroeck - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users From http://www.postgresql.org/docs/8.3/static/release-8-3.html: Previously, if a non-character value was supplied to an operator or function that requires text input, it was automatically cast to text, for most (though not all) built-in data types. This no longer happens: an explicit cast to text is now required for all non-character-string types. It looks like we need to update some of our queries. You may be able to work around this for the moment by redefining the integer - text cast as implicit. See http://www.postgresql.org/docs/8.3/interactive/sql-createcast.html. -- Mark Leslie Geospatial Software Architect LISAsoft http://www.lisasoft.com/LISAsoft/SupportedProducts.html - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] epsg in postgres 8.3.1
Mark Leslie wrote: Previously, if a non-character value was supplied to an operator or function that requires text input, it was automatically cast to text, for most (though not all) built-in data types. This no longer happens: an explicit cast to text is now required for all non-character-string types. It looks like we need to update some of our queries. You may be able to work around this for the moment by redefining the integer - text cast as implicit. See http://www.postgresql.org/docs/8.3/interactive/sql-createcast.html. Agreed; the class used is here: The FactoryUsingAnsiSQL should be used; I don't think we need a Postgres specific subclass; but you can check out how FactoryUsingOracleSQL and FactoryUsingHSQL does things. The Idea here is a one two punch: - punch 1: ThreadedPostgresSQLEpshFactory keeps a pool of connections to your database for scalability; and keeps a cache of results around - punch 2: A pool of FactoryUsingSQL subclass grab the definitions from the database as needed to keep ThreadedPostgresSQLFactory happy Cheers, Jody - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
Jody Garnett wrote: Farrukh Najmi wrote: I was looking at trunk/modules/library/main/src/main/java/org/geotools/gml/SubHandlerPolygon.java and other classes there. I think that is the SAX parser; it does GML2 as I understand it. In general I don't know what these parsers do for a JTS Geometry object; because the CRS information is stored at the Feature level in GeoTools right now (there is no set convention for how to handle JTS Geometry srid name and userData object; because that convention would be for a specific application.) In other words its left up to the application? correct What are these fields set to when a JTS Geometry is stored after being mapped from a GML geomtery? GML Geometry comes back as a JTS Geometry with the correct coordinates This is where my mental block is. What CRS are these correct coordinates in? I am assuming in the CRS for the Feature in question. Yes. The JTS Geometry (and its coordiantes) don't care; it is the Feature that cares about the CRS. Based on a past thread I recall you saying that geometries are stored in a normalized CRS (ie. all stored geometries are in the same CRS.). No they are not; what is stored is the data as it was read in. And the FeatureType stores the CRS. Those two bits of information is enough for you to do your work. You cannot use a Geometry on its own. If so what is that CRS and where in the code is the conversion between Feature specific CRS and normalized CRS? Let me try writing a code example from memory FeatureType schema = feature.getFeatureType(); Geometry geometry = (Geometry) feature.getDefaultGeometry(); CoordianteReferenceSystem crs = schema .getDefaultGeometry().getCoordianteReferenceSystem(); My apologies for asking some pretty low level questions and with a relatively limited knowledge of the code base. Heh; so lets focus on getting you going; no more appologizes on either side - we need to make it work for you. Now if you would like the srsName to be saved as the userData object by each and every parser; that may be a good idea - and we can take it up with the developers list. First we need to determine if that is necessary. I though it was necessary because I cannot see how else one could store geometry instances in a normalized CRS and read it back in an app specific (or is that feature-type specific?) CRS. I suspect I have a fundemental lack of undertstanding still of how geometries are stored and read back. I hope the above clarification helps; the geometries are stored as is; the data about what they mean (the CRS) is stored in the FeatureType. Just to be clear. I am (most likely incorrectly) assuming that all geometries for all features are stored in a normalize CRS and that when they are read as part of reading of features they are converted to an app-specific CRS. that is the wrong assumption. A different possibility could be that geometries are stored in app-specific CRS and it is up to the app to convert it to whatever app-specific crs when needed. That is close but also not the right assumption. I am almost getting it now thanks to your help :-) Geometries are stored in a CRS according to their data format; Can you give an example of what you mean by above? What is an example of a data format and how does a data format specify its CRS. the application can transform from this representation to what the application is using when needed. Rest of your explanation is very clear. This possibility seems to be questionable because it prevents the ability to do global spatial queries across data from different feature types. It does not; the application knows enough to modify its request into the data CRS and make the query. Can you download the following application that I am working on and give it a go; http://udig.refractions.net/ You can load up shapefiles and WFS from different locations with different CoordinateReferenceSystems and see how it works. This (udig) was a great visual example to make your point that features from different sources using different CRS can all be used in the same map. How does udig determine what CRS to use for each feature set loaded from a shape file? Where in the code is that determination done? Thanks again. It would go a long way if you could clear up some of these fundamental understanding issues perhaps by way of a simple example. I am very aware and grateful for the time it takes for you and other dev team members to clear up these understanding issues. Once my understanding is clear I could write some content for consideration in the manual. Not to worry; we need these conversations in order to get our user guide in order. Jody -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com - This SF.net email is sponsored by: Microsoft Defy all challenges.
