#417 wkb reader of spatialite

[michael michaud]

Spatialite driver can't read geometries with Z, M or ZM because geopackage uses ogc-specification for wkb while postgis ewkb uses its own encoding (and JTS has been implemented according to ewkb specification.
A small patch has been made in OpenJUMP to change how the geometry is written before reading it with JTS wkb parser, but it does not work for multi-geometries.
A more complete patch must be proposed to JTS as soon as possible.

[michael michaud]

I've submitted a patch on github to Dr JTS two days ago.

[Jukka Rahkonen]

Michaël, the pull request has been rejected because of missing some CLA https://github.com/locationtech/jts/pull/33. Must be some licensing thing. And there is no open issue in tracker either.

[michael michaud]

Jukka,

Since JTS migrated to Github/Locationtech, contributions have become very painfull.

I have 3 ongoing PRs submited since months, and I have already done everything I could to get them merged (including refactoring my PRs, signing the ETA, mailing to locationtech, and being patient).
Locationtech told me to be patient, closed my pull request by error and finally told me they will review them anyway (22/11/2016).

I will

Anyway, I think that package names in the library have changed and the migration of OpenJUMP to a new version of JTS will probably be a big change. It is not a problem if the new version is a big improvement and if the library is actively maintained, but since the start of the migration to locationtech, progresses seem quite slow.

[Jukka Rahkonen]

It is also a mess to try to find information from the web. One site has experienced http://tsusiatsoftware.net/, the Sourceforge site is still somewhat active, at least the mailing list, and then there is the newest one https://github.com/locationtech/jts which feels rather quiet. And even this https://github.com/dr-jts/jts.

[michael michaud]

I think tsusiat is a personnal site of Martin Davis.
JTS project in sourceforge is no more active bu MD kept the mailing list opened.
Since the project has been moved to GitHub, I think there has been two phases,

• first, code changes happened in MD's repository (dr-jts/jts) because the migration to location tech was not achieved
• I think that now, changes happen in locationtech/jts and dr-jts/jts is just a clone of the project

[Jukka Rahkonen]

This PR has been merged https://github.com/locationtech/jts/pull/92#issuecomment-336943045 but it is only in the Locationtech master and therefore not available for OJ without that big change.

[michael michaud]

OK, I just saw your comment and MD's answer. Of course, he's right asking for javadoc update. I'll try do do that, but I'll have to cross two obstacles : using git and understanding what our change did exactly (it is quite old). After that, there will be the question of migrating to JTS 1.15 and the new package tree...I think it could be a breaking change (OpenJUMP 2.0 ?)

[michael michaud]

The PR has been merged and in v1.15 of JTS, but it cannot be used until we decide to migrate to JTS 1.15+

[michael michaud]

Hey, I made a quick test with OpenJUMP 2.0 (snapshot) and it seems to read geometry 3d correctly (thanks to JTS 1.18 upgrade). Note that I could read it with a spatialite db created from postgis, but I could not read any geometry from my first try with a database opened in spatialite_gui where I imported shapefiles. Any spatialite user to confirm this ticket can be closed ?

[michael michaud]

Jukka, you are the expert about spatialite. I made a quick test but a confirmation from you would be welcome. I think OpenJUMP is not ready to manage the full set of geometries with Z, M and ZM, but it should read geometries with Z without losing Z and read geometries with ZM at least as geometries with Z.

[Jukka Rahkonen]

Multi* geometries behave pretty well.

• MULTIPOLYGON Z -> comes as MULTIPOLYGON Z into OJ with x,y,z coordinates
• MULTIPOLYGON M -> comes as MULTIPOLYGON Z into OJ with x,y,z coordinates (M gets converted into Z)
• • MULTIPOLYGON ZM-> comes as MULTIPOLYGON Z into OJ with x,y,z coordinates (M gets dropped)

Similar results with MULTIPOINT and MULTILINESTRING geometries.

Simple geometries behave well if they are * Z or * M. They become * Z with 3 coordinates in OJ.
But there is still some an issue with simple ZM geometries

POINT ZM (1 2 3 200)
becomes POINT (1 2)

LINESTRING ZM (1 2 3 200,4 5 6 200)
becomes LINESTRING ( 1 2, 3 200 ) (ERROR!)

POLYGON ZM ((0 0 100 200,0 10 100 200,10 10 100 200,10 0 100 200,0 0 100 200),(1 1 100 200,1 9 100 200,9 9 100 200,9 1 100 200,1 1 100 200))
becomes POLYGON (( 0 0, 100 200, 0 10, 100 200, 10 10, 0 0 ), EMPTY ) (ERROR!)

Polygon case also leads into Array index out of bounds error because it is impossible to render the converted geometry.

What is good is that spatialite and geopackage behave in the same way.