updating @turf/inside or @turf/within from v4.1 to v4.2 causes "coordinates must only contain numbers" error #940
Comments
|
yes, looks exactly the same |
|
@barbalex please provide some data sample (I mean sample of |
|
The code running is: where {
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": {
"TPopId": 2146452464
},
"geometry": {
"type": "Point",
"coordinates": [
8.764992013425216,
47.3637963754393
]
}
},
{
"type": "Feature",
"properties": {
"TPopId": 2146452428
},
"geometry": {
"type": "Point",
"coordinates": [
8.692715305147914,
47.28269957982056
]
}
},
{
"type": "Feature",
"properties": {
"TPopId": 2146452583
},
"geometry": {
"type": "Point",
"coordinates": [
8.182694109987512,
47.811366689874944
]
}
}
]
}and {
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": {},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
8.670399,
47.253074
],
[
8.670399,
47.255754
],
[
8.67469,
47.255754
],
[
8.67469,
47.253074
],
[
8.670399,
47.253074
]
]
]
}
}
]
}Json created using console.save as explained here: https://stackoverflow.com/a/19818659/712005 |
|
Hi @barbalex
I'm not sure if there was a change as to how this worked prior to 4.2, @DenisCarriere may know...?
|
|
@barbalex following what @rowanwins said, I don't see any issue with your code and data for |
|
Grrrrr. My app is running several datasets through In v4.7.3 the function processing the dataset I gave you worked fine in this corrected version (which I used to extract the data): https://github.com/barbalex/apf2/blob/c478aeccde2b09d940a69d71b74064a30e37cfdb/src/modules/tpopIdsInsideFeatureCollection.js. The error occured at a different dataset. The reason was that I am using MobX and the The solution for me was to convert them back to pure objects using I am very sorry to have bugged you with this problem of mine. I can only hope that this issue may be helpful for someone else using MobX and stumbling on to the same problem. Thanks a lot for this great tool and the time you put into it. |
|
Arriving a little late to this discussion (as @barbalex) has closed the issue, but I noticed a similar issue as well (when I realized a previously functional web app broke following the most recent turf update). For simplicity of demonstration, I extracted the problematic code & JSON objects: in the zip file attached here, are "test_pois.geojson" and "test_buffer.geojson". Both conform to the documented format required for turf.within(). Performing a within (pois, buffer) yields: "Uncaught Error: No valid coordinates" And, similar to barbalex's situation, my code uses .within() multiple times. It still works for the other instances, but fails for the one case mentioned above. @stebogit @rowanwins I'm new to issues reporting on Github -- let me know if I should open a new issue for this. Thanks! |
|
Hey @corinnali I notice in your buffer.geojson there are a bunch of features where the geometry is null If I was a gambling man I'd hazard a guess and say this is causing the problem... We'll look into it further |
|
Hi @rowanwins -- your guess was spot on! When I added some checks in the code to filter out features with null geom, everything came back to life again. Thanks to your pointers, I think I know the real cause of this. This buffer object is actually a result of a turf.intersect(), which started returning features with null geom thanks to Fix #820. All's good now! Perhaps would help others if we add a note in the docs cautioning FeatureCollections that contains some features with null geoms for methods such as .within(). |
|
Thanks @corinnali for the info. |
|
Hey @stebogit Im not sure if we should add support for null geometries, that would potentially take us down a path of having to do that for every module. I think my preference would be to add a |
|
I see your point, it would probably take time to make sure null geometries are handled correctly by all modules, but in my understanding Turf aims to be as much as possible GeoJSON compliant, so erroring out on null geometries (which are technically valid geometries) is not good. Having said that, modules like |
MobX observable objects won't play nice with TurfJS modules, unfortunately there's no good solution for this other than the proposed solution to convert back to JS would be your best bet.
👍Your issue reporting is great! Thanks for submitting your comments 🤗
👎 Don't think there would be much value to develop this kind of module. We shouldn't cause extra iterations over FeatureCollections if it's not needed, it's better to leverage the callback methods in
A possible solution could be to add an extra optional property ( |
This happens in all versions between 4.2.0 and 4.6.0 (it seems that in npm other versions exist than on github).
It happens:
This is the module that runs when the error happens: https://github.com/barbalex/apf2/blob/75ad2a1efc2c57d006e52d93fda8eee1b6d6d9b7/src/modules/tpopIdsInsideFeatureCollection.js
I have checked the data generated for this action several times. There are multiple checks that make sure only valid numbers are passed.
This is the console message:
The text was updated successfully, but these errors were encountered: