h0shy / pytheas Goto Github PK

Hey there,

so if you want to support both Apple MapKit and GoogleMaps I would suggest to not include these in your library, what makes them more platform independent. Instead a consumer needs the following data structures (that you have to construct from the GeoJSON), so he’s able to easily build polygons or poly lines or points for the respective platforms:

• Path: Build a struct Path that defines a set of coordinates coordinates: [CLLocationCoordinate2D]. coordinates must never be nil or empty and contain at least 2 items since otherwise it is a Position (see below).
• MKPolygon / GMSPolygon: Build a struct Polygon that has the properties path: Path which defines the outer hull, interiorPolygons: [Polygon] which is again a Polygon and defines inner holes plus whatever metadata there might be attached (title, etc.). interiorPolygons should never be nil but can be empty. path must never be nil and must contain at least 3 coordinates since otherwise it is not possible to construct a polygon (the smallest polygon is a triangle) .
• MKPolyline / GMSPolyline: Build a struct PolyLine that has the property path: Path which defines the poly line plus whatever metadata there might be attached (title, etc.). path must contain at least 2 coordinates since that is the minimum amount for a line.
• Points: Build a struct Position that has the properties coordinate: CLLocationCoordinate2D which defines the position plus whatever metadata there might be attached (title, etc.). coordinate must never be nil and never has the value kCLLocationCoordinate2DInvalid (check with the function CLLocationCoordinate2DIsValid() before adding to results).

You only have to define these structures. Since GeoJson can also contain multi-polygons and poly-lines the result of the parsing function of your library should be another struct Geometry that contains the properties polygons: [Polygon], lines: [PolyLine] and positions: [Position]. All the constraints above can nicely be covered by unit tests 🙌

Thats it! With this I can construct both Google and Apple objects. Do you think that is realistic?

PS: As a plus it would be nice to provide the computed property encodedPath: String for the struct Path since google objects are initialized using this string. The good thing is that this is an open standard which does not require to include the whole google library. We also have the algorithm for that in the app so this extra is not required but would be a nice addition. Documentation of how to construct it can be found here.

With the objective in mind of having every elements of our model Equatable, it could be nice to reduce the usage of Any.

When parsing a shape we could replace [Any] by a generic type implementing Equatable.

This would integrate much better in current and future projects and helps the user to avoid boilerplate code.