fixes issue 90: unwanted conversion of depth from 'ft' to 'm' #102
Conversation
|
Thank you for this... I'm hesitating because I think there was a reason why I wanted metres... but I can't remember what it was. Maybe just not quite ready to dive into managing units everywhere. We should bite the bullet, as you say, and maybe even start using |
|
Yeah, I knew you must have had a reason for choosing to default to meters. I understand it will probably be quite a project to start handling units everywhere. I haven't heard of |
|
What about a keyword argument |
|
Just to say I haven't forgotten about this. I'm refactoring indexing and might come at this another way. |
…ic#102) The keyword argument index="existing", "m", "ft" is now implemented in Well.from_lasio (and passed through from Well.from_las). If index == "existing", depth_curve is created using las.index (per mharty3's PR). If index == "m" (the default, as index=None), depth_curve is created using las.depth_m. If index == "ft", depth_curve is created using las.depth_ft.
|
Matt, I wonder if you have thought about this particular change any more? I like @kinverarity1's idea of the keyword argument for the units of the index. It would make the default behavior of coercing the depth units to m explicit, and allow people who want to to work in feet, or really whatever crazy units they have in their las files :) ( @ThomasMGeo FYI) |
|
This was fixed by Kent |
Issue 90
When loading *.las files with the depth units in ft, the depth track was converted to m.
It looks like this is because in the
well.from_lasio()method sets thecurve_params['depth']from the laiso propertydepth_mrather thanindex. It seems to me that thefrom_lasio()method should read in whatever units are in the .las file rather than force any unit conversion.The lasio property index returns the first column of the las file.