Unsquish after #600

[lnicola]

• I agree to follow the project's code of conduct.
• I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

---

[JmsPae]

Also some minor errors in CHANGELOG.md;

• Line 19: get_point_vecx now returns usize, not i32
• Line 38: Redundant comma and space

[lnicola]

I guess get_point_vec should be called get_points now?

[lnicola]

I rephrased this, since it wasn't exactly correct (MultiPoint has points, for example).

[lnicola]

r? @JmsPae

(that's a review request, I can't pick you from the reviewers box)

[JmsPae]

No complaints here.

[JmsPae]

Upon some reflection, however, it was weird for get_points to append to a vec instead of overwriting it, but that could be addressed elsewhere if you just want to push this PR out.

[lnicola]

I thought so too, but it matches e.g. BufRead::read_line and Read::read_to_end, so at least there's some prior art. I even appreciated your diligence there :-).

[JmsPae]

Thank you!

I'd prefer if it follows the original lib's behavior and overwrites the vec, but whether or not you want to fix it here or want to keep it is up to you. (I'm scheming for a switch over to OGR_G_GetPoints so i suppose you really don't have to)

[lnicola]

I think appending makes sense in some cases (maybe you're producing something like WKB or another compact format), so I wouldn't mind keeping it for now.

[JmsPae]

I think appending makes sense in some cases (maybe you're producing something like WKB or another compact format), so I wouldn't mind keeping it for now.

Yea, I suppose if we end up 'fixing' it back to overwriting the vec then we can always add another method for appends.