-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GeoJSON Vertex Ordering #4
Comments
@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
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 |
Hi will check into that! I was just using the following:
and will try:
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 ( |
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
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.
The text was updated successfully, but these errors were encountered: