location search: zoom to : tilt in 45°

[davidoesch]

When choosing a result in swisssearch, eg creux du van

the camera position is looking into nadir
https://mf-geoadmin3.dev.bgdi.ch/?dev3d=true&topic=geol&lang=fr&bgLayer=ch.swisstopo.pixelkarte-farbe&lon=6.73053&lat=46.93696&elevation=2509&heading=360.000&pitch=-90.000&catalogNodes=1786,1787

expecting result when in 3D: pitch 45° to north
https://mf-geoadmin3.dev.bgdi.ch/?dev3d=true&topic=geol&lang=fr&bgLayer=ch.swisstopo.pixelkarte-farbe&lon=6.73067&lat=46.92857&elevation=2151&heading=359.347&pitch=-45.000&catalogNodes=1786,1787

[oterral]

Maybe some results from searh should have a pitch and rotate properties to position the camera well.

[gjn]

Important for Thursday release.

[fredj]

Something like:

orientation: {
  pitch: Cesium.Math.toRadians(-50.0)
},

Should be added here: https://github.com/geoadmin/mf-geoadmin3/blob/master/src/components/map/MapService.js#L1546-L1555

[fredj]

And ol3-cesium version must be updated to have openlayers/ol-cesium#284

[cedricmoullet]

@fredj @gberaudo could you take care of the PR for the cesium update ?

[gberaudo]

Flying to a point or rectangle with a pitch is not supported by Cesium.
In order to implement it, we would need the height of the terrain at the destination point.

Would it be possible to add this height to the search data (attrs) we receive from the server?
https://mf-chsdi3.dev.bgdi.ch/ltteo/1447239069/rest/services/ech/SearchServer?searchText=lausanne&lang=de&type=locations_preview

An alternative would be to request the terrain tile containing the destination point and extract the height from it. But it would add a request and a delay.

@davidoesch, what should we do?

[gberaudo]

There is also the simple alternative of rotating around the destination point once the flyTo (nadir) is complete. Hard to say how it will feel for the user.

[davidoesch]

• and if we assume that the camera position is always at elevation=8000 after a fly to? would be enough as well (since we actually do not even know in 2d on which scale the locations are visible): here we can cover AVERS (the highest pop place in europe ) and ZURICH as well

-attributing this to search data: this will slow down the search or increase the index @gjn worth for the beta?

• rotating: google earth does this ....but the average user will loose orientation...

so solution: why not fly directly to destination and start rotating around the point until north orientation is reached?

[gjn]

We have a height service which is pretty fast (one of our fastest services) which could be used to determine height for a given service. See http://api3.geo.admin.ch/services/sdiservices.html#height. It's already used in mf-geoadmin3 in the contextpopup (https://github.com/geoadmin/mf-geoadmin3/blob/master/src/components/contextpopup/ContextPopupDirective.js#L131)

Note that this height service returns EPSG:21781 heights, not EPSG:4326 geoid heights though.

To put height in sphinx index is possible. The question is where to get the height information from. Maybe the original data is containing the height. If not, we need to calculate it (either once during the data import or everytime during the index creation). I suspect this to be quite heavy process. @ltclm Does the original location data contain height information?

[ltclm]

the swisssearch results have different data sources:

origin	source	height available
address	kobis.bfs.adr	no height information available
parcel	dritte.kantone.parzellen	no height information available
sn25	stopo.tlm.swissnames_sn25_und_tlm	available as attribute altitude for some data
gazetteer	stopo.tlm.swissnames3d_*	original data has 3d vertices, are flattened to 2d during fme import
gg25	stopo.tlm.swissboundaries_gemeinden_uebersetzt	no height information available
kantone	stopo.tlm.swissboundaries_kantone	no height information available
distrcit	stopo.tlm.swissboundaries_bezirke	no height information available
zipcode	stopo.vd.gabmo_plz	no height information available

as you can see, the data basis concerning 3d is incomplete.
i would propose to use the height service for this information.

[gjn]

Thanks @ltclm

@fredj Please try to use the height service in front-end. But be aware that these are not correct WGS84 heights as in our terrain (I think for this use case, it's safe to add 50 meters to get WGS84 approx. heights).

[fredj]

See also CesiumGS/cesium#2501