Should we have firmer class assertions?

[aardrop]

As I'm leaning into this package, I wanted to know if we want to use any of the other GeoJSON rules with harder typing. As for Polygons, we can assert that they are closed or contain at least 3 positions, which is required, but we don't. Similarly, I believe features are required to have IDs, at least from what I'm reading online.

I find it hard to debug broken GeoJSONs because the consumers are platform view apps like Google Maps and Flutter Maps that don't return input formatting errors. If we don't want to force some of the GeoJSON conventions, does anyone have advice on dubbing formatted goujons for dynamic data with turf? I'm having issues putting together multi polygons, collections of polygons, and larger feature lists.

[lukas-h]

We are right now doing an improvement of some of the core de-/serialization features of GeoJSON and we can prioritise a few checks here. For polygons it would definitely make sense to have that (incl. a check if the first equals the last coordinate). The problem is with more complex geometries the assertios / checks are getting increasingly complex too with different edge-cases, etc. So we have to really see if we want to add all of that complexity to our library. But I think a few more checks would definitely make sense.

But I think these checks should only be the default during debugging, not in a production app, as they could potentially crash a whole app and make deserialization considerably slower.

@jsiedentop What's your opinion about that?

[jsiedentop]

I think it's a good idea, thank you for initiating the discussion.

Basically, I would try to separate the three topics:

1. Deserialization:
   • As far as it makes sense, it should be possible to map GeoJson to Dart types. Whether a feature has an ID, for example, does not play a major role for most use cases and we shouldn't break existing applications here.
2. Validation:
   • All intended validations should be implemented. Especially if you use more restrictive third party Apis, we could avoid unnecessary trouble.
   • If we validate automatically during deserialization, this should initially be treated more like a warning.
   • The first step could be to allow users to trigger validation manually.
3. Automatic fixing:
   • A lot of errors could be fixed automatically. It also seems sensible to me to provide this implementation in a central location.
   • Not every validation error must be able to be fixed automatically, but we could start with some and expand the capability over time.
   • I have noticed that some turf functions implicitly fix at least some errors. For example, the coordinates are often sorted or features are provided with ids.
   • Making these fixes in a central location and not implicitly in the Turf functions would add value. Currently it seems, that some errors will be fixed automatically in some of our turf functions. Quite possible, that we have undiscovered bugs here. Fixing it at a central point will probably lead to many failing tests and a breaking change for our users.
   • In the long term (TurfDart 1.0.0 or maybe better 2.0.0), it would probably be safer if the turf functions only validate GeoJson and fail, if errors are detected (fail fast). If we fix validation errors implicitly, we are hiding the actual cause and not making the user aware of invalid data at all. However, this is a breaking change and would cause many tests to fail.

So what could be a possible roadmap?

• Implement strict validators, that follow the GeoJson conventions. If we decide at some point to run these validation automatically, we should only issue warnings.
• Start to provide functionality to fix certain validation errors. I tend to think that this must be explicitly called up by the user on a permanent basis.
• Introduce strict mode where validation issues leads to errors. Make it default in the long term (1.0.0 or 2.0.0)? We have also survived null safety 😅