Open mezcalhead opened 4 years ago
@mezcalhead I will look into that, though it might take some time. But is there any reason that you aren't using the GDAL GeoJSON output_type
's? For example:
cell_output_type GDAL
cell_output_gdal_format GeoJSON
cell_output_file_name theCells.geojson
I have a high level of confidence that the GDAL GeoJSON output is standards compliant, and will remain so as the standards evolve. I was planning on deprecating the old GeoJSON for point_output_type
and cell_output_type
in favor of the GDAL versions in the next release of DGGRID.
Hi will check into that! I was just using the following:
cell_output_type GEOJSON
and will try:
cell_output_type GDAL
cell_output_gdal_format GeoJSON
I should be able to confirm or provide feedback by end of next week. thanks.
@mezcalhead I realized my answer is incorrect; the vertex order is set before the GDAL output sees it; so I do need to verify that it is being set correctly and get back to you. Sorry for the confusion. Though I still recommend switching to the GDAL version of GeoJSON.
@mezcalhead I have verified that the GDAL GeoJSON polygons are output in CCW order. In the process I realized that the first vertex wasn't being repeated as the last vertex, as required. That is now fixed in the current version (7.05
).
that's great sahrk, because we discovered it wasn't closing either. perfect!
also thank you for confirming CCW. my lead dev noticed they weren't closing. Elastic still won't accept res 3 or 4 for a few of the polygons in the PlanetRisk grid, but if Elastic will load res 5, 6... i will be fine for now.
Sorry about the closure bug; I've become too reliant on visual checks; the cells looked fine in a grid :) . If you let me know cell IDs on the cells that elastic won't accept, and any feedback it's giving on why they aren't accepted, I could take a look if there is anything special about the geometry of those cells. A lot of moving parts changed internally in DGGRID version 7.0, so there may still be other bugs lurking.
While trying to index polygons to Elasticsearch, I managed to log some of the documents that raised exceptions and they all have something in common: they're all ambiguous (e.g. cross the 180th meridian) and they seem to self-intersect at some point.
If I paste the following snippet to https://geojson.io, I can see that all of these polygons self-intersect and I get exceptions regardless of orientation, even though the default rule is right-hand (counterclockwise outer ring, clockwise inner ring).
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": {
"name": "FailedPolygon2"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
-168.75000000075937,
68.56262182758454
],
[
171.40919217178978,
59.995718852251684
],
[
-178.0565334877783,
49.5605292364068
],
[
-159.4434665105249,
49.56052923437555
],
[
-148.90919217162116,
59.995718847010586
],
[
-168.75000000075937,
68.56262182758454
]
]
]
}
},
{
"type": "Feature",
"properties": {
"name": "FailedPolygon2"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
11.250000001204288,
79.18997812078811
],
[
73.76559829644516,
78.08590585137581
],
[
128.7344016991396,
78.08590585195984
],
[
-168.75000000123785,
79.18997811839556
],
[
-106.23440170396226,
78.08590585140351
],
[
-51.26559830126784,
78.08590585193215
],
[
11.250000001204288,
79.18997812078811
]
]
]
}
},
{
"type": "Feature",
"properties": {
"name": "FailedPolygon2"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
-168.74999999876215,
79.1899781206542
],
[
128.7344016991396,
78.08590585195984
],
[
130.8314512419392,
65.86766210914863
],
[
150.7450921238266,
58.49753175508607
],
[
171.4091921670018,
59.99571884704776
],
[
-168.7499999992406,
68.5626218298948
],
[
-168.74999999876215,
79.1899781206542
]
]
]
}
},
{
"type": "Feature",
"properties": {
"name": "FailedPolygon2"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
171.4091921670018,
59.99571884704776
],
[
150.7450921238266,
58.49753175508607
],
[
147.99285787283387,
46.84104063326802
],
[
160.25204620388084,
38.528489138913606
],
[
175.35710324802992,
40.005481777054655
],
[
-178.0565334877783,
49.5605292364068
],
[
171.4091921670018,
59.99571884704776
]
]
]
}
},
{
"type": "Feature",
"properties": {
"name": "FailedPolygon2"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
73.76559830086043,
-78.08590585195984
],
[
11.249999998762139,
-79.1899781206542
],
[
-51.26559829603775,
-78.08590585140351
],
[
-106.23440169873217,
-78.08590585193215
],
[
-168.74999999879572,
-79.18997811852945
],
[
128.73440170355485,
-78.08590585137581
],
[
73.76559830086043,
-78.08590585195984
]
]
]
}
},
{
"type": "Feature",
"properties": {
"name": "FailedPolygon"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
175.35710324773262,
40.005481777893294
],
[
160.25204620388084,
38.528489138913606
],
[
156.919868964176,
27.95281340607203
],
[
166.26502974816566,
19.839930894362748
],
[
178.77923453481165,
20.82743443679779
],
[
-175.86444948597156,
30.64478059589871
],
[
175.35710324773262,
40.005481777893294
]
]
]
}
}
]
}
Possible solution: have the points across the 180th meridian extrapolate it (longitude > 180).
This works fine both in https://geojson.io and Elasticsearch:
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": {
"name": "OkayPolygon"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[ 175.35710324773262, 40.005481777893294 ],
[ 160.25204620388084, 38.528489138913606 ],
[ 156.919868964176, 27.95281340607203 ],
[ 166.26502974816566, 19.839930894362748 ],
[ 178.77923453481165, 20.82743443679779 ],
[ 187.86444948597156, 30.64478059589871 ],
[ 175.35710324773262, 40.005481777893294 ]
]
]
}
}
]
}
Unfortunately I think it's more complicated than that. If you use all positive longitudes (0-360 degrees) then a similar problem occurs crossing the prime meridian (I verified this in geojson.io), so for polygons containing such an edge you have to use negative longitudes west of the prime meridian. Any polygon that contains the north or south pole will have edges that cross both the anti-meridian (requiring only positive longitudes be used) and the prime meridian (which requires that negative and positive longitudes be used), which is a contradiction. I can't get geojoson.io to draw pole-containing polygons, and I'm not sure if Elasticsearch can handle them (I'm betting "no"), but the existence of such polygons means that there is no general solution possible. This is a problem inherent in using DGGS with what are essentially 2D systems. DGGRID could fix anti-meridian crossings in non-polar polygons, but it would have to check for polar polygons (doable but I don't think cheap) and handle them specially.
@mezcalhead I finally implemented the fix @ultimagriever suggested above, giving you the option to handle cells that straddle the anti-meridian by outputting all positive (or all negative) longitudes for their vertexes. Looks like exactly one year from when you opened the issue, sorry!
See examples/planetRiskGridNoWrap
for an example metafile using the new parameters. And here is the relevant section from the updated manual:
By default, each longitude value is output in the range -180.0
to 180.0 degrees. When visualized using a 2D program, cells that
straddle the anti-meridian can appear to “wrap” across the image.
The choice parameter longitude_wrap_mode can be used to force the
output vertex longitudes of such cells to be entirely positive
(value UNWRAP_EAST), entirely negative (value UNWRAP_WEST), or to
follow the default behavior (the default value WRAP). Setting the
boolean parameter unwrap_points to TRUE (the default value) forces
each output cell center point to follow the associated cell when
it is unwrapped, so that cells and points will display together in
a 2D program.
This still doesn’t quite fix the issue with cells that contain the poles, but I think a more robust fix would have to happen inside the elasticsearch data structure.
Hi sahrk, I am looking for confirmation that the vertex ordering is counterclockwise when using the GEOJSON output parameter.
WKT does not enforce a specific order for vertices thus ambiguous polygons around the dateline and poles are possible BUT GeoJSON mandates that the outer polygon must be counterclockwise and interior shapes must be clockwise, which agrees with the Open Geospatial Consortium (OGC) Simple Feature Access specification for vertex ordering. This is very important for applications like ElasticSearch. Thanks.