Re: Solved! (was: Re^10: Geo Package files)

Good to hear it works now. It would be useful to have a generalised WKB reader (and writer) on CPAN.

WRT the midpoints - the centroid will work as a start. However, if your mid-point must correspond with a street address on the road then it is not too hard to find the mid-point along a series of vertices.

One approach is to convert the array of vertices to cumulative distances and then use a binary search to find the distance that is half the maximum (which is the last cumulative distance array element). It won't make much difference with small numbers of geometries but if you have many geometries with many vertices then it adds up as the average case will be of the order of (n+log(n)) calculations compared with 1.5n for a two pass search that exits when the half way point is found. (For 100,000 vertices this is ~100,011 compared with 150,000). There are binary search implementations on CPAN that will avoid the problems of implementing your own, two I have used are in List::MoreUtils and List::BinarySearch.

Edit - updated the n+log(n) value to use the natural log, and a typo.

Comment on Re: Solved! (was: Re^10: Geo Package files) Select or Download Code

Replies are listed 'Best First'.
Re^2: Solved! (was: Re^10: Geo Package files) by Bod (Parson) on Mar 11, 2022 at 23:57 UTC
It would be useful to have a generalised WKB reader (and writer) on CPAN. As I write this code, I shall bear in mind that a WKB decoder would be a useful addition to CPAN. However, WKB is much more extensive than the limited scope I am looking at so whatever I produce will be a limited version that will be useful to some people. Either to use as-is or to build upon. The first requirement I have from this USRN data is to find the nearest USRN to a given point. For that, the centre of the envelope is sufficient. In future, I will be wanting to plot the LineStrings so proper decoding will be needed but that's for another day.	[reply]
Re^3: Solved! (was: Re^10: Geo Package files) by swl (Parson) on Mar 12, 2022 at 02:08 UTC
Even a limited version would be a very useful thing. The seven types supported by GEOS would cover more than 90% of use cases (points, polylines and polygons, their multi-part variants and geometry collections).	[reply]
WKB Reader (was: Re^2: Solved! (was: Re^10: Geo Package files)) by Bod (Parson) on Dec 23, 2023 at 22:19 UTC
It would be useful to have a generalised WKB reader (and writer) on CPAN This has been swirling around in my mind for a little while now...certainly happy to have a stab at creating a WKB reader - not sure about the writer as that seems to be a whole extra layer or three of complexity. What I cannot envision is what sort of output a WKB reader would provide. In other words, what sort of Perl data structure would it read a WKB-encoded file into? Would an array of GEO::Point objects be the output one might expect?	[reply]
Re: WKB Reader (was: Re^2: Solved! (was: Re^10: Geo Package files)) by swl (Parson) on Dec 24, 2023 at 00:21 UTC
I have not checked closely but Geo::Point seems to be for geographic coordinates, so latitude and longitude and not projected coordinates such as UTM. (Edit: actually it does but it uses proj4 which is long deprecated). It also seems not to handle Z and M coordinates, and neither does the parent Geo::Shape class. For a single part polygon or polyline one just needs an array of coordinates (vertices), so an array of arrays would do. Maybe each vertex could be blessed into an array based object if that makes other things easier. Multipart features are collections of polygons, polylines and points (one type per feature) so would be a different object class. Then there are geometry collections which can be a mix of feature types. e.g. http://postgis.net/workshops/postgis-intro/geometries.html	[reply]


Problems? Is your data what you think it is?
	PerlMonks