When writing:

XX000: WKB structure does not match expected size!
Data:
  Severity: ERROR
  InvariantSeverity: ERROR
  SqlState: XX000
  MessageText: WKB structure does not match expected size!
  File: lwgeom_pg.c
  Line: 250
  Routine: pg_error

Originally flagged in npgsql/npgsql#3467

In #5 I addressed a problem with ordinates handling, but the issue seems wider, so I'm opening a discussion here.

Both PostGisWriter and PostGisReader have a HandleOrdinates property on them. These properties determine the ordinates sent and received,

• Sending an XY point with an XYZ writer will send an XYZ point with a zero Z coordinate
• Receiving an XY point with an XYZ reader will return an XYZ point with a NaN Z coordinate

In effect, there seems to be no way to simply send or receive a point, with all its ordinates (and nothing but its ordinates): the user must currently set the ordinates manually on the writer and reader beforehand. Aside from being odd and unnecessary, this makes it awkward to work in situations where geometry objects of varying ordinates are used: writing both 2D and 3D points involves having two writers and two readers (or constantly changing the ordinates properties on them).

Here's a proposal for a new behavior:

• Treat the ordinate setting on the reader/writer only as a "maximum" value, allowing users to "crop" unwanted ordinates.
• For example, if an XYZ point is sent with an XY writer, an XY point will be sent, discarding the Z coordinate. Similarly, if an XYZ point is received with an XY reader, an XY point will be returned. This is the current behavior - no change.
• However, if the geometry object is missing a coordinate present in the reader/writing setting, it is not completed with either 0 or NaN. So an XY point will be sent as an XY point with an XYZ-configured writer. Similarly, reading an XY point with an XYZ-configured reader would return an XY point.
• In effect, the ordinates sent and received will be a bitwise AND between the ordinates set on the reader/writer, and the actual ordinates present on the object.
• As a special case, Ordinates.None would mean that the reader/writer have no particular setting, and would always simply pass through the object as-is, without adding or removing anything.
• Ordinates.None would become the default behavior for PostGisWriter and PostGisReader.

Note that the Ordinates.None behavior is already somewhat present in PostGisWriter, but is disabled as described in #6.

If this is accepted, I'll submit a PR for the changes including tests.

/cc @austindrenski @YohDeadfall

Since creating this repository and now there have been considerable changes in the develop branch:

• NetTopologySuite/NetTopologySuite@4d99b0c

Hi,
the version 2.1.0 introduced this issue: all XY geometries are stored in postgis as XYZ geometries, with NaN value in Z.

Example: I store POINT(0 0) using Npgsql and NTS.
Using NetTopologySuite.IO.PostGis v2.0.0, postgis' st_ndims returns: 2 and st_astext returns: POINT (0 0)
Using NetTopologySuite.IO.PostGis v2.1.0, postgis' st_ndims returns: 3 and st_astext returns: POINT Z (0 0 -1.#IND)

-1.#IND is a NaN representation in Windows https://stackoverflow.com/a/347940.

I'm using:

• net6.0 running in Windows (VS 2022)
• Npgsql.EntityFrameworkCore.PostgreSQL.NetTopologySuite 5.0.7 (and later)
• PostgreSQL 11.11, compiled by Visual C++ build 1800, 64-bit managed in Azure as Single Server
• POSTGIS="2.5.1 r17027" [EXTENSION] PGSQL="110" GEOS="3.7.0-CAPI-1.11.0 3.7.1" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.2.4, released 2018/03/19 GDAL_DATA not found" LIBXML="2.7.8" LIBJSON="0.12" LIBPROTOBUF="1.2.1" RASTER

How to reproduce the issue:

NpgsqlConnection.GlobalTypeMapper.UseNetTopologySuite();
using NpgsqlConnection conn = new(connectionString);

conn.Open();

using (var cmd = new NpgsqlCommand(@"
  CREATE TEMP TABLE test 
  (
    geometry geometry, 
    CONSTRAINT enforce_dims CHECK (st_ndims(geometry) = 2)
  )", conn))
{
  cmd.ExecuteNonQuery();
}

using (var cmd = new NpgsqlCommand("INSERT INTO test (geometry) VALUES (@g)", conn))
{
  cmd.Parameters.AddWithValue("@g", new WKTReader().Read("POINT(0 0)"));
  cmd.ExecuteNonQuery();
}

The above code works in net6.0 with Npgsql.EntityFrameworkCore.PostgreSQL.NetTopologySuite 5.0.5 (using NetTopologySuite.IO.PostGis 2.0.0). Using the next version 5.0.7 (using NetTopologySuite.IO.PostGis 2.1.0) it throws Npgsql.PostgresException with the message 23514: new row for relation "test" violates check constraint "enforce_dims".

The PostGisReader is smart enougth to see the Z coordinate is NaN, returning a 2 dimensional coordinate.

I think the issue has been introduced with the following commit:

ddd394c#diff-b1018343089a37cb228d0c3357039b782d592ad2591204f0d4c6d41089d1ecf8L585

Version 2.1.0 is:
if (sequence.HasZ)
version 2.0.0 was:
if (sequence.HasZ && !double.IsNaN(sequence.GetZ(0)))

Setup an automated build similar to the NTS core.

Currently the PostGisWriter emits SRID value for every child geometry in a multi-geometry.
This does not match Postgis ST_AsEWKB output for these geometries.

This might not be an issue, but it is different.

Could be significantly more efficient than the default?

We are updating our EF Core provider to version 3.0, but we handle geometry in the driver plugin using this library. How should we update our NTS driver plugin to support version 2.0 and use it for EFCore.PG 3.0? I have found no preview package version 2.0 of NetTopologySuite.IO.PostGis on NuGet. If you're not going to support it anymore, we will all required stuff in out library.

/cc @roji

To improve an overall performance of an app it makes sense to use async IO since it's not blocking and allows to process data in background and prevent the pooled thread from being blocked. The only blocker here is that BinaryReader has no async methods and all logic should be rewritten, but to avoid repeating internals and bringing errors to the existing code there is System.IO.Pipelines.

Would you guys be open to a PR bringing this up-to-date to modern C# standards? A while back the question was raised with regards to NTS itself - which tracks JTS - but unless I'm mistaken the IO modules don't track anything and should be more free?