-
Notifications
You must be signed in to change notification settings - Fork 1
First Meetup
- If we want inter-operability between our libraries/packages, we don't want to convert between different types (where possible)
- Provide design patterns for developers who want to provide their own set of geometry types.
- Some people want to use geometry types, and not define their own. What should they be using, and if there's a decision to be made, how should they make that decision?
My guess(es):
- to capture semantics not otherwise available
- for a more compact/efficient representation
- as wrappers around other opaque objects
I'm pretty scared of over-engineering a solution now, but it's good to have some consensus now, and to learn from each other, to refactor our codebase early. It'll only get more painful later. Can always re-visit our decisions through next-juliacon/subsequent-meetups.
"You see, a great designer starts with the whys. She conveys the principles behind her thinking and leaves you feeling like you understand the core values from which all her design decisions flow."
(Julie Zhuo, A Matter of Principle: Surfacing the core truths in every design)
"A good set of design principles does the following:
- Helps resolve practical and real-world questions around specific design decisions.
- Applies to an entire class of design decisions, both things we can think of today, as well as questions that will pop up in the future.
- Imparts a human-oriented sense of “why?” that is easy for everybody — including non-designers — to understand.
- Has a point of view and a sense of prioritization that a rational person could disagree with.
- Is generally paired with illustrative examples that show how the principle applies to specific decisions."
Here's some illustrative examples ("test cases"), for whatever specification we have in mind.
| data | semantics | coordinates |
+----------------------+-------------------------------------------------------------------------+-----------------------------------+
| vec2 | point/"position", direction/"line" | cartesian, polar, geographical |
+----------------------+-------------------------------------------------------------------------+-----------------------------------+
| vec3 | point/"position", direction/"line", | cartesian, polar(?), geographical |
+----------------------+-------------------------------------------------------------------------+-----------------------------------+
| Vector{vec2} | collection{point}, multipoint, linestring(series of points), | cartesian, polar(?), geographical |
| | linestring("ring"), polygon | |
+----------------------+-------------------------------------------------------------------------+-----------------------------------+
| Vector{vec3} | collection{point}, multipoint, linestring(series of points), | cartesian, polar(?), geographical |
| | linestring("ring"), polygon | |
+----------------------+-------------------------------------------------------------------------+-----------------------------------+
| Vector{Vector{vec2}} | collection{collection{point}}, collection{linestring}, multilinestring, | cartesian, polar(?), geographical |
| | polygon(with holes), collection{polygon}, | |
+----------------------+-------------------------------------------------------------------------+-----------------------------------+
| Vector{Vector{vec3}} | collection{collection{point}}, collection{linestring}, multilinestring, | cartesian, polar(?), geographical |
| | polygon(with holes), collection{polygon}, | |
+----------------------+-------------------------------------------------------------------------+-----------------------------------+
| Vector{Vector{Vector{vec2}}} ... | |
+----------------------+-------------------------------------------------------------------------+-----------------------------------+
What hasn't been covered: meshes/faces/triangles/circles/cubes/rectangles/etc.
[1]: E. Clementini, P. Di Felice, and P. van Oosterom, “A Small Set of Formal Topological Relationships Suitable for End-User Interaction,” Third International Symposium on Large Spatial Databases (SSD). Lecture Notes in Computer Science no. 692, David Abel and Beng Chin Ooi, Eds., Singapore: Springer Verlag, 1993, pp. 277-295. (PDF)
[2]: John R. Herring, Ed., “OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture,” Oct. 2006.
[3]: M.J. Egenhofer and John R. Herring, Categorizing Binary Topological Relations Between Regions, Lines, and Points in Geographic Databases, Orono, ME: University of Maine, 1991. (PDF)
[4]: C. Strobl, “Dimensionally Extended Nine-Intersection Model (DE-9IM),” Encyclopedia of GIS, S. Shekhar and H. Xiong, Eds., Springer, 2008, pp. 240-245. (PDF)
[5]: Martin Davis, “JTS Technical Specifications,” Mar. 2003. (PDF)
[6]: David H. Douglas and Thomas K. Peucker, “Algorithms for the Reduction of the Number of Points Required to Represent a Digitized Line or its Caricature,” Cartographica: The International Journal for Geographic Information and Geovisualization, vol. 10, Dec. 1973, pp. 112-122.
[7]: E pur si muove: Galiliean-invariant cosmological hydrodynamical simulations on a moving mesh (doi: 10.1111/j.1365-2966.2009.15715.x) (PDF)