Add validity rules for polygons in locations.geojson

[leonardehrenfried]

Problem

When you have self-intersecting polygons in locations.geojson, there can be situations where routing engines cannot decide if a point is inside or outside of it:

Yesterday I asked in Slack about validity rules of flex polygons and received positive responses about tightening them.

For this reason, I'm opening this PR to gather more feedback and eventually call a vote.

Rather than spelling out all the ways in which polygons can be invalid or just mentioning self-intersecting ones, I opted instead to reference another standard that has been battle hardened and has a very good description of of validity rules for polygons.

cc @miles-grant-ibigroup @m-mcqueen @LeoFrachet

[skinkie]

+1 I don't even think this should be a vote.

[westontrillium]

(Copying my Slack comments here)

I would support adding this kind of restriction. Feeds with these polygons are in effect already “invalid” if they have impossible polygons. This wouldn’t be so much introducing a backwards compatibility-breaking restriction as it would be codifying a requirement that already exists implicitly. It makes sense to make it explicit so that it can be easily enforced since there are already several examples of these kind of errors out in the wild.

I was not previously familiar with the OpenGIS Simple Features Specification, but it seems to account for everything we need (including valid multipolygons). I encourage interested parties to do a more thorough review of that document before casting a vote for due diligence's sake. I'll be particularly looking for any cases where it would impose unwanted restrictions excluding use cases we've actually encountered (unlikely, but again, due diligence 🙂).

[leonardehrenfried]

👍

You can start your due diligence in the GeoJSON RFC which refers to this spec in its introduction and says it implements its data model.

It's also the data model for the very popular software packages PostGIS and Java Topology Suite (JTS). It's where names like Linestring, Polygon, MultiPolygon come from.

[LeoFrachet]

Thanks @leonardehrenfried for working on that and coming with some great reference. 🎉

Looks great on my side!

[westontrillium]

Do we need anymore discussion on this proposal? Should a vote be opened?

[leonardehrenfried]

A vote can be opened but I'm currently on holiday. @tzujenchanmbd @eliasmbd Could you be so kind and start the formalities of the voting process?

[eliasmbd]

As per request of @leonardehrenfried, I open the vote for this proposal

The vote requirements are as follow:

• Vote lasts the minimum period sufficient to cover 14 full calendar days. Vote ends at 23:59:59 UTC.
• Anyone is allowed to vote yes/no in a form of comment to the pull request, and votes can be changed until the end of the voting period. If a voter changes her vote, it is recommended to do it by updating the original vote comment by striking through the vote and writing the new vote.
• Votes before the start of the voting period are not considered.
• The proposal is accepted if there is a unanimous consensus yes with at least 3 votes

The voting period ends on Wednesday, September 11, 2024 at 23:59:59 UTC.

Happy voting!

[westontrillium]

+1 Trillium

[evansiroky]

+1 Caltrans

[gcamp]

+1 Transit

[leonardehrenfried]

@miles-grant-ibigroup @LeoFrachet You indicated approval before the voting started but would you be so kind as to give your unambiguous +1?

[LeoFrachet]

With pleasure!

+1 from Spare.

[miles-grant-ibigroup]

+1 Arcadis

[PodarisEng]

+1 Podaris

[eliasmbd]

The voting period has ended on Wednesday, September 11, 2024 at 23:59:59 UTC.

The result is:
+1 Trillium
+1 Caltrans
+1 Transit
+1 Spare
+1 Arcadis
+1 Podaris

@leonardehrenfried Congratulations the vote has passed with 6 votes for and 0 against.