Hi Andrea,
The formatting changes I made were necessary because I placed large blocks of
code within a try/finally block. To preserve readability I needed to indent the
code. If I have done this wrong I apologise. If it is just that file with no
try/finally block requiring an indent then it is an over site from me.
> I see in BasicSQLDialect that you look into the z of teh geometry to
> determine the dimension,
> imho this should be done the other way, just like we do with srid: a
> geometry is saved as
> 3d if the database accepts 3d data, not the other way around.
> If a 2d geometry is saved in a 3d database it must get in without issues.
> Vice versa is indeed debatable, in my patch I forced 3d geoms to 2d if the
> database says so, silently,
> but it's mostly a convenience (though I believe I prefer this behavior
> rather than an exception,
> the data might be coming out of a processing chain that left some 3d bits
> in a data that is meant
> to be saved as 2d, if we throw exceptions the caller will be forced to
> manually shave
> off the third dimension).
2D into 3D I would call an error. Setting the third dimension to NaN is forcing
a projection/transformation onto the data. A simple, trivial and naive
projection/transformation, but the intent of the table may be violated by this.
This assumption, I feel, may cause hidden problems.
3D into 2D I would also call an error for the same reason.
The most important thing for me was to get the PostGIS test to pass. This
directed me to do things in the fashion I did.
I'm happy to provide another point of testing. I am running on Windows 7
64-bit, Postgres v9.1.3 64-bit, PostGIS v2.0 64-bit.
Thanks,
Brett
From: [email protected] [mailto:[email protected]] On Behalf Of Andrea
Aime
Sent: Monday, 4 June 2012 5:05 PM
To: Brett Walker
Subject: Re: [Geotools-devel] PostgreSQL/PostGIS and 3D Geometries
On Mon, Jun 4, 2012 at 2:56 AM, Brett Walker
<[email protected]<mailto:[email protected]>> wrote:
Hi Andrea,
I have attached a patch covering my work with PostGIS 3D and PostGIS v2.0. It
looks like you have been working for top down from the FeatureType heading
towards the DB. I have been looking at the DB and working my way up. (Which way
is up and which is down? DB at the bottom of the technology stack.)
Actually no, my patch goes both ways, just like the srid treatment does.
If you specify it in the feature type passed to createSchema it will be set in
the db, and while reflecting the feature type out of the DB
the hint is set back into the geometry user data (just like srid does).
My starting point was trying to address the missing srsName that I raised in a
previous email [1]. To start looking at this I needed to set up a testing
environment which I was never able to do to my satisfaction. I found the
PostGIS test suite was deficient (failing test, tests in error and
non-responsive tests) when I set up a local PostGIS 2.0 test DB.
Hum, that's odd? I did the work of moving the functions to ST_ version one year
ago:
http://jira.codehaus.org/browse/GEOT-3612
I've just run the full test suite against the Postgis 2.0 version I had back at
the time and
all 320+ tests do pass. That said, what I have locally it's not the final
Postgis 2.0 version,
but a svn checkout of some time ago.
I guess some extra non ST_ functions have been removed since then.
In my work I did not manually switch all functions to ST_ bust just made enough
changes
to make it work since the PostGIS documentation does not say when the ST_ ones
have been introduced.
Unfortunately that alrady forced some people I know to upgrade PostGIS from pre
1.2.x
to a more recent version. Given that it was working fine for them and the
upgrade
was forced by Geotools they were none too pleased, at the same time we cannot
preserve backwards compatibility forever...
Looking at the patch it seems SRID was removed and we now have to use ST_SRID?
I'll have a look next weekend (this is not paid work for me, so I can't spend
time
on it during working hours).
There are four areas that are covered in the patch:
1) Prefixing 'ST_' to previously deprecated function that are now removed.
2) Writing geometries to PostGIS in 2D or 3D format as required.
3) Setting up testing environment that are compatible to PostGIS v2.0.
4) Making the tests more robust in regards to no responsive tests.
Point 1 is obvious. There could be more that I have missed.
Point 2 is my take on getting 3D geometries into PostGIS. There are two files
that are concerned with this effort; BasicSQLDialect [2] and PostGISDialect
[3]. Given your effort this is area that needs to change.
Point 3 and 4 are the areas of the most change. Point 3 addresses a different
behaviour now seen in PostGIS v2.0, perhaps in earlier versions as well. In
early versions of PostGIS an sql statement of the like "INSERT INTO
GEOMETRY_COLUMNS VALUES('', 'public', 'line3d', 'geom', 3, '4326',
'LINESTRING')" would add geometry constraints to the table concerned, in this
case the table would be 'line3d'. In PostGIS v2.0 the geometry constraints need
to be added manually. I'm not sure which version of PostGIS the change in the
behaviour occurred. So I added the appropriate lines to add the constraints to
the spatial tables. As it now stands, in my patch, the tests would probably
fail when run against an early version an PostGIS.
The code is actually adding the constraints manually already, they are in
PostgisDialect.postCreateTable?
Ah, you mean in the test setups?
Looking at the patch now. In its current state the patch to
JDBCDataStoreAPITest is not suitable for review,
you did not use the GeoTools coding conventions and the patch is full of
reformats, e.g.:
- for (i = 0; i < ORIGINAL.length; i++) {
- ADD[i] = ORIGINAL[i];
- }
+ for (i = 0; i < ORIGINAL.length; i++) {
+ ADD[i] = ORIGINAL[i];
+ }
Patches contributed to GeoTools should never show signs of reformats. Which
does not mean that
you have to apply the GeoTools coding convention and then reformat the file
with them, but that
the file should never be automatically formatted at all. (btw, the other files
in the patch are not affected).
I see in BasicSQLDialect that you look into the z of teh geometry to determine
the dimension,
imho this should be done the other way, just like we do with srid: a geometry
is saved as
3d if the database accepts 3d data, not the other way around.
If a 2d geometry is saved in a 3d database it must get in without issues.
Vice versa is indeed debatable, in my patch I forced 3d geoms to 2d if the
database says so, silently,
but it's mostly a convenience (though I believe I prefer this behavior rather
than an exception,
the data might be coming out of a processing chain that left some 3d bits in a
data that is meant
to be saved as 2d, if we throw exceptions the caller will be forced to manually
shave
off the third dimension).
Cheers
Andrea
--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
