Null-safety implementation

[lukas-h]

Hi,
this is my attempt at null-safety.

GeoJson serialization/deserialization

I tried to follow the official GeoJSON RFC-standard as good as possible, there is still some ambiguity left on how to interpret and translate it into Dart.

• The attributes of CoordinateType and it's child-classes BBox and Position are non-nullable.
  

  turf_dart/lib/src/geojson.dart

  Line 35 in 315b05f

  abstract class CoordinateType implements Iterable<num> {

• RFC 7946 – 3.1.1 The optional third attribute (alt) for Position is also non-nullable and by default == 0. I'm not sure if this is a good way of dealing with it?!

• RFC 7946 – 3.1.2 and following: I made the coordinates attribute for Point, MultiPoint, LineString, MultiLineString, Polygon and MultiPolygon nullable. But I only made the "top-level" type nullable: this means, either you assign null to coordinates or you have to provide it entirely null-safe.

• But should it be nullable? Let's vote on that.

  "GeoJSON processors MAY interpret Geometry objects with empty "coordinates" arrays as null objects." RFC 7946 – 3.1

• RFC 7946 – 3.1.8 similarly to the other types above, I made the geometries attribute for GeometryCollection nullable

• RFC 7946 – 3.2 Feature: the geometry is also nullable

• RFC 7946 – 3.3 FeatureCollection: the features attribute "can be empty" according to the RFC-standard, so I chose to treat it as nullable.

Ported "Components" from Turf.js

For functions such as midpoint, destination, etc. we have two implementations: "raw" (which takes just the Position) and the other one with Points, which just passes Point.position attribute to the "raw" function.

turf_dart/lib/src/midpoint.dart

Line 14 in 315b05f

Point midpoint(Point point1, Point point2) => Point(

turf_dart/lib/src/midpoint.dart

Line 6 in 315b05f

Position midpointRaw(Position point1, Position point2) {

I don't really think using the bang(!)-operator is a good way of dealing with it, because we give the responsibility to check for null again to the user, which is kind of opposed to the whole idea of null-safety.

turf_dart/lib/src/midpoint.dart

Line 15 in 315b05f

coordinates: midpointRaw(point1.coordinates!, point2.coordinates!),

Please @baparham @tobrun, review and correct the migration for the meta functions, ...

---

Also: I have still an error with json_serializable, which has some kind of type error, I guess it has something to do with the nested-generic types..

When I try to run: dart run build_runner build, this is the output:

...
[SEVERE] json_serializable:json_serializable on lib/src/geojson.dart:

UnimplementedError: (TypeParameterTypeImpl) T?
[INFO] Running build completed, took 3.8s
[INFO] Caching finalized dependency graph completed, took 36ms
[SEVERE] Failed after 3.8s

---

@tobrun @baparham if you could take a look and help me with all of the decisions? 🙂

[tobrun]

RFC 7946 – 3.1.1 The optional third attribute (alt) for Position is also non-nullable and by default == 0. I'm not sure if this is a good way of dealing with it?!

Capturing from the spec:

Altitude or elevation MAY be included as an optional third element.

To me optional equals nullable. The issue with defaulting to 0 means you can't differentiate when a value is uninitialized or actually 0.

RFC 7946 – 3.1.2 and following: I made the coordinates attribute for Point, MultiPoint, LineString, MultiLineString, Polygon and MultiPolygon nullable. But I only made the "top-level" type nullable: this means, either you assign null to coordinates or you have to provide it entirely null-safe.

My personal opinion would be to make these non-nullable. Is their any language in the specification that goes against this? Conceptually a GeoJSON type is determined by the underlying geometry, if their isn't any geometry, is it really an instance of it?

RFC 7946 – 3.3 FeatureCollection: the features attribute "can be empty" according to the RFC-standard, so I chose to treat it as nullable.

👍

[lukas-h]

Conceptually a GeoJSON type is determined by the underlying geometry, if their isn't any geometry, is it really an instance of it?

RFC 7946 – 3.1

GeoJSON processors MAY interpret Geometry objects with empty "coordinates" arrays as null objects.

And for Features [I wanted to treat Feature, FeatureCollection, GeometryCollection and the geometry types (Point, Polygon, ...) the same way nullability-wise]:

A Feature object has a member with the name "geometry". 
The value of the geometry member SHALL be either a Geometry object as defined above or,
in the case that the Feature is unlocated, a JSON null value.

RFC 7946 – 3.2

[lukas-h]

To me optional equals nullable. The issue with defaulting to 0 means you can't differentiate when a value is uninitialized or actually 0.

Totally makes sense, but I have to see how that will complicate the implementation of bounding boxes.

Following the RFC, they can have either 4 (without altitude, 2D) or 6 parameters (with alt, 3D), see here.

I had implemented it before as 3D by default.

turf_dart/lib/src/geojson.dart

Line 211 in 14e9b66

]) : super([lng1, lat1, alt1, lng2, lat2, alt2]);

[baparham]

a few thoughts

[lukas-h]

I think I now have implemented everything necessary for the migration
and I would really appreciate to get reviews on my latest changes 😄

[baparham]

who or what changes this file? Is it generated code somehow or is it used to generate code?

[lukas-h]

It‘s auto-generated by json_serializable.

This package: https://pub.dev/packages/json_serializable
A code generator for JSON (de)serialization.

[baparham]

Looks like you've addressed our questions and decisions, nice work!

[lukas-h]

Can I go ahead and merge it?

@baparham @tobrun any objections?

[baparham]

History is reversible. At least here it is 😂