tonystone / geofeatures2 Goto Github PK

Add to protocol Geometry and all implementing types with the syntax:

   func buffer(distance: Distance) -> Geometry

Add to protocol Geometry and all implementing types with the syntax:

   func union(_ other: Geometry) -> Geometry

Add to protocol Geometry and all implementing types with the syntax:

    ///
    /// - Returns: A derived geometry collection value that matches the specified m coordinate value.
    ///
    func locate(along: Double) -> Geometry

This should produce strict OGC WKT output for all geometry types and options including Z and M.

NOTE: Internally this will look nearly the same as WKTReader in function hierarchy accept it will produce the WKT String instead of consume it.

When Apple ApplicationServices is imported either directly or indirectly (XCTest imports it indirectly) code using GeoFeatures can not resolve our Polygon. We get the following messages. We need to decide how or if we handle this edge case.

error: 'Polygon' is ambiguous for type lookup in this context

ApplicationServices.Polygon:1:18: note: found this candidate
public typealias Polygon = MacPolygon
                 ^
GeoFeatures.Polygon:1:15: note: found this candidate
public struct Polygon : Geometry, Surface {
              ^

Create a recursive descent parser as the internals of the GeoJSONReader class.

A comprehensive test suite needs to be developed for all variations of geometries for the crosses function.

Add to protocol Geometry and all implementing types with the syntax:

    ///
    /// - Returns:  true if this GeometryType instance has no anomalous geometric points, such
    /// as self intersection or self tangent.
    ///
    func isSimple() -> Bool

Add to protocol Geometry and all implementing types with the syntax:

    public func distance(other: Geometry) -> Distance

A comprehensive test suite needs to be developed for all variations of geometries for the relate function.

A comprehensive test suite needs to be developed for all variations of geometries for the intersects function.

This is an inconsistency in the OGC standard as it defines query predicates like equals and contains which all follow a convention where the name is not prefixed. On the other hand, it also contains methods such as isEmpty.

For consistency in out implementation should we consider simply empty() or keep it like it is?

A comprehensive test suite needs to be developed for all variations of geometries for the contains function.

This can be done with the Realm/Jazzy tool.

Need a function to return a collection of outer rings of a MultiPolygon. This would likely be very similar to returning the collection of inner rings on a single Polygon, which returns an array of RingType objects.

Create a recursive descent parser as the internals of the WKTReader class.

Initially this should parse the types we support completely ignoring any others. It should also support the full WKT syntax as defined by OGC including Z & M indicators.

Lets create some standards for code and style.

For starters (and this can change when standards are done) is that you should follow the predominant style in the file so that the file is consistent :-)

Add to protocol Geometry and all implementing types with the syntax:

    ///
    /// - Returns: A derived geometry collection value that matches the specified range of m coordinate values inclusively.
    ///
    func locate(within: CountableRange<Double>) -> Geometry

A comprehensive test suite needs to be developed for all variations of geometries for the overlaps function.

Add to protocol Geometry and all implementing types with the syntax:

    func intersection(other: Geometry) -> Geometry

Hello! I am also working on a geometry tool library as referenced above. You might find something useful there. Paul

Need a function to return a collection of inner rings of a MultiPolygon. This would likely be very similar to returning the collection of inner rings on a single Polygon, which returns an array of RingType objects. In this case, the result would be an array of an array of RingType objects. There would not need to be any particular ordering of the arrays.

A comprehensive test suite needs to be developed for all variations of geometries for the within function.

The OGC standard states for Collection types

By the nature of digital representations, collections are inherently ordered by the underlying storage mechanism. Two collections whose difference is only this order are spatially equal and will return equivalent results in any geometric-defined operations.

-- OGC Simple Feature Access - Part 1: Common Architecture v1.2.1 (6.1.3.2)

We currently require specific ordering on our equals() and == since it is based on equals(). The new implementation should possibly be based on the relate method which should ignore ordering.

Precondition: need to decide on final structure

Add to protocol Geometry and all implementing types with the syntax:

   func symDifference(other: Geometry) -> Geometry

Base cases are currently covered, but probably need to go more in depth for each geometry type.

Add to protocol Geometry and all implementing types with the syntax:

    ///
    /// - Returns: A derived geometry collection value that matches the specified m coordinate value.
    ///
    func locate(along: Double) -> Geometry

Should equals consider precision and coordinateReferenceSystem determining equality for 2 objects?

It currently considers the exact type of the object including it's coordinate type and if they are not the same, it's not considered equal.

⎯ Equals (anotherGeometry: Geometry): Integer — Returns 1 (TRUE) if this geometric object is “spatially equal” to anotherGeometry.

-- OGC Simple Feature Access - Part 1: Common Architecture v1.2.1 (6.1.2.3)

To be "spatially equal" I would assume we need to consider both but would like other perspectives on this.

A comprehensive test suite needs to be developed for all variations of geometries for the equal function.

Add to protocol Geometry and all implementing types with the syntax:

   func difference(other: Geometry) -> Geometry

It's currently not copy on write ready.

A comprehensive test suite needs to be developed for all variations of geometries for the disjoint function.

A comprehensive test suite needs to be developed for all variations of geometries for the touches function.

As part of the standard interface for Geometry objects we need to create copy constructers for all Geometry types.

Create a visualization framework for drawing all of GeoFeatures 2 shapes in 2D or 3D space. This should work into Playgrounds and outside.

It must be completely separate from the main Swift based GeoFeatuters 2 as an optional add on package. It must also not modify the main code line to achieve the goal.

It can however live in the same project as GeoFeatures 2.

The following code is required on in this scenario. This needs to be resolved.

#if (os(OSX) || os(iOS) || os(tvOS) || os(watchOS)) && SWIFT_PACKAGE
    /// TODO: Remove this after figuring out why there seems to be a symbol conflict (error: cannot specialize a non-generic definition) with another Polygon on Swift PM on Apple platforms only.
    import struct GeoFeatures.Polygon
#endif

Standard operations line insert, append, etc can be made generic and moved into the CollectionBuffer class.

There's a broken link in the CocoaPods page. Did I miss the documentation some where?