Define 3D intrinsic geometries (missing Z) - Elevation MAP

Using farmOS
1

Hi all,

Summary:
Is there an already implemented solution to define and/or get Z (elevation) from a WKT geometry?

Context:
We plan using farmOs as the GUI to define paths for our Ground Robot. To do so we are considerning creating “Land” assets, use the “Draw Line” feature to define the “way” and then use this information to tell robot what path to follow (Check image below)

image
image1594×793 136 KB

It is much more complex but tu simplify we thougth it would be a good idea to try to put constrains on the GUI so the user CAN’T draw paths with more than XX% of inclination and to do so we need Z values of the terrain. We found possible solution using for instance Google Maps Elevation api. Then we plan to develop on top of farmos-map the restrictions on how to create this “points” but before that we wanted to check if anyone faced this problem before and already created a similar solution.

Thank you so much for your time,

Dani

1 Like
2

Welcome to the forum @danpy! :smile:

That’s awesome! Please share progress in a dedicated forum topic, if you want! I’d be very interested to hear how it goes (and help if you run into any hurdles)!

Hmm not in the farmOS or farmOS-map UI, no. But I imagine that something could be implemented in a custom module! Very interesting set of questions to think through… :thinking:

For context, there are a few main pieces involved:

  1. farmOS has a geometry field on assets and logs that stores WKB (Well-known binary) in the database, and shows that as WKT (Well-known text) in the UI/API.

According to Wikipedia, WKT/WKB does support Z coordinates (TIL!):

Coordinates for geometries may be 2D (x, y), 3D (x, y, z), 4D (x, y, z, m) with an m value that is part of a linear referencing system or 2D with an m value (x, y, m). Three-dimensional geometries are designated by a “Z” after the geometry type and geometries with a linear referencing system have an “M” after the geometry type.

The question is: does the farmOS Geofield module support that? Or will it fail validation? That would be the first thing to test. If you have some 3D WKT you can paste it into the textarea below the map when you are editing a log and then save the log. That will run validation and show you an error message if it fails.

If it fails, then the next step would be to open an issue with that module and help to add support for it. I’d be happy to help with that process if we need to.

If it succeeds, great! But… that doesn’t mean it will work in the map.

  1. The visualization of the data is handled by farmOS-map which is a separate project from farmOS (which farmOS uses).

farmOS-map is built on OpenLayers, and provides some customized behaviors on top of it for farm management apps (like farmOS) to use. So if 3D WKT fails to render properly in the map, we may need to make some adjustments to add support for that. Right now I can tell you it was all built for 2D rendering, so there isn’t any special logic in place to handle 3D. Maybe it will “just work”, but if so then it will still appear as 2D in the map. And I would be worried about the drawing controls “flattening” the geometry if you use them to draw/edit.

The drawing controls are a custom behavior that we built for farmOS-map. So that could be a good starting place to study and understand how they work, and think through what might be needed to support 3D drawing. We’re getting to the edge of my expertise here… but I’d love to help think about it! :slight_smile:

  1. It might be worth creating a custom farmOS module to experiment with all of this. Modules can add/modify farmOS-map behaviors inside farmOS.

farmOS-map behaviors are written in JavaScript. If you want to hop into the farmOS chat or one of the dev calls we can get you up and running with a dev environment to experiment in.

Makes sense, and a great idea. Also a challenging one. :slight_smile:

Looking forward to seeing how this evolves!

2 Likes
3

Very cool topic!

I thought about working with elevations a long time back when I was moving data over from QGIS, but for my use-case it wasn’t worth overcoming the hurdles.

There are some cool things one could do with elevation connected to farming though. e.g.

  • Detect which fields/areas are workable by which machinery
  • Model fertilizer run-off
  • Model flooding risk/mitigations
  • Optimize shading from tall crops
  • Etc
1 Like
4

@danpy I was thinking more about this…

Perhaps an easier way to accomplish what you want would be to NOT use 3D WKT at all… and let the user draw whatever they want… but then perform some validation on the 2D geometry to see if any of it crosses the XX% inclination threshold. If it does, then maybe a validation warning is displayed to the user, preventing them from saving the path.

You may also be able to change the color of sections of the line to indicate areas of the path that are out of bounds. I’m not sure how to do that in OpenLayers, but I’m sure there’s some way to accomplish it.

The key point is: you may not need to save Z coordinates of the path, or provide any kind of support for Z coordinates in the drawing functions themselves. That means you can use most of the farmOS-map and farmOS Geofield functionality as-is, and just save 2D paths.

The only thing you need the Z coordinate for is validation, so perhaps you can write an algorithm that looks up the elevation at all points along your 2D path of lat/lon coordinates and performs the necessary math to check if the path follows the rules you want.

Just a thought!

1 Like
5

Or, if your main goal is to prevent users from sending their robots up mountains, you could create a separate “boundary” land asset that is specific to the user’s farm, which is just a simple polygon that indicates “the robot cannot leave these boundaries”. Then you just need to check if any of the user-generated paths crossed those boundaries.

1 Like