Per the discussion on #171, there's an existing bug in our handling of Z and M coordinates in the GeoJSON decoder.
GeoJSON does not recognize any such geometry type as PointZ, LineStringZ, etc. Indeed, if you give these to PostGIS, you'll get an error. However, when GeoJSON types such as LineString are given with the 3rd position present in coordinates, we should assume it is Z, as the spec indicates, and parse it into the correct 'Z' type. This means that a LineString GeoJSON could be decoded into either Geo.LineString or Geo.LineStringZ, depending on the data.
Rather than making this a breaking change, I think we could maintain backward compatibility with past versions of geo by continuing to accept the Z-variant types, as long as we also accept 3-position coordinates as Z types as well.
Since GeoJSON has no notion of an M coordinate, we should continue to strip out 4th or greater positions on GeoJSON decode, such as 'M'. Decode 4+ member coordinates into 3 member 'Z' types.
Per the discussion on #171, there's an existing bug in our handling of Z and M coordinates in the GeoJSON decoder.
GeoJSON does not recognize any such geometry type as
PointZ,LineStringZ, etc. Indeed, if you give these to PostGIS, you'll get an error. However, when GeoJSON types such as LineString are given with the 3rd position present in coordinates, we should assume it is Z, as the spec indicates, and parse it into the correct 'Z' type. This means that a LineString GeoJSON could be decoded into either Geo.LineString or Geo.LineStringZ, depending on the data.Rather than making this a breaking change, I think we could maintain backward compatibility with past versions of
geoby continuing to accept the Z-variant types, as long as we also accept 3-position coordinates as Z types as well.Since GeoJSON has no notion of an M coordinate, we should continue to strip out 4th or greater positions on GeoJSON decode, such as 'M'. Decode 4+ member coordinates into 3 member 'Z' types.