Jeql testing
6 views
Skip to first unread message
Keith
Mar 21, 2008, 6:24:19 PM3/21/08
to JEQL Users
Martin,
I cannot get the ShapefileReader to read a shapefile. I've tried JEQL .
3 and .4 alpha, jre1.5.0_05 is installed. I noticed there are two ways
of opening a ShapefileReader. Do both methods work?
ShapefileReader t1
file: basedir + "roads.shp";
ShapefileReader
file: "C:\temp\keith\city.shp"
table: ttr;
I'm very interested in manipulating the geometry of Shapefiles. Can
Jeql append features to a shapefile? Is there a way to define the
geometry type (polygon, line, point) of a new shapefile?
Also, can I create a stand-alone dbf file instead of a text file? Is
there a dbfwriter? If so, how would I define the field datatype?
string, date, numeric,etc...
The CSVwriter and Textwriter are working for me, I'm on Windows XP,
however the text files created have a Unix end-of-line character.
Keith
I cannot get the ShapefileReader to read a shapefile. I've tried JEQL .
3 and .4 alpha, jre1.5.0_05 is installed. I noticed there are two ways
of opening a ShapefileReader. Do both methods work?
ShapefileReader t1
file: basedir + "roads.shp";
ShapefileReader
file: "C:\temp\keith\city.shp"
table: ttr;
I'm very interested in manipulating the geometry of Shapefiles. Can
Jeql append features to a shapefile? Is there a way to define the
geometry type (polygon, line, point) of a new shapefile?
Also, can I create a stand-alone dbf file instead of a text file? Is
there a dbfwriter? If so, how would I define the field datatype?
string, date, numeric,etc...
The CSVwriter and Textwriter are working for me, I'm on Windows XP,
however the text files created have a Unix end-of-line character.
Keith
Martin Davis
Mar 21, 2008, 6:40:10 PM3/21/08
to jeql-...@googlegroups.com
Hi, Keith.
Cool - an actual user!
I'm surprised the ShapefileReader isn't working for you - I use it all the time. But I will do another direct test of the install that's available for download - possibly something is awry. Can you send me an example of a shapefile that doesn't work?
As for shapefile manipulation, that is definitely a #1 use case for Jeql. So the *theoretical* answer to your questions is yes, yes, yes.
However... one thing which is missing from Jeql right now is the ability to add to or union tables together. I do intend to implement the SQL UNION operator. In the short term, I will create a TableUnion procedure which will do the same thing. That would be the preferred way to add records to a table - although it would be probably be nice to have the equivalent of an INSERT command (although, in absence of true looping this is less useful).
Can you tell me more about your use case?
As for defining the spatial type of a shapefile, this is done implicitly based on the type of the GEOMETRY column that is being written.
I do intent to implent a DBF Reader & Writer - just haven't got there yet.
I'll look into the CSVWriter/TextWriter EOL issue - I think I know what the problem is. I'll post an update when I get a fix.
By the way - are you the same Keith that I emailed a while back, and then haven't had a chance to follow up on? If so - thanks for hanging in there!
Martin
Cool - an actual user!
I'm surprised the ShapefileReader isn't working for you - I use it all the time. But I will do another direct test of the install that's available for download - possibly something is awry. Can you send me an example of a shapefile that doesn't work?
As for shapefile manipulation, that is definitely a #1 use case for Jeql. So the *theoretical* answer to your questions is yes, yes, yes.
However... one thing which is missing from Jeql right now is the ability to add to or union tables together. I do intend to implement the SQL UNION operator. In the short term, I will create a TableUnion procedure which will do the same thing. That would be the preferred way to add records to a table - although it would be probably be nice to have the equivalent of an INSERT command (although, in absence of true looping this is less useful).
Can you tell me more about your use case?
As for defining the spatial type of a shapefile, this is done implicitly based on the type of the GEOMETRY column that is being written.
I do intent to implent a DBF Reader & Writer - just haven't got there yet.
I'll look into the CSVWriter/TextWriter EOL issue - I think I know what the problem is. I'll post an update when I get a fix.
By the way - are you the same Keith that I emailed a while back, and then haven't had a chance to follow up on? If so - thanks for hanging in there!
Martin
Martin Davis
Mar 21, 2008, 6:56:07 PM3/21/08
to jeql-...@googlegroups.com
Oh, and as for the two ways to call ShapefileReader - they are equivalent. Jeql Commands have the concept of a default parameter. In the case of ShapefileReader (and for most other Readers) the default parameter is the table variable which is populated with the read table. The table: parameter is just a synonym for the same thing.
This will all be documented as soon as I can get to it!
By the way, you do need to initialize the table variable you are using. The line "t1 = null;" will do it. I'm contemplating dropping this requirment, or at least replacing it with a declaration stmt. The idea is to prevent typos from creating "phantom variable" errors - but possibly this is overkill. Seems like plenty of other scripting langs get by without this!
M
This will all be documented as soon as I can get to it!
By the way, you do need to initialize the table variable you are using. The line "t1 = null;" will do it. I'm contemplating dropping this requirment, or at least replacing it with a declaration stmt. The idea is to prevent typos from creating "phantom variable" errors - but possibly this is overkill. Seems like plenty of other scripting langs get by without this!
M
Martin Davis
Mar 21, 2008, 7:02:53 PM3/21/08
to jeql-...@googlegroups.com
One more answer (you have many questions - and they're all good!)
The types of the columns in a DBF output from the (soon-to-be-written) DbfWriter are determined by the types of the columns in the source table. Every table in Jeql has a fully-typed schema (and every object has a fixed type - although variables are untyped).
CSV files and Text files of course don't have typed columns when you first read them in - all columns are of String type. You can use the Value.toX() functions to cast String values to the types that you want for them.
M
The types of the columns in a DBF output from the (soon-to-be-written) DbfWriter are determined by the types of the columns in the source table. Every table in Jeql has a fully-typed schema (and every object has a fixed type - although variables are untyped).
CSV files and Text files of course don't have typed columns when you first read them in - all columns are of String type. You can use the Value.toX() functions to cast String values to the types that you want for them.
M
On Fri, Mar 21, 2008 at 3:24 PM, Keith <lewis....@gmail.com> wrote:
Martin,
Keith
Mar 24, 2008, 2:34:52 PM3/24/08
to JEQL Users
Thanks for those quick answers, Martin. I want to use the Geometry
functions but I'm missing something. This is my code adapted from
testGeomAggFunction.jql in the UnitTest folder. Basically, I am
creating 2 polygons from WKT and then I want to get the Centroid of
each polygon. The error message is - NullPointerException.
t1 = select Geom.fromWKT(g) as geom from table (
("POLYGON ((-105.205625 43.474800000000002,-105.20564166699999
43.476666667000003,-105.201883333 43.476677778000003,-105.200538889
43.476672221999998,-105.200516667 43.474883333,-105.205625
43.474800000000002))"),
("POLYGON ((-105.200488889 43.472516667,-105.20560555599999
43.472644443999997,-105.205625 43.474800000000002,-105.200516667
43.474883333,-105.200488889 43.472516667))")
) tbl(g);
t2 = select Geom.centroid(geom) from t1;
print t2;
Keith
On Mar 21, 5:02 pm, "Martin Davis" <mtncl...@gmail.com> wrote:
> One more answer (you have many questions - and they're all good!)
>
> The types of the columns in a DBF output from the (soon-to-be-written)
> DbfWriter are determined by the types of the columns in the source table.
> Every table in Jeql has a fully-typed schema (and every object has a fixed
> type - although variables are untyped).
>
> CSV files and Text files of course don't have typed columns when you first
> read them in - all columns are of String type. You can use the Value.toX()
> functions to cast String values to the types that you want for them.
>
> M
>
functions but I'm missing something. This is my code adapted from
testGeomAggFunction.jql in the UnitTest folder. Basically, I am
creating 2 polygons from WKT and then I want to get the Centroid of
each polygon. The error message is - NullPointerException.
t1 = select Geom.fromWKT(g) as geom from table (
("POLYGON ((-105.205625 43.474800000000002,-105.20564166699999
43.476666667000003,-105.201883333 43.476677778000003,-105.200538889
43.476672221999998,-105.200516667 43.474883333,-105.205625
43.474800000000002))"),
("POLYGON ((-105.200488889 43.472516667,-105.20560555599999
43.472644443999997,-105.205625 43.474800000000002,-105.200516667
43.474883333,-105.200488889 43.472516667))")
) tbl(g);
t2 = select Geom.centroid(geom) from t1;
print t2;
Keith
On Mar 21, 5:02 pm, "Martin Davis" <mtncl...@gmail.com> wrote:
> One more answer (you have many questions - and they're all good!)
>
> The types of the columns in a DBF output from the (soon-to-be-written)
> DbfWriter are determined by the types of the columns in the source table.
> Every table in Jeql has a fully-typed schema (and every object has a fixed
> type - although variables are untyped).
>
> CSV files and Text files of course don't have typed columns when you first
> read them in - all columns are of String type. You can use the Value.toX()
> functions to cast String values to the types that you want for them.
>
> M
>
Keith
Mar 24, 2008, 3:10:15 PM3/24/08
to JEQL Users
Martin,
Initializing the table variable helped and I discovered the field
names are case sensitive. Is everything in Java case-sensitive? I'm
able to manipulate the tabular data now but how can I work with the
Geometry data? The following throws a nullpointerexception.
t1 = null;
ShapefileReader t1
file: "E:\keith\gis_opensource\jeql\jeql\geometry_sample
\t40n70w.shp";
t2 = select Geom.centroid( GEOMETRY ) as geometry from t1 limit 1;
print t2;
Keith
On Mar 21, 4:56 pm, "Martin Davis" <mtncl...@gmail.com> wrote:
> Oh, and as for the two ways to call ShapefileReader - they are equivalent.
> Jeql Commands have the concept of a default parameter. In the case of
> ShapefileReader (and for most other Readers) the default parameter is the
> table variable which is populated with the read table. The table:
> parameter is just a synonym for the same thing.
>
> This will all be documented as soon as I can get to it!
>
> By the way, you do need to initialize the table variable you are using. The
> line "t1 = null;" will do it. I'm contemplating dropping this requirment,
> or at least replacing it with a declaration stmt. The idea is to prevent
> typos from creating "phantom variable" errors - but possibly this is
> overkill. Seems like plenty of other scripting langs get by without this!
>
> M
>
Initializing the table variable helped and I discovered the field
names are case sensitive. Is everything in Java case-sensitive? I'm
able to manipulate the tabular data now but how can I work with the
Geometry data? The following throws a nullpointerexception.
t1 = null;
ShapefileReader t1
file: "E:\keith\gis_opensource\jeql\jeql\geometry_sample
\t40n70w.shp";
t2 = select Geom.centroid( GEOMETRY ) as geometry from t1 limit 1;
print t2;
Keith
On Mar 21, 4:56 pm, "Martin Davis" <mtncl...@gmail.com> wrote:
> Oh, and as for the two ways to call ShapefileReader - they are equivalent.
> Jeql Commands have the concept of a default parameter. In the case of
> ShapefileReader (and for most other Readers) the default parameter is the
> table variable which is populated with the read table. The table:
> parameter is just a synonym for the same thing.
>
> This will all be documented as soon as I can get to it!
>
> By the way, you do need to initialize the table variable you are using. The
> line "t1 = null;" will do it. I'm contemplating dropping this requirment,
> or at least replacing it with a declaration stmt. The idea is to prevent
> typos from creating "phantom variable" errors - but possibly this is
> overkill. Seems like plenty of other scripting langs get by without this!
>
> M
>
> On Fri, Mar 21, 2008 at 3:40 PM, Martin Davis <mtncl...@gmail.com> wrote:
> > Hi, Keith.
>
> > Cool - an actual user!
>
> > I'm surprised the ShapefileReader isn't working for you - I use it all the
> > time. But I will do another direct test of the install that's available for
> > download - possibly something is awry. Can you send me an example of a
> > shapefile that doesn't work?
>
> > As for shapefile manipulation, that is definitely a #1 use case for Jeql.
> > So the *theoretical* answer to your questions is yes, yes, yes.
>
> > However... one thing which is missing from Jeql right now is the ability
> > to add to or union tables together. I do intend to implement the SQL UNION
> > operator. In the short term, I will create a TableUnion procedure which
> > will do the same thing. That would be the preferred way to add records to a
> > table - although it would be probably be nice to have the equivalent of an
> > INSERT command (although, in absence of true looping this is less useful).
>
> > Can you tell me more about your use case?
>
> > As for defining the spatial type of a shapefile, this is done implicitly
> > based on the type of the GEOMETRY column that is being written.
>
> > I do intent to implent a DBF Reader & Writer - just haven't got there yet.
>
> > I'll look into the CSVWriter/TextWriter EOL issue - I think I know what
> > the problem is. I'll post an update when I get a fix.
>
> > By the way - are you the same Keith that I emailed a while back, and then
> > haven't had a chance to follow up on? If so - thanks for hanging in there!
>
> > Martin
>
> > Hi, Keith.
>
> > Cool - an actual user!
>
> > I'm surprised the ShapefileReader isn't working for you - I use it all the
> > time. But I will do another direct test of the install that's available for
> > download - possibly something is awry. Can you send me an example of a
> > shapefile that doesn't work?
>
> > As for shapefile manipulation, that is definitely a #1 use case for Jeql.
> > So the *theoretical* answer to your questions is yes, yes, yes.
>
> > However... one thing which is missing from Jeql right now is the ability
> > to add to or union tables together. I do intend to implement the SQL UNION
> > operator. In the short term, I will create a TableUnion procedure which
> > will do the same thing. That would be the preferred way to add records to a
> > table - although it would be probably be nice to have the equivalent of an
> > INSERT command (although, in absence of true looping this is less useful).
>
> > Can you tell me more about your use case?
>
> > As for defining the spatial type of a shapefile, this is done implicitly
> > based on the type of the GEOMETRY column that is being written.
>
> > I do intent to implent a DBF Reader & Writer - just haven't got there yet.
>
> > I'll look into the CSVWriter/TextWriter EOL issue - I think I know what
> > the problem is. I'll post an update when I get a fix.
>
> > By the way - are you the same Keith that I emailed a while back, and then
> > haven't had a chance to follow up on? If so - thanks for hanging in there!
>
> > Martin
>
Martin Davis
Mar 24, 2008, 3:43:57 PM3/24/08
to jeql-...@googlegroups.com
This one's pretty simple. The problem is that command names are case-sensitive, so you have to use "Print" in the last line.
Making this change, I get the output:
COL1:Geometry
(
( POINT (-105.20309785904612 43.47575696402768) ),
( POINT (-105.20301925302253 43.47371071220398) ) )
I'll fix the error message so that it's clearer. (Error reporting is going to be an on-going task....)
M
Making this change, I get the output:
COL1:Geometry
(
( POINT (-105.20309785904612 43.47575696402768) ),
( POINT (-105.20301925302253 43.47371071220398) ) )
I'll fix the error message so that it's clearer. (Error reporting is going to be an on-going task....)
M
Martin Davis
Mar 24, 2008, 3:51:52 PM3/24/08
to jeql-...@googlegroups.com
The case-sensitivity is a design choice in JEQL - but it does follow the Java convention, which is that names are case-sensitive. I realize it can seem like a bit of a pain, but in Java coding you quickly get used to it, and it does mean that you can actually deal with upper/lower case names, rather than forcing them all to be upper-case.
As I just replied, the error here is that the Print command name needs to be cased correctly. Good luck and let me know how you get on.
M
As I just replied, the error here is that the Print command name needs to be cased correctly. Good luck and let me know how you get on.
M
Reply all
Reply to author
Forward
0 new messages