incoming geometry srid assumed to be db rather than client

[sfletche]

When a new polygon feature is sent to the server for storage, there appears to be an assumption that the geometry of the feature is in the DB SRID, rather than the assumption that the feature is in the CLIENT SRID. (If the SRID is not explicitly stated in the wkt/ewkt.)

My experience:

With GEOMETRY_CLIENT_SRID = 3857 and GEOMETRY_DB_SRID = 99996, a feature geometry was sent to the server for storage (NOTE: with no SRID attached), and was stored in the DB without being transformed. This resulted in an incorrect transform result when later this feature geometry was exported back to the client (requested in the GEOJSON_SRID (3857)).

The solution was to explicitly state (ewkt format) the client side SRID of 3857 as part of the geometry ewkt sent to the server.
In other words originally the client sent the following geometry representation:
POLYGON((-8215412.1196364 4902436.4493572,-8172607.3838027 4934234.2531195,-8138363.5951357 4901213.4569048,-8194621.2479457 4873084.6304998,-8215412.1196364 4902436.4493572))
Resulting in a geometry that was stored in the DB as 99996 (rather than 3857).

My solution:

Changing the geometry representation to explicitly state the SRID as follows:
SRID=3857;POLYGON((-8215412.1196364 4902436.4493572,-8172607.3838027 4934234.2531195,-8138363.5951357 4901213.4569048,-8194621.2479457 4873084.6304998,-8215412.1196364 4902436.4493572))
fixed the problem and the geometry was then transformed from 3857 to 99996 before being stored in the DB -- resulting in geometries later sent from the DB to the client to be transformed and exported correctly.