[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Seeking more direction from the uDIG community
|
Hi, I think CQL could be a friendly solution to make filter. The user could
write CQL predicate and uDig would use CQLParser to make the filter.
Have a look inside
http://docs.codehaus.org/display/GEOTOOLS/CQL+Parser
It could be part of solution.
regards
--
Mauricio Pazos
www.axios.es
On Wednesday 10 January 2007 22:18, Jesse Eichar wrote:
> This are very simple snippets. Once you look at them consider a
> MathExpression that calculates a value based on two attributes in a
> Feature:
>
> FilterFactory fac=FilterFactoryFinder.createFilterFactory();
>
> MathExpression mathExpr = fac.createMathExpression
> (ExpressionType.MATH_ADD);
> mathExpr.addLeftValue(fac.createAttributeExpression("att1"));
> mathExpr.addRightValue(fac.createAttributeExpression("att2"));
>
> CompareFilter compare = fac.createCompareFilter
> (FilterType.COMPARE_GREATER_THAN_EQUAL);
> compare.addLeftValue(mathExpr);
> compare.addRightValue(fac.createLiteralExpression(200));
>
>
>
> this example returns the feature if the sum of the attributes: att1
> and att2 is greater than or equal to 200.
>
> Jesse
>
> On 10-Jan-07, at 1:06 PM, Jesse Eichar wrote:
> > You are right that you can write queries that reference multiple
> > table at the same time. You have to write a detailed query for one
> > then do more queries based on that result. If you are looking at a
> > very complicated query then it is probably easier to make use of
> > the DB connection.
> >
> > For snippets on how to make Filters (the real power of a Query)
> > take a look at:
> >
> > http://docs.codehaus.org/display/GEOTOOLS/Snippets
> >
> > and look at the examples under the Filters heading.
> >
> > FYI. A query currently permits you to restrict the Attributes
> > retrieved from the table. SO if you are only interested in the
> > geometry or just the a couple of attributes it allows you to
> > restrict the features retrieved to only have those attributes.
> > (Save bandwidth).
> >
> > Jesse
> >
> > On 10-Jan-07, at 12:58 PM, Murray Richardson wrote:
> >> Thanks Jesse,
> >>
> >> Are there some coded examples on working with geotools? I don't
> >> see exactly how I can execute queries on multiple layers using
> >> QUERY and DATASTORE objects, although it's obviously possible from
> >> what you say.
> >>
> >> I think getting the database connection and generating custom SQL
> >> would be most flexible, even if it's not very slick. Also, in
> >> some cases I work with massive point files (posted a question
> >> about this a couple days ago) and I think it would be better to
> >> have spatial queries done on the server side. Similarly with time-
> >> series data it is often necessary to add temporary columns,
> >> iterate through the table several times and perform some
> >> calculations. Given this I would happily take you up on some
> >> details to go this route, if it isn't too much trouble for you...
> >>
> >> On the other hand, I may find this gets over my head fairly
> >> quickly and just have to implement these ideas without using uDIG
> >> for anything accept for viewing outputs!
> >>
> >> Murray
> >>
> >> Jesse Eichar wrote:
> >>> Right now a layer is a table in postGIS. Using the QUERY object
> >>> and a FeatureStore from the layer, it is possible to obtain
> >>> features from that table with the attributes you specify in the
> >>> query. The types of queries that can be created can be very
> >>> complex and can use many spatial operations. However the
> >>> datastore is primarily an Access/Query object that allows access
> >>> to the features in the PostGIS (or more generally the data source
> >>> what ever it may be) for viewing or direct editing. There isn't
> >>> an API for adding columns but there is one for creating new tables.
> >>> There is not yet an OPERATIONS API yet in Geotools, which is
> >>> likely what you are looking for. There are currently 2 ways to
> >>> do what you require that I can think of:
> >>> 1. In order to satisfy your requirements on the server side you
> >>> would have to get the Database connection and generate custom SQL
> >>> queries and execute them.
> >>> 2. You can fetch the features to the client using the Datastore
> >>> API and its queries, and do the calculations on the client and
> >>> write the result back to the PostGIS, also using the Datastore API.
> >>> As far as I can tell you can do most of these steps using the
> >>> second method. As I said Queries (and Filters) can do some very
> >>> complicated work including GeoSpatial and other "normal"
> >>> queries. Intersection, differences, etc... can all be done
> >>> server side using Filter and Query.
> >>> If you want more details on any of these steps let me know,
> >>> Jesse
> >>>
> >>> On 10-Jan-07, at 9:32 AM, Murray Richardson wrote:
> >>>> Hello Community,
> >>>>
> >>>> Thanks for previous help you've offered. I could use a bit more
> >>>> direction if possible to determine whether I should carry on
> >>>> with uDIG for a small project I am working on. I'm finding the
> >>>> uDIG development learning curve to be a bit steep so far.
> >>>>
> >>>> I've spent the last few days looking at uDIG (e.g. plugin
> >>>> tutorial and all the other online resources) and I am trying to
> >>>> figure out the simplest way to make use of powerful postgreSQL/
> >>>> postGIS capabilities. Previously I was concerned with
> >>>> constructing spatial queries on massive point data sets. These
> >>>> processes are easy if I use a standard postgreSQL interface like
> >>>> psql or pgAdmin. It seems like it should be a fairly simple
> >>>> task to construct plugins within uDIG that make use of these and
> >>>> other RDBMS capabilities through JDBC (if they don't already
> >>>> exist somewhere). I read an entry on Cory Horner's community
> >>>> page about extending uDIG functionality to incorporate better
> >>>> RDBMS capabilities. I am most definitely interested in this
> >>>> because I am always faced with problems where this type of
> >>>> capability would be an asset.
> >>>>
> >>>> To give you an idea of the type of functionality I am interested
> >>>> in, considering the following two examples:
> >>>>
> >>>> (1) I am constantly using GIS and RDBMS capabilities separately
> >>>> (loosely coupled fashion)for information management in the field
> >>>> of hydrology. For example - I need to summarize the joint
> >>>> probability distribution of land-use and soil types to determine
> >>>> an average (lumped) runoff coefficient for nested watersheds
> >>>> (since runoff is a function of landuse and underlying soil
> >>>> properties, among other things). I do this by exporting the
> >>>> polygon intersection of a soils layer, land-use layer and
> >>>> watershed layer to a RDBMS. Then I use lookup tables to
> >>>> determine coefficients for individual landuse-soil combinations
> >>>> and use an aggregate query to determine the mean value for each
> >>>> watershed. It is nice to then join the mean value back to the
> >>>> watershed layer and display this in a map. I also use the RDBMS
> >>>> to do reporting of the individual intersected polygons by
> >>>> watershed. This type of analysis and reporting is standard in
> >>>> flood risk assessment and could be very easily streamlined with
> >>>> a tool like uDIG and postgreSQL.
> >>>>
> >>>> (2) Storing and accessing spatial-temporal hydrology data is an
> >>>> emerging area of interest (consider the ESRI ArcHydro framework
> >>>> if you're familiar with it) and an interesting direction for
> >>>> Open Source GIS. For example, I would like to be able to store
> >>>> decades worth of hourly streamflow data for numerous gauged
> >>>> weirs within a postgreSQL DB and have this linked to a uDIG
> >>>> application that allows me to extract the streamflow data by
> >>>> (e.g.) clicking on a point station and entering a date. The
> >>>> query result could be just exported to a text file for now. This
> >>>> capability would open the door to a whole range of interesting
> >>>> spatial-temporal hydrology applications (e.g. recession
> >>>> analysis, climate and streamflow data interpolation, hydrologic
> >>>> model parameterization).
> >>>>
> >>>> Based on these two particular examples, could someone perhaps
> >>>> direct me on how to proceed to develop a very simple proof of
> >>>> concept for enhanced RDBMS capabilities within a GIS
> >>>> environment? Consider example 1 for instance - can I create a
> >>>> uDIG operation that is accessed by right-clicking on 3
> >>>> highlighted layers (like the difference operation that is
> >>>> available when two layers are selected). For my purposes I
> >>>> would like these to be postGIS layers. The operation could then
> >>>> execute the postGIS intersection procedure, the attribute join
> >>>> and the aggregate function all within the postgreSQL service,
> >>>> and then map the results back to the watershed layer for display
> >>>> in uDIG?
> >>>>
> >>>> I know this is a fairly specific question, but what it boils
> >>>> down to is, how do I access postGIS spatial operations as well
> >>>> as general postgreSQL RDBMS functionality and non-spatial tables
> >>>> within the uDIG environment?
> >>>>
> >>>> Thanks in advance for any help. This project is for a small
> >>>> Open Source/Open Access Student Experience program grant I am
> >>>> working on through University of Toronto that involves
> >>>> developing a proof-of-concept idea and some educational
> >>>> tutorials using postgreSQL/postGIS. I would like to eventually
> >>>> be able to post the results on my own uDIG community page if
> >>>> things go well. I think this type of work could help open up
> >>>> uDIG capabilites to the slightly less technical users like
> >>>> myself (e.g. GIS and basic programming/RDBMS skills experience,
> >>>> but still need lots of examples and explicit documentation to
> >>>> follow!).
> >>>>
> >>>> Look forward to hearing back from someone - hope it's not too
> >>>> much to ask over a mailing list!
> >>>>
> >>>> --Murray Richardson, M.Sc
> >>>> PhD Candidate
> >>>> University of Toronto
> >>>> murray.richardson@xxxxxxxxxxx
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> User-friendly Desktop Internet GIS (uDig)
> >>>> http://udig.refractions.net
> >>>> http://lists.refractions.net/mailman/listinfo/udig-devel
> >>>
> >>> _______________________________________________
> >>> User-friendly Desktop Internet GIS (uDig)
> >>> http://udig.refractions.net
> >>> http://lists.refractions.net/mailman/listinfo/udig-devel
> >>> --No virus found in this incoming message.
> >>> Checked by AVG Free Edition.
> >>> Version: 7.5.432 / Virus Database: 268.16.8/621 - Release Date:
> >>> 1/9/2007 1:37 PM
> >>
> >> _______________________________________________
> >> User-friendly Desktop Internet GIS (uDig)
> >> http://udig.refractions.net
> >> http://lists.refractions.net/mailman/listinfo/udig-devel
> >
> > _______________________________________________
> > User-friendly Desktop Internet GIS (uDig)
> > http://udig.refractions.net
> > http://lists.refractions.net/mailman/listinfo/udig-devel
