Enable lat/lon coordinates

[bast]

Collecting some notes/reading material:

• https://sgp1.digitaloceanspaces.com/proletarian-library/books/5cc63c78dc09ee09864293f66e2716e2.pdf

[district10]

Maybe just use https://github.com/mapbox/cheap-ruler to convert lon/lat to local XYZ (ENU) coordinates reference system. (I did similar thing here)

Did you benchmarked your point-in-polygon.

I used to use point-in-polygon test from GEOS/shapely, but found out that matplotlib version of this is generally faster.

[bast]

About the lat/lon: I think it is not so simple because it's not just about converting coordinates but then the question whether a point is on the one side or the other side of a "line" changes since lines become "curved".

About the benchmarking: I ran benchmarks but did not compare much with other codes. What is the size of the system that you have used to benchmark GEOS/shapely? (how many polygons, how many points)

[district10]

"line" changes since lines become "curved".

Seems you are right. I thought point-in-polygon is stable before/after converting WGS84 to ENU, because lon: east, lat:north is bilinear in local spatial reference system (under my typical use case of polygon as an area of highway ramp, intersection, crossover).

Yeah, when your use cases involves bigger area (1000km+ maybe), you can't just choose one ENU (or latitude, like cheap-ruler did).

how many polygons, how many points

Benchmarking is tricky, I created some random points (10,000) and random polygons (30% of whole area), tests show that matplotlib version is always 50x times faster (same result).

code here: https://fast-crossing.readthedocs.io/en/latest/point-in-polygon/

[bast]

I agree that for smaller distances your approach is fine but we use this for coastlines and there the distances can be significant.

The benchmarks are interesting. I use polygons for millions of points and typically thousands of polygons.

[district10]

I tested 1000,000 points: