feature: measure elevation profile

[johnnyblasta]

Closes #1567

Add this config option to measure control to point to a Origoserver that adds height to the geometry:

"options": {
        "elevationProfileURL": "http://localhost:3001/origoserver/lm/elevation"
}

Use this PR origo-map/origo-server#120 for setting height.

[tonnyandersson]

I think there's a plugin for this. Well, not quite, but kinda.

[johnnyblasta]

I think there's a plugin for this. Well, not quite, but kinda.

Yes, I'm aware of the plugin, but there has to be a configured layer with heights on that one and since this uses the Lantmäteriet Höjd Direkt service to add the heights we thought it were appropiate to have it in measure control.

[tonnyandersson]

I'm sure the elevation profile plugin can be modified to make use of the LM service. There's even an open issue on this very subject.

The thing is, this feature uses the ol-ext library, which is why the elevation profile plugin was created as a plugin and not a built-in feature. Same thing with the multiselect plugin, which uses the turf.js library.

[johnnyblasta]

I'm sure the elevation profile plugin can be modified to make use of the LM service. There's even an open issue on this very subject.

Then it has to be hooked on too some draw function also to get an arbitrarily drawn objects elevation profile, which I guess could be done somehow.

The thing is, this feature uses the ol-ext library, which is why the elevation profile plugin was created as a plugin and not a built-in feature. Same thing with the multiselect plugin, which uses the turf.js library.

Hm, is there a way to build it without including the external library and those that want to use the function includes it from the html file?

[tonnyandersson]

Hm, is there a way to build it without including the external library and those that want to use the function includes it from the html file?

Well, I guess there is, technically. But that's bad design. Like, really bad.

I guess this raises a bunch of philosophical questions regarding plugins and non-essential external libraries that needs to be discussed in a larger forum. To me, it's a no-brainer. But this is not a dictatorship. Sadly. :)

[johnnyblasta]

Moved showing of elevation profile to plugin to lose dependency on ol-ext in Origo.
New version of plugin is on the way.

[tonnyandersson]

So, here's my opinion.

I'm not asking you to make any changes now because I think more project members need to weigh in on this.

But.

In my opinion, plugins should be more or less self-contained, i.e. all logic, styling etc. associated with the plugin should be kept in the plugin's own repository. Sometimes it's necessary to add minor helper functions and things like that to the core, and that's fine, but other that that, the core should be kept clean.

Right now it looks like half (or more) of the elevation profile logic is placed in the measure control, and the rest of the logic is placed in the elevation profile plugin repo. This means there are large chunks of code in the core that does absolutely nothing unless you download and install the appropriate plugin. Will this lead to the Armageddon and the end of the world? No. But it may make code maintenance a whole lot harder with bits and pieces of code scattered across multiple repos.

I think it would be a better idea to upgrade the current elevation profile plugin by adding the option to use the LM elevation service. And why not add a stand-alone point-and-click type tool to it? That way it could potentially work with measure, draw and regular features. Or perhaps something completely different, I don't know.

Basically, my point is that we must try to maintain a coherent core structure and not just throw things in there because it's easy and it works. It's messy enough as it is.