Re: [Jaspa-users] Questions

[Simon G. <si...@sp...>]

Jose,

>  Hi Simon, I know you because of the mailing list and your great blog.

Most kind. I know this is hard to believe but I get little recognition for what I do so it is nice to hear it.
I am actually quite ready to move to another database like PostGIS but there is so little work in that space
in Australia. SQL Server Spatial is my other option mainly because of the amount of installs in Oz. Working
with Oracle is awful.
>
>> Jaspa Users,
>>
>> I have a question. I am looking at either porting JASPA to Oracle to work in conjunction with SDO_GEOMETRY
>> or to pull out particular methods for use on their own augmenting Oracle Sdo_Geometry functionality.
> Marta Gonzales who has worked with me in the jaspa project is working now about porting Jaspa to Oracle 11g in her Master thesis. She has already done a good job about that using the spatial indexes and migrating most of the jaspa functionality. I dont know exactly the current status >of her work but the idea is to add it to the jaspa release.
>  Marta is you read this email maybe you can give some details about your work to Simon.

OK, look I have been working on exposing JTS in Oracle's JVM now for quite a while. I am doing it more directly looking a functionality
that complements or fills gaps in the Oracle stack rather than any theoretically complete OGC/SFS compliant API. The results of my work
are documented on my website under what is called the GEOPROCESS PL/SQL package. I have actually renamed this to JTS and added
in a lot more functionality. It is ready to go up on my site to replace GEOPROCESS but it may not happen till next week. Still, GEOPROCESS
gives you a feel for what I have done.
>
>> Firstly, I note that Jaspa appears to have its own version of JTS as its definition of Coordinate.java includes a measure.
>> I am currently working with JTS1.12 and its Coordinate.java does not have a measure ordinate. Is this the case? How deep
>> do the changes go? Is there a plan to fold them back into JTS?
>  yes, you are right, jaspa has modified JTS but just a little bit like the one you found out or a few methods. I dont think the changes are useful for every jts users thats why I didnt even ask Martin Davis about that.

It is very important that you do merge this back into JTS. One major issue I have with GeoTools/JTS is the handling of 3 and 4D geometies, never mind the bigger issues of circular curve and geodetic support.

As part of my GeoRaptor work exporting Oracle data to shapefiles, I looked at the conversion from GeoTools to JTS and back again for Oracle because it does not handle measures.
To be honest, even though I am not a vastly experienced profesional and full-time Java programmer I wasn't impressed with the code. It didn't just need a fix for the measures it needed a complete
re-write. I started work on the "fix" with Jody Garnett but I lost interest for a bunch of reasons.

Perhaps JASPA is the better framework in which to get Oracle/JTS integration working.

What are your plans for circular arc and geodetic support given that JTS doesn't support either?

(Aside: How is it that PostGIS etc all seem to use JTS/GEOS but from that basis extend to support circular arcs etc but don't work to help JTS/GEOS get that support?)

> Secondly, I prefer to work with Java 1.4 as Oracle 10gR2 is 1.4 and only 11g is 1.5.  All in all this doesn't look too difficult an issue
>> if I pull out functions but more so if I work with Jaspa as a whole.
>>
>> Thirdly, JASPA seems to allow for auto conversion of primitive ints to Integers, boolean to Boolean in its functions .... when moving
>> back to an earlier JVM it is a pain because one has to do formal conversions eg
>> public static Double ST_Area(Geometry geom) {
>>
>> if (Core.isNullGeometry(geom)) return null;
>>
>> return geom.getArea();
>> }
>>
>> public static Double ST_Area(Geometry geom) {
>>
>> if (Core.isNullGeometry(geom)) return null;
>>
>>  return new Double(geom.getArea()) ;
>> }
>>
>> I can see why one might use class types over the primitive types but wouldn't more formal casting/conversion from JTS to JASPA bebetter than compiler based conversion? But I have to admit I am not a vastly experienced Java programmer. When going from Oracle'sPL/SQL to the JVM I use primitive types.
> I think you are right about formal casting/conversion, it was just for writing less code. You are talking just about the returning values or you found any other problem with java 1.4 and Oracle?
> Anyways this project is mainly maintained by me and I dont think i can change the source code a lot right now because lack of time. For the next release I can change the casting as you suggested if you think this is really worth it.

It is not a difficult thing to do. Mainly it is because of JASPA's use of class data types like Integer whereas JTS uses the primitive types like int. So, yes, I suggest you make the change.

The only other changes I needed to make (for 1.4 compliance as JTS is 1.4 compliant) were to change things like List<Geometry> ... to List and add in casts when needed. This was actually very simple to do as JASPA
doesn't seem to use LinkedHashMaps etc with key/value typing. The only pain is:

     public static <U> U[] removeNulls(U array[]) {

I would be happy to change the code for you in agreed areas but only once the Oracle integration has occurred. Also, I am happy to offer to test Marta's work if you are interested.
Perhaps once Marta is finished I could be involved as the maintainer of this branch of the code? But isn't one thing about JASPA to offer an alternate type system to Oracle (BTW
aggregates with Java in Oracle are awful!) My needs are for a solution that is about integration.

Happy to keep talking or get involved in any way you are comfortable with.

regards
Simon
-- 
Holder of "2011 Oracle Spatial Excellence Award for Education and Research."
SpatialDB Advice and Design, Solutions Architecture and Programming,
Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional
Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, FME, Radius Topology and Studio Specialist.
39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia.
Website: www.spatialdbadvisor.com
Email: si...@sp...
Voice: +61 362 396397
Mobile: +61 418 396391
Skype: sggreener
Longitude: 147.20515 (147° 12' 18" E)
Latitude: -43.01530 (43° 00' 55" S)
GeoHash: r22em9r98wg
NAC:W80CK 7SWP3