grid_map
grid_map copied to clipboard
ANYbotics
When combining layers, `nan`s ruin everything
In a previous application I was working on, I combined layers of information after moving the map. Since the move() function sets unknown data to nan, adding the layers together ruins the resultant data.
Would it be acceptable to open a PR to change the API to add in a parameter for the move function to specify what you would like your unknown data to be set to? I could have it default to std::nanf in the signature so the existing API would hold.
Hey @lucbettaieb, interesting idea. What would you set it to?
But out of my head, I would not advise to go in this direction, as you would have to update the check for validity at several places.
Adding on to @lucbettaieb's idea, would it be possible to specify this independently for each layer in the map. For some of my applications, every time I move the map I have to go fill in each layer with a default value to avoid the nan's and to make the layer consistent with my chosen representation.
@maximilianwulf In a previous application, I was trying to set the new cells to all 0.0, as they were representing a log odds. I already had to check for validity and nans at multiple places anyway.
@tbostic32 I believe that would be a bit trickier, but one could definitely do that with a function overload.
Would it be acceptable to open a PR to change the API to add in a parameter for the move function to specify what you would like your unknown data to be set to?
Coming back to that idea, it might actually make sense to have an overlaod move function that fills up empty space with a desired value. I would make sure that the original move function is untouched.
I believe that would be a bit trickier, but one could definitely do that with a function overload.
+1
@maximilianwulf
Coming back to that idea, it might actually make sense to have an overlaod move function that fills up empty space with a desired value. I would make sure that the original move function is untouched.
The original move function would just call the new one with std::nanf or something as the additional param. I think I've seen a similar design pattern elsewhere in your codebase, so I'm for it.