#StackBounty: #data-visualization #correspondence-analysis #geometry #model-checking How do I interpret the angles of two concentration…

Bounty: 100

Consider a map with two concentration ellipses like this below. The Vomit_y group is (almost?) perfectly vertical, while the Vomit_n group seems to be oriented at about 45 degrees. I understand that Vomit_y displays no correlation between Dim1 and Dim2, while Vomit_n displays a strong correlation. What interesting things might this tell me about the differences between the two groups? How would that differ if, say, the two ellipses were “parallel” but non-overlapping, or if they were oriented at 90 degrees to each other?
Individuals factor map - MCA with two concentration ellipses


Get this bounty!!!

#StackBounty: #json #python-2.7 #geometry #polyline #jython-2.7 Calculate the midpoint of JSON polylines (Python 2.7.0, no libraries)

Bounty: 100

Scenario:

I have a system that makes a request to a web service.

  • The web service returns a JSON object.
  • The JSON object contains polyline vertices in an array.

A small snippet from the JSON object would be:

{
  "objectIdFieldName": "OBJECTID",
  "globalIdFieldName": "",
  "geometryType": "esriGeometryPolyline",
  "spatialReference": {
    "wkid": 476,
    "latestWkid": 476
  },
  "fields": [
    {
      "name": "OBJECTID",
      "alias": "OBJECTID",
      "type": "esriFieldTypeOID"
    }
  ],
  "features": [
    {
      "attributes": {
        "OBJECTID": 3311
      },
      "geometry": {
        "paths": [
          [
            [
              675844.1562959617,
              4861766.9811610579
            ],
            [
              675878.30397594348,
              4861792.5977392439
            ],
            [
              675891.38832408097,
              4861800.4024024364
            ],
            [
              675902.17710777745,
              4861804.9933949765
            ],
            [
              675912.27726199664,
              4861808.2070551421
            ],
            [
              675923.52513550781,
              4861810.2730065044
            ],
            [
              675934.77300901897,
              4861811.1911861338
            ],
            [
              675943.03676202707,
              4861811.1911861338
            ],
            [
              675951.07095439639,
              4861810.502546167
            ],
            [
              675961.17111910321,
              4861808.6661449578
            ],
            [
              675970.35304125212,
              4861806.1411667075
            ],
            [
              675981.51595173683,
              4861800.7007851209
            ],
            [
              675998.03647276573,
              4861792.2469376959
            ]
          ]
        ]
      }
    },

**The JSON object has been cut off.**

The full JSON object can be found on PasteBin: JSON Polylines


Question:

Using the JSON vertices, I would like to calculate the midpoints of the polylines (see green dots below):

  • Some of the lines (OBJECTIDs 3716 and 3385) are multi-part. In this case, the midpoint should only be generated for the longest part of the line (not the other parts).
  • For the purpose of solving this problem, the JSON text could be saved as a text file, and loaded into the python script. In this case, Python’s JSON library could be used–despite the catch that is mentioned below.

enter image description here


The output would look like this (formatting is flexible):

OBJECTID  MIDPOINT_X    MIDPOINT_Y
2165      676163.9343   4861476.373
2320      676142.0017   4861959.66
2375      676118.1226   4861730.258
2682      676060.3917   4861904.762
2683      675743.1666   4861724.081
2691      676137.4796   4861557.709
3311      675916.9815   4861809.071
3385      676288.0887   4861576.03
3546      676262.2623   4861665.146
3547      676167.5738   4861612.699
3548      676021.3677   4861573.141
3549      675914.4334   4861669.87
3550      675866.6003   4861735.572
3551      675800.1232   4861827.482
3552      675681.9432   4861918.989
3716      676054.3981   4861664.265

The Catch:

This would need to be done in Python 2.7.0 — since the work order management system uses Jython 2.7.0.

  • It’s important to note that I can’t import any Python libraries into the Jython implementation in the system that I’m using. So, unfortunately, the script should not import any python libraries (other than the JSON library for testing).
  • I can technically import Java classes in Jython (example, a JSON java class), but that’s probably not relevant to the Python crowd.

Is it possible to calculate the midpoints of a JSON polylines using Python 2.7.0 (without importing libraries)?


Get this bounty!!!

#StackBounty: #code-challenge #sequence #geometry #polyomino Counting generalized polyominoes

Bounty: 100

This challenge will have you count pseudo-polyforms on the snub square tiling.

I think that this sequence does not yet exist on the OEIS, so this challenge exists to compute as many terms as possible for this sequence.

Definitions

The snub square tiling is a semiregular tiling of the plane that consists of equilateral triangles and squares.

snub square tiling

A pseudo-polyform on the snub square tiling is a plane figure constructed by joining together these triangles and squares along their shared sides, analogous to a polyomino. Here is an example of a six-cell and an eight-cell pseudo-polyform:

enter image description here

Examples

For n = 1 there are two 1-cell pseudo-polyforms, namely the square and the triangle:

For n = 2 there are two 2-cell pseudo-polyforms, namely a square with a triangle and two triangles.

For n = 3 there are four 3-cell pseudo-polyforms.

Challenge

The goal of this challenge is to compute as many terms as possible in this sequence, which begins 2, 2, 4, ... and where the n-th term is the number of n-cell pseudo-polyforms up to rotation and reflection.

Run your code for as long as you’d like. The winner of this challenge will be the user who posts the most terms of the sequence, along with their code. If two users post the same number of terms, then whoever posts their last term earliest wins.

(Once there are enough known terms to prove that this sequence does not already exist in the OEIS, I’ll create an entry in the OEIS and list the contributor as a co-author if he or she desires.)


Get this bounty!!!

#StackBounty: #optimization #geometry #information-geometry Is the Franke-Wolfe algorithm the same as Manifold optimization?

Bounty: 50

The Frank-Wolfe optimization algorithm describes optimization over a constrained domain.
In the Manifold Optimization literature (e.g. [1]) a Gradient-Step is done using an exponential map. This maps takes account of both the gradient and the manifold constraint.

I thus ask: can the Frank-Wolfe algorithm be seen as an instance of Manifold Optimization?

[1] Absil, P-A., Robert Mahony, and Rodolphe Sepulchre. Optimization algorithms on matrix manifolds. Princeton University Press, 2009.


Get this bounty!!!

#StackBounty: #sql-server #tsql #geometry #spatial #sql-server-2017 Preserve start points in UnionAggregate

Bounty: 100

DECLARE @Geom TABLE 
( 
   shape geometry, 
   shapeType nvarchar(50) 
); 

INSERT INTO @Geom(shape,shapeType) 
VALUES('LINESTRING(1 2, 3 4)', 'A'), 
('LINESTRING(3.2 4, 7 8)', 'B'); 

SELECT *
FROM @Geom

SELECT geometry::UnionAggregate(shape).ToString(), geometry::UnionAggregate(shape)
FROM @Geom;

The WKT for the output is

MULTILINESTRING ((7 8, 3.2 4), (3 4, 1 2))

when I would want

MULTILINESTRING ((1 2, 3 4), (3.2 4, 7 8))

Where the beginning of the “A” and “B” line should be (1 2) and (3.2 4) respectfully.

This behavior of UnionAggregate doesn’t seem to care about “direction” of the geometry in order to maintain that A union B and B union A is the same result. However, I want to preserve start/endpoints as I am unioning street geometry and I want all the LINESTRINGs to go in their original direction.

This problem is discussed here: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/89e95366-3649-4294-a0bc-f3921598157f/union-of-linestrings-and-reversing-direction?forum=sqlspatial

They seem to suggest at a possible solution about checking the end result, but it is not clear to me how to do that. It is hinted at in a linked thread that

The MultiLineString always represents the graph from the point which farthest from the origin point.

It is not clear to me exactly what this means, but I don’t think I can just assume the result of a UnionAggregate is always the reverse of what I want

If it is hard to know directional intent then I can add M measures where the direction should follow increasing M values.

Assuming I have a method for reversing the points in line, how would I go about solving for this?

I found a function that mimics for STUnion for added support for Z and M measure: http://www.spatialdbadvisor.com/files/SQLServer.html#robo48 however it is noted that “their direction could change (eg Start/Start Point relationship).”, which is what I want to avoid.


Get this bounty!!!